Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.

Whitepapers

Addressing in AMHS: Building a solution that works for the End User

Purpose

AMHS (Air Traffic Services (ATS) Message Handling Services), as specified in the ICAO ATN (Aeronautical Telecommunications Network) SARPs, is the new standard for ground to ground messaging communications, which is being adopted rapidly and will eventually replace existing AFTN and CIDIN systems.

AMHS provides a complex addressing scheme, which is used in conjunction with the ATN Directory. Users need to address messages, and the complexity of the AMHS addressing has potential to make this difficult. This paper explains how AMHS and the ATN Directory can be used together to provide a simple and effective user experience.

Why Addressing is Important

AMHS is a complex system. Most of the functionality, like the engine in a good car, is hidden from the end user and simply provides a means to transport messages reliably. The user is not aware of the underlying technology and functionality. The single exception to this is addressing, as messages being transported over AMHS have to be addressed by the end user to the intended recipients. This means that AMHS addressing will be visible to the end user. It is important to understand the impact of this new addressing on end users of ground to ground applications.

The AFTN User Experience

AFTN addresses are eight characters long, with an internal hierarchical structure. For example, "LEMGZPZX". While this looks quite ugly and awkward to someone unfamiliar with AFTN, in practice users become very familiar with these addresses. Many users work directly with these addresses and input them directly to their AFTN user interface.

AMHS Addressing

AMHS uses X.400 addressing. The basic addressing structure in X.400 is know as the O/R Name (Originator/Recipient Name). An O/R Name is composed of two elements, of which at least one must always be present:

1. An O/R Address. This is a structured address, supported by all X.400 systems.
2. Directory Name. This is the name of an entry in an X.500 directory, which represents the end user.

The O/R address is structured in attribute value pairs, which supports message routing without directory and enables high flexibility in addressing structure and approach. AMHS allows any O/R address to be used, but for early deployments it is anticipated that most addresses will follow one of two specific forms, know as "XF" and "CAAS". Examples O/R Addresses:

• /C=XX/A=ICAO/P=ED/O=AFTN/OU=EDDEZTZX/ (XF form)
• /C=XX/A=ICAO/P=Aena/O=LECS/OU=LEMG/CN=LEMGZPZX/ (CAAS form)

It can be seen that these O/R Addresses bear some relationship to AFTN addresses, but not a simple algorithmic one.

Directory names are also attribute structured and are hierarchical, typically following a "Country, Organization, Common Name" hierarchy. For example:

• Country=FR, Organization=LFCI, Common Name=LFCIZPZX
• Country=FR, Organization=LFCI, Common Name=Operator

This structure is easier to understand than the O/R Address (because it does not need to include routing information) and can use values which are intuitive.

The Problem

While AMHS addressing is very flexible, and gives opportunity to broaden use of the common AMHS infrastructure, they present new challenges. In particular, they are too long to be input directly by an end user, and the O/R Address component is certainly to complex for most users to remember and handle on a regular basis. This is compounded by the difficulty that some recipients will use XF format addresses, others will use CAAS, and others will use generic X.400 addresses. Deployment of AMHS needs to consider how users will deal with the new addresses.

Deployment with and without Directory

AMHS can be deployed with or without the support of an ATN Directory. Where a directory is not used, addressing is handled completely in terms of O/R Addresses. These O/R Addresses will need to be handled by the AMHS Client. Users will need to directly input O/R Addresses, at least the first time that they are used. For subsequent use, O/R addresses may be stored in a local address book for the client.

When users refer to each other, they will need to do this in terms of the O/R Address. This means that users will need to become very familiar with O/R Addresses in order for the infrastructure to work. This will require significant training, and is not going to be particularly comfortable or convenient for most end users. AMHS users will also need to enter O/R Addresses for AFTN users, which are sent through an AFTN/AMHS gateway.

Where an ATN Directory is available, things can be made significantly easier for the end user. The rest of this paper shows how this can be achieved.

