ACP SGN3 WP ______
14 May 2004
AERONAUTICAL COMMUNICATIONS PANEL (ACP)
WORKING GROUP N (NETWORKING) – 3RD MEETING
Montréal (Canada), 19th May – 28th May 2004
Comments on ACP WGN02-WP14 – AMHS Implementation Profiles
Presented by EUROCONTROL
Summary
ACP WGN02-WP14 – AMHS Implementation Profiles presents an initial view of sub-setting rules for
AMHS.
In the meantime, at least one important requirement for messages carrying Binary Body Part Types
has become evident (the WMO BUFR File formats). It would therefore seem that the requirement to
carry binary data in messages is a high priority. The AMHS Implementation Profiles paper suggests
that support for BBP is dependent on the Directory and the IPM Heading Extensions functions. This
paper re-examines the rationale for these dependencies, and suggests a simpler structuring.
This paper also provides comments and suggestions on the structure and purpose of the
Implementation Profiles document.
Comments onACP WGN02-WP14 = AMHS Implementation Profiles
Ref : ///
TABLE OF CONTENTS
1.
Introduction .....................................................................................................................................1
1.1
References ................................................................................................................................1
1.2
Abbreviations ............................................................................................................................1
2.
Justification for DIR to support BBP ...............................................................................................1
3.
Justification for IHE to support BBP ...............................................................................................1
4.
Specifying Basic AMHS + BBP and DIR ........................................................................................2
5.
A minimum Global Profile ...............................................................................................................2
6.
Overall Purpose of the Document ..................................................................................................2
7.
6.1
Footnote 1 – ‘Functional Units’ .................................................................................................2
6.2
Description of the paper’s intention and use .............................................................................3
6.3
Directory Functions ...................................................................................................................4
Recommendations .........................................................................................................................4
Version: 1.0
Date: 14 May 2004
Page: ii
Comments onACP WGN02-WP14 = AMHS Implementation Profiles
Ref : ///
1.
INTRODUCTION
The AMHS Implementation Profiles paper [1] defines a set of sub-setting rules for AMHS
Regional Implementation Profiles. However, a number of overall comments are made in
this paper on its purpose, structure and content:
1.1

The purpose of the sub-setting rules should be clarified – in particular whether the
profile applies to the overall service offered by and within a region, or whether the
profile applies to particular systems (procured) to support an overall regional AMHS
service;

The need for the DIR (MHS Use of Directory) and IHE (IPM Heading Extensions)
functions to support Binary Body Part (BBP) messages (e.g. containing Bilaterally
Defined, File Transfer, Extended body parts). The rationale for both DIR and IHE
should be re-examined and the dependencies of BBP on DIR and IHE should be
removed to allow much simpler means of conveying BBP;

The profile should also suggest a ‘Global Minimum’ AMHS Functional Subset that all
regions should support as a minimum.
References
ACP WGN02-WP14 – AMHS Implementation Profiles
[1]
1.2
Abbreviations
BBP
DIR
IHE
2.
Binary Body Part
MHS Use Of Directory Functional Group
IPM Heading Extensions Functional Group
JUSTIFICATION FOR DIR TO SUPPORT BBP
The document currently implies that support for BBP is dependent on the DIR Functional
Group. The only justification for this is that the originator, using the directory, can
determine whether the recipient can actually take delivery of a BBP message.
However, this seems not to be necessary:

There are other mechanisms that could be used to support this (including offline or
local directories and bilateral agreements which do not use the MHS use of Directory
Functional Group);

