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

isode.com / solutions / vertical solutions /

Isode's AMHS Architecture

Air Traffic Management (ATM), Aeronautical Information Management (AIM) and other Air Traffic Control (ATC) systems use a number of communication channels supporting different protocols that enable information exchange and provision, including as radar data exchange, voice communications, air/ground communications messaging and data link and ground to ground communications messaging.

AMHS (Air Traffic Services (ATS) Message Handling Services) is the new ICAO (International Civil Aviation Organization) standard for ground to ground message communications, that supersedes the older AFTN (Aeronautical Fixed Telecommunication Network) and CIDIN (Common ICAO Data Interchange Network) standards. Most aeronautical ground to ground communication currently uses AFTN and CIDIN, but AMHS deployment is growing rapidly and will eventually become the dominant system.

Where do Isode products fit?

ATM, AIM and ATC systems generally use a number of communication channels in support of the overall management function, as illustrated in the diagram below. From the standpoint of those systems, AMHS can be thought of as a new ground to ground communications channel, which will initially complement and eventually replace AFTN and CIDIN channels.

Isode offers a set of products which include the servers, management tools, and APIs, necessary to provide the AMHS ground to ground communication channel for ATM, AIM and ATC systems. Because AFTN, CIDIN, and AMHS will co-exist for a long period, Isode also provides integration products that enable an AFTN/CIDIN vendor to build solutions that give AFTN/CIDIN interworking with AMHS and to build solutions with integrated AFTN/CDIN and AMHS management.

The Need for AMHS

Ground to ground systems connect international airports, Air Traffic Control facilities and international airline companies, ensuring the telecommunications necessary for the safety, regularity and efficiency of international air navigation. These systems exchange vital information for aircraft operations such as distress messages and traffic, urgency, flight safety, meteorological, flight regularity and aeronautical administrative messages.

AFTN evolved to provide this ground to ground infrastructure, using protocols that are originally derived from Telex. AFTN is both a dedicated telecommunications infrastructure and a special purpose messaging protocol for providing ground to ground communications.

AMHS is defined in a new set of ICAO SARPS (Standard and Recommended Practices), that are being adopted to replace the existing AFTN and CIDIN systems for ground to ground communications. AMHS is based on the ITU (International Telecommunications Union) X.400 messaging standards, which provides the core messaging framework that AMHS extends to support aeronautical applications.

AMHS offers a number of benefits over the older AFTN and CIDIN systems, including:

• AMHS can operate over a general purpose network, which can be shared with other systems, rather than the dedicated AFTN network.
• AMHS define the Basic ATS Message Service, which gives an application service equivalent to the older systems. This enables a straightforward co-existence and transition strategy.
• AMHS defines the Extended ATS Message Service, which enables the following new capabilities:
  • The general body part capabilities of X.400 can be used to enable transfer of additional, new and extended information over the X.400 messaging infrastructure, as well as existing ATC (Air Traffic Control) messages.
  • Support of large and very large messages.
  • Digital signature of messages, to provide content integrity, origin authentication and non-repudiation.
  • A directory is provided, which enables:
• Address verification at message submission time.
• Managing security parameters
• Determining recipient capabilities. This enables new AMHS features to be used, while co-existing with systems that do not support these features, without risk of service loss.

In summary, the Basic ATS Message Service enables transition of the existing service and gives a platform for new services. The Extended ATS Message Service enables these new services to be introduced and improves quality of service for existing applications.

Isode's AMHS Solution

This diagram shows Isode's core AMHS channel solution, comprising five products:

• M-Switch X.400: An X.400 MTA (Message Transfer Agent) that provides the core message switching services and connects to external systems.
• M-Store X.400: An X.400 Message Store, for storing messages.
• M-Vault X.500: An X.500 and LDAP directory server, which is used to configure the Isode AMHS solution, and may also provide an independent directory service
• The Isode AMHS API is used to connect AMHS applications to Isode servers using either X.400 P3 (to M-Switch X.400) or X.400 P7 (to M-Store X.400). This multi protocol approach allows applications to either directly access M-Switch X.400, or to go via M-Store X.400 if message storage is needed.
• The Isode ATN Directory API is use to connect AMHS applications to M-Vault X.500 using X.500 DAP (Directory Access Protocol). This allows lookup of information such as Certificates and AMHS parameters, and supports mappings between AFTN addresses and X.400 O/R Addresses.

By default, external communication uses TCP/IP and the RFC 1006 transport mapping. Isode also provides an option for using SARPs conformant OSI transport protocols, to enable use of AMHS over the ATN (Air Traffic Network).

Support of ATM Stations

A typical ATM, AIM or ATC user at a large site will work at a custom workstation or console, which will provide the various applications to the end user that utilize ground to ground messaging communications. These applications include flight planning, briefing and weather reports. Isode provides a number of APIs to enable these applications to be directly connected to the AMHS infrastructure. Direct connection offers a number of advantages:

• Access to all AMHS features and services, including Extended SARPS.
• No protocol conversion or intermediate formats that might cause loss of service.
• Optimum performance.

The core access to the AMHS is through Isode AMHS API. This provides a simple client API, that gives an easy to use abstraction of the AMHS services that can be mapped onto either X.400 P3 or P7. The Isode AMHS API is available in 'C', Java and Tcl, and on Windows, Linux and Solaris platforms, making it suitable for a very wide range of applications.

