Publication and maintenance of the ICAO register of AMHS MD

ACP WGN03-WP27
ACP/SGN3 WP/2-3
01/08/17
AERONAUTICAL COMMUNICATIONS PANEL(ACP)
WORKING GROUP N - NETWORKING
SUBGROUP N3 – GROUND-GROUND APPLICATIONS
Montréal, April 2003 (SGN3 second meeting, WGN third meeting)
Agenda Item 3 : ATS Message Handling Services
Publication and Maintenance of the ICAO Register of AMHS MDs
Presented by Jean-Marc Vacher
Summary
The ICAO Secretariat has collected from ICAO Member States and Organizations information aimed at
building the “ICAO Register of AMHS MDs and addressing information”.
The goal of this paper is to propose a set of practices and procedures aimed at publication and
maintenance of the Register by the ICAO Secretariat, in co-operation with States continuing to provide upto-date information.
Publication and maintenance of the ICAO register of AMHS MD
ACP/WGN and SGN3 meetings (Montreal, May 2004)
TABLE OF CONTENTS
1
INTRODUCTION ................................................................................................................................................. 3
2
GOAL OF THE REGISTER ................................................................................................................................ 3
3
ROLE OF THE ICAO SECRETARIAT ............................................................................................................. 4
3.1
3.2
ROLE AND TASKS .............................................................................................................................................. 4
ISSUES TO BE CONSIDERED ............................................................................................................................... 4
4
REGISTER LIFECYCLE .................................................................................................................................... 5
5
EXAMPLES OF PUBLICATION FORMAT ..................................................................................................... 6
6
PROCEDURES FOR REGISTER MAINTENANCE........................................................................................ 7
7
RECOMMENDATIONS TO THE MEETING .................................................................................................. 8
8
APPENDIX A: DESCRIPTION OF PROCEDURES ........................................................................................ 9
8.1
SCHEDULE: GENERAL DESCRIPTION.................................................................................................................. 9
8.2
NOTATION ........................................................................................................................................................ 9
8.3
DESCRIPTION OF PROCEDURES........................................................................................................................ 11
8.3.1
Proposed update .................................................................................................................................... 11
8.3.2
Actors..................................................................................................................................................... 12
8.3.3
Purpose of the procedure ...................................................................................................................... 12
8.3.4
Description ............................................................................................................................................ 12
8.3.5
Trigger ................................................................................................................................................... 12
8.3.6
List of tasks ............................................................................................................................................ 13
8.3.7
Pro forma............................................................................................................................................... 13
REFERENCES
[1]
Manual of Technical Provisions for the Aeronautical Telecommunication Network (ATN), ICAO Doc 9705,
Third Edition - Sub-Volume III, Ground-Ground Applications
[2]
Manual of Technical Provisions for the Aeronautical Telecommunication Network (ATN), ICAO Doc 9705,
Third Edition - Sub-Volume VII, ATN Directory Services
[3]
Comprehensive ATN Manual (CAMAL), ICAO Document 9739, Second Edition (draft to be published)
[4]
RFC2849 The LDAP Data Interchange Format (LDIF) - Technical Specification
DGAC/STNA/81916147
WGN02-WP__ - SGN3 WP/2-3
2
01/08/17
Publication and maintenance of the ICAO register of AMHS MD
1
ACP/WGN and SGN3 meetings (Montreal, May 2004)
INTRODUCTION
The ICAO Secretariat has collected from ICAO Member States and Organizations information aimed at building the
“ICAO Register of AMHS MDs and addressing information”.
The ACP Working Group N and its subgroup N3 (ground applications) are committed to provide support to the ICAO
Secretariat in the establishment of this Register.
The goal of this paper is to make use of the collected information, and to propose a set of practices and procedures
aimed at publication and maintenance of the Register by the ICAO Secretariat, in co-operation with States continuing
to provide up-to-date information.
2
GOAL OF THE REGISTER
The goal of the Register is to facilitate the implementation of the ATS Message Handling System (AMHS), and the
migration from AFN/CIDIN to AMHS, through the official publication of up-to-date information needed to construct
the AMHS addresses of users in this new messaging system.
The published Register shall be the collection of addressing information provided by each ICAO Member State or
Organization. This will enable each State or Organization to determine the most appropriate addressing scheme and
address attributes for its own AMHS Management Domain, within the framework defined by the ICAO Manual of
Technical Provisions for the Aeronautical Telecommunications Network (Document 9705, Edition 3).
Each AMHS user or user system (ATS Message User Agent, AFTN/AMHS gateway) will construct a recipient AMHS
address using on the one hand the AFTN addressee indicator of the considered user, and on the other hand the
Register information to derive additional MHS address attributes (e.g. PRMD-name, organization-name).
It will be possible to use the published information in different ways:
-
human AMHS users will be able to directly use the published information to manually construct AMHS addresses
of the recipients to whom they wish to send AMHS messages. They will derive AMHS addresses from former
AFTN (or CIDIN) address indicators, based on detailed AMHS address attributes retrieved from the Register;
-
AMHS system operators and/or administrators will also be able to facilitate the above task for AMHS users, up to
the point of making it completely invisible if desired. For this purpose, the information published in the Register
may be entered in three main ATN/AMHS system categories belonging to each AMHS Management Domain:
 the preferred option is to enter the Register information into a Directory Server implementing the
Document 9705 requirements for Directory support of AMHS. The entered directory information may in
turn be retrieved by ATS Message User Agents or by AFTN/AMHS Gateways, e.g. using AFTN
addressee indicators as an input to construct AMHS addresses, as explained in the ICAO Comprehensive
ATN
Manual
(Document
9739
Edition
2,
draft
available
electronically
from
http://www.icao.int/anb/panels/atnp/misc/Doc9739/ , part 3, sections 6.2.1.5.10 to 6.2.1.5.20).
Other (i.e. non-ATN) directory systems may also be used for the same purpose provided that they also
facilitate the users’s task of constructing AMHS addresses;
 the same information may also be entered directly into ATS Message User Agents, to be used locally as
part of a “local address book”. However the task of maintaining the information up-to-date might be more
difficult than if it is stored in a central directory server as suggested above;
DGAC/STNA/81916147
WGN02-WP__ - SGN3 WP/2-3
3
01/08/17
Publication and maintenance of the ICAO register of AMHS MD
ACP/WGN and SGN3 meetings (Montreal, May 2004)
 this information is also required in AFTN/AMHS gateways, to populate the address look-up tables that
are an essential function of such gateways. Direct input of the Register information into the gateway lookup tables is possible, but retrieval from a Directory Server is also a valid option.
AMHS addresses are subject to changes, additions and withdrawals, as in any communication system. Therefore the
ICAO Register of AMHS MDs and addressing information should not be seen as a static document (or collection of
information), but rather as an evolutive database. This is particular true in the initial time of AMHS deployment, in
which changes are likely to occur, e.g. because of States migrating from an XF addressing scheme to a CAAS
addressing scheme when starting up operational AMHS services.
For each of these changes, the Register will have to be updated. It is suggested that the update frequency be in
accordance with the AIRAC cycle (every 28 days). This means that the information entered in AMHS systems, as
described above, will have to be updated accordingly.
3
ROLE OF THE ICAO SECRETARIAT
3.1
ROLE AND TASKS
The ICAO Secretariat should play a central role in the registration and publication process of the Register of AMHS
MDs and addressing information, in the same way as ICAO manages and publishes ICAO Location Indicators in
Document 79101. This would be in continuation with the work that was started with the publication of State Letter
referenced SP 54/1-03/39 concerning the establishment of the Register.
In general terms, the tasks that are required from the Secretariat in this area are the following:

collection of updates to the Register proposed by ICAO Member States,

verification of the proposed updates, to ensure that they are institutionally and technically valid,

input of the validated updates in the publishable, electronic version of the Register,

publication of the Register.
3.2
ISSUES TO BE CONSIDERED
The issues to be considered appear to be related to two main aspects, in conjunction with the fact that the Register
information is made available to Member States for operational purposes (creation of AMHS addresses by systems
contributing to the Aeronautical Fixed Service):

The management of the Register information represents a workload, which is likely to be low but cannot be
neglected. Cyclic publication dates will have to be met, in accordance with the lifecycle described in
section 4 below. This is critical to States because they will require up-to-date information, in accordance with
1
Doc 7910 is a good example of similar practice. It provides information of a similar nature to that included in the
Register. It is published by ICAO both in written and electronic format.
DGAC/STNA/81916147
WGN02-WP__ - SGN3 WP/2-3
4
01/08/17
Publication and maintenance of the ICAO register of AMHS MD
ACP/WGN and SGN3 meetings (Montreal, May 2004)
the AIRAC cycle, for proper message routing and delivery in the AMHS. It should be ensured that resources
are available so that publication date constraints can be met;

Integrity of Register information is essential, because of the operational nature of this addressing information.
Accidental or intentional corruption of the Register information would lead to AMHS dysfunctions. This
implies that exchanges between Member States and ICAO for the collection of updates are secured, either
technically or procedurally. This also implies that the ICAO publication medium for the Register be protected
from loss of integrity.
However, it should be noted that there is no “real-time” constraint associated with the Register update and publication,
given that the publication cycle is based on a 28 days period. Likewise, there is no strong availability constraint placed
on the Register publication. The service could incur e.g. maintenance disruptions of up to one day, provided that the
proposed cycle milestones described in section 4 are met.
Finally, the question of confidentiality of the Directory information should be discussed, particularly in view of the
intention to publish the Register on the ICAO web site.
4
REGISTER LIFECYCLE
The Register lifecycle, including the publication, utilization and maintenance processes is illustrated below.
DGAC/STNA/81916147
WGN02-WP__ - SGN3 WP/2-3
5
01/08/17
Publication and maintenance of the ICAO register of AMHS MD
ACP/WGN and SGN3 meetings (Montreal, May 2004)
PUBLICATION (by ICAO Secretariat)
AND UTILIZATION (by ATSOs / AMHS MDs)
PROCESS
MAINTENANCE
PROCESS
(by ICAO Secretariat)
(web) publication of
Register Version N
Storage of register
Engineering version N
input of Register
Version N information
in AMHS MDs’ systems
One full
AIRAC
Cycle
(28 days)
Reception of a
Reception ofofaa
Reception
proposedupdate
update
proposed
proposed update
to Version N
14 days
applicability of
Register Version N
AIRAC Date
Verification of
proposed updates
14 days
Updates
OK ?
Yes
No
Reject or coordination procedure
Entry/formatting of
validated updates
into Engineering version N
(web) publication of
Engineering Version N
as Register Version N+1
Figure 1: Lifecycle of the ICAO Register of AMHS MDs and addressing information
5
EXAMPLES OF PUBLICATION FORMAT
The tools and publication formats depend upon ICAO web publication standards. There is consequently no intention
to constrain such formats in this paper.
Nevertheless, principles can be established, and examples given, to show how the Register could be easily
implemented.
DGAC/STNA/81916147
WGN02-WP__ - SGN3 WP/2-3
6
01/08/17
Publication and maintenance of the ICAO register of AMHS MD
ACP/WGN and SGN3 meetings (Montreal, May 2004)
The Register needs to be posted on the ICAO web site in at least two, and ideally three forms:

an easily readable, user-friendly format for web publishing (e.g. HTML or LDAP browsing), and

an electronic file (or a set of) that can be imported into an AMHS system or a Directory system. LDIF
(LDAP Data Interchange Format, specified in RFC 2849) should be preferred for the latter. For importation
into other AMHS systems not including a standard directory function, formats such as tab-separated or CSV
text files could be easier to manage for systems not implementing LDAP.

ideally an ICAO-managed electronic directory database, X.500 or LDAP-based would also enable the
creation of a central Register consistent with States technical systems. However it is uncertain whether the
operation of such a database fits into the terms of reference of the ICAO Secretariat (or of another central
ICAO body).
Apart from recommending a directory format if feasible, the format used for storage of the Register internally to ICAO
is not a matter for recommendation. At present, the working file building the Register is a Microsoft Excel  folder, but
many other options can be envisaged. The only constraint is that creation of the formats for posting should be as
simple as possible. The Excel format meets this goal, with native HTML and CSV storage functions.
A software tool enabling export of data from the ICAO internal storage format to the LDIF format should be either
procured (preferably using freeware or Open Source software) or developed.
6
PROCEDURES FOR REGISTER MAINTENANCE
The procedures to be developed for the maintenance of the Register, in accordance with the lifecycle described above,
are listed in the table below.
The “initiator” is the entity that takes the initiative of starting the procedure. The “trigger” is the main event that
causes the procedure to be started. In some cases, calendar considerations related to the AIRAC cycle may also
participate in the triggering decision. Work optimization to perform the procedure on a set of proposed updates (rather
than on a single one as described below) may also be taken into consideration.
procedure name
proposed update
initiator
State
(AMHS
MD)
involved parties
description
originating State, action by which a State submits to
ICAO Secretariat ICAO a Register update reflecting an
intended amendment of the State’s
AMHS address space
trigger
State decision to amend
its AMHS address space
in
accordance
with
ICAO
Global
and
Regional practices
verification of a ICAO
proposed update
Secretariat
ICAO Secretariat verification by the ICAO Secretariat reception of proposed
that the amended address information update
is valid from an institutional and
technical viewpoint and can be
published
co-ordination
update
originating State, action by which the ICAO Secretariat
ICAO Secretariat co-ordinates with the submitting State
to modify the proposed update, so as
to make it valid in case of initial non-
of ICAO
Secretariat
DGAC/STNA/81916147
WGN02-WP__ - SGN3 WP/2-3
7
diagnostic by ICAO
Secretariat
that
the
initially proposed update
is invalid
01/08/17
Publication and maintenance of the ICAO register of AMHS MD
ACP/WGN and SGN3 meetings (Montreal, May 2004)
validity
entry of validated ICAO
update
Secretariat
ICAO Secretariat actual update by the ICAO Secretariat
of the Register engineering version
with the (validated) amended address
information provided by the State
diagnostic by ICAO
Secretariat
that
the
initially proposed update
is valid
web publication ICAO
of Register
Secretariat
ICAO Secretariat replacement by the ICAO Secretariat AIRAC date + 14 days
of the published version of the
Register with the engineering version
that includes the validated updates
input of Register AMHS
information
MDs
AMHS MDs
action by which AMHS MDs and publication of a Register
organizations operating Directory update
Systems in support of AMHS update
(but do not activate) the Register
information entered in their systems
application
of AMHS
Register update
MDs
AMHS MDs
activation of updated information in AIRAC date (next cycle)
operational AMHS systems
If this principle is agreed, each of these procedures should be described in a more detailed fashion. An example of
detailed description for the “proposed update” procedure is given in Appendix A to this paper.
7
RECOMMENDATIONS TO THE MEETING
The meeting is invited to provide comments, if any, about the publication principles and maintenance procedures
described above, and to recommend their adoption, after amendment as appropriate, by the ICAO Secretariat, for the
purpose of managing and operating the ICAO Register of AMHS MDs and addressing information.
The meeting is further invited to task SGN3 with the continuation of this work so as to provide the ICAO Secretariat
with a detailed set of procedures at the earliest opportunity.
DGAC/STNA/81916147
WGN02-WP__ - SGN3 WP/2-3
8
01/08/17
Publication and maintenance of the ICAO register of AMHS MD
8
ACP/WGN and SGN3 meetings (Montreal, May 2004)
APPENDIX A: DESCRIPTION OF PROCEDURES
Publication and Maintenance Procedures are sequences of operations which are specified in detail in this section and
which involve the use of the ICAO Register of AMHS MDs and addressing information, both in its officially webpublished version and in its engineering version maintained by the ICAO Secretariat..
8.1
SCHEDULE: GENERAL DESCRIPTION
Procedures are executed on a fixed schedule. This schedule is based on a fixed cycle of exactly 28 days, each cycle
being fixed by a so-called “AIRAC Date” which is always a Thursday. In this cycle, specified actions shall be
performed on given days or within a range of days.
The days in a cycle are numbered 1, 2, …, 27, 28. Day 28 is always an AIRAC Date – see Figure 2.
AIRAC Date

27 28 1 2 3
AIRAC Date

cycle n-1
15 16

27 28 1 2
cycle n

cycle n+1
Figure 2: Illustration of the 28-day cycle
8.2
NOTATION
Procedures are specified formally in Section 8.3. At present section 8.3 contains only the description of the “proposed
update” procedure, as an example, but it is intended to complement it with other descriptions. This section describes
the notation used for the specifications.
A procedure is a single action or a set of actions performing a well-defined task which has a unique starting and a
unique end point.
An actor is an organization involved in the procedure.
A task is a unit of work performed by an actor.
A trigger is an event which causes an action to be started, e.g. a fixed time, an external event or an event created by
another procedure.
A procedure description consists of the following parts:
-
a graphic defining the elements of the procedure,
DGAC/STNA/81916147
WGN02-WP__ - SGN3 WP/2-3
9
01/08/17
Publication and maintenance of the ICAO register of AMHS MD
-
a list of the actors,
-
a description of the purpose of the procedure,
-
a verbal description of the procedure,
-
a list of triggers,
-
a list of tasks and decisions and
-
a set of proforma (where appropriate).
ACP/WGN and SGN3 meetings (Montreal, May 2004)
The following additional elements are used in the procedure definition:
A delay is a scheduled time period between the commencement of two sequential actions.
In a decision the operator shall select among alternatives according to given criteria.
END indicates the end of the procedure.
A Goto, e.g. Goto x, is an unconditional jump to the indicated connector in another part of the graphical description.
Figure 3 illustrates the use of these graphic elements.
trigger
action
delay
END
terminate
decision
continue
goto
x
Figure 3: Example of graphical notation used to specify procedures
DGAC/STNA/81916147
WGN02-WP__ - SGN3 WP/2-3
10
01/08/17
Publication and maintenance of the ICAO register of AMHS MD
8.3
8.3.1
ACP/WGN and SGN3 meetings (Montreal, May 2004)
DESCRIPTION OF PROCEDURES
Proposed update
decision to amend
AMHS addressing
space
internal specification of
new addressing scheme
retrieve update
submission form from
ICAO web site
prepare update
submission forms
wait publication of
Version N (day 1)
check applicability of
update to Version N
securely send proposed
update to ICAO
Secretariat before day 14
END
DGAC/STNA/81916147
WGN02-WP__ - SGN3 WP/2-3
11
01/08/17
Publication and maintenance of the ICAO register of AMHS MD
8.3.2
ACP/WGN and SGN3 meetings (Montreal, May 2004)
Actors
There are two actors involved in the “proposed update” procedure:

the single active actor of the “proposed update” procedure is the State / ATSO implementing an AMHS MD
and willing to amend its AMHS address space,

the ICAO Secretariat is present as a passive actor, being the recipient of the proposed update developed by
the ATSO.
8.3.3
Purpose of the procedure
The purpose of this procedure is to provide a framework for the submission of an update to the address space of an
AMHS MD, to be applicable within one AIRAC cycle from submitting the update to ICAO. This means that the
update refers to Version N of the Register, and is applicable from the applicability date of Version N+1.
Potential updates include:

the modification of the PRMD-name used by the considered AMHS MD (this should be as unfrequent as
possible since PRMD-names as required to be stable);

modification of the addressing scheme selection (from XF to CAAS – recommended) and from CAAS to XF
(not recommended);

modification of the CAAS detailed table;

addition of an entry in the Register to deal with specific cases (e.g. Kosovo recently);

deletion of an entry in the Register (this is unlikely to happen but it should still be envisaged for efficient
Register maintenance).
8.3.4
Description
Upon the decision to amend the AMHS address space of a State / ATSO, the specification of the amended addressing
scheme is developed by the staff in charge of managing the considered AMHS MD. Changes in the information
already published by ICAO as part of the Register version currently published are specifically identified, and the
update is formulated using a submission form provided by ICAO (retrieved from the ICAO web site).
Upon publication of Version N of the Register, the proposed update (if prepared in advance) is checked for
applicability before being submitted. This is to make sure that changes between Version N-1 (available when the
update was being prepared) and Version N (to which the update shall apply) do not compromise the proposed update.
After this verification the proposed update is formally sent to the ICAO Secretariat before day 14 following the
publication of Version N. Security measures must guarantee the integrity of the proposed update transmission from the
State / ATSO to ICAO.
8.3.5
Trigger
The trigger for the “proposed update” procedure is the decision to amend the AMHS address space of the AMHS MD
implemented (or to be implemented) by a State / ATSO. Such a decision may result from internal (e.g. MD-topology
DGAC/STNA/81916147
WGN02-WP__ - SGN3 WP/2-3
12
01/08/17
Publication and maintenance of the ICAO register of AMHS MD
ACP/WGN and SGN3 meetings (Montreal, May 2004)
reorganization) or external (e.g. ICAO Regional decision for a new system being operationally started) events. The
identification of such events is beyond the scope of this procedure.
8.3.6
List of tasks
1.
internal specification of new addressing scheme. The details of this task are a matter local to the considered
State / ATSO. This task must be performed at any time between the trigger and at the latest 29 days (one
AIRAC cycle + one day) before the intended applicability of the new scheme, as part of Register Version
N+1;
2.
retrieve update submission form from ICAO web site. [Add URL]. This task should be performed at any time
between the trigger and the submission of the proposed update;
3.
prepare update submission forms. This task consists in entering in the update form retrieved from ICAO the
intended changes specified as part of task 1 above. It must be performed at any time between completion of
task 1 and at the latest 29 days (one AIRAC cycle + one day) before the intended applicability of the new
scheme, as part of Register Version N+1;
4.
wait publication of Register Version N. This task is a passive self-explanatory task;
5.
check applicability of update to Version N. This is in case the proposed update has been prepared in tasks 1
and 3 upon the basis of the published ICAO Version N-1 (or earlier) of the Register. In this case official
changes may have been made between Version N-1 and Version N, and it is necessary to check that they do
not compromise the proposed update. This task must be performed between publication of Version N and the
submission of the proposed update, occurring at the latest 29 days before the intended applicability of the
update;
6.
securely send proposed update to ICAO. This must be performed between day 1 of publication of Version N
and day 14 after this publication.
8.3.7
Pro forma
[to be developed on the basis of the pro forma attached to State Letter referenced SP 54/1-03/39 concerning the
establishment of the Register]
DGAC/STNA/81916147
WGN02-WP__ - SGN3 WP/2-3
13
01/08/17