The ATN Directory

The ATN directory is a distributed service holding information on AMHS users and other ATN components and services. The logical structure of an ATN Directory is illustrated below:

It can be seen the the directory holds information in a natural hierarchy, with entries containing information that is useful for the underlying system, as well as information such as telephone number and location that will be useful to the end user. This service is provided in a distributed manner, using the hierarchy of the directory information tree in a natural manner. Data is also replicated in the directory for robustness and performance reasons.

Address Verification

An AMHS system can verify a Directory Name component of an O/R Name on message submission, and fill in the O/R Address component of the O/R Name. This will increase service quality, as it will ensure the messages are only submitted with correct recipient addresses. For this reason alone, it is preferable for end users to always make use of the Directory Name component of the O/R Name whenever this is available. This capability also means that end users will be able to work in terms of the friendlier Directory Names, and in the long term (when all AMHS users are registered in the ATN Directory) the O/R Address will be a component that is used primarily within the AMHS system and will not generally be used by the end user.

Browsing and Searching

When a directory is available, users will not generally have to type in recipient addresses. They will be able to browse or search the ATN Directory in order to find the desired recipient. This approach is convenient for the end user, and also prevents mistyping of addresses. An example directory browsing interface is shown below.

Address Books

Although browsing the directory is easy and convenient, it will not be appropriate for high volume users to enter the addresses of recipients who they regularly correspond with. To achieve this, it will make sense for users to store their regular recipients in a local address book. While such an address book could be stored and managed by the client application, it makes sense for this information to be stored in the directory for two reasons:

1. The user may access messages from multiple locations or machines. By holding the address book in the directory, it will be available to the user from every location, and not just on one machine.
2. It will easily permit shared address books to be built, that can be used by multiple users at a single location who have a common set of "regular recipients". This approach will also enable new users to be provided with a basic list of recipients.

Mapping from AFTN Addresses

The directory scenario described so far, corresponds to a long term situation where most AMHS users are registered in the directory, and can be identified by browsing or searching the directory. It is important to understand this model, and the benefits of achieving this situation in the long term. For early AMHS deployments, most recipients will not have directory entries, and most recipients will be AFTN users.

A key capability of the ATN directory is the ability to map from an AFTN address to an O/R Address (and the reverse). The way this works is described in Isode's ATN Directory Vision paper. The importance of this capability, is that it enables the AMHS user to simply enter an AFTN address. This is then looked up in the directory, and the user does not have to directly deal with the X.400 O/R Address. This can work in three specific scenarios.

1. The recipient is an AFTN (or CDIN) user. In this case there is a single entry in the directory which enables the AFTN address to be mapped into the correct form (XF or CAAS) O/R Address. The single entry is associated with the recipient's ATC organization. This is important, as only a limited number of directory entries is needed to perform this mapping for all possible recipients. The information necessary to build these directory entries is already available from Eurocontrol.
2. The recipient is an X.400 user without a directory entry. In this case, the same mapping is used, and the AFTN address of the user can be entered.
3. The recipient is an X.400 user with a directory entry. In this case a similar mapping is used, but in this case the Directory Name of the user is also returned and the O/R Address is not restricted to XF and CAAS format. The directory will help support situations where there is a mixture of XF and CAAS addresses.

This mapping will provide huge benefit for early AMHS deployments. It will enable end users to enter and use the AFTN addresses that they are familiar with. There will be no requirement to handle the complex an unfamiliar O/R Addresses. This will give a comfortable user interface and an easy transition, to the longer term scenario where all users can be found in the ATN Directory.

Conclusions

This paper has described how AMHS addressing works, and the difficulties of supporting AMHS end users without a directory. It has also shown how the ATN Directory can be used to remove these problems and to provide an end user experience that is better than the currently deployed AFTN systems. Isode believes that it makes sense to always deploy directory in conjunction with AMHS.