If an originator does send a BBP to a recipient whose UA cannot process it, then
either the MTS will cause non-delivery of the message or the recipient’s UA can
generate a Non-Receipt Notification.
In conclusion, it is suggested that the dependency of BBP on the DIR functional Group
should be removed.
3.
JUSTIFICATION FOR IHE TO SUPPORT BBP
The original justifications for the IHE functions were:
1. To ‘clean up’ the mapping between the AFTN envelope and the IPM Heading.
Without IHE, important AFTN heading fields are mapped as text into the IPM text
Body Part. With IHE, these fields are mapped into IPM Heading Fields defined in the
Business Class IPM Functional Group, and are therefore more readily processable;
2. To provide an adequate mapping between AMHS messages and CIDIN messages
(primarily for OPMET).
Version: 1.0
Date: 14 May 2004
Page: 1
Comments onACP WGN02-WP14 = AMHS Implementation Profiles
Ref : ///
With regard to (1) above, this does not seem a strong requirement to mandate IHE for
BBP since AMHS can work without it. It also introduces some difficulties in management
(including the suggestion that DIR is required to support it), and AFTN<>AMHS interworking is quite capable of operating without IHE.
With regards to (2) above, recent decisions to abandon plans to implement gateways
between CIDIN and AMHS (which was intended to carry OPMET Data) means that IHE is
no longer required to support that mapping.
The conclusion is that IHE should not be mandated for support of BBP.
4.
SPECIFYING BASIC AMHS + BBP AND DIR
The arguments given in sections 3 and 4 above suggest that both DIR and IHE can be
reclassified as optional for the support of BBP. This seems to be a potentially expensive
overhead for the initial implementation of AMHS. It is therefore suggested that BBP
should not be made dependent on DIR or IHE, and that a new subset of Basic + BBP be
introduced. Also, a further subset of Basic + BBP + DIR seems to be useful.
In fact, following the suggestions in 3 and 4 above simplifies the whole structure, and
makes the different functions much more independent of each other.
5.
A MINIMUM GLOBAL PROFILE
Given the potential importance of BBP, and the optional nature of DIR and IHE with
respect to BBP, it is worthwhile defining a new Global Minimum Profile to be:
Basic Service + BBP.
6.
OVERALL PURPOSE OF THE DOCUMENT
The relationship between this document [1] and the AMHS regional profiles should be
made clearer. The document should therefore be modified to indicate that it specifies a
number of technically useful increments of AMHS functionality that each region might
consider as a basis for development of its own internal procurement profiles, and that the
document’s intention is to encourage co-ordination of profiles among different regions.
Thus the document becomes a list of technically useful subsets from which each region
can select its own functionality whilst remaining in step with other regions. The following
sections elaborate on this.
6.1 Footnote 1 – ‘Functional Units’
The introduction of the term Functional Units is unnecessary and potentially confusing. In
fact, the term ‘Functional Group’ is entirely correct in so far as the Functional Groups are
correctly specified. For instance, the DIR ‘Functional Unit’ corresponds to the ‘MHS Use
of Directory’ Functional Group, and this link should be maintained for clarity.
There are other ‘Functional Units’ which have more remote relationships with Functional
Groups, but they all essentially do the same job as Functional Groups (i.e. specifying a bit
of functionality of AMHS (or MHS) in terms of Protocol and Processing Capability (and
implying combinations of Elements of Service). Also industry is liable to be more
confused with the term ‘Functional Units’ than Functional Groups.
It is suggested that the document [1], should actually define an a set of new functional
groups that are useful in the AMHS environment – e.g. known as AMHS-Functional
Groups. One Functional Group is defined for each of the components such as BBP or
IHE. It should also relate the AMHS specific Functional Groups to the Standard
Functional Groups – e.g.

Version: 1.0
DIR with MHS Use of Directory;
Date: 14 May 2004
Page: 2
Comments onACP WGN02-WP14 = AMHS Implementation Profiles
Ref : ///

S0 with S0;

IHE with IPM BCC + additional AMHS specific processing and mapping rules.
In this way, the document would be rather like ISO/IEC ISP 10611-1 (Common
Messaging), except that it defines groups of Elements of Service relevant in an AMHS
system.
6.2 Description of the paper’s intention and use
There is a need to describe the intended use of the document in the process of design
and procurement. This description should say:
Version: 1.0

This document (i.e. [1]) specifies a generic set of ‘Functional Groups’ that are useful
in the AMHS context;

These Functional Groups express the optional functionality of an AMHS service or
capability of a Region as a whole;

However, it must be noted that in order to define how and where those AMHS
Functional Groups are realised by particular systems within an AMHS region or
island, a distributed design of the region/service must be undertaken for that region.
This must identify an appropriate procurement profile of functional groups that apply
to each individual system supporting the region. For instance, the regional profile may
state that it supports the DIR Functional Group. However, DIR may actually be
supported either by all of the AMHS User Agents in the region, or by a number of
MTAs, or both UAs and MTAs. The region must make this choice and state it before
system procurement. The regional design must therefore take the overall profile of
Functional Groups and decide which of its component systems will support each of
the selected functional groups. This leads directly to a procurement specification of a
single system (e.g. UA or MTA), and the profile can be locally updated to reflect that
product requirement (See Diagram 1);

This description means that the AMHS Region’s (or AMHS Island’s) systems must be
designed so that appropriate individual systems are implemented to the correct
profile to support the overall regional requirement;

The determination of the correct procurement profile for any individual system
therefore starts with the specification functional groups supported by the region (or
AMHS Island), continues through a distributed design process to identify the
functionality of each system component, and results in a procurement specification
including the procurement profile that applies to it
Date: 14 May 2004
Page: 3
Comments onACP WGN02-WP14 = AMHS Implementation Profiles
Ref : ///
AMHS Functional Groups, Design and Profiles
UA1 specification
UA2 specification
UA3 specification
‘AMHS Implementation
Profiles’ - Doc [1]
Functional
Group
Definitions
Regional
Design
Processes
•DIR
•IHE
•S0
•BBP
• ...
•Identify Functional Groups
•Identify each System
•Allocate FG’s to Systems
•…. Design topology etc.
Regional
Procurement
Profile
Tailored
to
Region
UA4 specification
MTA1 specification
MTA2 specification
MTA3 specification
Gate1 specification
Gate2 specification
Diagram 1 AMHS Functional Groups, Design and Profiles
6.3 Directory Functions
The concepts of the document should also extend to the various aspects of Directory
Functionality. For instance, the following profiles can be identified for DUAs and DSAs:

DIR – which corresponds to the MHS use of Directory specified in ISO/IEC 11189;

AFTN<>AMHS address mapping (CAAS and APS distribution);

General purpose DUA directory access;

Administrative DUA;

Security (X.509) DUA Access;

....
In this way we can define appropriate ‘functional groups’ that relate to AMHS
requirements and to existing directory specifications (such as FDI2 ISO/IEC 11189).
7.
RECOMMENDATIONS
The previous suggestions lead to the following proposal for new recommendations to the
AMHS Implementation Profiles paper. Recommendations:
1. The paper should allow the subset Basic Service + BBP;
2. The paper should allow the subset Basic Service + DIR + BBP;
Version: 1.0
Date: 14 May 2004
Page: 4
Comments onACP WGN02-WP14 = AMHS Implementation Profiles
Ref : ///
3. The paper should define a new ‘Global Minimum’ Subset of Basic Service AMHS +
BBP.
4. The terminology and title of the document should be modified as indicated in section
6.
5. We should consider definition of Directory Functional Groups to identify modules of
Directory Functionality (e.g. DIR, AFTN Address Translation, Sec0 ...).
Version: 1.0
Date: 14 May 2004
Page: 5