Delivering the ATS Message Service to the End User using AMHS

Benefits of Delivering the ATS Message Service to the End User

The ATS message service is not used directly by the end user. Rather, it is the support infrastructure for a number of messaging applications, such as flight planning and meteorological data. These are the services which currently are usually provided by AFTN or CIDIN. End user requirements are driven by current and future applications that will run over the ATS Message Service. Key questions, are “what applications can be supported” and “how well are applications supported “.

International connectivity for messaging applications is changing to use AMHS. ICAO and regional organizations are setting cut over dates and putting in place plans for this to happen. National organizations have two basic approaches to integrate their users with this infrastructure.

In this approach AMHS is used internationally, and then converted to something else for national service.

In this approach, AMHS is used nationally, right through to the end user. This delivers the ATS Message Service all the way to the end user. There are two advantages to this approach.

The first advantage is inherent to the architecture. Protocol conversion should always be avoided. It gives another failure point, and there is risk that information cannot be converted, there is semantic shift, or errors occur. A system that avoids protocol conversion is almost always going to deliver a higher level and quality of service.

If the local format is of similar functionality and complexity to AMHS, this would require maintaining an additional national specification, which would be a massive overhead. Conversion usually proposes use of a simpler national protocol: typically AFTN or AFTN message format using a different transport mechanism. In this case there is a reduced quality of service to the end user, or lack of flexibility to introduce new services. In particular the following services may not be available:

• Support of large messages.
• Access to new AMHS addressing formats, which may restrict international connectivity and convenience.
• No access to AMHS security services.
• No access to the ATN Directory for verification and capability determination.

The rest of this paper looks at how the ATS Message Service can be delivered to the end user, in order to achieve these benefits.

Integrated ATM System: Solution for the High Volume User

Many users of the ATS Message Service are full time ATC staff, who will spend most of their working day performing ATC functions. Such a user will generally sit at a dedicated terminal (or terminals) and operate software specifically designed for supporting ATM (Air Traffic Management). The architecture of such a system is shown below.

The ATM system provides an integrated view to the end user, and will typically utilize a number of communication channels, including AMHS, in order to provide a full set of services. The end user will have a custom interface provided by the ATM system, which is layered over AMHS. A typical ATM System will support multiple concurrent users with a centralized or distributed configuration. For the ATM System, the AMHS is just one of the communication technologies used by the interface.

The following diagram show in more detail how the ATM application could use Isode’s APIs in order to connect to an AMHS Service:

The ATM system will use Isode’s APIs to connect to two AMHS components:

• The ATN Directory, for verification, capability, security and address mapping information.
• Direct access to M-Switch X.400 (X.400 MTA) using the X.400 P3 protocol. As the ATM will provide managed reliable storage, it is appropriate for it to connect directly to the

AMHS Terminal: A solution for small and medium sites

Some users only require access to messaging services and the associate applications such as flight planning, and so need a system which provides these services only (and not a general purpose ATM system). These would be users who currently make use of an AFTN Terminal, for which an AMHS Terminal would be a direct replacement. Typically, this approach will be appropriate for low and medium volume users.

The AMHS Terminal interface to the end user would be very similar to that provided by an AFTN Terminal. The underlying AFTN communication would be replaced by AMHS to give direct delivery of the ATS Message Service. There are two components to this.

• The ATN Directory, for verification, capability, security and address mapping information. The address mapping is particularly important, as it will enable the user to be presented with familiar AFTN addresses, which Isode’s API can convert to AMHS addresses using the ATN Directory.
• Access to AMHS for submission and delivery of messages uses X.400 P7 to access M-Store. The Message Store will provide a managed system for storage and backup of messages, including meeting ICAO 30 Day archiving requirements.

Web Interface: A simple solution for remote sites

The high volume user of an ATM application will typically connect using a custom terminal and custom interfaces. Another way to provide access to an ATM application is with a Web interface.

The Web application will connect to the ATN Directory or verification, capability, security and address mapping information. Connection to the AMHS can use either X.400 P3 to M-Switch X.400 or X.400 P7 to M-Store, dependent on whether or not the Web Application provides reliable message storage and archive.

