Delivering the ATS Message Service to the End User using AMHS Possible issues and solutions

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).

Issue	Email Client Only	Email Delivery + Web	AMHS Terminal
Sending correctly formatted messages.	A problem, as an email client has no knowledge of the syntax and semantics of an ATS Message.	Messages are created using Web forms, and the underlying application can enforce syntax and semantics.	Messages are created by the AMHS Terminal.
Support of ATS Specific Parameters, such as ATS Message Filing time.	A problem, as there is nowhere in a standard Internet email message to put these.	On sending, these are created by the Web application, with user input as needed. On reception, these parameters may be rendered in the HTML, where they are useful to the recipient.	Handled directly by the AMHS Terminal.
Use of any email client.	An approach which can support any email client leads to a very basic and inadequate solution. One option is to pick a single email client and extend it to partially address some of the issues set out here. Microsoft Outlook is a likely choice, as it is a popular email client has has some extension capabilities. Restricting to one email client is undesirable, and reduces flexibility. If an email client were extended to deal with the issues here, it would no longer be a standard email client, and would be closer to being a custom ATM interface. This also gives the problem of having to manage non-standard software on end user desktops.	Only standard features of Internet Email is used (HTML rendering) and so almost any email client can be used.	n/a
Transformation Process robustness.	In order to connect the Internet email client to AMHS, at some point there has to be some transformation process that performs the conversion. Errors in the transformation process can lead to loss of messages and general lack of robustness.	No transformation process is needed, and so this is not an issue.	No transformation process is needed, and so this is not an issue.
Use of end user's "normal" email address.	A solution would typically have a mapping to internet email addresses of the form aftn-address@domain, which would need to be the client's email address in order to correctly originate messages being sent.	Email can be delivered to the end user's normal mailbox, and so be mixed with general purpose email.	n/a
Addressing remote AMHS users.	Problematic, as Internet email clients do not support X.400 addressing, and so dealing with different AMHS addressing schemes (XF, CAAS) is tricky.	Straightforward, as the Web application has full access to X.400 addressing, which can be used in conjunction with address books and directory lookup.	Straightforward, as the AMHS Terminal has full access to X.400 addressing, which can be used in conjunction with address books and directory lookup.
Archiving (meeting ICAO requirements)	Most email clients would not meet this requirement.	Archiving would be provided by the ATM (Web) application.	Archiving would be provided by use of Isode's M-Store X.400 product, in conjunction with the AMHS Terminal.
Directory Verification. The ATS Message Service requires this, as a core service (to minimize incorrectly addressed messages) and to verify recipient capabilities.	Standard email clients cannot do this.	Directory verification can be supported by the Web application, transparent to the end user.	Directory verification can be supported by the AMHS Terminal, transparent to the end user.
Support of addressing options and extended addressing. The ATS Message Service supports rich addressing capabilities (using X.400 and X.500 addresses) that will give transitional support to AFTN style addressing, with much higher long term flexibility.	There is no framework in Internet email to support anything other than user@domain style addressing.	A Web interface can support any form of addressing supported by the underlying AMHS and ATN Directory. Early deployments can allow the end user to enter AFTN addressing. The Web application will then use the ATN Directory to map these to AMHS addresses. Directory browsing, and directory managed address books can also be supported.	An AMSH Terminal can support any form of addressing supported by the underlying AMHS and ATN Directory. Early deployments can allow the end user to enter AFTN addressing. The Web application will then use the ATN Directory to map these to AMHS addresses. Directory browsing, and directory managed address books can also be supported.
AMHS Security.	Cannot be supported in an Internet email client, because AMHS security needs access to X.400 protocol elements.	Can be supported in the Web application, transparent to the end user.	Can be supported in the AMHS Terminal, transparent to the end user.
Distress (SS) Messages and acknowledgements	Some messages require acknowledgements, as a part of the ATS Message Service definition. There is no way to enforce this with an email client approach.	The Web application can ensure that acknowledgements are sent, and escalate status on un-acknowledged messages to an operator.	The AMHS Terminal can ensure that acknowledgements are sent, and escalate status on un-acknowledged messages to an operator.
ATS Message Service Applications and semantics. The ATS Message Service is not an end application in its own right, but is a the basis for supporting other applications such as weather and flight planning. For example, if an update to a flight plan is sent, it may be desirable to present this to the end user in the context of the original flight plan.	An email client is unaware of the application semantics.	The Web application is an ATM application, and can have appropriate knowledge of the flight planning and other applications to sensibly represent semantics and actions to the end user.	The AMHS Terminal is an ATM application, and can have appropriate knowledge of the flight planning and other applications to sensibly represent semantics and actions to the end user.

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:

Approach	Isode Recommendation
ATM Application with custom terminals.	A good approach, particularly suitable for high volume end users.
AMHS Terminal	A good solution for small and medium volume end users.
Web Interface	A good approach, suitable for a wide range of end users.
Email Delivery plus Web	A good approach, suitable for end users who are frequent email users.
Email Client Only	Not Recommended, as this approach cannot deliver the ATS Message Service and meet service requirements.