In addition, access to the directory is provided, which may be used for extended SARPs support or other purposes. Isode recommends use of X.500 DAP (Directory Access Protocol) as this is SARPs conformant, and has a number of technical advantages. Isode provides an ATN Directory API, which gives simple access to the directory, and provides support for a number of ATN and AMHS specific functions. M-Vault X.500 also supports LDAP (Lightweight DAP) access, and this may be convenient for some functions, particularly simple directory browsing and searching.

Web and Internet Access

For users where a special purpose Work Station is not appropriate (e.g., those who only use ATC applications occasionally), Isode recommends a Web interface, and the above diagram illustrates how a typical AMHS Web application would integrate with the Isode AMHS channel. This model assumes Web applications written in Java and running in an application server such as Tomcat or Websphere. These applications are integrated using the Java versions of Isode's AMHS API and ATN Directory API. These APIs make it straightforward to integrate an ATM Web Application with AMHS.

A note on email client support Isode's AMHS architecture provides an approach where, in appropriate situations, AMHS messages are delivered to Internet email clients. Messages are either sent from and special purpose Work Station or from a Web application. Isode's architecture discourages direct sending AMHS messages from an Internet email client because: Internet email addressing is different to AMHS addressing, and mapping may cause confusion. Less data is available to the email client than to the Web application, so data verification will be poorer. The translation to AMHS will happen subsequent to Internet email submission. As this conversion is not immediate, any errors in conversion to AMHS may cause critical operational problems due to this delay. Extended SARPS features, including security and directory functions cannot be supported from a standard Internet email client. For these reasons, sending AMHS messages from an Internet email client is not recommended.

A Web interface can provide a complete solution for many ATM, AIM, ATC, airline and airport users. It is generally appropriate for users who only spend a part of their time using applications that require AMHS support. Such users can access a Web interface when they wish to initiate communication. However, such users may not be looking at the Web when messages arrive, so it is important that the Web application includes an appropriate alert mechanism. This could include:

• Printing the message for manual distribution.
• Use of conventional alerting tools, such as pager or SMS.
• Sending an email alert. This will often be convenient where the user frequently reads email. Because the Web application can render the message in HTML, it will be easy to include a copy of the message in the email alert. This means that the message may be read in a convenient graphical format in any Internet email client. For many messages, particularly non-critical messages which do not need an action, sending the email alert may be used as the message delivery mechanism. Where a message has security implications or only makes sense in the context of other ATM data, it may not be appropriate to include the message content in an email alert.

For distress messages, which require an AMHS acknowledgement, it makes sense to bring the user back to the Web interface, to ensure that the message is acknowledged. Critical messages may lead to alerts to multiple users, to ensure that at least one person responds rapidly.

Co-existence with Internet Email

AMHS Solutions will often need to co-exist with Internet email, including SMTP, POP3 and IMAP protocols. Isode's M-Switch product is available in three basic setups:

• M-Switch X.400: An X.400 MTA.
• M-Switch SMTP: An Internet Message Switch.
• M-Switch MIXER: Supports both 1 and 2, and conversion between X.400 according to the Internet MIXER standards.

Thus, M-Switch can be used to support SMTP switching, and with our new M-Box product can be used for Internet Message Delivery and Access (both POP3 and IMAP). This will be convenient for customers needing both Internet email and AMHS.

To support reading of AMHS messages from an Internet Mailbox, we recommend that delivery is made to an AMHS (X.400) mailbox. Then an application will read the X.400 message (typically using the Isode AMHS Client API) and render the information from the X.400 messages in HTML. This HTML will then be included in an Internet email and delivered as a nicely formatted Internet message to the recipient's Internet email mailbox, as described above.

An alternative approach is to use the mapping between X.400 and Internet Mail provided by M-Switch MIXER. This will enable basic connectivity with core services. Some service elements, particularly those of the Extended ATS Message Service will be lost in the mapping. The messages will also not be particularly convenient for the end user. However, this mechanism is available and will work.

Co-existence with AFTN and CIDIN

The diagram above illustrates how AFTN/CIDIN and AMHS will co-exist. Four civil and military Air Navigation Service Providers (ANSPs) or Civil Aviation Authorities (CAAs) are shown operating:

• A legacy AFTN/CIDIN system
• An AMHS system,
• A mixed AFTN/CIDIN and AMHS system and
• An AMHS transitional/gateway solution

The role of the AFTN/CDIN to AMHS gateway is a critical part of this transition. Isode provides two APIs which support the AMHS side of such a gateway, which can be used by Isode's partners to build full ACTN/CIDIN to AMHS Gateways. The APIs are:

1. Isode's own AMHS Gateway API. This is designed for AMHS/AFTN gateway applications. The library provides all of the AMHS side of an AMHS/AFTN gateway, making it very straightforward for a vendor with an AFTN product to offer an AMHS/AFTN gateway.
2. The X.400 Gateway API, which is a programmatic interface allowing messages to pass between a mail-enabled application or a proprietary mail system and an X.400 message service. M-Switch supports the X.400 Gateway API, including X.400 (1984) and X.400 (1988) versions. In order to integrate X.400 Gateway API applications with M-Switch, Isode supplies an X.400 Gateway API Developer's kit.

Integrated AFTN/CDIN and AMHS Management

Isode's AMHS channel includes full management capabilities. AFTN/CDIN and AMHS provide the same service, so in many situations it makes sense to have integrated management of both services. To enable this, Isode provides APIs to all of its AMHS management capabilities. Isode uses these APIs for its own management tools. These APIs are also available to Isode AFTN vendor partners, to provide an integrated management GUI that can manage both AFTN/CIDIN and AMHS components.