Comments to WP Alternative Approaches to ATN Application Specification

ACP – ACP WGN SGN3/x - WPxx

WGN-02 WP10

05/03/04

AERONAUTICAL COMMUNICATIONS PANEL

WORKING GROUP N

SUB GROUP N/2 – Air/Ground Applications – 2nd Meeting

Montreal, Canada, May 18 – 28, 2004

WORKING GROUP N – Networking – 3rd Meeting

Montreal, Canada, May 18 – 28, 2004

Agenda Item 5.1 – Subgroup N2 progress report

Prepared by: H. Denis, P-H. Pagès, F. Picard

Comments to WP "Alternative Approaches to ATN Application Specification"

Summary

This paper XXXX.

1 Introduction

This paper aims XXX.

1.1 References

[1] Alternative Approaches to ATN Application Specification. EATM – DAS/CSM – CITRS/T17/DEL/01. Version 0.B. 15 Jan 2004.

2 Background

The ICAO standardisation process for specifying the ATN air/ground and ground/ground applications took several years to produce a mature and validated specification. This can be explained (amongst other reasons) by the necessity identified from the beginning to define a generic ATN specification framework, allowing both the specification of the initial set of ATN applications (the so-called "Package-1" applications including CM, ADS, CPDLC and FIS) and the addition of new functionality with a minimum impact on the existing specification and implementations.

The ATN application specification framework is based on one hand on the compliance with the OSI Basic Reference Model (BMR) and on the other hand on a specification methodology appropriate for ATN applications :

The OSI BMR breaks down the end-to-end functions of communicating applications into 4 layers (Transport, Session, Presentation and Application), each layer being responsible for a specific task and using the services provided by the underlying layer. In addition, it specifies a structure for the application layer (ALS) used to ease the specification of the complex functions of the application layer.

The ATN ASE specification methodology is based on a structured way of specifying both protocol and service of the ATN application service elements through 8 separate chapters (1. General, 2. General Requirements, 3. Definition of the Service, 4. Definition of Messages, 5. Protocol Specification, 6. Communications Requirements, 7. User Requirements and 8. Protocol Subsetting).

It must be recognised that this ATN application specification framework was fully appropriate for the initial set of applications since many ATN end systems have been successfully developed by the industry on the basis of the ICAO Doc. 9705 specification.

However, experience showed that that the management of the dialogues by the ASE brought complexity in the specification of each ASE protocol and it appeared that this management would be more efficient if handled in a single entity on behalf of all applications instead of being duplicated in each ASE. To respond to this issue, 2 variants to the ATN Upper Layer Architecture were developed : the dialogue management was shifted from the ASE to the Control Function (AIDC solution) or in a new ASE (GACS solution).

Today, new ATC services based on data link applications are being specified by operational bodies and ACP will be tasked to develop the ATN specifications to support these new services in the ATN environment.

Document [1] considers the alternative approaches to specifying and implementing these ATM air-ground data link services.

This document presents the position of STNA on these different approaches.

3 Discussion

3.1 General

3.2 Alternative Approaches

3.2.1 ATN ASE

This approach is based on the current ATN application specification framework where the ATN ASEs relies on the Dialogue Service specified in Doc 9705 Edition 1 and 2. This allows to produce a clean specification in a short period of time, based on the experience of the existing ATN application specifications.

Advantages

In addition to the advantages listed in [1], this solution allows the use of all the functions provided by CM : anticipated negotiation of the application capability, anticipated negotiation of the ASE version number, exchange of application information (name, address, security information). The integration of the new ASEs into the existing implementations is straightforward.

Disadvantages

However, the main drawback of this solution is the specification within the new ATN ASE of the dialogue management. A specific dialogue management was specified in each Package-1 ATN ASE for CM, CPDLC, ADS and FIS, in particular for ADS and FIS the protocol specification is made very complex because of the possible multiplexing of several ADS/FIS contracts over one dialogue. Transferring the dialogue management within a separate ASE would drastically simplify the ATN ASE specification. This solution is the GACS ASO solution developed below.