The Web Application is essentially going to provide the same functions as an AMHS Terminal or a more general ATM Application, but with a Web front end which can be accessed remotely by Web (Http) access. This means that any standard desktop can access the service with a Web browser – no special equipment is required at the remote site. This is a major advantage. There are two basic approaches to implementing this architecture:

1. Provide a Web front end to a conventional ATM system or AMHS Terminal. This will leverage on a general purpose implementation, and provide Web access for remote users.
2. Develop a special purpose Web ATM implementation, specifically targeted at Web users. Such an application will typically be developed in Java as a Web service, running in an application server. Isode provides Java versions of its AMHS APIs, in order to facilitate this type of implementation.

A modern Web interface provides a clean and convenient way to compose new ATS Messages and to access stored messages and databases. It works well for the low volume user, as a Web interface is convenient, well understood and can be accessed from anywhere. When an end user wishes to initiate an action, it will be straightforward to get to a system with Web access and send the message. A low volume user will typically not be sitting at a terminal, and this presents a problem for incoming messages. It may not be convenient to go to a Web site at frequent intervals to check for new messages. The solution is to include an alerting mechanism as a part of the Web implementation, which can send an alert to the user by a mechanism that is appropriate to the situation. For a low volume user on a small airfield, a pager alert might be a good mechanism.

The key point about a Web solution is that it is simply a user interface, so it is straightforward to provide the end user with full access to the ATS Message Service.

Email Delivery plus Web: A solution for the Email User

There are some users who make heavy use of email, and for whom their email client is the ideal place to receive information. The Web architecture described above can be extended to support such users. The simplest extension is simply to provide email notifications of new messages on the Web site. The user will then go to the Web site to receive messages.

For many ATS Services, the only operational requirement is delivery of information to the end user. This could be achieved by printing the information on paper and handing it to the recipient. For this type of service, it is straightforward to extend email delivery, to include an HTML (Hyper Text Markup Language) rendering of the message. This format is supported by all popular email clients, and so does not constrain the end user’s choice. Because HTML is the format used by Web pages, this format will already be available at the Web interface. This makes it very straightforward to add to a Web interface. Essentially, the a Web page showing the message is delivered to the user’s email client. Standard facilities of the email client are being used to display an ATS Message, without the need for the email client to be aware of the syntax or semantics of the underlying information.

This basic HTML rendering can be extended by use of URLs (Uniform Resource Locators) in the message, which will take the end user back to the Web interface. This will enable:

• Access to related information. For example, a message updating a flight plan can contain a URL linking to the original flight plan.
• Drill down. The message can be used to show basic information, and use URLs to provide access to more detailed information on the Web site.
• URLs to facilitate responses. If a reply or acknowledgement is needed, a URL can take the user to an appropriate form on the Web site.

This solution provides email delivery using any Internet email client, and gives a convenient email interface for services that can be fully and cleanly provided over email. For services which cannot, the Web element of the solution provides access to the full ATS Message Service.

Email Client Only solution and why it is a Very Bad Approach

A typical ATS Message Service interface has a lot in common with a general purpose Internet email interface. An “obvious” approach is to use a standard email client as the end user interface onto the ATS Message Service.

The basic idea of using a standard email client as the interface to the ATS Message Service is attractive. Unfortunately, it is at best a partial solution, and in general has many problems. The conclusion, which will be justified below in more detail, is that this approach is not desirable. The basic problem is:

The ATS Message Service is more than Inter-Personal Messaging

Email clients are primarily designed to support Inter Personal messaging (informal messaging between human users) generally using Internet protocols. Although the ATS Message Service shares things in common with this, there are many things that go beyond Inter Personal messaging. This means that, while things can be made to work to some approximation, it is not possible to deal with all of the features and advanced services. This has two implications:

• An email client user cannot access all elements of the ATS Message Service.
• The overall ATS Message service is degraded.

This section now looks in detail at the difficulties of providing the ATS Message Service with an email client only solution, and compares it with the two solutions that Isode recommends for low volume users (Email Deliver + Web, and AMHS Terminal).

These points make clear why use of an email client only solution is a very bad idea.

Conclusions

This paper has examined four solutions for delivering the ATS Message Service to end users. Isode’s recommendations are: