SGN2-07 WP 6/11
WGN/6 WP-XX
July 3rd, 2006
AERONAUTICAL COMMUNICATIONS PANEL
(ACP)
SUB GROUP N/2 (A/G APPLICATIONS) – 7th MEETING
WORKING GROUP N (NETWORKING) – 6th MEETING
Brussels (Belgium), 3rd – 7th July 2006
WHITE PAPER ON PM-ADS
Prepared by SGN/2 Members
Presented by F. Picard
In May 2005, ACP WGN/x has tasked SGN2 “ATN Air Ground Applications” to investigate the introduction of a protected mode (PM) for both the ADS and the FIS air/ground applications.
SGN2 has successfully developed a specification for PM-FIS, using the very same approach than the one used for CPDLC: an Application Message Integrity Check is added to each “sensible” operational data and a mechanism to negotiate the checksum algorithm is supported at contract establishment time. For ADS, this approach appears too be much more difficult to be followed,
The objective of this document is to describe what the problem with ADS is and to present the different solutions that have been identified by SGN2.
As none of these solutions is obviously preferred by the SG, the WGN is invited to review the results of the SGN2 analysis and to provide the SG with guidance on the way to proceed.
1 Introduction
1.1 In May 2005, ACP WGN/x has tasked SGN2 “ATN Air Ground Applications” to investigate the introduction of a protected mode (PM) for both the ADS and the FIS air/ground applications.
1.2 SGN2 has successfully developed a specification for PM-FIS, using the very same approach than the one used for CPDLC: an Application Message Integrity Check is added to each “sensible” operational data and a mechanism to negotiate the checksum algorithm is supported at contract establishment time. For ADS, this approach appears too be much more difficult to be followed,
1.3 The objective of this document is to describe what the problem with ADS is and to present the different solutions that have been identified by SGN2.
1.4 As none of these solutions is obviously preferred by the SG, the WGN is invited to review the results of the SG analysis and to provide the SG with guidance on the way to proceed.
2 References
[ED120] Safety and performance requirements standard for air traffic data link services in continental airspace (continental SPR Standard).
[WGN5/WP23] – Boeing – May 2005 - ADS change proposal to add an application level integrity check as provided for Protected Mode CPDLC.
3 Discussion
3.1 The need for a PM mode in ADS
3.1.1 Document [WGN/WPxx] had developed the rationale for a protected mode in ADS.
3.1.2 The Safety and Performance Document for initial Continental ATS data link services has clearly identified undetected ADS report corruption[1] an undetected ADS report misdirection[2] as a serious “class 3” hazard with corresponding Safety Requirements that have to be met with a high degree of confidence. The implementation of a checksum applicable end-to-end from the source of the data to the recipient and computed over the encoded data and the source and destination identities is an efficient way to meet the safety requirement.
3.1.3 Oceanic operation will likely introduce additional hazards, including those associated with misidentification of the source of an ADS report when the reports are used for separation. The same issues apply to ADS as were identified for CPDLC in providing assurance that the source/destination of the message has been correctly identified.
3.1.4 Given that CPDLC will not be relying on the transport-level checksum for mitigation of hazards associated with corruption or misdirection, ADS should use a similar application-level integrity mechanism. This will allow the ATN stack developed for the Protected Mode CPDLC application to be used for the ADS application, with the same level of software development assurance
3.2 Current Situation
3.2.1 ACP WGN has endorsed in May 2005 the decision to develop a PM-ADS application.
3.2.2 SGN2 has produced several draft of the PM-ADS application, none of which been considered satisfactory unanimously by the SGN2 members. The current specification does not allow to introduce the PM variant transparently as it was done for CPDLC.
3.3 Description of the Problem
3.3.1 The ATN model
3.3.1.1 In ATN, the Application-ASEs are responsible for all communication tasks of the Application Entity, on behalf of the Application-Users. These tasks encompass the following functions:
Local user behavior monitoring function: the ASE checks that the user is invoking the communication services as expected (e.g. the user is prohibited from sending an ADS report if no ADS contract has been previously established) and provides the appropriate parameters (e.g. identity of the peer system when requesting the establishment of a CPDLC connection).
Protocol Monitoring function: the ASE is specified as a state machine that enforces protocol rules. For each state is defined a set of allowed events (service primitives from local user, PDU from peer system, etc.) and associated actions.
Peer system monitoring function: the ASE checks that the peer system is actually working and is working according to the specified protocol. In case no response at all is received from the peer when one is expected, the ASE returns in a clean state (connections aborted, contexts and resources released, etc…). Upon detection of error performed by the peer (invalid data, incorrect encoding, invalid used QoS or security parameter, etc…), the ASE informs the peer of the error and decides either to stop completely the communication (abort) or to continue (error message).
“Association” Management function: in order to communicate, users need to establish an association between them. This association takes the form of a “CPDLC connection” (CPDLC or DSC), an “ADS Contract” (on-demand, event, periodic, emergency) or a “FIS Contract” (on-demand or update). The ASEs control that the exchanges of data over this association is compliant with the nature of the association.
Dialogue Management function: the underlying communication system provides both a connection-mode and a connectionless-mode services (the so-called dialogue service). The ASE is responsible for mapping the “associations” (as identified above) on the dialogue service. It is straightforward for CPDLC (there is a one-to-one link between the CPDLC connection and the dialogue). This is more complex for FIS and ADS where multiple contracts between two peers are multiplexed over a single dialogue.
In other words, the ASE is responsible of the technical interoperability during the communication phase.
Figure 1: ASE Functions
3.3.1.2 The Application-Users are focused on the operational processing of the information. They handle “operational message” such as flight plan, an ATC clearance, a pilot response, an ATIS or an ADS report. They do not take part in the communication activity with the peer systems ; instead when communication with a peer system is required, for instance to send an ATC Clearance to an aircraft, the Application-User requests the ASE to perform the data transfer and report about the result of the operation. The Application-Users are responsible of the operational interoperability.
3.3.1.3 In this model, the ASEs do not need to know the structure and the content of the “operational message” to perform the communication tasks. However, the ATN ASEs have also been tasked to ensure that the operational messages handled by the aircraft and the ground systems are compatible (operational message identification & negotiation function ()). This function requires that the ASEs have the visibility over the contents of these messages and support a mechanism to negotiate the version of these messages at connection establishment time. As a consequence, the ASE protocol specification also contains the ASN.1 definition of the operational messages.
3.3.2 The impact of PM on the ATN approach
3.3.2.1 The introduction of the Protected Mode consists for the Application-user in adding a checksum to the operational message. Depending on the parameters used to compute the checksum (source and destination entity identifier, flight identifier, encoded operational message), the checksum allows detection by the recipient of the message of any message corruption and mis-direction.
3.3.2.2 With the Protected Mode, the data exchanged between two peers is now made of two pieces of information: the operational message already encoded, plus a message integrity check (AMIC) computed over the encoded message.
3.3.2.3 As a consequence, the operational message identification and negotiation function () cannot be supported by the ASE and must be supported by the users themselves. The communication functions identified in 2.2.1.1 are still performed by the ASEs, but without the insight of the operational data.
3.3.2.4 Let’s take the CPDLC example. Currently, the ASE and the user exchange together at the Application Service Interface (ASI) the CPDLC message. With the protected mode, what is exchanged at the ASI is not the CPDLC message anymore but a data structure containing the PER-encoded CPDLC Message plus the associated Message Integrity Check.
Figure 2: ASE supporting the Protected Mode
3.3.2.5 The support of the protected mode has for main effect that the ASE is not aware anymore of the content of the Message generated by the user:
· For CPDLC, the ASE does not know the structure nor the contents of the CPDLC messages. For instance, the ASE does not know which message element (e.g. UM163, DM100) is being sent or received by its user.
· For FIS, the ASE does not know the structure nor the contents of the FIS Request and the FIS report. For instance, it will not know what FIS Service is being provided on a contract (e.g. ATIS, METAR).
· For ADS, the ASE does not know the structure nor the contents of the ADS Request and ADS report. For instance, it will not know which ADS blocks or event has been requested by the ground and which ADS blocks are actually supported by the aircraft.
3.3.2.6 In theory, having no visibility on the operational messages should not impair the ASE capability to perform the other functions. For CPDLC and FIS, it does not. Unfortunately, for ADS it does.
3.3.3 The ADS problem
3.3.3.1 There are two problems with ADS. The fist problem is the way the ADS messages have been specified in Doc 9705. In an attempt to simplify the ADS protocol, a mix was done between operational and technical information. As a consequence, the information in the ADS Request or ADS Report is of interest for both the user and the ASE. The second problem is the absence of real safety analysis for ADS-based services, leading to the requirement to protect too much information against corruption.
3.3.3.2 The first problem with ADS is that some information present in the ADS Request, ADS Reply and the ADS Reports is also used by the ASE to perform the contract management and the dialogue management functions ( and ). This information is the following:
· The “positive acknowledgement flag” embedded in the ADS-Report message is used by the ASE to close the contract establishment phase,
· The “positive acknowledgement flag” embedded in the ADS-Report message is used by the ASE to close the contract modification phase,
· The “reply type” (positive ack, negative ack, non compliance notification) embedded in the ADS-Reply message is used by the ASE to close or maintain the ADS contract; and
· The “contract type” (demand, event, periodic) embedded with the ADS Request or the ADS Report is used by the ASE to select the appropriate protocol state machine.
3.3.3.3 The second problem is the definition of the scope of the checksum. Based on the initial safety analysis performed on Baseline 1 ADS-based services, the checksum is required to protect against modification and mis-direction of the operational data of the ADS Requests and ADS Reports. There is no need to protect the positive acknowledgement, the reply type or the contract type as such.
3.3.3.4 An additional problem has been brought up during the SGN2 discussion about the role distribution between the application-user and the ASE. Some people think that function 4 (“association” management) is definitively not a function for the ASE and should be exclusively handled by the application user. This approach leads to the complete redefinition of the ADS application.
3.3.4 Why don’t we have the problem with CPDLC and FIS ?
3.3.4.1 For CPDLC, the management of the CPDLC connection (accept, reject) is separated from the contents of the CPDLC messages. This reply information is not part of the CPDLC message and is presented as separate service parameters to the ASE. Encapsulating the CPDLC message with the checksum has therefore no impact on the visibility of these parameters by the ASEs.
3.3.4.2 For FIS, the information pertaining to the FIS contracts management is not embedded in the operational FIS messages (FIS Request and FIS Reports). Thus, the ASE does not need to look the contents of the operational message to monitor the protocol, or to manage the FIS contracts.
3.4 Description of the Solutions
3.4.1 3 solutions are possible:
1. Keep the current ADS application as much as it is. Duplicate information that is inserted in the protected ADS messages as service parameters for direct use by the ASE;
2. Modify the current ADS application to separate operational and technical data. Consider the ADS contract management is an ASE functions and that the positive acknowledgement, the reply type, the contract type are part of the technical data and do not have do be protected by the checksum. This information is only passed as service parameters and are not included in the ADS messages;
3. Consider the ADS contract management is a user function only and must not be supported at all by the ASE. The positive acknowledgement, the reply type, the contract type are part of the operational data, they are protected by the checksum and are not made visible at all to the ASE. This information is not included in the ADS service parameters.
Figure 3: Alternative Solutions
3.4.2 Solution 1: Basic PM-ADS
3.4.2.1 ADS Contract Management Data that are included in the operational messages and not visible to the PM-ASE but are used by the ASE are duplicated at the service level and at the PDU level.
· Advantages: no impact on the dynamic behavior described in the current SARPs, slight modification to the interface and to the ASN.1. No full validation required, validated specifications available within 6 months. Slight impact on existing ADS implementations. A draft specification is already on the table (December SGN2 meeting).
· Drawbacks: duplication of data at user and ASE level, few bit overhead, not clear role separation between user and ASE.
3.4.3 Solution 2: Enhanced PM-ADS
3.4.3.1 ADS Contract Management Data are deleted from the operational messages and are passed at the ASI as separate ADS service parameters. The ADS service is modified to fully separate the different ADS contract management phases: contract establishment, contract modification, report transfer, contract termination.