Comments to [1]

The disadvantages listed in [1] should be justified in more details. As explained in 3.2.1 and 3.2.2, the protocol overhead and the specification overhead are not greater than in other solutions. Concerning the transmission mode, it is unlikely that a given application will have to work on both CO and CL. The transmission mode is naturally deduced from the nature of the application (e.g. DYNAV on CO, URCO on CL). The ATN ASE approach allows specification of ASE above CO or CL dialogue service. The limitation of the address space does not seem to be a real issue (2 octets for the TSAP allows for 65536 different applications). This issue is more related to the maximal CM capability, able to exchange up to 256 application data blocks.

3.2.2 GACS ASO

This approach enhances the current ATN application specification framework here the ATN ASEs relies on an enhanced Dialogue Service (GACS) specified in Doc 9705 Edition 3. The ASE specification will be made lighter and easier to implement.

Advantages

As stated in [1], this solution allows to keep all the advantages of the ATN ASE solution (e.g. use of CM services) and provide a solution its dialogue management disadvantage by proposing the "implicit start" service to the ASE. Application specification is considerably simplified.

The real added value for applications using GACS instead of the DS is the support by GACS of some applications features (message type, identifier and reference, list of recipient, multicast, confirmed transfer service) and the independence with the transmission modes. These new services must therefore be of real interest for the new application before choosing to specify the application above a GACS or a DS service provider.

Disadvantages

The disadvantage identified in [1] seems occur only for GACS implementations relying on CO Dialogue service only. Since GACS is responsible for selecting the more appropriate transmission mode based on user-supplied parameters, GACS should automatically select the CL service for applications not requesting maintenance of connections.

The main disadvantage of all approaches using GACS is the need to upgrade the ATN ULCS to the Edition 3 specification to support the extended ATN addressing scheme and the CL service.

An other disadvantage is to build a complex upper layer architecture above the Transport Service Provider (including Session, Presentation, ACSE, CF, GACS) to end up with a GACS service similar to the Transport service…

Comments to [1]

The way [1] describes this solution is an unacceptable deviation to an acceptable solution. In [1], the DYNAV ASE does not handle DYNAV messages but only bit strings.

"The ASE protocol and the format of the data exchanged by the ASEs do not need to be standardised by ICAO nor disclosed externally. These ASEs are "black boxes" for the ATN (the same way the Package-1 ASEs were considered as "black boxes" by the DSP".

All the functions related to the encoding/decoding, message verification, encoding rules negotiation are moved to the user. The ASE is only responsible for checking the sequence of DYNAV primitives and the correct mapping onto GACS primitive. In that case, why specifying an ASE for doing so little, this could be done by the user itself (cf. GACS AE). The specification of the GACS ASO solution must be modified in [1] to present a real ASE (e.g. DYNAV ASE) and not a dummy one.

3.2.3 GACS AE

With this model, any new application is specified outside the ATN environment, using an application-gateway (GACS Application) to use the ATN communication service.

Advantage

The primary advantage of this solution is to allow smooth migration of non-native ATN application in the ATN infrastructure. Indeed, only the adaptation of the lower interface of those applications to invoke the service provided by the GACS application is required.

Disadvantages

Other issues need to be identified :

Essential ATN upper layer functions are not accessible anymore to the user applications. As a consequence, they must be introduced (and duplicated) in the user protocol : e.g. application identification (name and address), negotiation of abstract and transfer syntaxes

The functions supported by CM must be introduced (and duplicated) in the user protocols.

Interoperability issues are migrated from standard specification to proprietary specifications. Proprietary solutions will be specified on an application basis by aircraft and ground system manufacturers, leading to an heterogeneous, inefficient and non-interoperable communication environment.

Essential ATN Application functions are not accessible anymore. Interoperability issues such as:

– those covered by Doc 9705: identification of applications and addressing, identification and specification of message contents, allowed technical sequence of messages, error handling procedures, …

– those covered by EUROCAE/RTCA ED110 document: conditions of use of optional features, allowed operational sequence of messages,

will not disappear (as [1] presents it) but will have to be specified for each application by application designers. For instance, using this method to re-define ADS will make much more complex the ADS protocol than today to support for instance addressing and syntax issues.

It should be made clear that this solution moves the complexity of the ATN end system to the user applications, while inhibiting the access to ES essential functions.

Comments to [1]

The advantages listed in [1] should be justified since they are not so obvious :

– what is the added value of implementing a dynamic application level message router ("transaction server") ?

– The communication architecture and ATN addressing are not simplified but their use is restricted. This does not seem to be a real advantage.

– The migration/use of CO and CL transparently for the applications through GACS is a real advantage but provided by GACS and not by this specific solution.

The drawbacks identified above should be listed in the "Disadvantages" section.

3.2.4 CLDS

This approach is based on the current ATN application specification framework where the ATN ASEs relies on the Dialogue Service specified in Doc 9705 Edition 3 (Connnection-less). This allows to produce a clean specification in a short period of time, based on the experience of the existing ATN application specifications.

Comments to [1]

This solution should not be described as a separate approach since it is fully compliant with the ATN ASE solution (section 2). The approach is identical, the only difference is the type of dialogue service used by the ASE.

The disadvantages listed in [1] are not real ones for the following reasons:

– "Application must maintain any required context application", "possible undetected message loss". These are not real disadvantages but characteristics of the CL transmission mode. If ASE are designed to be used over CL, it is on purpose. Obviously, data link services based on pilot/controller transactions like DYNAV must not be designed over CL service. In the case of the URCO (Urgent Contact) specified by the Eurocontrol ODIAC AGC working group, a CL ASE would be appropriate and the loss of message is integrated in the service definition.

– "Security ASO not currently supported by CLDS". This should not be a decision criteria for choosing the approach. The Security ASO in CLDS is in the work program of ACP and should be developed in the future.

– "No operational deployment of CL profile". The reason for this is that there is no ATN application already specified over CL. Such profile will have to be specified at the time of the first CL-based applications.

3.2.5 Enhanced DS (as in AIDC)

This approach is based on the use by the ASE of a simplified service limited to the sending and the reception of data packet (the so-called "implicit start") and error indication. This service is mapped by the AIDC CF onto the appropriate ACSE and Presentation services without using the Dialogue service.

The main disadvantage identified in [1] (the CF is specific to AIDC and must be re-specified for each new application service element) is a definitive show stopper for this solution. The complexity of the ASE is moved into the CF, therefore the simplification of the ASE specification is only shifted into the CF. In addition, the benefit of having a generic CF for all ATN application is lost.

However, the solution showed that removing the dialogue management from the ASE specifications had a real impact on the clarity of the specification. The try to move the dialogue management in the CF is not conclusive, this solution is a transition to a better architecture where the dialogue management would be handled by a specific ASE and the CF would stay generic.

It is therefore recommended that this solution be not retained as an alternative approach.

3.2.6 Raw Transport Service (CO) and Raw Transport Service (CL)

These solutions must not be identified as credible alternatives for ATN Applications.

3.2.7 CPDLC Extension

This solution is strongly recommended when the new functionality can be supported by addition of new messages, with no impact on the current service, protocol and user requirements.

This solution has already been applied when defining CPDLC version 2 (the UM238 message REQUEST AGAIN WITH NEXT UNIT was added).

Note. The DYNAV service can be hardly be supported by an extension of the CPDLC ASE for the following reasons:

– DYNAV can be initiated by a D-ATSU and the CPDLC ASE does not support ground-initiated DSC connection,

– DYNAV supports the concept of "conditional clearance" where the LACK to the uplink WILCO makes effective the clearance. This concept may have some impacts on the current specification.