international civil aviation organization … · web viewpart i. air-ground applications. chapter...

Doc 9880AN/466

Manual on Detailed TechnicalSpecifications for theAeronautical TelecommunicationNetwork (ATN) using ISO/OSIStandards and Protocols

________________________________

Approved by the Secretary Generaland published under his authority

First Draft Second Edition — 20140

International Civil Aviation Organization

Part I — Air-Ground Applications

2

Published in English only by theINTERNATIONAL CIVIL AVIATION ORGANIZATION999 University Street, Montréal, Quebec, Canada H3C 5H7

For ordering information and for a complete listing of sales agentsand booksellers, please go to the ICAO website at www.icao.int

Doc 9880, Manual on Detailed Technical Specificationsfor the Aeronautical Telecommunication Network (ATN)using ISO/OSI Standards and ProtocolsPart I, Air-Ground ApplicationsOrder Number: 9880P1ISBN 978-92-9231-524-5

© ICAO 2010

All rights reserved. No part of this publication may be reproduced, stored in aretrieval system or transmitted in any form or by any means, without priorpermission in writing from the International Civil Aviation Organization.

3456789

1011121314151617181920212223242526272829303132333435363738394041424344

AMENDMENTS

Amendments are announced in the supplements to the Catalogue of ICAO Publications; the Catalogue and its supplements are available on the ICAO website at www.icao.int. The space below is provided to keep a record of such amendments.

RECORD OF AMENDMENTS AND CORRIGENDA

AMENDMENTS CORRIGENDA

No. Date Entered by No. Date Entered by

(iii)

454647484950515253545556

57

58

TABLE OF CONTENTS

Page

Foreword............................................................................................................................................................ (vii)

Acronyms and Abbreviations.......................................................................................................................... (ix)

Definitions.......................................................................................................................................................... (xi)

Chapter 1. Introduction.................................................................................................................................. 1-11.1 Overview........................................................................................................................................ 1-11.2 Dialogue service (DS).................................................................................................................... 1-2

Chapter 2. Context Management Application.............................................................................................. 2-12.1 Introduction.................................................................................................................................... 2-12.2 General requirements.................................................................................................................... 2-42.3 The abstract service...................................................................................................................... 2-52.4 Formal definitions of messages..................................................................................................... 2-252.5 Protocol definition.......................................................................................................................... 2-312.6 Communication requirements........................................................................................................ 2-852.7 CM-user requirements................................................................................................................... 2-862.8 Subsetting rules............................................................................................................................. 2-100

Chapter 3. Controller-Pilot Data Link Communications Application........................................................ 3-13.1 Introduction.................................................................................................................................... 3-13.2 General requirements.................................................................................................................... 3-33.3 The abstract service...................................................................................................................... 3-33.4 Formal definitions of messages..................................................................................................... 3-163.5 Protocol definition.......................................................................................................................... 3-643.6 Communication requirements........................................................................................................ 3-1103.7 CPDLC-user requirements............................................................................................................ 3-1113.8 Subsetting rules............................................................................................................................. 3-143

Chapter 4. (to be developed) Flight Information Services (FIS) (to be developed) ...................................... 4-1

Chapter 5. Automatic Dependent Surveillance — Contract (ADS-C) (to be developed)........................... 5-1

Chapter 6. ATN Message Integrity Check Algorithm.................................................................................. 6-16.1 Use of the integrity check function................................................................................................. 6-16.2 Default ATN message checksum algorithm.................................................................................. 6-1

______________________

(v)

5960616263646566676869707172737475767778798081828384858687888990919293949596979899

100101102103104105

FOREWORD

This manual amends and replaces the third edition of the Manual of Technical Provisions for the Aeronautical Telecommunication Network (ATN) (Doc 9705). This manual is a result of ongoing validation and operational experience gained during implementation of elements of the ATN. Amendments were reviewed at the first meeting of the Aeronautical Communications Panel (ACP) Working Group of the Whole in June 2005 and further updated at the ACP Working Group N/6 meeting held in July 2006. Relevant background material is available on the website www.icao.int/anb/panels/acp.

This manual contains the detailed technical specifications for the ATN based on relevant standards and protocols established for open systems interconnection (OSI) by the International Organization for Standardization (ISO) and the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T). A separate manual, the Manual on the Aeronautical Telecommunication Network (ATN) using Internet Protocol Suite (IPS) Standards and Protocols (Doc 9896), addresses detailed technical specifications for the ATN based on standards developed for the IPS by the Internet Society (ISOC). Standards and Recommended Practices (SARPs) for the ATN/IPS are contained in Annex 10 — Aeronautical Telecommunications, Volume III — Communication Systems. Where necessary and to avoid duplication of material, Doc 9896 refers to this manual.

Editorial practices in this document are as follows:

• The detailed technical specifications in this manual that include the operative verb “shall” are essential to be implemented to secure proper operation of the ATN.

• The detailed technical specifications in this manual that include the operative verb “should” are recommended for implementation in the ATN. However, particular implementations may not require this specification to be implemented.

• The detailed technical specifications in this manual that include the operative verb “may” are optional.

This manual is published in the following parts:

Part I: Air-Ground Applications (replaces Doc 9705, Sub-volume II)

Part II: Ground-Ground Applications — Air Traffic Services Message Handling Services (ATSMHS) (replaces Doc 9705, Sub-volume III)

Part III: Upper Layer Communications Service (ULCS) and Internet Communications Service (ICS) (replaces Doc 9705, Sub-volumes IV and V)

Part IV: Directory Services, Security Services and Systems Management (replaces Doc 9705, Sub-volumes I, VI, VII, VIII and IX).

(vii)

106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150

Manual on Detailed Technical Specifications for the Aeronautical(viii) Telecommunication Network (ATN) using ISO/OSI Standards and Protocols

Structure of Part I:

This part of Doc 9880 contains technical provisions for air-ground applications. It is structured as follows:

Chapter 1: INTRODUCTION

Chapter 2: CONTEXT MANAGEMENT APPLICATION

Chapter 3: CONTROLLER-PILOT DATA LINK COMMUNICATIONS APPLICATION

Chapter 4: FLIGHT INFORMATION SERVICES (FIS) (to be developedPlaceholder for new application)

Chapter 5: AUTOMATIC DEPENDENT SURVEILLANCE — CONTRACT (ADS-C) (to be developed)

Chapter 6: ATN MESSAGE INTEGRITY CHECK ALGORITHM

______________________

151152153154155156157158159160161162163164165166167168169170

ACRONYMS AND ABBREVIATIONS

ACP Aeronautical Communications PanelADM Administration identifierADS Automatic dependent surveillanceADS-C Automatic dependent surveillance — contractAE Application entityAFI Authority and format identifierAPDU Application protocol data unitARS Administration region selectorASE Application service elementASN.1 Abstract Syntax Notation OneATIS Automatic terminal information serviceATN Aeronautical telecommunication networkATS Air traffic servicesATSC Air traffic service communicationsCF Control functionCM Context managementCnf ConfirmationCPDLC Controller-pilot data link communicationsDLIC Data link initiation capabilityDS Dialogue serviceDSC Downstream clearanceFIS Flight information servicesFU Functional unitIC Integrity checkICAO International Civil Aviation OrganizationICS Internet communications serviceIDI Initial domain identifierIDP Initial domain partIEC International Electrotechnical CommissionIFR Instrument flight rulesInd IndicationIPS Internet Protocol SuiteISO International Organization for StandardizationITU-T International Telecommunication Union — Telecommunication Standardization SectorKm KilometreNm Nautical mileNSEL Network selectorOID Object identifierOSI Open systems interconnectionP/OICS Protocol/Operational Implementation Conformance StatementsPDU Protocol data unitPER Packed Encoding RulesQOS Quality of ServiceRDF Routing domain formatRDP Router domain partReq Request

(ix)

171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220

Manual on Detailed Technical Specifications for the Aeronautical(x) Telecommunication Network (ATN) using ISO/OSI Standards and Protocols

RER Residual error rateRFC Request for commentsRsp ResponseSARPs Standards and Recommended PracticesSSO System security objectTSAP Transport service access pointTSEL TSAP selectorULCS Upper layer communications serviceUTC Coordinated universal timeVER VersionVMC Visual meteorological conditions

______________________

221222223224225226227228229230231232233234235236

DEFINITIONS

Abstract service interface. The abstract interface between the application entity (AE) and the application-user.

Abstract Syntax Notation One (ASN.1). Abstract Syntax Notation One is defined in ISO/IEC 8824-1. The purpose of this notation is to enable data types to be defined, and values of those types specified, without determining their actual representation (encoding) for transfer by protocols.

Addressing plan. A plan that provides common address syntax and management of global addresses for the unambiguous identification of all end and intermediate systems in accordance with the rules prescribed in ISO/IEC 7498-3 and ISO/IEC TR 10730.

Aeronautical administrative communications (AAC). Communications necessary for the exchange of aeronautical administrative messages.

Aeronautical administrative messages. Messages regarding the operation or maintenance of facilities provided for the safety or regularity of aircraft operation. Messages concerning the functioning of the ATN and messages exchanged between government civil aviation authorities relating to aeronautical services.

Aeronautical operational control (AOC). Communication required for the exercise of authority over the initiation, continuation, diversion or termination of flight for safety, regularity and efficiency reasons.

Aeronautical passenger communication (APC). Communication relating to the non-safety voice and data services to passengers and crew members for personal communication.

Air application service element (air-ASE). An abstract part of the aircraft system that performs the communication-related functions of the application.

Air-ground application. An application that has one peer application on an aircraft and its other peer application on the ground. An air-ground application may require the use of ground-ground subnetworks.

Air traffic control (ATC) clearance. Authorization for an aircraft to proceed under conditions specified by an air traffic control unit.

Note 1.— For convenience, the term “air traffic control clearance” is frequently abbreviated to “clearance” when used in appropriate contexts.

Note 2.— The abbreviated term “clearance” may be prefixed by the words “taxi”, take-off”, “departure”, “en-route”, “approach” or “landing” to indicate the particular portion of flight to which the air traffic control clearance relates.

Air traffic control (ATC) instruction. Directives issued by air traffic control for the purpose of requiring a pilot to take specific action.

(xi)

237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283

Manual on Detailed Technical Specifications for the Aeronautical(xii) Telecommunication Network (ATN) using ISO/OSI Standards and Protocols

Air traffic control (ATC) service. A service provided for the purpose of:

a) preventing collisions:

1) between aircraft; and

2) on the manoeuvring area between aircraft and obstructions; and

b) expediting and maintaining an orderly flow of air traffic.

Air traffic services (ATS). A generic term meaning variously, flight information service, alerting service, air traffic advisory service, air traffic control service (area control service, approach control service or aerodrome control service).

Air user (air-user). The abstract part of the aircraft system that performs the non-communication-related functions of the application.

Aircraft address. A unique combination of twenty-four bits available for assignment to an aircraft for the purpose of air-ground communications, navigation and surveillance.

Aircraft flight identification. A group of letters, figures or a combination thereof which is either identical to, or the coded equivalent of, the aircraft call sign to be used in air-ground communication and which is used to identify the aircraft in ground-ground air traffic services communication.

Application. The ultimate use of an information system, as distinguished from the system itself.

Application entity (AE). Part of an application process that is concerned with communications within the OSI environment. The aspects of an application process that need to be taken into account for the purposes of OSI are represented by one or more AEs.

Application entity service interface. The interface between the application-users and the application service provider.

Application entity title. An unambiguous name for an application entity.

Application process (AP). A set of resources, including processing resources, within a real open system which may be used to perform a particular information processing activity.

Application protocol data unit (APDU). An application protocol data unit is an (N) PDU, where N refers to the application layer. An APDU is the basic unit of information exchanged between the airborne application and the ground application.

Application service. The abstract interface between the (N) service and the (N) service user, where N refers to the application layer; thus it is the boundary between the AE and the application user.

Application service element (ASE). The element in the communication system that executes the application specific protocol. In other words, it processes the application specific service primitive sequencing actions, message creation, timer management, and error and exception handling. The application’s ASE interfaces only with the application’s control function.

Application service element (ASE) service interface. The abstract interface through which the ASE service is accessed.

Note.— In version 1 of the ADS-C application, the ADS-ASE service interface coincides with the ADS-AE abstract service interface.

284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337

Part I. Air-Ground ApplicationsDefinitions (xiii)

Application-user. That abstract part of the aircraft or ground system that performs the non-communication-related functions of the application.

ATIS application. An ATN application that supports the ATIS.

ATN application. Refers to an application that is designed to operate over ATN communication services.

ATS communication (ATSC). Communication related to air traffic services including air traffic control, aeronautical and meteorological information, position reporting and services related to safety and regularity of flight. This communication involves one or more air traffic service administrations. This term is used for purposes of address administration.

ATS message. A unit of user-data, coded in binary form, which is conveyed from an originator of the data to one or more recipients of the data. It is possible to associate a unique message identifier and a priority with each ATS message.

ATS unit (ATSU). A generic term meaning variously, air traffic control unit, flight information centre or air traffic services reporting office.

ATSC class. The ATSC class parameter enables the ATSC-user to specify the quality of service expected for the offered data. The ATSC class value is specified in terms of ATN end-to-end transit delay at 95 per cent probability.

Automatic dependent surveillance (ADS). A surveillance technique in which aircraft automatically provide, via a data link, data derived from on-board navigation and position-fixing systems, including aircraft identification, four-dimensional position and additional data as appropriate.

Automatic dependent surveillance – Contract (ADS-C) application. An ATN application that provides ADS data from the aircraft to the ATS unit(s) for surveillance purposes.

Automatic dependent surveillance — contract (ADS-C). A means by which the terms of an ADS-C agreement will be exchanged between the ground system and the aircraft, via a data link, specifying under what conditions ADS-C reports would be initiated, and what data would be contained in the reports.

Note.— The abbreviated term “ADS contract” is commonly used to refer to ADS event contract, ADS demand contract, or an ADS periodic contract or an emergency mode.

Automatic terminal information service (ATIS). The automatic provision of current, routine information to arriving and departing aircraft throughout 24 hours or a specified portion thereof.

Data link-automatic terminal information service (D-ATIS). The provision of ATIS via data link.

Voice-automatic terminal information service (Voice-ATIS). The provision of ATIS by means of continuous and repetitive voice broadcasts.

Context management (CM) application. An ATN application that provides a logon service allowing initial aircraft introduction into the ATN and a directory of all other data link applications on the aircraft. It also includes functionality to forward addresses between ATS units.

Note.— Context management is a recognized OSI presentation layer term. The OSI use and the ATN use have nothing in common.

338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389

Manual on Detailed Technical Specifications for the Aeronautical(xiv) Telecommunication Network (ATN) using ISO/OSI Standards and Protocols

Control function (CF). That abstract part of the AE that performs the mapping between the ASE service primitives, the association control service element (ACSE) service primitives and other elements within the application entity.

Controller pilot data link communication (CPDLC). A means of communication between controller and pilot, using data link for ATC communications.

Controller pilot data link communication (CPDLC) application. An ATN application that provides a means of ATC data communication between controlling, receiving or downstream ATS units and the aircraft, using air-ground and ground-ground subnetworks, and which is consistent with the ICAO phraseology for the current ATC voice communication.

Controlling ATSU (C-ATSU). The air traffic control unit exercising legal authority over the initiation, continuation, diversion or termination of flights and providing air traffic control service to controlled flights in the control area under its jurisdiction.

Current data authority. The designated ground system through which a CPDLC dialogue between a pilot and a controller currently responsible for the flight is permitted to take place.

Data authority. A ground system that provides for the establishment and maintenance of a CPDLC transport connection with an aircraft. The transfer of communication from the current data authority to the next data authority is prepared prior to the actual data link switch by designating a next data authority in a specific CPDLC message.

Data link initiation capability (DLIC). A data link application that provides the ability to exchange addresses, names and version numbers necessary to initiate data link applications.

Dialogue service (DS). The lower service boundary of an ASE; the service allows two ASEs to communicate, e.g. a CM ground-ASE to communicate with a CM air-ASE.

Directory. A facility that supports on request the retrieval of address information or the resolution of application names.

Domain. A set of end systems and intermediate systems that operate according to the same routing procedures and that is wholly contained within a single administrative domain.

Downstream ATSU (D-ATSU). D-ATSU handles the coordination of the conditions of transfer for a flight from the controlling ATSU (C-ATSU) which may notify the D-ATSU of a flight’s cleared profile prior to its effective transfer to the receiving ATSU (R-ATSU).

Downstream clearance (DSC). Specific clearance request by an aircraft to an ATSU that is not the controlling ATSU. The initiation of the DSC service can only be initiated by an aircraft.

Downstream data authority. A designated ground system, different from the current data authority through which the pilot can contact an appropriate ATC unit for the purposes of receiving a downstream clearance.

Emergency contract. A contract to provide ADS reports at regular intervals during an emergency situation.

End system (ES). A system that contains the OSI seven layers and contains one or more end-user application processes.

End-to-end. Pertaining or relating to an entire communication path, typically from (1) the interface between the information source and the communication system at the transmitting end to (2) the interface between the communication system and the information user or processor or application at the receiving end.

390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441

Part I. Air-Ground ApplicationsDefinitions (xv)

End-user. An ultimate source and/or consumer of information.

Entity. An active element in any layer which can be either a software entity (such as a process) or a hardware entity (such as an intelligent I/O chip).

Flight information region (FIR). An airspace of defined dimensions within which flight information service and alerting service are provided.

Flight information service (FIS). A service provided for the purpose of giving advice and information useful for the safe and efficient conduct of flights.

Flight information service (FIS) application. An ATN application that provides to aircraft information and advice useful for the safe and efficient conduct of flight.

Flight plan. Specified information provided to air traffic services units, relative to an intended flight or portion of a flight of an aircraft.

Note.— Specifications for flight plans are contained in Annex 2 — Rules of the Air. A model Flight Plan Form is contained in the Procedures for Air Navigation Services — Air Traffic Management (PANS-ATM, Doc 4444), Appendix 2.

General communication. A category of communications that includes APC, public correspondence and other non-operational and non-administrative communication.

Ground application service element (ground-ASE). An abstract part of the ground system that performs the communication-related functions of the application.

Ground forwarding function. The capability for a ground system to forward a CPDLC message to another ground system via a CPDLC message with an indication of success, failure or non-support from the receiving ground system. This function may be invoked by the current data authority in order to avoid retransmission of a request by an aircraft by forwarding the information to the next data authority. The downstream data authority may use this function in order to relay a message to the current data authority which then performs the actual transmission to the aircraft.

Ground user (ground-user). The abstract part of the ground system that performs the non-communication-related functions of the application.

International Alphabet No. 5 (IA5). International Alphabet Number 5 defined by ITU-T.

Note.— ATN uses the “6-bit ASCII” subset of 1A5, as used in SSR Mode S specifications.

Internet communications service (ICS). The Internet communications service is an internetwork architecture which allows ground, air-to-ground and avionics data subnetworks to interoperate by adopting common interface services and protocols based on the ISO/OSI reference model.

Internetwork. A set of interconnected, logically independent heterogeneous subnetworks. The constituent subnetworks are usually administrated separately and may employ different transmission media.

Internetworking protocol (IP). A protocol that performs the basic end-to-end mechanism for the transfer of data packets between network entities. In the ATN Internet communications service, the ISO/IEC 8473 internetwork protocol is used.

442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493

Manual on Detailed Technical Specifications for the Aeronautical(xvi) Telecommunication Network (ATN) using ISO/OSI Standards and Protocols

Interoperability. Describes the ability of the ATN to provide, as a minimum, a transparent data transfer service between end systems even though the ATN comprises various ground, air-to-ground and avionics subnetworks. The ability to interoperate between end systems can be extended to include commonality of upper layer protocols.

Long transport service access point (TSAP). Composed of the router domain part (RDP) and the short TSAP.

Lower layers. The physical, data link, network and transport layers of the OSI reference model.

Managed object. Data processing and data communication resources that may be managed through the use of the OSI management protocol.

Message. Basic unit of user information exchanged between an airborne application and its ground counterpart or between two ground applications. Messages are passed in one or more data blocks from one end-user to another through different subnetworks.

Message element. A component of a message used to define the context of the information exchanged.

Message element identifier. The ASN.1 tag of the ATCUplinkMsgElementId or the ATCDownlinkMsgElementId.

Mobile subnetwork. A subnetwork connecting a mobile system with another system not resident in the same mobile platform. These subnetworks tend to use free-radiating media (e.g. VHF/UHF radio, D-band satellite or D-band secondary surveillance radar) rather than contained media (e.g. wire or coaxial cable); thus they exhibit broadcast capabilities in the truest sense.

Naming plan. A plan that provides common naming conventions and designations for the unambiguous identification of all end and intermediate systems in accordance with the rules prescribed in ISO/IEC 7498-3, ISO/IEC TR 10730 and ISO/IEC 9545.

Network addressing domain. A subset of the global addressing domain consisting of all the NSAP addresses allocated by one or more addressing authorities.

Network entity (NE). A functional portion of an internetwork router or host computer that is responsible for the operation of internetwork data transfer, routing information exchange and network layer management protocols.

Network service access point (NSAP). Point within the ISO protocol architecture at which global end-users may be uniquely addressed on an end-to-end basis.

Network service access point (NSAP) address. A hierarchically organized global address supporting international, geographical and telephony-oriented formats by way of an address format identifier located within the protocol header. Although the top level of the NSAP address hierarchy is internationally administered by ISO, subordinate address domains are administered by appropriate local organizations.

Network service access point (NSAP) address prefix. Used to identify groups of systems that reside in a given routing domain or confederation. An NSAP prefix may have a length that is either smaller than or the same size as the base NSAP address.

Network topology map. Provides an overall view of the global network connectivity and is used in path computations by the operative routing algorithm.

Next data authority. The ground system so designated by the current data authority through which an onward transfer of communications and control can take place.

494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545

Part I. Air-Ground ApplicationsDefinitions (xvii)

NOTAM. A notice distributed by means of telecommunication containing information concerning the establishment, condition or change in any aeronautical facility, service, procedure or hazard, the timely knowledge of which is essential to personnel concerned with flight operations.

Open systems interconnection (OSI) protocol architecture. A set of protocols used to implement the OSI reference model.

Open systems interconnection (OSI) reference model. A model providing a standard approach to network design introducing modularity by dividing the complex set of functions into seven more manageable, self-contained, functional layers. By convention these are usually depicted as a vertical stack.

Note.— The OSI reference model is defined by ISO/IEC 7498-1.

Operational requirement. A statement of the operational attributes of a system needed for the effective and/or efficient provision of air traffic services to users.

Packed Encoding Rules (PER). Encoding rules, as defined in ISO/IEC 8825-2, that have been designed to minimize the number of bits transmitted.

Performance requirements. Requirements that define a function’s characteristics, such as reliability, availability, response time, processing delay, integrity, that are necessary to meet the operational requirements for a specific application of the function.

Presentation data value (PDV). The unit of information specified in an abstract syntax, which is transferred by the OSI presentation service (ISO/IEC 8822).

Priority (P). The relative importance of a particular protocol data unit (PDU) relative to other PDUs in transit and used to allocate resources which become scarce during the transfer process.

Profile. Defines implementation conformance constraints on a set of reference specifications.

Protocol. A set of rules and formats (semantic and syntactic) that determines the communication behaviour between peer entities in the performance of functions at that layer.

Protocol data unit (PDU). (1) A unit of data transferred between peer entities within a protocol layer consisting of protocol control information and higher layer user data (i.e. service data units). (2) A unit of data specified in an (N) protocol and consisting of (N) protocol control information and possibly (N) user data, where N indicates the layer.

Protocol implementation conformance statement (PICS). A protocol implementation conformance statement enables conformance testing of protocols. As recommended by ISO/IEC 9646-2, PICS pro forma, tailored to ATN context, have been developed as ATN profile requirements list (APRLs) to provide an effective basis for conformance testing of implementations.

Quality of service (QOS). The information relating to data transfer characteristics used by various communication protocols to achieve various levels of performance for network users.

Receiving ATSU (R-ATSU). The next air traffic control unit which is in the process of accepting the control authority and communication responsibility for a flight transferred by the controlling ATSU (C-ATSU).

Runway visual range (RVR). The range over which the pilot of an aircraft on the centre line of a runway can see the runway surface markings or the lights delineating the runway or identifying its centre line.

546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597

Manual on Detailed Technical Specifications for the Aeronautical(xviii) Telecommunication Network (ATN) using ISO/OSI Standards and Protocols

Secondary surveillance radar (SSR). A surveillance radar system which uses transmitters/receivers (interrogators) and transponders.

Security label. May indicate requirements for protection of a protocol data unit (PDU) and provide information used by network layer access control functions.

Service data unit (SDU). A unit of data transferred between adjacent layer entities, which is encapsulated within a protocol data unit (PDU) for transfer to a peer layer.

Service primitive. A function of an application service element (ASE) that is not broken down further into subfunctions and is presented as part of the abstract service interface (i.e. request, indication, response or confirmation).

Service provider. An entity at a layer that provides services to the layer above. These services are provided at service access points through the use of service primitives.

Short transport service access point (TSAP). Composed of the administrative region selector (ARS), (Optional), the location identifier (LOC), the system identifier (SYS), the network selector (SEL) and the transport selector (TSAP selector).

System application. An application supports the operation of the air-ground applications, ground-ground applications or communication services. A system application can take the form of either an air-ground application or a ground-ground application.

System level requirement. The system level requirement is a high-level technical requirement that has been derived from operational requirements, technological constraints and regulatory constraints (administrative and institutional). The system level requirements are the basis for the functional requirements and lower-level requirements.

Traffic category. A subdivision of the operational communication traffic type used to distinguish between ATS communication and aeronautical operational control (AOC).

Traffic type. A means used to distinguish different types of message traffic for the purposes of establishing communication paths to support operational and legal requirements. There are four traffic types:

a) the operational communication traffic type, which is subdivided into the following two categories representing safety and regularity of flight communication:

1) ATS communication; and

2) aeronautical operational control;

b) administrative communication, representing non-safety and regularity of flight communication sent by aircraft operating agencies and ATS administrations;

c) general communication, representing APC, public correspondence and other non-operational and non-administrative communication; and

d) systems management communication, representing systems management information that is critical for support of network operations.

598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646

Part I. Air-Ground ApplicationsDefinitions (xix)

Note.— The differentiation of traffic types is required because different data traffic may have different access to subnetworks. The traffic type is conveyed in the ATN security label of ISO/IEC 8473 and ISO/IEC 10747. It is used to qualify connectionless mode network protocol (CLNP) data packets and (inter-domain) routes according to the class of traffic that they carry. Based on this qualification, access of subnetworks is controlled by the ATN Internet communications service.

User requirements. Requirements that are allocated to the user to ensure the interoperability of the communication services and application entities.

______________________

647648649650651652653654655656657658659

Chapter 1

INTRODUCTION

1.1 OVERVIEW

1.1.1 General

Included in this part of Doc 9880 are technical provisions for:

a) context management (CM);

b) controller-pilot data link communications (CPDLC);

c) flight information services (FIS) (in preparation);

dc) automatic dependent surveillance — contract (ADS-C) (in preparation); and

ed) ATN message integrity check algorithm.

1.1.2 Context management (CM)

1.1.2.1 The CM application allows addressing capability for data link applications. It provides the capability to establish a logon between peer ATS ground systems and ATS ground and aircraft systems. Once an appropriate connection is established, CM provides data link application information, the capability to logon to another ground system and the capability to update logon information.

1.1.2.2 The CM application needs to be considered in the context of the guidance material for the data link initiation capability (DLIC), as provided in the Manual of Air Traffic Services Data Link Applications (Doc 9694, Part II). The DLIC process supports addressing requirements for ATS such as CPDLC, FIS and ADS-C.

1.1.3 Controller-pilot data link communications (CPDLC)

1.1.3.1 The CPDLC application allows data link communications between controllers and pilots.

1.1.3.2 The CPDLC application provides the capability to establish, manage and terminate CPDLC dialogues between ATS ground and aircraft system peers. Once a dialogue is established, CPDLC provides for message exchange between the controller and the pilot. The CPDLC application supports a variety of operational data link services, depending upon the CPDLC message and operational procedures applied.

1.1.3.3 Also provided by the CPDLC application is the capability to establish, manage and terminate CPDLC dialogues between two ATC ground system peers for the purpose of ground-ground forwarding of a CPDLC message.

1-1

660

661

662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708

Manual on Detailed Technical Specifications for the Aeronautical1-2 Telecommunication Network (ATN) using ISO/OSI Standards and Protocols

1.1.3.4 The CPDLC application includes an end-to-end protection of message integrity by an application level integrity check that also provides assurance of correct delivery.

1.1.3.5 The CPDLC application complies with the provisions in the fifteenth edition of the Procedures for Air Navigation Services — Air Traffic Management (PANS-ATM, Doc 4444), Chapter 14 (Controller-pilot data link communications (CPDLC)) and Appendix 5 (CPDLC message set). It also complies with the provisions in Doc 9694, Part IV.

1.1.3.56 Depending upon the message subset and operational procedures applied, the CPDLC application supports a variety of operational data link services.

1.1.4 Flight information services (FIS)

(To be developed.)

1.1.45 Automatic dependent surveillance — contract (ADS-C)

1.1.4.1 The ADS-C application allows ground systems to retrieve aircraft-generated data.

1.1.4.2 The ADS-C application provides the capability to establish, manage and terminate demand, periodic and event ADS-C contracts between ATS ground and aircraft system peers.

(To be developed.)

1.1.4.3 The ADS-C application includes an end-to-end protection of message integrity by an application level integrity check.

1.1.56 ATN message integrity check algorithm

The integrity check algorithm may optionally be invoked by the ATN application-user specification to provide a proof of message integrity, as well as proof of delivery to an intended recipient, etc. The default ATN message checksum algorithm is discussed in Chapter 6.

1.2 DIALOGUE SERVICE (DS)

Throughout Part I, references to dialogue services (D-START, D-DATA, D-END, D-ABORT, D-P-ABORT) are references to the DS specified in Part III of this manual.

______________________

709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755

Chapter 2

CONTEXT MANAGEMENT APPLICATION

2.1 INTRODUCTION

2.1.1 Overview

This chapter is designed as follows:

• Section 2.1 — INTRODUCTION: Besides outlining the material covered in Chapter 2, this section provides a description of the functions of the CM application.

• Section 2.2 — GENERAL REQUIREMENTS: This section focuses on the CM-ASE version number and error-processing requirements.

• Section 2.3 — THE ABSTRACT SERVICE: The description of the abstract service provided by the CM application service element (CM-ASE) is contained in this section.

• Section 2.4 — FORMAL DEFINITIONS OF MESSAGES: This section contains the formal definitions of messages exchanged by CM-ASEs using Abstract Syntax Notation One (ASN.1).

• Section 2.5 — PROTOCOL DEFINITION: This section describes the exchanges of messages allowed by the CM protocol, as well as time constraints. It also provides CM-ASE protocol descriptions and state tables.

• Section 2.6 — COMMUNICATION REQUIREMENTS: The requirements that the CM application imposes on the underlying communication system are covered in this section.

• Section 2.7 — CM-USER REQUIREMENTS: This section contains requirements imposed on the user of the CM-ASE service.

• Section 2.8 — SUBSETTING RULES: The conformance requirements that all implementations of the CM protocol obey are covered in this section.

2.1.2 Description of the functions of the CM application

2.1.2.1 Logon function

2.1.2.1.1 The logon function provides a means for an aircraft and a ground system to exchange ATN application information. The logon function has two variants — secure and unsecure. Secure logons are only available to version 2 CM systems. Version 2 CM systems have the option of performing secure or unsecure logon functionsThe security mechanism is assumed to be able to be inititated by indication from the dialog service.

2-1

756

757

758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804


Note. – The specific security mechanisms that may provide the security functionality are out of scope for this document.805806807

Part I. Air-Ground ApplicationsChapter 2. Context Management Application 2-3

2.1.2.1.2 The logon function can only be air-initiated. The aircraft system can use the logon function to provide an application name and version number for each air-only-initiated application, and an application name, address and version number for each application that the aircraft wishes to use that can be ground-initiated, along with flight plan information as required by the ground system. Additionally, if the aircraft is a version 2 CM, it can provide the Security Requirements parameter. This parameter will have different values depending on whether or not the logon will be requesting secure or unsecure services. Version 1 CM applications cannot provide the Security Requirements parameter. The user data in the CM-logon request is the same for both secure and unsecure services. In response, the ground provides an application name for each ground-only-initiated requested application, and an application name, address and version number for each requested application that can be air-initiated and that the ground can support. For version 2 CM, iIf a secure logon service is requested and is able to be supported, the response to the CM-logon request will also include additional security information as well as the Security Requirements parameter and may result in additional security information processing. However, a successful secure logon function does not guarantee that other applications (such as ADS-C and, CPDLC and FIS) will be able to be run in a secure mode — that will be dependent on local security policy.

2.1.2.1.3 For version 2 CM, an “emulated version” CM-logon can also be performed. This option may be used in order to start a CM-logon service with a known earlier version ground CM application.

2.1.2.1.43 Up to a maximum of 256 applications can be supported by the logon function.

2.1.2.1.54 Each time a logon is accomplished between a given aircraft and a ground system, the latest exchanged information replaces any previous information for each indicated application.

2.1.2.1.65 The CM-logon request message provides required flight plan information, the aircraft’s CM application name and address, and information for each application for which data link services are desired. For each application that can be ground-initiated, the aircraft must provide the application name, version number and address. For each application that is only air-initiated, the aircraft must provide the application name and version number.

2.1.2.1.76 The CM-logon response message provides information for the logon-indicated air-initiated applications. For each desired air-initiated application, the ground provides the application name, version number and address. For version 2 CM, if security is supported, tThe CM-logon response message also contains the key for each application, as well as an indication of the key’s domain applicabilityservice also contains an indication of whether or not security is desired for the exchange.

Note. – The specific security mechanisms that may provide the security functionality are out of scope for this document.

2.1.2.2 Server facility query function

2.1.2.2.1 The server facility query function is only available for version 2 CM. It may be secure or unsecure. The server facility query function can only be air-initiated. The aircraft can use the server facility query function to provide application information to a ground system supporting CM server functionality. In addition, the aircraft can specify up to eight facility designations with which it wishes to perform data link services. In response, the ground provides application information for each of the facility designations specified. If secure services are supported and requested, the ground will also reply with key information and domain usage information for each application. However, a successful secure server facility query function does not guarantee that other applications (such as ADS-C and, CPDLC and FIS) will be able to be run in a secure mode — that will be dependent on local security policy. The ground may also reply with a message saying the service is not supported or unavailable.

2.1.2.2.2 Up to a maximum of 256 applications can be supported by the server facility query function.

2.1.2.2.3 Each time a server facility query is accomplished between a given aircraft and a ground system, the latest

808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859


exchanged information replaces any previous information for each indicated application.

2.1.2.2.4 The CM server facility query request message provides required flight plan information, the aircraft's CM application name and address, up to eight facility designations with which the aircraft wishes to perform data link services, and information for each application on the aircraft for which data link services are desired. For each application that can be ground-initiated, the aircraft must provide the application name, version number and address. For each application which is only air-initiated, the aircraft must provide the application name and version number.

2.1.2.2.5 The CM server facility query response message provides application information for each of the facility designations as indicated by the server facility query request. For each application that can be air-initiated, the ground system must provide the application name, version number and address. For each application that is only ground-initiated, the ground system must provide the application name and version number. Additionally, if secure services are supported and requested, the ground system must also provide key information and domain usage applicability for each application, if available.

2.1.2.3 Server facility update function

2.1.2.3.1 The server facility update function is only available for version 2 CM, and may be secure or unsecure. This function provides a method for the ground system to update application information for up to eight facility designations. This function assumes that the server facility query function has been accomplished.

2.1.2.3.2 The CM server facility update message can provide updated ground information for up to 256 applications for each of up to eight different facilities. For each updated application, the ground provides the application's name, version number and address, if applicable. Additionally, if secure services are supported and requested, the ground system must also provide key information and domain usage applicability for each application, if available.

2.1.2.34 Update function

2.1.2.34.1 The update function provides a method for the ground system to update application information. This function assumes that the logon function has been accomplished.

2.1.2.34.2 The CM-update service also contains an indication of whether or not security is desired for the exchange.

Note. – The specific security mechanisms that may provide the security functionality are out of scope for this document.For version 2 CM, both secure and unsecure update functions are available.

2.1.2.34.3 The CM update message can provide updated ground information for up to 256 applications. For each updated application, the ground provides the application’s name, version number and address. For version 2 CM secure updates, security information for each application (key and domain usage indication) is also included. However, a successful secure update function does not guarantee that other applications (such as ADS, CPDLC and FIS) will be able to be run in a secure mode — that will be dependent on local security policy.

2.1.2.45 Contact function

2.1.2.45.1 The contact function provides a method for the ground system to request the aircraft system to initiate the logon function with a designated ground system. It is expected that the contact function will only be used when ground connectivity is not available between respective ground system applications. This function assumes that the logon function has been accomplished with the ground system initiating the contact function. The ground initiates this function with a contact request specifying the ground system with which to logon. The aircraft initiates a logon as specified

860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892893894895896897898899900901902903904905906907908909910911


in 2.1.2.1 and indicates the success or lack thereof of the logon. For version 2 CM, tThe contact function may be secure or unsecure. There are no differences in the user data provided by the CM-ground-user or CM-air-user; only the provision of the Security Requirements parameter is different.


2.1.2.45.2 The CM contact request message provides the ground system CM application address that the initiating ground system is requesting the aircraft to logon with.

2.1.2.45.3 The CM contact response message provides the information indicating whether or not the requested contact was successful.

2.1.2.56 Forward function

2.1.2.56.1 The forward function provides a method for a ground system to forward aircraft information received from the CM-logon function to another ground system. This function is initiated by a ground system that supports ground-ground forwarding. After an aircraft has completed a successful logon with that ground system, that ground system can then forward the aircraft CM-logon information to other ground systems. It is a one-way forwarding of information with an indication of success, failure or non-support from the receiving ground system. If the ground system receiving this CM information supports ground-ground forwarding, it can then initiate a CM update function to provide information to the aircraft for any air-initiated applications.

2.1.2.56.2 The CM-forward request message contains the information as provided in the initial logon.

2.1.2.56.3 The CM-forward service also contains an indication of whether or not security is desired for the exchange.

Note. – The specific security mechanisms that may provide the security functionality are out of scope for this document.For version 2 CM, the CM-forward function may be secure or unsecure. In addition, the version 2 CM-forward function includes the aircraft’s CM version number along with the aircraft’s CM-logon information.

2.1.2.67 Registration function

2.1.2.67.1 The registration function provides a method for the air and ground CM applications to make available the application name, address and version number for each application exchanged in the logon, update or forward functions to other applications or communications systems in the aircraft or on the ground.

2.1.2.67.2 For version 2 CM, rRegistration may also includes additional security functionality. For CM ground systems, thisThis security functionality is beyond the scope of this document, but may includes retrieving the key agreement public keys and domain usage information for each supported application from the directory maintaining that information, and making it available to the user of each application (such as CPDLC) as well as to the secure dialogue service (DS). For CM aircraft systems, this includes making the key agreement public keys and domain information received from a ground system available to the user of each application (such as CPDLC) as well as to the secure DS-provider. These steps are necessary in order for other secure services to be used. Additionally, local procedures may call for further directory interaction in order to retrieve information from, or submit updated information to, the directory.

2.1.2.67.3 There are no standard message exchanges for the registration function.

2.2 GENERAL REQUIREMENTS

912913914915916917918919920921922923924925926927928929930931932933934935936937938939940941942943944945946947948949950951952953954955956957958959960961962963


2.2.1 CM-ASE version number

The CM-air-ASE and CM-ground-ASE version numbers shall both be set to one (basic CM functionality) or two (extended CM functionality).

Note.— The extended CM functionality provides additional capability to CM-users: it allows a CM-air-user to request information for multiple ground facilities, a CM-ground-user to give an aircraft information for multiple ground facilities, authentication and data integrity services to be performed for air-ground and ground-ground dialogues, and the requirement to obtain information from a directory.

2.2.2 Error-processing requirements

2.2.2.1 In the event of information input by the CM-user being incompatible with that which is able to be processed by the system, the CM-user shall be notified.

2.2.2.2 In the event of a CM-user invoking a CM service primitive when the CM-ASE is not in a state specified in 2.5, the CM-user shall be notified.

2.3 THE ABSTRACT SERVICE

2.3.1 Service description

2.3.1.1 An implementation of either the CM ground-based service or the CM air-based service shall exhibit external behaviour consistent with having implemented a CM-ground-ASE or CM-air-ASE, respectively.

2.3.1.2 This section defines the abstract service interface for the CM service. The CM-ASE abstract service is described from the viewpoint of the CM-air-user, the CM-ground-user and the CM service provider.

2.3.1.3 This section defines the static behaviour (i.e. the format) of the CM abstract service. Its dynamic behaviour (i.e. how it is used) is described in 2.7.

2.3.1.4 Figure 2-1 shows the CM application. The functional modules identified in the CM application are the following:

a) the CM-user;

b) the CM application entity (CM-AE) service interface;

c) the CM-AE;

d) the CM control function (CM-CF);

e) the CM application service element (CM-ASE) service interface;

f) the CM-ASE; and

g) the DS interface.

964965966967968969970971972973974975976977978979980981982983984985986987988989990991992993994995996997998999

1000100110021003100410051006100710081009101010111012101310141015


2.3.1.5 The CM-user represents the operational part of the CM system. This user does not perform the communication functions but relies on a communication service provided to it via the CM-AE through the CM-AE service interface. The individual actions at this interface are called CM-AE service primitives. Similarly, individual actions at other interfaces in the communication system are called service primitives at these interfaces.

2.3.1.6 The CM-AE consists of several elements including the CM-ASE and the CM-CF. The DS interface is made available by the CM-CF to the CM-ASE for communication with the peer CM-ASE.

2.3.1.7 The CM-ASE is the element in the communication system that executes the CM-specific protocol. In other words, it takes care of the CM-specific service primitive sequencing actions, message creation, timer management, and error and exception handling.

Figure 2-1. Functional model of the CM application

2.3.1.8 The CM-ASE interfaces only with the CM-CF. This CM-CF is responsible for mapping service primitives received from one element (such as the CM-ASE and the CM-user) to other elements that interface with it. The part of the CM-CF that is relevant from the point of view of the CM application, i.e. the part between the CM-user and the CM-ASE, will map CM-AE service primitives to CM-ASE service primitives transparently.

2.3.1.9 The DS interface is the interface between the CM-ASE and the part of the CM-CF underneath the CM-ASE, and provides the DS as defined in Part III of this manual.

2.3.2 The CM-ASE abstract service

2.3.2.1 There is no requirement to implement the CM-ASE abstract service in a CM product; however, it is necessary to implement the ground-based and air-based system in such a way that it will be impossible to detect (from the peer system) whether or not an interface has been built.

2.3.2.2 The CM-ASE abstract service shall consist of a subset of the following services as allowed by the subsetting rules in 2.8:

a) CM-logon service as defined in 2.3.3;

b) for CM version 2, CM-server-facility-query service as defined in 2.3.4;

bc) CM-update service as defined in 2.3.54;

Contro l fu nc tio n

C M appl icationse rv ic e e le m e n t

CM ap pl ication en tity

Con tro l func tio nD ia lo gu e serv ice interface

CM ap pl ica tion se rviceelem en t serv ice interface

CM appl ication en tityserv ice inte rfa ce

CM -air-useror

C M -gro un d-user

101610171018101910201021102210231024102510261027

10291030103110321033103410351036103710381039104010411042104310441045104610471048104910501051105210531054


d) for CM version 2, CM-server-facility-update service as defined in 2.3.6;

ec) CM-contact service as defined in 2.3.57;

fd) CM-end service as defined in 2.3.86;

ge) CM-forward service as defined in 2.3.79;

hf) CM-user-abort service as defined in 2.3.810; and

ig) CM-provider-abort service as defined in 2.3.911.

2.3.2.3 For a given primitive, the presence of each parameter is described by one of the following values in the parameter tables in 2.3:

blank not present;

C conditional upon some predicate explained in the text;

C(=) conditional upon the value of the parameter to the immediate left being both present and equal;

M mandatory;

M(=) mandatory, and equal to the value of the parameter to the immediate left; or

U user option.

2.3.2.4 The following abbreviations are used in Chapter 2 of this manual:

Req request; data is input by the CM-user initiating the service to its respective ASE;

Ind indication; data is indicated by the receiving ASE to its respective CM-user;

Rsp response; data is input by the receiving CM-user to its respective ASE; and

Cnf confirmation; data is confirmed by the initiating ASE to its respective CM-user.

2.3.2.5 An unconfirmed service allows a message to be transmitted in one direction without providing a corresponding response.

2.3.2.6 A confirmed service provides end-to-end confirmation that a message sent by one user was received by its peer user.

2.3.2.7 An abstract syntax is a syntactical description of a parameter that does not imply a specific implementation. Only when the CM-ASE maps a parameter onto an application protocol data unit (APDU) field, or vice versa, is the abstract syntax of the parameter described by using the ASN.1 at 2.4 for this field.

2.3.3 CM-logon service

1055105610571058105910601061106210631064106510661067106810691070107110721073107410751076107710781079108010811082108310841085108610871088108910901091109210931094109510961097109810991100110111021103110411051106


2.3.3.1 General

2.3.3.1.1 The CM-logon service allows the CM-air-user to initiate data link service. The CM-air-user provides information on each data link application for which it desires a data link service. The CM-ground-user responds indicating whether or not the CM-logon was successful, and if successful, includes information on each data link application it can support. It is a confirmed service.

2.3.3.1.2 For CM version 2 CM-logon service, tThe CM-air-user will set the Security Requirements parameter as required for the particular airspace. A version 2 CM-air-user may attempt either a secure or an unsecure CM-logon service.


Additionally, if it is known that the peer CM ground system is an earlier version CM, then the sending CM-air-user may indicate to the CM-air-ASE that it wishes to run in a previous version mode through the Emulated Version parameter. If this parameter is used, no other version 2 CM services may be invoked with that ground system.2.3.3.1.3 If the CM-air-ASE version number is less than or equal to the CM-ground-ASE version number, then the CM-logon service shall contain the primitives and parameters as presented in Table 2-1.

Table 2-1. CM-logon service parameters —air-ASE version number ≤ ground-ASE version number

Parameter name Req Ind Rsp Cnf

Facility Designation M

Aircraft Address M M(=)

CM-ASE Version Number C

Logon Request M M(=)

Logon Response M M(=)

Class of Communication Service U

Maintain Dialogue U C(=)

Security Required M M(=) C(=)

Emulated Version U

2.3.3.1.4 If the CM-air-ASE version number is greater than the CM-ground-ASE version number, then the CM-logon service shall contain the primitives and parameters as presented in Table 2-2.

Table 2-2. CM-logon service parameters —air-ASE version number > ground-ASE version number

110711081109111011111112111311141115111611171118111911201121112211231124112511261127112811291130

113111321133113411351136113711381139


Parameter name Req Cnf


Aircraft Address M

CM-ASE Version Number M

Logon Request M


Security Required M

Emulated Version U

2.3.3.2 Facility Designation parameter

2.3.3.2.1 This parameter contains the addressed ground system’s facility designation.

2.3.3.2.2 The Facility Designation parameter value shall conform to the abstract syntax four- to eight-character facility designation.

2.3.3.3 Aircraft Address parameter

2.3.3.3.1 The Aircraft Address parameter contains the ICAO 24-bit aircraft address of the aircraft initiating the CM-logon service.

2.3.3.3.2 The Aircraft Address parameter value shall conform to the abstract syntax of the ICAO 24-bit aircraft address.

2.3.3.4 CM-ASE Version Number parameter

2.3.3.4.1 This parameter contains the version number of the CM-ASE.

2.3.3.4.2 When provided by the CM-ASE, the CM-ASE Version Number parameter shall conform to an abstract integer value from 1 to 255.

2.3.3.4.3 Only if the CM-air-ASE version number is less than the CM-ground-ASE version number shall the CM-air-ASE version number be indicated to the CM-ground-user.

2.3.3.4.4 Only if the CM-air-ASE version number is greater than the CM-ground-ASE version number shall the CM-ground-ASE version number be confirmed to the CM-air-user.

2.3.3.4.5 If the CM-air-ASE version number is the same as the CM-ground-ASE version number, the CM-ASE Version Number parameter is not present in the indication given to the CM-ground-user or in the confirmation to the CM-air-user.

2.3.3.5 Logon Request parameter

114011411142114311441145114611471148114911501151115211531154115511561157115811591160116111621163116411651166116711681169117011711172117311741175117611771178


2.3.3.5.1 The Logon Request parameter contains the following data:

a) information for each data link application available on the aircraft, for which the aircraft requires data link service; and

b) aircraft flight plan information (e.g. flight identification, aircraft destination and departure airport and time) as required by the addressed ground system.

2.3.3.5.2 The Logon Request parameter value shall conform to the ASN.1 abstract syntax CMLogonRequest.

2.3.3.6 Logon Response parameter

2.3.3.6.1 The Logon Response parameter contains information for each requested data link application for which the ground is able to provide data link service. For the CM version 2 secure CM-logon service, this parameter also contains key and domain usage information for each application.

2.3.3.6.2 For CM version 1, tThe Logon Response parameter value shall conform to the ASN.1 abstract syntax CMLogonResponse.

2.3.3.6.3 For CM version 2, the Logon Response parameter value shall conform to the ASN.1 abstract syntax CMSecureLogonResponse.

2.3.3.6.4 For unsecure CM version 2, no security information is provided in the CMSecureLogonResponse.

2.3.3.7 Class of Communication Service parameter

2.3.3.7.1 This parameter contains the value of the required class of communication service if specified by the CM-air-user.

2.3.3.7.2 When the Class of Communication Service parameter is specified by the CM-air-user, this parameter shall have one of the following abstract values: “A”, “B”, “C”, “D”, “E”, “F”, “G” or “H”.

2.3.3.7.3 If the Class of Communication Service parameter is not specified by the CM-air-user, it indicates that there is no routing preference.

2.3.3.8 Maintain Dialogue parameter

2.3.3.8.1 The Maintain Dialogue parameter is used to indicate whether or not the requested CM dialogue is to remain open after a Logon Response.

2.3.3.8.2 Whenever a CM dialogue is kept open by the CM-ground-user, it must later be explicitly closed by the CM-ground-user.

2.3.3.8.3 This parameter is only provided by the CM-ground-user when the CM-ground-user wishes to keep the CM dialogue open.

2.3.3.8.4 If provided by the CM-ground-user, this parameter shall have the abstract value “maintain”.

1179118011811182118311841185118611871188118911901191119211931194119511961197119811991200120112021203120412051206120712081209121012111212121312141215121612171218121912201221122212231224122512261227122812291230


2.3.3.9 Security Required parameter

2.3.3.9.1 The Security Required parameter contains an indication of whether or not a CM version 2 requires security. It is used by the requester of the version 2 CM-logon service and is indicated to the responder. It is not used by version 1 CM.


2.3.3.9.2 If the received Security Required parameter is not as expected per the local security policy, the CM-ground-ASE will abort. The CM-ground-user will use the indicated Security Required parameter to determine whether or not to return key information to the requesting aircraft. This is necessary for the case where a ground system can provide both secure and unsecure services.

2.3.3.9.3 The value of the Security Required parameter provided by the CM-air-user shall be indicated to the CM-ground-user.

2.3.3.9.4 When the CM-air-user requires a secure CM-logon service, the Security Required parameter shall have the abstract value “secured dialogue supporting key managementsecured dialogue supporting security information management”.

Note.— This is to give an indication to the CM-ground-user that security is to be used. However, the specific security mechanisms that may provide the security functionality are out of scope for this document

2.3.3.9.5 When the CM-air-user requires an unsecure CM-logon service or the CM-air-user is communicating with a CM version 1 ground system, the Security Required parameter shall have the abstract value “no security”.

Note.— This is to give an indication to the CM-ground-user that security is not to be used. However, the CM-ground-user will have the ultimate decision of whether or not security is required. If security is required by the ground system but not requested by the aircraft, the aircraft may be denied data link services.

2.3.3.10 Emulated Version parameter

2.3.3.10.1 The Emulated Version parameter is used by a CM-air-user to indicate that the CM-air-ASE is to operate in a degraded mode, i.e. to emulate a previous CM version. If this parameter is provided, the CM-air-user must ensure that no services incompatible with the CM version emulated are invoked. This parameter is not used by version 1 CM.

2.3.3.10.2 This parameter is not normally provided for a first logon unless there is explicit a priori knowledge of the CM-ground-ASE version number.

2.3.3.10.3 The value supplied by the CM-air-user must be less than the actual CM-air-ASE version number.

2.3.3.10.4 If provided by the CM-air-user, this parameter shall conform to an abstract integer value from 1 to 255.

2.3.4 CM-server-facility-query service

2.3.4.1 General

2.3.4.1.1 The CM-server-facility-query service allows version 2 CM-air-users to initiate either secure or unsecure

12311232123312341235123612371238123912401241124212431244124512461247124812491250125112521253125412551256125712581259126012611262126312641265126612671268126912701271127212731274127512761277127812791280128112821283


data link services with a CM server. This service is similar to a CM-logon service. However, unlike the CM-logon service, the CM-server-facility-query service does not perform version negotiation. In addition, the CM-server-facility-query service can be invoked either with or without a dialogue in place. The CM-air-user provides information on each data link application for which it desires a data link service, as well as on the facility designations of the end systems with which it wants data link service. The CM-ground-user responds indicating whether or not the CM-server-facility-query was successful, and if successful, includes information of each data link application supported by the requested facilities. It is a confirmed service. This service is not used for version 1 CM.

2.3.4.1.2 The CM-server-facility-query service shall contain the primitives and parameters as presented in Table 2-3.

Table 2-3. CM-server-facility-query service parameters


Facility Designation C

Aircraft Address C C(=)

Server Facility Query Request M M(=)

Server Facility Query Response M M(=)


Maintain Dialogue U C(=)

Security Required C C(=)




2.3.4.2.3 If a CM dialogue does not exist when a CM-air-user invokes the CM-server-facility-query request, the CM-air-user shall provide the Facility Designation parameter value.

Note.— The CM-server-facility-query service does not use this parameter when a CM dialogue exists.


2.3.4.3.1 The Aircraft Address parameter contains the ICAO 24-bit aircraft address of the aircraft initiating the CM-server-facility-query service.


2.3.4.3.3 If a CM dialogue does not exist when a CM-air-user invokes the CM-server-facility-query request, the CM-air-user shall provide the Aircraft Address parameter value.

Note.— The CM-server-facility-query service does not use this parameter when a CM dialogue exists.

1284128512861287128812891290129112921293129412951296

1297129812991300130113021303130413051306130713081309131013111312131313141315131613171318131913201321


2.3.4.4 Server Facility Query Request parameter

2.3.4.4.1 The Server Facility Query Request parameter contains the following data:

a) information for each data link application available on the aircraft, for which the aircraft requires data link service;

b) the facility designations of up to eight facilities with which the aircraft would like to perform data link services; and

c) aircraft flight plan information (e.g. flight identification, aircraft destination and departure airport and time) as required by the addressed ground system.

2.3.4.4.2 The Server Facility Query Request parameter value shall conform to the ASN.1 abstract syntax CMServerFacilityQueryRequest.

2.3.4.5 Server Facility Query Response parameter

2.3.4.5.1 The Server Facility Query Response parameter contains application information for each of the facilities as requested in the Server Facility Query Request parameter. If application information for one of the facilities is not available, then no application information is returned for that facility. If there is no access to a directory, then the reason for the lack of access will be returned (i.e. either a directory service is not supported or the service is temporarily unavailable). Additionally, if a collision occurs and preference is given to the ground system’s CM service, then that condition will be indicated to the CM-air-user. The Server Facility Query Response parameter will contain key information only if security is supported.2.3.4.5.2 The Server Facility Query Response parameter value shall conform to the ASN.1 abstract syntax CMServerFacilityQueryResponse.


2.3.4.6.1 This parameter contains the value of the required class of communication service if specified by the CM-air-user.

2.3.4.6.2 When the Class of Communication Service parameter is specified by the CM-air-user, this parameter shall have one of the following abstract values: “A”, “B”, “C”, “D”, “E”, “F”, “G” or “H”.

2.3.4.6.3 If the Class of Communication Service parameter is not specified by the CM-air-user, it indicates that there is no routing preference.

2.3.4.7 Maintain Dialogue parameter

2.3.4.7.1 The Maintain Dialogue parameter is used to indicate whether or not the requested CM dialogue is to remain open after a Server Facility Query Response.

2.3.4.7.2 Whenever a CM dialogue is kept open by the CM-ground-user, it must later be explicitly closed by the CM-ground-user.

1322132313241325132613271328132913301331133213331334133513361337133813391340134113421343134413451346134713481349135013511352135313541355135613571358135913601361136213631364136513661367136813691370137113721373


2.3.4.7.3 This parameter is only provided by the CM-ground-user when the CM-ground-user wishes to keep the CM dialogue open and a dialogue is not already in place.

2.3.4.7.4 This parameter is not used if a dialogue is already in place.

2.3.4.7.5 If provided by the CM-ground-user, this parameter shall have the abstract value “maintain”.


2.3.4.8.1 The Security Required parameter contains an indication of whether or not a CM version 2 requires security. It is used by the requester of the CM-server-facility-query service and is indicated to the responder.

2.3.4.8.2 If the received Security Required parameter is not as expected in the indication primitive, the CM-ground-ASE will abort.

2.3.4.8.3 If a CM dialogue does not exist when a CM-air-user invokes the CM-server-facility-query request, the CM-air-user shall provide the Security Required parameter.

Note.— The CM-server-facility-query service does not use this parameter if a dialogue exists.

2.3.4.8.4 When the Security Required parameter is provided by the CM-air-user, the same value shall be indicated to the CM-ground-user.

2.3.4.8.5 When the CM-air-user requires a secure CM-server-facility-query service, and no previous session key has been established with the CM ground system which is to be contacted, the Security Required parameter shall have the abstract value “secured dialogue supporting key management”.

Note.— A session key may be established with a secure CM-logon, secure CM-update, secure CM-server-facility-update, or secure CM-server-facility-query. If one of these secure services has not already been successfully performed with the ground system, then a session key needs to be established, and the “secured dialogue supporting key management” will tell the upper layers to establish a new session key. The CM-air-user does not establish the session key itself; that is handled as described in Part IV of this manual.

2.3.4.8.6 When the CM-air-user requires a secure CM-server-facility-query service, and a previous session key has been established with the CM ground system which is to be contacted, the Security Required parameter shall have the abstract value “secured dialogue”.

Note.— A session key may be established with a secure CM-logon, secure CM-update, secure CM-server-facility-update or secure CM-server-facility-query. If one of these secure services has already been successfully performed with the ground system, then a session key is considered to be established, and the “secured dialogue” will tell the upper layers to continue using security with the established session key. The CM-air-user does not establish the session key itself; that is handled as described in Part IV of this manual.

2.3.4.8.7 When the CM-air-user requires an unsecure CM-server-facility-query service, the Security Required parameter shall have the abstract value “no security”.

Note.— This is to give an indication to the CM-ground-user that security is not to be used. However, the CM-ground-user will have the ultimate decision of whether or not security is required. If security is required by the ground system but not requested by the aircraft, the aircraft may be denied data link services.

1374137513761377137813791380138113821383138413851386138713881389139013911392139313941395139613971398139914001401140214031404140514061407140814091410141114121413141414151416141714181419142014211422142314241425


2.3.45 CM-update service

2.3.45.1 General

2.3.45.1.1 The CM-update service allows the CM-ground-user to transmit updated ground information for its applications to update previously coordinated CM-logon information. It is an unconfirmed service.

2.3.45.1.2 For CM version 2 CM-update service, tThe CM-ground-user will set the Security Required parameter as appropriate in order to perform secure or unsecure services. This parameter is not used by version 1 CM.


2.3.45.1.3 The CM-update service shall contain the primitives and parameters as presented Table 2-34.

Table 2-34. CM-update service parameters

Parameter name Req Ind

Aircraft Address C

Facility Designation C C(=)

Update Information M M(=)


Security Required C


2.3.45.2.1 The Aircraft Address parameter contains the addressed aircraft’s ICAO 24-bit aircraft address.


2.3.45.2.3 If a CM dialogue does not exist when a CM-ground-user invokes the CM-update service request, the CM-ground-user shall provide the Aircraft Address parameter value.

Note.— The CM-update service does not use this parameter when a CM dialogue exists.


2.3.45.3.1 This parameter contains the ground system’s facility designation.


142614271428142914301431143214331434143514361437143814391440144114421443

1444144514461447144814491450145114521453145414551456145714581459146014611462146314641465


2.3.45.3.3 If a CM dialogue does not exist when a CM-ground-user invokes the CM-update service request, the CM-ground-user shall provide the Facility Designation parameter value.

Note.— The CM-update service does not use this parameter when a CM dialogue exists.

2.3.45.4 Update Information parameter

2.3.45.4.1 The Update Information parameter contains information on each updated data link application. For version 2 secure CM-update service, this parameter also contains key and domain usage indications for each application.

2.3.45.4.2 For CM version 1 or CM version 2 with no security required, tThe Update Information parameter value shall conform to the ASN.1 abstract syntax CMUpdate.

2.3.45.4.3 For CM version 2 with security required, the Update Information parameter value shall conform to the ASN.1 abstract syntax CMSecureUpdate.


2.3.45.5.1 This parameter contains the value of the required class of communication service if specified by the CM-ground-user.

2.3.45.5.2 The CM-update service does not use this parameter when a CM dialogue exists.

2.3.45.5.3 When the Class of Communication Service parameter is specified by the CM-ground-user, this parameter shall have one of the following abstract values: “A”, “B”, “C”, “D”, “E”, “F”, “G” or “H”.

2.3.45.5.4 If the Class of Communication Service parameter is not specified by the CM-ground-user, it indicates that there is no routing preference.


2.3.5.6.1 The Security Required parameter contains an indication of whether or not secure CM-update services will be used by a version 2 CM. This parameter is not used for CM version 1.


2.3.5.6.2 When the CM-ground-user requires a secure CM-update service, and up-to-date security information has not already been established between that airborne system and the CM ground system (i.e. a current session key is not shared), the Security Required parameter shall have the abstract value “secured dialogue supporting key management”.

Note.— This is to give an indication to the CM-air-ASE that security is to be used. The CM-air-ASE can then make security decisions based on local security policy.

2.3.5.6.3 When the CM-ground-user requires a secure CM-update service, and up-to-date security information has already been established between that airborne system and the CM ground system (i.e. a current session key is shared), the Security Required parameter shall have the abstract value “secured dialogue”.

Note.— This is to give an indication to the CM-air-ASE that security is to be used. The CM-air-ASE can

1466146714681469147014711472147314741475147614771478147914801481148214831484148514861487148814891490149114921493149414951496149714981499150015011502150315041505150615071508150915101511151215131514151515161517


then make security decisions based on local security policy.

2.3.5.6.4 When the CM-ground-user requires an unsecure CM-update service, and the CM aircraft system is not version 1, the Security Required parameter shall have the abstract value “no security”.

Note.— This is to give an indication to the CM-air-ASE that security is not to be used. The CM-air-ASE can then make security decisions based on local security policy.

2.3.5.6.5 If a CM dialogue does not already exist between the CM ground system and CM aircraft system, and the CM aircraft system is not version 1, then when a CM-ground-user invokes the CM-update request, the CM-ground-user shall provide the Security Required parameter.

Note.— The CM-update service does not use this parameter if a dialogue exists.

2.3.5.6.6 When communicating with a version 1 CM aircraft, the CM-ground-user shall be prohibited from providing the Security Required parameter.

2.3.6 CM-server-facility-update service

2.3.6.1 General

2.3.6.1.1 The CM-server-facility-update service allows version 2 CM servers to transmit updated application information for up to eight specific facilities to update previously coordinated CM-server-facility-query information. It is an unconfirmed service and may be either secure or unsecure. This service is not used by version 1 CM.

2.3.6.1.2 The CM-server-facility-update service shall contain the primitives and parameters as presented in Table 2-5.

Table 2-5. CM-server-facility-update service parameters


Aircraft Address C


Server Facility Update Information M M(=)


Security Required C




151815191520152115221523152415251526152715281529153015311532153315341535153615371538153915401541154215431544154515461547154815491550

155115521553155415551556155715581559


2.3.6.2.3 If a CM dialogue does not exist when a CM-ground-user invokes the CM-server-facility-update service request, the CM-ground-user shall provide the Aircraft Address parameter value.

Note.— The CM-server-facility-update service does not use this parameter when a CM dialogue exists.


2.3.6.3.1 This parameter contains the ground CM server’s facility designation.


2.3.6.3.3 If a CM dialogue does not exist when a CM-ground-user invokes the CM-server-facility-update service request, the CM-ground-user shall provide the Facility Designation parameter value.

Note.— The CM-server-facility-update service does not use this parameter when a CM dialogue exists.

2.3.6.4 Server Facility Update Information parameter

2.3.6.4.1 The Server Facility Update Information parameter contains information on each updated data link application.

2.3.6.4.2 The Server Facility Update Information parameter value shall conform to the ASN.1 abstract syntax CMServerFacilityUpdate.

2.3.6.4.3 The Server Facility Update Information parameter will contain key information only if security is supported.

1560156115621563156415651566156715681569157015711572157315741575157615771578157915801581158215831584158515861587158815891590




2.3.6.5.2 The CM-server-facility-update service does not use this parameter when a CM dialogue exists.




2.3.6.6.1 The Security Required parameter contains an indication of whether or not secure CM-server-facility-update services will be used.

2.3.6.6.2 When the CM-ground-user requires a secure CM-server-facility-update service, and a previous CM-logon has not been performed with the CM ground system which is to be contacted, the Security Required parameter shall have the abstract value “secured dialogue supporting key management”.


2.3.6.6.3 When the CM-ground-user requires a secure CM-server-facility-update service, and a previous CM-logon has been performed with the CM ground system which is to be contacted, the Security Required parameter shall have the abstract value “secured dialogue”.


2.3.6.6.4 When the CM-ground-user requires an unsecure CM-server-facility-update service, the Security Required parameter shall have the abstract value “no security”.


2.3.6.6.5 If a CM dialogue does not exist when a CM-ground-user invokes the CM-server-facility-update request, the CM-ground-user shall provide the Security Required parameter.

Note.— The CM-server-facility-update service does not use this parameter if a dialogue exists.

2.3.57 CM-contact service

2.3.57.1 General

2.3.57.1.1 The CM-contact service allows the CM-ground-user, after successful completion of a CM-logon, to request that an aircraft logon with another ground system. It is a confirmed service.

1591159215931594159515961597159815991600160116021603160416051606160716081609161016111612161316141615161616171618161916201621162216231624162516261627162816291630163116321633163416351636163716381639164016411642


2.3.57.1.2 For CM version 2 CM-contact service, tThe CM-ground-user will set the Security Required parameter as appropriate in order to perform secure or unsecure services. This parameter is not used by version 1 CM.

2.3.57.1.3 The CM-contact service shall contain the primitives and parameters as presented in Table 2-654.

Table 2-654. CM-contact service parameters


Aircraft Address C


Contact Request M M(=)

Contact Response M M(=)


Security Required C




2.3.57.2.3 If a CM dialogue does not exist when a CM-ground-user invokes the CM-contact service request, the CM-ground-user shall provide the Aircraft Address parameter value.

Note.— The CM-contact service does not use this parameter when a CM dialogue exists.


2.3.57.3.1 This parameter contains the ground system’s facility designation.


2.3.57.3.3 If a CM dialogue does not exist when a CM-ground-user invokes the CM-contact service request, the CM-ground-user shall provide the Facility Designation parameter value.


2.3.57.4 Contact Request parameter

2.3.57.4.1 The Contact Request parameter contains the facility designation for the ground system that the CM-ground-user requests the aircraft to contact.

2.3.57.4.2 The Contact Request parameter value shall conform to the ASN.1 abstract syntax CMContactRequest.

16431644164516461647164816491650

1651165216531654165516561657165816591660166116621663166416651666166716681669167016711672167316741675167616771678167916801681168216831684


2.3.57.5 Contact Response parameter

2.3.57.5.1 The Contact Response parameter indicates success, or lack thereof, of the requested contact.

2.3.57.5.2 The Contact Response parameter value shall conform to the ASN.1 abstract syntax CMContactResponse.






2.3.57.7.1 The Security Required parameter contains an indication of whether or not a CM-ground-user requires security. It is used by the requester of the version 2 CM-contact service. It is not used by version 1 CM.


2.3.7.7.2 When the CM-ground-user requires a secure CM-contact service, and a previous secure CM-logon has been performed with the CM ground system, the Security Required parameter shall have the abstract value “secured dialogue”.


2.3.7.7.3 When the CM-ground-user requires an unsecure CM-contact service or if the CM-ground-user is communicating with a version 1 CM aircraft, the Security Required parameter shall have the abstract value “no security”.


2.3.7.7.4 If a CM dialogue does not exist when a CM-ground-user invokes the CM-contact request, the CM-ground-user shall provide the Security Required parameter.


2.3.68 CM-end service

2.3.68.1 General

1685168616871688168916901691169216931694169516961697169816991700170117021703170417051706170717081709171017111712171317141715171617171718171917201721172217231724172517261727172817291730173117321733173417351736


2.3.68.1.1 This service provides the capability for the CM-ground-user to terminate a CM dialogue. This service is only needed when the CM-ground-user maintains a CM dialogue during the logon process. It is an unconfirmed service.

2.3.68.1.2 Only the CM-ground-user will be capable of initiating the CM-end service.

2.3.68.1.3 The CM-end service shall contain the primitives as presented Table 2-675.

Table 2-756. CM-end service parameters


None

2.3.79 CM-forward service

2.3.79.1 General

2.3.79.1.1 The CM-forward service allows a CM-ground-user to forward data received in a CM-logon request to another CM-ground system. It is a confirmed service.

2.3.79.1.2 If security is supported, the CM-forward service also contains an indication of whether or not security is desired for the exchange.

Note. – The specific security mechanisms that may provide the security functionality are out of scope for this document.For CM version 2, the CM-forward service can be secure or unsecure. This is indicated by the CM-ground-user setting the Security Required parameter. If it is known that the peer CM ground system is an earlier version CM, then the sending CM-ground-user may indicate to the CM-ground-ASE that it wishes to run in a previous version mode through the Emulated Version parameter.

2.3.79.1.3 If the sending CM-ground-ASE version number is less than or equal to the receiving CM-ground-ASE version number, then the CM-forward service shall contain the primitives and parameters as presented in Table 2-876.

Table 2-876. CM-forward service parameters —sending ground-ASE version number ≤ receiving ground-ASE version number

Parameter name Req Ind Cnf

Called Facility Designation M

Calling Facility Designation M M(=)

CM-ASE Version Number C

Forward Request M M(=)


Result M

17371738173917401741174217431744174517461747

17481749175017511752175317541755175617571758175917601761176217631764176517661767176817691770177117721773


Security Required M

Emulated Version U

2.3.79.1.4 If the sending CM-ground-ASE version number is greater than the receiving CM-ground-ASE version number, then the CM-forward service shall contain the primitives and parameters as presented in Table 2-987.

Table 2-789. CM-forward service parameters —sending ground-ASE version number > receiving ground-ASE version number



Calling Facility Designation M

CM-ASE Version Number M

Forward Request M


Result M

Security Required M

Emulated Version U

2.3.79.2 Called Facility Designation parameter

2.3.79.2.1 The Called Facility Designation parameter contains the receiving ground system’s facility designation.

2.3.79.2.2 The Called Facility Designation parameter value shall conform to the abstract syntax four- to eight-character facility designation.

2.3.79.3 Calling Facility Designation parameter

2.3.79.3.1 This parameter contains the sending ground system’s facility designation.

2.3.79.3.2 The Calling Facility Designation parameter value shall conform to the abstract syntax four- to eight-character facility designation.

2.3.79.4 CM-ASE Version Number parameter

2.3.79.4.1 This parameter contains the version number of the CM-ground-ASE.

2.3.79.4.2 When provided by the CM-ASE, the CM-ASE Version Number parameter shall conform to an abstract integer value from 1 to 255.

2.3.79.4.3 Only if the sending CM-ground-ASE version number is less than the receiving CM-ground-ASE version

177417751776177717781779178017811782

17831784178517861787178817891790179117921793179417951796179717981799180018011802180318041805180618071808


number shall the sending CM-ground-ASE version number be indicated to the receiving CM-ground-user.

2.3.79.4.4 Only if the sending CM-ground-ASE version number is greater than the receiving CM-ground-ASE version number shall the receiving CM-ground-ASE version number be confirmed to the sending CM-ground-user.

2.3.79.4.5 If the sending CM-ground-ASE version number is the same as the receiving CM-ground-ASE version number, the CM-ASE Version Number parameter is not present in the indication given to the receiving CM-ground-user or in the confirmation given to the sending CM-ground-user.

2.3.79.5 Forward Request parameter

2.3.79.5.1 The Forward Request parameter contains information as provided in the CM-logon request. For the CM version 2 CM-forward service, this parameter also contains the aircraft’s CM application version number.

2.3.79.5.2 For CM version 1, or for CM version 2 acting as a CM version 1 in emulation, tThe CM-forward service Forward Request parameter value shall conform to the ASN.1 abstract syntax CMForwardRequest.

2.3.9.5.3 For CM version 2 CM-forward service, the Forward Request parameter value shall conform to the ASN.1 abstract syntax CMEnhancedForwardRequest.


2.3.79.6.1 This parameter contains the value of the required class of communication service if specified by the initiating CM-ground-user.


2.3.79.6.3 If the Class of Communication Service is not specified by the CM-ground-user, it indicates that there is no routing preference.

2.3.79.7 Result parameter

2.3.79.7.1 The Result parameter indicates whether or not the information was forwarded as requested.

2.3.79.7.2 The Result parameter shall conform to the ASN.1 abstract syntax CMForwardResponse.

2.3.79.7.3 When the sending CM-ground-ASE version number is less than or equal to the receiving CM-ground-ASE version number, the Result parameter takes the abstract value “success”. When the sending CM-ground-ASE version number is greater than the receiving CM-ground-ASE version number, the Result parameter takes the abstract value “incompatible version”. When the receiving CM-ground-ASE does not support ground-ground forwarding, the Result parameter takes the abstract value “service not supported”.


2.3.79.8.1 The Security Required parameter contains an indication of whether or not a CM-ground-user requires security. It is used by the requester of CM-forward service.

1809181018111812181318141815181618171818181918201821182218231824182518261827182818291830183118321833183418351836183718381839184018411842184318441845184618471848184918501851185218531854185518561857185818591860



The Security Required parameter contains an indication of whether or not a CM-ground-user requires security. It is used by the sending CM-ground-user of the version 2 CM-forward service. It is not used by version 1 CM, or by a version 2 CM emulating a version 1 CM.

2.3.9.8.2 When the sending CM-ground-user requires a secure CM-forward service, the Security Required parameter shall have the abstract value “secured dialogue”.

Note.— This is to give an indication to the peer CM-ground-ASE that security is to be used. The peer CM-ground-ASE can then make security decisions based on local security policy.

2.3.9.8.3 When the sending CM-ground-user requires an unsecure CM-forward service or is communicating with a version 1 CM ground system, the Security Required parameter shall have the abstract value “no security”.

Note.— This is to give an indication to the peer CM-ground-ASE that security is not to be used. The peer CM-ground-ASE can then make security decisions based on local security policy.

2.3.9.9 Emulated Version parameter

2.3.9.9.1 The Emulated Version parameter is used by a CM-ground-user to indicate that the sending CM-ground-ASE is to operate in a degraded mode, i.e. to emulate a previous CM version. This parameter is not used by version 1 CM.

2.3.9.9.2 This parameter is not normally provided for a first forward unless there is explicit a priori knowledge of the receiving ground CM application version number.

2.3.9.9.3 The value supplied by the sending CM-ground-user must be less than the actual sending CM-ground-ASE version number.

2.3.9.9.4 If provided by the sending CM-ground-user, this parameter shall conform to an abstract integer value from 1 to 255.

2.3.810 CM-user-abort service

2.3.810.1 This service provides the capability for either the CM-air-user or the CM-ground-user to abort communication with its peer. This can be used for operational or technical reasons. It can be invoked at any time by an active user. Messages in transit may be lost during this operation. It is an unconfirmed service.

2.3.810.2 If the service is invoked prior to complete establishment of the dialogue, the CM-user-abort indication may not be provided. A CM-provider-abort indication may result instead.

2.3.810.3 The CM-user-abort service shall contain the primitives as presented in Table 2-8910.

Table 2-8910. CM-user-abort service parameters


18611862186318641865186618671868186918701871187218731874187518761877187818791880188118821883188418851886188718881889189018911892189318941895189618971898189919001901190219031904190519061907190819091910


None

2.3.9101 CM-provider-abort service

2.3.9101.1 General

2.3.9101.1.1 The CM-provider-abort service provides the capability for the CM service provider to inform its users that it can no longer provide the CM service. Messages in transit may be lost during this operation.

2.3.9101.1.2 The CM-provider-abort service shall contain the primitives and parameters as presented in Table 2-9110.

1911191219131914191519161917191819191920192119221923192419251926


Table 2-9101. CM-provider-abort service parameters

Parameter name Ind

Reason M

2.3.9101.2 Reason parameter

2.3.9101.2.1 This parameter identifies the reason for the abort.

2.3.9101.2.2 The Reason parameter value shall conform to the ASN.1 abstract syntax CMAbortReason.

2.4 FORMAL DEFINITIONS OF MESSAGES

2.4.1 Encoding/decoding rules

2.4.1.1 A CM-air-ASE shall be capable of encoding CMAircraftMessage APDUs and decoding CMGroundMessage APDUs.

2.4.1.2 A CM-ground-ASE shall be capable of encoding and decoding CMGroundMessage APDUs and decoding CMAircraftMessage APDUs.

2.4.2 CM ASN.1 abstract syntax

The abstract syntax of the CM protocol data units (PDUs) shall comply with the description contained in the ASN.1 module CMMessageSetVersion1 (conforming to ISO/IEC 8824-1), as defined hereinafter. The ASN.1 module CMMessageSetVersion1 is used by both CM version 1 and CM version 2. The change in the ASN.1 for CM version 2 is the addition of PDUs for the CM-server-facility-query and CM-server-facility-update services and security enhancements, along with the supporting new service and security elements.

19271928

19291930193119321933193419351936193719381939194019411942194319441945194619471948194919501951195219531954195519561957195819591960


CMMessageSetVersion1 DEFINITIONS ::=

BEGIN

-- This is an import of the encoding of the subject’s public key from Doc 9880, Part IV, for CM Version 2IMPORTS atnPKI-explicit FROM ATNObjectIdentifiers { iso(1) identified-organization(3) icao(27) atn(0) objectIdentifiers(0) } -- Defined in Doc 9880, Part IV

ECPoint FROM ATN-PKI-Explicit atnPKI-explicit -- Defined in Doc 9880, Part IV; -- end of IMPORTS

1961196219631964196519661967196819691970197119721973


-- ------------------------------------------------------------------------------------ CM Message Structure-- ------------------------------------------------------------------------------------ Aircraft-generated messages

CMAircraftMessage ::=CHOICE{cmLogonRequest [0] CMLogonRequest,cmContactResponse [1] CMContactResponse,cmAbortReason [2] CMAbortReason,..., -- the PDU after extensibility is CM Version 2 only cmServerFacilityQueryRequest [3] CMServerFacilityQueryRequest}

-- Ground-generated messagesCMGroundMessage ::=CHOICE{cmLogonResponse [0] CMLogonResponse,cmUpdate [1] CMUpdate,cmContactRequest [2] CMContactRequest,cmForwardRequest [3] CMForwardRequest,cmAbortReason [4] CMAbortReason,cmForwardResponse [5] CMForwardResponse,..., -- All PDUs after extensibility are CM Version 2 only cmServerFacilityQueryResponse [6] CMServerFacilityQueryResponse, cmServerFacilityUpdate [7] CMServerFacilityUpdate, cmSecureLogonResponse [8] CMSecureLogonResponse, cmSecureUpdate [9] CMSecureUpdate, cmEnhancedForwardRequest [10] CMEnhancedForwardRequest} -- ------------------------------------------------------------------------------------ CM Message Components-- ----------------------------------------------------------------------------------

AircraftFlightIdentification ::= IA5String (SIZE(2..8))

Airport ::= IA5String (SIZE(4))

APAddress ::= CHOICE{

longTsap [0] LongTsap,shortTsap [1] ShortTsap

}

AEQualifier ::= INTEGER (0..255) -- ATN AE-Qualifier Numeric Values are described in Doc 9880, Part IV

AEQualifierVersion ::= SEQUENCE{

aeQualifier AEQualifier,apVersion VersionNumber

}

1974197519761977197819791980198119821983198419851986198719881989199019911992199319941995199619971998199920002001200220032004200520062007200820092010201120122013201420152016201720182019202020212022202320242025


AEQualifierVersionAddress ::= SEQUENCE{

aeQualifier AEQualifier,apVersion VersionNumber,apAddress APAddress

}

CMAbortReason ::= ENUMERATED{

timer-expired (0),undefined-error (1),invalid-PDU (2),protocol-error (3),dialogue-acceptance-not-permitted (4),dialogue-end-not-accepted (5),communication-service-error (6),communication-service-failure (7),invalid-QOS-parameter (8),expected-PDU-missing (9),...

}

CMContactRequest ::= SEQUENCE{

facilityDesignation FacilityDesignation,address LongTsap

}

CMContactResponse ::= Response

CMEnhancedForwardRequest ::= SEQUENCE -- CM Version 2 only{ cmVersionNumber VersionNumber, cmForwardRequest CMLogonRequest, ...}

CMForwardRequest ::= CMLogonRequest

CMForwardResponse ::= ENUMERATED{

success (0),incompatible-version (1),service-not-supported (2)

}

2026202720282029203020312032203320342035203620372038203920402041204220432044204520462047204820492050205120522053205420552056205720582059206020612062206320642065206620672068206920702071


CMLogonRequest ::= SEQUENCE{

aircraftFlightIdentification [0] AircraftFlightIdentification,cMLongTSAP [1] LongTsap,groundInitiatedApplications [2] SEQUENCE SIZE (1..256) OF AEQualifierVersionAddressOPTIONAL,

2072207320742075207620772078


airOnlyInitiatedApplications [3] SEQUENCE SIZE (1..256) OF AEQualifierVersionOPTIONAL,facilityDesignation [4] FacilityDesignation OPTIONAL,airportDeparture [5] Airport OPTIONAL,airportDestination [6] Airport OPTIONAL,dateTimeDepartureETD [7] DateTime OPTIONAL

}

CMLogonResponse ::= SEQUENCE{

airInitiatedApplications [0] SEQUENCE SIZE (1..256) OF AEQualifierVersionAddressOPTIONAL,

groundOnlyInitiatedApplications [1] SEQUENCE SIZE (1..256) OF AEQualifierVersionOPTIONAL

}

CMSecureLogonResponse ::= SEQUENCE -- CM Version 2 only{ facilityDesignation [0] FacilityDesignation OPTIONAL, secureAirInitiatedApplications [1] SEQUENCE SIZE (1..256) OF SecAir OPTIONAL, secureGroundOnlyInitiatedApplications [2] SEQUENCE SIZE (1..256) OF SecGnd OPTIONAL, ...}

CMSecureUpdate ::= CMSecureLogonResponse -- CM Version 2 only

CMServerFacilityQueryRequest ::= SEQUENCE -- CM Version 2 only{ aircraftFlightIdentification [0] AircraftFlightIdentification, cMLongTSAP [1] LongTsap, groundInitiatedApplications [2] SEQUENCE SIZE (1..256) OF AEQualifierVersionAddress OPTIONAL, airOnlyInitiatedApplications [3] SEQUENCE SIZE (1..256) OF AEQualifierVersion OPTIONAL, requestedFacilities [4] SEQUENCE SIZE (1..8) OF FacilityDesignation, airportDeparture [5] Airport OPTIONAL, airportDestination [6] Airport OPTIONAL, dateTimeDepartureETD [7] DateTime OPTIONAL, ...}

CMServerFacilityQueryResponse ::= CHOICE -- CM Version 2 only{ infoUnavailable [0] InfoUnavailable, requestedInfo [1] SEQUENCE SIZE (1..8) OF RequestedInfo, ...}

CMServerFacilityUpdate ::= SEQUENCE SIZE (1..8) OF RequestedInfo -- CM Version 2 only

CMUpdate ::= CMLogonResponse

2079208020812082208320842085208620872088208920902091209220932094209520962097209820992100210121022103210421052106210721082109211021112112211321142115211621172118211921202121212221232124212521262127212821292130


Date ::= SEQUENCE{

year Year,month Month,day Day

}-- The Date field does not have to correspond to the flight if the field is not to be used; the field’s value can be assigned a meaningless, but compliant, value locally. If operational use of the Date field is intended, there must be bilateral agreements in place to ensure its proper use. This is a local implementation issue.

DateTime ::= SEQUENCE{

dateDate,timeTime

}

Day ::= INTEGER (1..31)--unit = Day, Range (1..31), resolution = 1

DomainFlag ::= ENUMERATED -- CM Version 2 only{ keySharedInADM (0), keyNotSharedInADM (1), ...}

FacilityDesignation ::= IA5String (SIZE(4..8))

InfoUnavailable ::= ENUMERATED -- CM Version 2 only{ serverNotSupported (0), serverUnavailable (1), serviceInterrupted (2), ...}

LongTsap ::= SEQUENCE{rDP OCTET STRING (SIZE(5)),shortTsap ShortTsap}

Month ::= INTEGER (1..12)--unit = Month, Range (1..12), resolution = 1

213121322133213421352136213721382139214021412142214321442145214621472148214921502151215221532154215521562157215821592160216121622163216421652166216721682169217021712172217321742175


RequestedInfo ::= SEQUENCE -- CM Version 2 only{ facilityDesignation [0] FacilityDesignation, cMLongTSAP [1] LongTsap OPTIONAL, airInitiatedApplications [2] SEQUENCE SIZE (1..256) OF SecAir OPTIONAL,groundOnlyInitiatedApplications [3] SEQUENCE SIZE (1..256) OF SecGnd OPTIONAL, ...}Response ::= ENUMERATED{

contactSuccess (0),contactNotSuccessful (1)

}

SecAir ::= SEQUENCE -- CM Version 2 only{ applicationInformation [0] AEQualifierVersionAddress, keyAgreementPublicKey [1] ECPoint OPTIONAL, domainFlag [2] DomainFlag OPTIONAL, ...}

SecGnd ::= SEQUENCE -- CM Version 2 only{ applicationInformation [0] AEQualifierVersion, keyAgreementPublicKey [1] ECPoint OPTIONAL, domainFlag [2] DomainFlag OPTIONAL, ...}

ShortTsap ::= SEQUENCE{

aRS [0] OCTET STRING (SIZE(3)) OPTIONAL,-- the aRS contains the ICAO 24-bit aircraft address when the ShortTsap belongs to an aircraft;-- or a ground address when the Short Tsap belongs to a ground systemlocSysNselTsel [1] OCTET STRING (SIZE(10..11))}

Time ::= SEQUENCE{

hours Timehours,minutes Timeminutes

}

Timehours ::= INTEGER (0..23) -- units = hour, range (0..23), resolution = 1 hour

Timeminutes ::= INTEGER (0..59) -- units = minute, range (0..59), resolution = 1 minute

VersionNumber ::= INTEGER (1..255) -- VersionNumber 0 is reserved for the dialogue service

2176217721782179218021812182218321842185218621872188218921902191219221932194219521962197219821992200220122022203220422052206220722082209221022112212221322142215221622172218221922202221222222232224222522262227


Year ::= INTEGER (1996..2095)--unit = Year, Range (1996..2095), resolution = 1

END

2.5 PROTOCOL DEFINITION

2.5.1 Sequence rules

2.5.1.1 With the exception of abort primitives, only the sequence of primitives illustrated in Figures 2-2 to 2-231 shall be permitted.

2.5.1.2 Figures 2-2 to 2-231 define the valid sequences of primitives that are possible to be invoked during the operation of the CM application. The figures show the relationship in time between the service request and the resulting indication and, if applicable, the subsequent response and resulting confirmation.

Figure 2-2. Sequence diagram for CM-logon service— CM-air-ASE version ≤ CM-ground-ASE version

TI

ME

CM -groun d-u se r CM serv ice p rov id er C M -air-user

D - S T A R T In d

D - S T A R T R s p

D - S T A R T R e q

D - S T A R T C n f

C M - lo g o n I n d

C M - lo g o n R s p

C M - lo g o n C n f

C M - lo g o n R e q

t lo g o n

22282229223022312232223322342235223622372238223922402241224222432244224522462247

2249225022512252


Figure 2-3. Sequence diagram for CM-logon service

Figure 2-4. CM-server-facility-query service

TI

ME

CM -ground-u se r C M serv ice p rov ider CM -air-user

D - S T A R T R e q

D - S T A R T C n f

D - S T A R T In d

D - S T A R T R s p

C M -lo g o n C n f

C M -lo g o n R e q

t lo g o n

TI

ME

D - S T A R T In d

D - S T A R T R s p

D - S T A R T R e q

D - S T A R T C n f

C M -s e rv e r - f a c i l i ty - q u e ry C n f

C M -s e rv e r - f a c i l i ty - q u e ry R e q

C M -s e rv e r - f a c i l i ty - q u e ry I n d

C M -s e rv e r - f a c i l i ty - q u e ry R s p

C M -gro und-user CM serv ice p rov id er CM -a ir-user

t s rv _ q u e ry

2254

22562257225822592260


Figure 2-5. CM-server-facility-query service— Existing CM dialogue (CM Version 2)

CM -gro un d-u se r CM se rv ice p rov id er CM -air-user

D - D A T A In d

D - D A T A In dD - D A T A R e q

D - D A T A R e q

C M -s e rv e r - f a c i l i t y - q u e ry C n f

C M -s e rv e r - f a c i l i t y - q u e ry R e q

C M -s e rv e r - f a c i l i t y - q u e ry In d

C M -s e rv e r - f a c i l i t y - q u e ry R s p

TI

ME

ts rv _ q u e ry

226222632264


Figure 2-46. Sequence diagram for CM-update service— No existing CM dialogue

Figure 2-7. Sequence diagram for CM-server-facility-update service— No existing CM dialogue (CM Version 2)

TI

ME

CM -gro und-u se r C M serv ice p rov ider CM -air-user

D - S T A R T R e q

D - S T A R T C n f

D - S T A R T In d

D - S T A R T R s p

C M -u p d a te In d

C M - R e qu p d a te

t u p d a te

TI

ME

CM -user CM se rv ice p rov ider CM -user

D - S T A R T R e q

D - S T A R T C n f

D - S T A R T In d

D - S T A R T R s p

C M -s e rv e r - f a c i l i ty - u p d a te R e q

C M -s e rv e r - f a c i l i t y - u p d a te In d

t u p d a te

226622672268226922702271

227322742275


Figure 2-58. Sequence diagram for CM-update service— Existing CM dialogue

Figure 2-9. Sequence diagram for CM-server-facility-update service— Existing CM dialogue (CM Version 2)

CM -ground-u se r CM serv ice p rov ider CM -air-user

D - D AT A R e q

D - D AT A In d

C M -u p d a te In d

C M -u p d a te R e q

TI

ME

CM -gro und-u se r CM serv ice p rov id er CM -air-user

D - D AT A R e q

D - D AT A In d

C M -s e rv e r - f a c i l i ty - u p d a te I n d

C M -s e rv e r - f a c i l i ty - u p d a te R e q

TI

ME

227722782279228022812282

228422852286


Figure 2-610. Sequence diagram for CM-contact service— No existing CM dialogue

— With CM-logon service as in Figure 2-2

C M - lo g o n I n d

C M - lo g o n R s p

C M -c o n ta c t C n f

C M -c o n ta c t R e q


C M - lo g o n R e q

C M -c o n ta c t I n d

H u m a ntr ig g e re v e n t

C M -c o n ta c t R s p

D - S T A R T In d

D - S T A R T R s p

D - S T A R T R e q

CM -gro un d-use r 1


CM se rv icepro vide r

CM serv icepro v ide r

C M -air-user

D - S T A R T C n f

D - S T A R T C n f

D - S T A R T R e q

D - S T A R T In d

D - S T A R T R s p

TI

ME

t c o n ta c tt lo g o n

2288228922902291


Figure 2-711. Sequence diagram for CM-contact Service— With existing CM dialogue



C M -lo g o n I n d

C M -lo g o n R s p



C M -lo g o n C n f

C M -lo g o n R e q



D - S T A R T In d

D - S T A R T R s p

D - S T A R T R e q


C M -gro un d-use r 2

CM serv iceprov ide r


CM -air-user

D - S T A R T C n f

D - D AT A In d

TI

ME

tc o n ta c tt lo g o n

D - D AT A R e q

D - D AT A In d

D - D AT A R e q

2293229422952296


Figure 2-812. Sequence diagram for CM-contact service — No existing CM dialogue






C M -lo g o n R e q



D - S T A R T In d

D - S T A R T In d

D - S T A R T C n f

D - S T A R T R s p

D - S T A R T R s p

D - S T A R T R e q

D - S T A R T R e q





CM -air-user

D - S T A R T C n f

TI

ME

tc o n ta c t t lo g o n

2298229923002301


Figure 2-913. Sequence diagram for CM-contact service — Existing CM dialogue






C M -lo g o n R e q



D - S T A R T In d

D - S T A R T R s p

D - D AT A R e q

D - D AT A R e q

D - D AT A In d

D - D AT A In d

D - S T A R T R e q





CM -air-user

D - S T A R T C n f

TI

ME

tc o n ta c t t lo g o n

2303230423052306


Figure 2-104. Sequence diagram for CM-contact service — No existing CM dialogue

— Without CM-logon service as requested

Figure 2-115. Sequence diagram for CM-contact service— With existing CM dialogue

— Without CM-logon service as requested

TI

ME

tc o n ta c t





D - S T A R T In d

D - S T A R T R s p

D - S T A R T R e q

D - S T A R T C n f

CM -gro un d-u se r CM serv ice p rov ider CM -air-user

TI

ME

tc o n ta c t





D - D AT A In d

D - R e qD A TA

D - R e qD A TA

D - In dD A TA

CM -gro un d-u se r CM serv ice p rov ider CM -air-user

230823092310231123122313

2315231623172318


Figure 2-126. Sequence diagram for CM-end service

Figure 2-137. Sequence diagram for CM-forward service— Sending CM-ground-ASE Version ≤ Receiving CM-ground-ASE Version,

— Ground-ground forwarding supported

TI

ME

t e n d

C M -e n d R e q

C M -e n d I n d

D - I n dE N D

D - R s pE N D

D - E N D R e q

D - C n fE N D

C M -gro un d-user C M serv ice p rov ider CM -air-user

TI

ME

t fo r w a rd

C M -fo r w a r d R e q

C M -fo r w a r d C n f

C M -fo r w a r d In d

D - In dS TA R T

D - R s pS TA R T

D - S T A R T R e q

D - C n fS TA R T

Se nd ingCM -gro un d-use r CM serv ice p rov ider

Rece iv ingC M -gro und-user

2320232123222323

2325232623272328


Figure 2-148. Sequence diagram for CM-forward service— Sending CM-ground-ASE Version > Receiving CM-ground-ASE Version, or

— Receiving CM-ground-ASE does not support ground-ground forwarding

Figure 2-159. Sequence diagram for CM-user-abort service— CM-air-user initiated

TI

ME

t fo r w a rd

C M -fo r w a r d R e q

C M -fo r w a r d C n f

D - In dS TA R T

D - R s pS TA R T

D - S T A R T R e q

D - C n fS TA R T

Se nd ingCM -gro un d-use r CM serv ice p rov ider

Rece iv ingC M -gro und-user

TI

ME

C M -u s e r- a b o r t I n d

C M -u s e r- a b o r t R e q

D - In dA B O R TD - A B O R T R e q

CM -gro und-u ser CM serv ice p rov ider CM -air-user

233023312332233323342335

233723382339


Figure 2-1620. Sequence diagram for CM-user-abort service— CM-ground-user initiated

Figure 2-1721. Sequence diagram for CM-provider-abort service— dialogue service abort

TI

ME

C M -u s e r - a b o r t In d

C M -u s e r - a b o r t R e q

D - In dA B O R T

D - A B O R T R e q

CM -gro und-u se r CM serv ice p rov id er C M -air-user

TI

ME

C M -p r o v id e r - a b o rt In dC M -p r o v id e r - a b o rt In d

D - P - In dA B O R T D - P - In dA B O R T

CM -gro un d-use r CM serv ice p rov ider C M -air-user

23412342234323442345

234723482349


Figure 2-1822. Sequence diagram for CM-provider-abort service— CM-air-ASE abort

Figure 2-1923. Sequence diagram for CM-provider-abort service— CM-ground-ASE abort

TI

ME

C M -p r o v id e r - a b o rt In d

C M -p r o v id e r - a b o rt In d

D - In dA B O R T

D - R e qA B O R T

CM -ground-u se r C M serv ice p rov ider CM -air-user

TI

ME

C M -p r o v id e r - a b o r t In d

C M -p r o v id e r - a b o r t In d D - In dA B O R T

D - R e qA B O R T

CM -gro un d-u se r C M serv ice p rov ider CM -a ir-user

23512352235323542355

235723582359


Figure 2-204. Sequence diagram for CM-user-abort service— Sending CM-ground-user initiated

Figure 2-215. Sequence diagram for CM-provider-abort service— Dialogue service abort

TI

ME

C M -u s e r- a b o r t R e qD - In dA B O R T

D - A B O R T R e q

SendingCM -gro un d-u se r CM serv ice p rov id er

Rece ivingC M -gro un d-user

TI

ME


D - P - In dA B O R TD - P - A B O R T In d

Se ndingCM -gro un d-u se r CM se rv ice p rov id er

ReceivingCM -gro un d-u se r

23612362236323642365

236723682369


Figure 2-226. Sequence diagram for CM-provider-abort service— Receiving CM-ground-ASE abort

Figure 2-237. Sequence diagram for CM-provider-abort service— Sending CM-ground-ASE abort

TI

ME

D - In dA B O R T

D - A B O R T R e q

Se nd ingC M -gro und-u ser C M se rv ice p rov ider

Rece ivingCM -gro und-u ser


TI

ME

C M -p r o v id e r - a b o r t In d D - In dA B O R T

D - R e qA B O R T

Se ndingCM -gro und-u ser C M serv ice p rov ider

ReceivingCM -gro un d-u se r

23712372237323742375

237723782379


Figure 2-28. Collision of CM-contact and CM-server-facility-query— Existing CM dialogue, subsequent CM-logon not shown (CM Version 2)

Figure 2-29. Collision of CM-end and CM-server-facility-query (CM Version 2)

TI

ME

tc o n ta c t

t s rv _ q u e ry





D - D AT A In d

D - R e qD A TA

D - R e qD A TAD - R e qD A TA

D - In dD A TA

D - In dD A TA

CM -gro un d-use r CM serv ice p rov ider CM -a ir-user



TI

ME

te n d

t s rv _ q u e ry

C M -e n d R e q

C M -e n d I n dD - E N D I n d

D - E N D R s p

D - R e qD A TAD - E N D R e q

D - E N D C n f

D - In dD A TA

CM -gro un d-use r CM serv ice p rov ider CM -a ir-user



23812382238323842385

23872388


Figure 2-30. Collision of CM-update and CM-server-facility-query (CM Version 2)

Figure 2-31. Collision of CM-server-facility-update and CM-server-facility-query(CM Version 2)

2.5.1.3 Abort primitives may interrupt and terminate any of the normal message sequences outlined in the rest of

TI

ME

ts rv _ q u e ry

C M -u p d a te R e q

D - D AT A In d

D - D AT A In d


D - R e qD A TA

D - D AT A In d

CM -gro und-user CM serv ice p rov id er C M -air-user


C M -s e rv e r - f a c i l i ty - q u e ry R e q



TI

ME

ts rv _ q u e ry

D - D AT A In d

D - D AT A In d


D - R e qD A TA

D - D AT A In d

CM -gro und-u se r CM serv ice p rov ider CM -air-user


C M -s e rv e r - f a c i l i ty - q u e ry R e qC M -s e rv e r - f a c i l i ty - u p d a te R e q



239023912392

239423952396


Section 2.5.

2.5.1.4 More than one CM-logon attempt may be made for a given CM-contact request. The number of attempts may be determined by local procedures.

2.5.1.5 Primitives are processed in the order in which they are received.

2.5.2 CM service provider timers

2.5.2.1 A CM-ASE shall be capable of detecting when a timer expires.

2.5.2.2 Table 2-12 106 lists the time constraints related to the CM version 1 and 2 applications. Table 2-13 lists the time constraints related only to the CM version 2 application. Each time constraint requires a timer to be set in the CM protocol machine.

2.5.2.3 If the timer expires before the final event has occurred, a CM-ASE takes the appropriate action as defined in 2.5.4.1.

2.5.2.4 The timer values should be as indicated in Table 2-12 106 for CM versions 1 and 2, and as indicated in Table 2-13 for CM version 2.

Table 2-12106. CM service provider timers for CM versions 1 and 2

CM service Timer Timer value Timer start event Timer stop event

CM-logon tlogon 4 minutes D-START request D-START confirmation

CM-update tupdate 4 minutes D-START request D-START confirmation

CM-contact tcontact 8 minutes D-START request,D-DATA request

D-START confirmation,D-DATA indication

CM-forward tforward 4 minutes D-START request D-START confirmation

CM-end tend 4 minutes D-END request D-END confirmation

Note — The receipts of CM-user-abort requests, D-ABORT indications or D-P-ABORT indications are also timer stop events.

Table 2-13. CM service provider timers unique to CM version 2

CM service Timer Timer value Timer start event Timer stop event

CM-server-facility-query

tsrv_query 6 minutes D-START request,D-DATA request

D-START confirmation,D-DATA indication

CM-server-facility-update

tupdate 4 minutes D-START request D-START confirmation

Note — The receipts of CM-user-abort requests, D-ABORT indications or D-P-ABORT indications are also timer stop events.

23972398239924002401240224032404240524062407240824092410241124122413241424152416241724182419242024212422

2423242424252426242724282429

243024312432


2.5.3 CM-ASE protocol description

2.5.3.1 Introduction

Note.— Section 2.5.3 presents requirements for CM-ASEs in specific states. Section 2.5.5 contains state tables for the CM-ASEs.

2.5.3.1.1 If no actions are described for a CM service primitive when a CM-ASE is in a specific state, then the invocation of that service primitive shall be prohibited while the CM-ASE is in that state.

2.5.3.1.2 Upon receipt of a PDU or dialogue service primitive, if no actions are described for the arrival of that PDU or dialogue service primitive when a CM-ASE is in a specific state, then that PDU or dialogue service primitive is considered not permitted and exception handling procedures as described in 2.5.4.4 shall apply.

2.5.3.1.3 If a PDU is received that cannot be decoded, then that PDU is considered an invalid PDU and exception handling procedures as described in 2.5.4.3 shall apply.

2.5.3.1.4 If a PDU is not received when one is required, then that PDU is considered an invalid PDU and exception handling procedures as described in 2.5.4.3 shall apply.

2.5.3.2 CM-air-ASE protocol description

2.5.3.2.1 General

2.5.3.2.1.1 The states defined for the CM-air-ASE are the following:

a) IDLE;

b) LOGON;

c) CONTACT;

d) SERVER QUERY (CM version 2);

e) SERVER QUERY DIALOGUE (CM version 2);

fd) DIALOGUE; and

ge) CONTACT DIALOGUE.

2.5.3.2.1.2 The CM-air-user is considered an active user from the time:

a) the CM-air-user invokes a CM-logon Req until it:

1) receives a CM-logon Cnf, if a dialogue is not maintained; or

2) receives a CM-end Ind, if a dialogue is maintained; or

243324342435243624372438243924402441244224432444244524462447244824492450245124522453245424552456245724582459246024612462246324642465246624672468246924702471247224732474247524762477247824792480248124822483


3) receives a CM-user abort; or

4) receives a CM-provider abort; or

5) invokes a CM-user abort; or

b) the CM-air-user receives a CM-contact Ind until it:

1) invokes a CM-contact Rsp, if a dialogue is not maintained; or



4) invokes a CM-user abort with the ground system that invoked the CM-contact service; or.

c) in version 2, the CM-air-user invokes a CM-server-facility-query Req until it:

1) receives a CM-server-facility-query Cnf, if a dialogue is not maintained; or

2) receives a CM-end Ind, if a dialogue is maintained; or



5) invokes a CM-user abort.

2.5.3.2.1.3 On initiation, the CM-air-ASE shall be in the IDLE state.

2.5.3.2.2 D-START indication

Upon receipt of a D-START indication, if the CM-air-ASE is in the IDLE state, and the D-START Priority Quality of Service (QOS) parameter has the abstract value “flight regularity communications”, and the D-START RER QOS parameter has the abstract value of “low”, and the D-START Routing Class QOS parameter identifies the traffic category “air traffic service communications (ATSC)”, and the Calling Peer ID parameter is a valid four- to eight-character facility designation, and if CM version 2, the D-START Security Requirements parameter is consistent with the local security policy, then:

a) if the APDU contained in the D-START User Data parameter is a CMGroundMesssage[CMUpdate] or, if CM version 2, a CMGroundMessage[CMSecureUpdate] APDU, the CM-air-ASE shall:

1) invoke CM-update service indication with:

i) the D-START Calling Peer ID parameter value as the CM-update Facility Designation parameter value; and

ii) the APDU contained in the D-START User Data parameter as the CM-update Update Information parameter value;

2484248524862487248824892490249124922493249424952496249724982499250025012502250325042505250625072508250925102511251225132514251525162517251825192520252125222523252425252526252725282529253025312532253325342535


2) invoke D-START response with the abstract value “rejected (permanent)” provided as the D-START Result parameter value and, if CM version 2, the D-START Security Requirements parameter value set to the same value as was received in the D-START indication; and

3) enter the IDLE state; or

b) if the APDU contained in the D-START User Data parameter is a CMGroundMessage[CMContactRequest] APDU, the CM-air-ASE shall:

1) invoke CM-contact service indication with:

i) the D-START Calling Peer ID parameter value as the CM-contact Facility Designation parameter value; and

ii) the APDU contained in the D-START User Data parameter as the CM-contact Contact Request parameter value; and

2) enter the CONTACT state; or.

c) for CM version 2, if the APDU contained in the D-START User Data is a CMGroundMessage[CMServerFacilityUpdate] APDU, the CM-air-ASE shall:

1) invoke CM-server-facility-update service indication with:

i) the D-START Calling Peer ID parameter value as the CM-server-facility-update Facility Designation parameter value; and

ii) the APDU contained in the D-START User Data parameter as the CM-server-facility-update Server Facility Update Information parameter value; and

2) invoke D-START response with the abstract value “rejected (permanent)” provided as D-START Result parameter, and the D-START Security Requirements parameter value set to the same value as was received in the D-START indication; and

3) enter the IDLE state.

2.5.3.2.3 D-START confirmation

2.5.3.2.3.1 Upon receipt of a D-START confirmation, if the CM-air-ASE is in the LOGON state, and if the APDU contained in the D-START User Data parameter is either a CMGroundMessage[CMLogonResponse] APDU or, if CM version 2, a CMGroundMessage[CMSecureLogonResponse] APDU, and if CM version 2, and the D-START confirmation Security Requirements parameter value is the same as was set for the D-START request, or if the D-START User Data parameter is not present but the D-START DS-User Version Number parameter is present, the CM-air-ASE shall:

a) stop timer tlogon;

b) if the abstract value of the D-START Result parameter is “rejected (permanent)” and the abstract value of the D-START Reject Source parameter is “DS-user”, then:

2536253725382539254025412542254325442545254625472548254925502551255225532554255525562557255825592560256125622563256425652566256725682569257025712572257325742575257625772578257925802581258225832584258525862587


1) if the version number of the CM-air-ASE is greater than the D-START DS-User Version Number parameter value, invoke CM-logon service confirmation with the D-START DS-User Version Number parameter value as the CM-logon CM-ASE Version Number parameter value; or

2) if the version number of the CM-air-ASE is not greater than the D-START DS-User Version Number parameter value, invoke CM-logon service confirmation with the APDU contained in the D-START User Data parameter as the CM-logon Logon Response parameter; and

3) enter the IDLE state; and

c) if the abstract value of the D-START Result parameter is “accepted”, then:

1) invoke CM-logon service confirmation with:

i) the APDU contained in the D-START User Data parameter as the CM-logon Logon Response parameter value; and

ii) the abstract value of “maintain” as the CM-logon Maintain Dialogue parameter value; and

2) enter the DIALOGUE state.

Note.— For CM version 2, iIf a secure D-START request was issued (i.e. the Security Requirements parameter was set to “secured dialogue supporting key managementsecured dialogue supporting security information management”), then the D-START confirmation Security Requirements parameter must be equal to that value. If an unsecure D-START request was issued (i.e. the Security Requirements parameter was set to “no security”), then the D-START confirmation Security Requirements parameter will be equal to that value. A peer CM version 1 peer willmay not set the Security Requirements parameter. However, the local upper layers will convert the absent parameter into a “no security” value. Therefore, the check to see that the received D-START confirmation Security Requirements parameter value is the same as the D-START request Security Requirements parameter value will work for all CM version 2 communicating with both CM version 2 and CM version 1 peers.

2.5.3.2.3.2 For CM version 2, upon receipt of a D-START confirmation, if the CM-air-ASE is in the SERVER QUERY state, and if the APDU contained in the D-START User Data parameter is a CMGroundMessage[CMServerFacilityQueryResponse] APDU, and the D-START confirmation Security Requirements parameter value is the same as was set for the D-START request, the CM-air-ASE shall:

a) stop timer tsrv_query;

b) if the abstract value of the D-START Result parameter is “rejected (permanent)” and the abstract value of the D-START Reject Source parameter is “DS-user”, then:

1) invoke CM-server-facility-query service confirmation with the APDU contained in the D-START User Data parameter as the CM-server-facility-query Server Facility Query Response parameter; and

2) enter the IDLE state; and

c) if the abstract value of the D-START Result parameter is “accepted”, then:

1) invoke CM-server-facility-query service confirmation with:

i) the APDU contained in the D-START User Data parameter as the CM-server-facility-query Server Facility Query Response parameter value; and

25882589259025912592259325942595259625972598259926002601260226032604260526062607260826092610261126122613261426152616261726182619262026212622262326242625262626272628262926302631263226332634263526362637263826392640


ii) the abstract value of “maintain” as the CM-server-facility-query Maintain Dialogue parameter value; and

2) enter the DIALOGUE state.

2.5.3.2.4 D-DATA indication

2.5.3.2.4.1 Upon receipt of a D-DATA indication, if the CM-air-ASE is in the DIALOGUE state, then:

a) if the APDU contained in the D-DATA User Data parameter is a CMGroundMessage[CMUpdate] or, if CM version 2, a CMGroundMessage[CMSecureUpdate] APDU, the CM-air-ASE shall:

1) invoke CM-update service indication with the APDU contained in the D-DATA User Data parameter as the CM-update service Update Information parameter value; and

2) remain in the DIALOGUE state; or

b) if the APDU contained in the D-DATA User Data parameter is a CMGroundMessage[CMContactRequest] APDU, the CM-air-ASE shall:

1) invoke CM-contact service indication with the APDU contained in the D-DATA User Data parameter as the CM-contact service Contact Request parameter value; and

2) enter the CONTACT DIALOGUE state; or.

c) for CM version 2, if the APDU contained in the D-DATA User Data parameter is a CMGroundMessage[CMServerFacilityUpdate] APDU, the CM-air-ASE shall:

1) invoke CM-server-facility-update service indication with the APDU contained in the D-DATA User Data parameter as the CM-server-facility-update service Server Facility Update Information parameter value; and

2) remain in the DIALOGUE state.

2.5.3.2.4.2 For CM version 2, upon receipt of a D-DATA indication, if the CM-air-ASE is in the SERVER QUERY DIALOGUE state, then:

a) if the APDU contained in the D-DATA User Data parameter is a CMGroundMessage[CMServerFacilityQueryResponse] APDU, the CM-air-ASE shall:

1) stop timer tsrv_query;

2) invoke CM-server-facility-query service confirmation with the APDU contained in the D-DATA User Data parameter as the CM-server-facility-query service Server Facility Query Response parameter value; and

3) enter the DIALOGUE state; or

b) if the APDU contained in the D-DATA User Data parameter is a CMGroundMessage[CMContactRequest] APDU, the CM-air-ASE shall:

2641264226432644264526462647264826492650265126522653265426552656265726582659266026612662266326642665266626672668266926702671267226732674267526762677267826792680268126822683268426852686268726882689269026912692


1) stop timer tsrv_query;

2) invoke CM-server-facility-query service confirmation with the CMServerFacilityQueryResponse [InfoUnavailable:serviceInterrupted] APDU message element as the CM-server-facility-query service Server Facility Query Response parameter value;

3) invoke CM-contact service indication with the APDU contained in the D-DATA User Data parameter as the CM-contact service Contact Request parameter value; and

4) enter the CONTACT DIALOGUE state; or

Note.— This is the collision case for a CM-server-facility-query service and a CM-contact service. The CM-air-user will abandon its CM-server-facility-query service and proceed with the CM-contact service.

c) if the APDU contained in the D-DATA User Data parameter is a CMGroundMessage[CMUpdate] APDU or a CMGroundMessage[CMServerFacilityUpdate] APDU, the CM-air-ASE shall:

1) discard the D-DATA indication; and

2) remain in the SERVER QUERY DIALOGUE state.

Note.— This is the collision case for a CM-server-facility-query service and a CM-update or CM-server-facility-update service. In either of these cases, if the aircraft gave precedence to the CM-update or CM-server-facility-update services (as it did for the CM-contact collision case) and abandons the CM-server-facility-query service, then the ground system will be left in a position where it may still respond to the CM-server-facility-query service after the CM-air-ASE has already completed it. This would result in a protocol error. Therefore, the CM-air-ASE ignores the CM-update or CM-server-facility-update services in this collision case.

2.5.3.2.5 D-END indication

2.5.3.2.5.1 Upon receipt of a D-END indication, if the CM-air-ASE is in the DIALOGUE state, then the CM-air-ASE shall:

a) invoke CM-end service indication;

b) invoke D-END response with the D-END Result parameter set to the abstract value “accepted”; and

c) enter the IDLE state.

2.5.3.2.5.2 Upon receipt of a D-END indication, if the CM-air-ASE is in the SERVER QUERY DIALOGUE state, then the CM-air-ASE shall:

a) stop timer tsrv_query;

b) invoke CM-server-facility-query service confirmation with the CMServerFacilityQueryResponse [InfoUnavailable:serviceInterrupted] APDU message element as the CM-server-facility-query service Server Facility Query Response parameter value;

c) invoke CM-end service indication;

2693269426952696269726982699270027012702270327042705270627072708270927102711271227132714271527162717271827192720272127222723272427252726272727282729273027312732273327342735273627372738273927402741274227432744


d) invoke D-END response with the D-END Result parameter set to the abstract value “accepted”; and

e) enter the IDLE state.

Note.— This is the collision case between the CM-server-facility-query service and the CM-end service. The CM-air-ASE will abandon its CM-server-facility-query service and proceed with the CM-end service.

2.5.3.2.6 CM-logon and CM-server-facility-query service request

2.5.3.2.6.1 Upon receipt of a CM-logon service request, if the CM-air-ASE is in the IDLE state, the CM-air-ASE shall:

a) create a CMAircraftMessage APDU with a cmLogonRequest APDU element based on the Logon Request parameter value;

b) invoke D-START request with:

1) the CM-logon Facility Designation parameter value as the D-START Called Peer ID parameter value;

2) the CM-logon Aircraft Address parameter value as the D-START Calling Peer ID parameter value;

3) for CM version 2, if the Emulated Version parameter is not provided, the CM-air-ASE version number as the D-START DS-User Version Number parameter value; otherwise, the Emulated Version parameter value as the D-START DS-User Version Number parameter value;

43) the D-START Quality of Service parameters set as follows:

i) if provided, the CM-logon service Class of Communication Service parameter value as the D-START Routing Class parameter value;

ii) the abstract value of “flight regularity communications” as the D-START Priority parameter value; and

iii) the abstract value of “low” as the D-START RER parameter value;

5) for CM version 2, the CM-logon Security Required parameter value as the D-START Security Requirements parameter value; and

6) the CMAircraftMessage APDU as the D-START User Data parameter value;

c) start timer tlogon; and

d) enter the LOGON state.

2.5.3.2.6.2 For CM version 2, upon receipt of a CM-server-facility-query request, if the CM-air-ASE is in the IDLE state, the CM-air-ASE shall:

a) create a CMAircraftMessage APDU with a cmServerFacilityQueryRequest APDU element based on the Server Facility Query Request parameter value;


1) the CM-server-facility-query Facility Designation parameter value as the D-START Called Peer ID parameter value;

2745274627472748

27492750275127522753275427552756275727582759276027612762276327642765276627672768276927702771277227732774277527762777277827792780278127822783278427852786278727882789279027912792279327942795279627972798


2) the CM-server-facility-query Aircraft Address parameter value as the D-START Calling Peer ID parameter value;

3) the CM-air-ASE version number as the D-START DS-User Version Number parameter value;

4) the CM-server-facility-query Security Required parameter value as the D-START Security Requirements parameter value;


i) if provided, the CM-logon service Class of Communication Service parameter value as the D-START Routing Class parameter value;


iii) the abstract value of “low” as the D-START RER parameter value; and

6) the CMAircraftMessage APDU as the D-START User Data parameter value;

c) start timer tsrv_query; and

d) enter the SERVER QUERY state.

2.5.3.2.6.3 For CM version 2, upon receipt of a CM-server-facility-query request, If the CM-air-ASE is in the DIALOGUE state, the CM-air-ASE shall:

a) create a CMAircraftMessage APDU with a cmServerFacilityQueryRequest APDU element based on the Server Facility Query Request parameter value;

b) invoke D-DATA request with the CMAircraftMessage APDU as the D-DATA User Data parameter value; and

c) enter the SERVER QUERY DIALOGUE state.

2.5.3.2.7 CM-contact service response

2.5.3.2.7.1 Upon receipt of a CM-contact service response, if the CM-air-ASE is in the CONTACT state, the CM-air-ASE shall:

a) create a CMAircraftMessage APDU with cmContactResponse APDU element based on the CM-contact Contact Response parameter value;

b) invoke D-START response with:

1) the abstract value “rejected (permanent)” as D-START Result parameter value;

2) if CM version 2, the D-START Security Requirements parameter value set to the same value as was received in the D-START indication; and

3) the CMAircraftMessage APDU as the D-START User Data parameter value; and


279928002801280228032804280528062807280828092810281128122813281428152816281728182819282028212822282328242825282628272828282928302831283228332834283528362837283828392840284128422843284428452846284728482849285028512852


2.5.3.2.7.2 Upon receipt of a CM-contact service response, if the CM-air-ASE is in the CONTACT DIALOGUE state, the CM-air-ASE shall:

a) create a CMAircraftMessage APDU with a cmContactResponse APDU element based on the CM-contact Contact Response parameter value;

b) invoke D-DATA request with the CMAircraftMessage APDU as the D-DATA User Data parameter value; and

c) enter the DIALOGUE state.

2.5.3.2.8 CM-user-abort service request

Upon receipt of a CM-user-abort service request, if the CM-air-ASE is not in the IDLE state, the CM-air-ASE shall:

a) stop timer tlogon or, if CM version 2, tsrv_query, if set;

b) invoke D-ABORT request with the D-ABORT Originator parameter set to the abstract value “user”; and


2.5.3.2.9 D-ABORT indication

Upon receipt of a D-ABORT indication, if the CM-air-ASE is not in the IDLE state, the CM-air-ASE shall:


b) if the CM-air-user is an active user, then:

1) if the D-ABORT Originator parameter contains the abstract value “user”, invoke CM-user-abort service indication; or

2) if the D-ABORT Originator parameter does not contain the abstract value “user”, invoke CM-provider-abort service indication with the APDU contained in the D-ABORT User Data parameter as the CM-provider-abort service Reason parameter value; and

c) enter IDLE state.

2.5.3.2.10 D-P-ABORT indication

Upon receipt of a D-P-ABORT indication, if the CM-air-ASE is not in the IDLE state, the CM-air-ASE shall:


b) if the CM-air-user is an active user, invoke CM-provider-abort service indication with the CM-provider-abort Reason parameter set to the abstract value “communication-service-failure”; and


2853285428552856285728582859286028612862286328642865286628672868286928702871287228732874287528762877287828792880288128822883288428852886288728882889289028912892289328942895289628972898289929002901290229032904


2.5.3.3 CM-ground-ASE protocol description

2.5.3.3.1 General

2.5.3.3.1.1 The states defined for the CM-ground-ASE are the following:

a) IDLE;

b) LOGON;

c) UPDATE;

d) CONTACT;

e) DIALOGUE;

f) CONTACT DIALOGUE;

g) SERVER QUERY (CM version 2);

h) SERVER QUERY DIALOGUE (CM version 2);

ig) END; and

jh) FORWARD.

2.5.3.3.1.2 The CM-ground-user is considered an active user from the time:

a) the CM-ground-user receives a CM-logon Ind until it:

1) invokes a CM-logon Rsp, if a dialogue is not maintained; or

2) invokes a CM-end Req, if a dialogue is maintained; or




b) the CM-ground-user invokes a CM-contact Req until it:

1) receives a CM-contact Cnf, if a dialogue is not maintained; or




2905290629072908290929102911291229132914291529162917291829192920292129222923292429252926292729282929293029312932293329342935293629372938293929402941294229432944294529462947294829492950295129522953295429552956


29572958


c) the CM-ground-user invokes a CM-forward Req until it:

1) receives a CM-forward Cnf; or



d) for version 2, the CM-ground-user receives a CM-server-facility-query Ind until it:

1) invokes a CM-server-facility-query Rsp, if a dialogue is not maintained; or

2) invokes a CM-end Req, if a dialogue is maintained; or



5) invokes a CM-user abort.

2.5.3.3.1.3 On initiation, the CM-ground-ASE shall be in the IDLE state.

2.5.3.3.2 D-START indication

2.5.3.3.2.1 Upon receipt of a D-START indication, if the CM-ground-ASE is in the IDLE state, and the abstract value of the D-START Calling Peer ID parameter is the ICAO 24-bit aircraft address, and the D-START Priority QOS parameter has the abstract value “flight regularity communications”, and the D-START RER QOS parameter has the abstract value of “low”, and the D-START Routing Class QOS parameter identifies the traffic category “air traffic service communications (ATSC)”, and if CM version 2, the D-START Security Requirements parameter is consistent with the local security policy, then:

a) if the D-START DS-User Version Number parameter value is greater than the CM-ground-ASE version number, the CM-ground-ASE shall:

1) invoke D-START response with:

i) the CM-ground-ASE version number as the D-START DS-User Version Number parameter value; and

ii) the abstract value of “rejected (permanent)” as the D-START Result parameter value; and

2) enter the IDLE state; or

Note.— For CM version 2, Tthe D-START Security Requirements parameter is not explicitly set by the CM-ground-ASE in the case that the aircraft’s CM version number is greater than the ground’s CM version number.

b) if the D-START DS-User Version Number parameter value is less than the CM-ground-ASE version number, and the APDU contained in the D-START User Data parameter is a CMAircraftMessage[CMLogonRequest] APDU, the CM-ground-ASE shall:

2959296029612962296329642965296629672968296929702971297229732974297529762977297829792980298129822983298429852986298729882989299029912992299329942995299629972998299930003001300230033004300530063007300830093010


1) invoke CM-logon service indication with:

i) the D-START Calling Peer ID parameter value as the CM-logon service Aircraft Address parameter value;

ii) if CM version 2, the D-START Security Requirements parameter value as the CM-logon service Security Required parameter value;

iii) the D-START DS-User Version Number parameter value as the CM-logon service CM-ASE Version Number parameter value; and

iv) the APDU in the D-START User Data parameter as the CM-logon service Logon Request parameter value; and

2) enter the LOGON state; or

c) if the D-START DS-User Version Number parameter value is equal to CM-ground-ASE version number, and the APDU contained in the D-START User Data parameter is a CMAircraftMessage[CMLogonRequest] APDU, the CM-ground-ASE shall:

1) invoke CM-logon service indication with:

i) the D-START Calling Peer ID parameter value as the CM-logon service Aircraft Address parameter value;

ii) if CM version 2, the D-START Security Requirements parameter value as the CM-logon service Security Required parameter value; and

iii) the APDU in the D-START User Data parameter as the CM-logon service Logon Request parameter value; and

2) enter the LOGON state.

2.5.3.3.2.2 Upon receipt of a D-START indication, if the receiving CM-ground-ASE is in the IDLE state, and the APDU contained in the D-START User Data parameter is a CMGroundMessage[CMForwardRequest] or, if CM version 2, a CMGroundMessage[CMEnhancedForwardRequest] APDU, and the abstract value of the D-START Calling Peer ID parameter is a four- to eight-character facility designation, and the D-START Priority QOS parameter has the abstract value “flight regularity communications”, and the D-START RER QOS parameter has the abstract value of “low”, and the D-START Routing Class QOS parameter identifies the traffic category “air traffic service communications (ATSC)”, then:

a) if the CM-ground-ASE does not support the CM-forward service, the CM-ground-ASE shall:

1) create a CMGroundMessage APDU with a cmForwardResponse [service-not-supported] APDU message element;


i) the APDU as the D-START User Data parameter value; and

ii) the abstract value “rejected (permanent)” as the D-START Result parameter value; and

3) remain in the IDLE state; or

3011301230133014301530163017301830193020302130223023302430253026302730283029303030313032303330343035303630373038303930403041304230433044304530463047304830493050305130523053305430553056305730583059306030613062


Note.— For CM version 2, tThe D-START Security Requirements parameter is not explicitly set by the CM-ground-ASE if the CM-forward service is not supported.

b) if the D-START DS-User Version Number parameter value is greater than the CM-ground-ASE version number and, if CM version 2, the D-START Security Requirements parameter is consistent with the local security policy and the CM-ground-ASE supports the CM-forward service, the CM-ground-ASE shall:

1) create a CMGroundMessage APDU with a cmForwardResponse [incompatible-version] APDU message element;


i) the CM-ground-ASE version number as the D-START DS-User Version Number parameter value;

ii) the APDU as the D-START User Data parameter value;

iii) the abstract value of “rejected (permanent)” as the D-START Result parameter value; and

iv) if CM version 2, the D-START Security Requirements parameter value set to the same value as was received in the D-START indication; and


c) if the D-START DS-User Version Number parameter value is less than the CM-ground-ASE version number and, if CM version 2, the D-START Security Requirements parameter is consistent with the local security policy and the CM-ground-ASE supports the CM-forward service, the CM-ground-ASE shall:

1) invoke CM-forward service indication with:

i) the D-START Calling Peer ID parameter value as the CM-forward service Calling Facility Designation parameter value;

ii) the D-START DS-User Version Number parameter value as the CM-forward service CM-ASE Version Number parameter value; and

iii) the APDU in the D-START User Data parameter as the CM-forward service Forward Request parameter value;

2) create a CMGroundMessage APDU with a cmForwardResponse [success] APDU message element;


i) the APDU as the D-START User Data parameter value;

ii) if CM version 2, the D-START Security Requirements parameter value set to the same value as was received in the D-START indication; and


3063306430653066306730683069307030713072307330743075307630773078307930803081308230833084308530863087308830893090309130923093309430953096309730983099310031013102310331043105310631073108310931103111311231133114



Note.— This assumes that CM-ASEs are backwards compatible.

d) if the D-START DS-User Version Number parameter value is equal to the CM-ground-ASE version number and, if CM version 2, the D-START Security Requirements parameter is consistent with the local security policy and the CM-ground-ASE supports the CM-forward service, the CM-ground-ASE shall:

1) invoke CM-forward service indication with:

i) the D-START Calling Peer ID parameter value as the CM-forward service Calling Facility Designation parameter value; and

ii) the APDU in the D-START User Data parameter as the CM-forward service Forward Request parameter value;

2) create a CMGroundMessage APDU with a cmForwardResponse [success] APDU message element;


i) the APDU as the D-START User Data parameter value;

ii) if CM version 2, the D-START Security Requirements parameter value set to the same value as was received in the D-START indication; and


4) remain in the IDLE state.

2.5.3.3.2.3 For CM version 2, upon receipt of a D-START indication, if the CM-ground-ASE is in the IDLE state, and the APDU contained in the D-START User Data parameter is a CMAircraftMessage[CMServerFacilityQueryRequest] APDU, and the abstract value of the D-START Calling Peer ID parameter is the ICAO 24-bit aircraft address, and the D-START Priority Quality of Service parameter has the abstract value “flight regularity communications”, and the RER Quality of Service parameter has the abstract value “low”, and the D-START Security Requirements parameter is consistent with the local security policy, then the CM-ground-ASE shall:

a) invoke CM-server-facility-query indication with:

1) the D-START Calling Peer ID parameter value as the CM-server-facility-query service Aircraft Address parameter value;

2) the D-START Security Requirements parameter value as the CM-server-facility-query service Security Required parameter value; and

3) the APDU in the D-START User Data parameter as the CM-server-facility-query service Server Facility Query Request parameter value; and

b) enter the SERVER QUERY state.

3115311631173118311931203121312231233124312531263127312831293130313131323133313431353136313731383139314031413142314331443145314631473148314931503151315231533154315531563157315831593160316131623163316431653166


2.5.3.3.3 D-START confirmation

2.5.3.3.3.1 Upon receipt of a D-START confirmation, if the CM-ground-ASE is in the UPDATE state and the D-START User Data parameter is not provided, the CM-ground-ASE shall:

a) stop timer tupdate; and

b) if the abstract value of the D-START Result parameter is “rejected (permanent)”, and the abstract value of the D-START Reject Source parameter is “DS-user” and, if CM version 2, the abstract value of the D-START Security Requirements parameter is the same as was set in the D-START request, enter the IDLE state.

Note.— For CM version 2, Iif a secure D-START request was issued (i.e. the Security Requirements parameter was set to “secured dialogue supporting key managementsecured dialogue supporting security information management” or “secured dialogue”), then the D-START confirmation Security Requirements parameter must be equal to that value. If an unsecure D-START request was issued (i.e. the Security Requirements parameter was set to “no security”), then the D-START confirmation Security Requirements parameter will be equal to that value. A peer CM version 1 peer maywill not set the Security Requirements parameter. However, the local upper layers will convert the absent parameter into a “no security” value. Therefore, the check to see that the received D-START confirmation Security Requirements parameter value is the same as the D-START request Security Requirements parameter value will work for CM version 2 communicating with both CM version 2 and CM version 1all CM peers.

2.5.3.3.3.2 Upon receipt of a D-START confirmation, if the CM-ground-ASE is in the CONTACT state, and the APDU contained in the D-START User Data parameter is a CMAircraftMessage[CMContactResponse] APDU, the CM-ground-ASE shall:

a) stop timer tcontact; and

b) if the abstract value of the D-START Result parameter is “rejected (permanent)”, and the abstract value of the D-START Reject Source parameter is “DS-user” and, if CM version 2, the abstract value of the D-START Security Requirements parameter is the same as was set in the D-START request then:

1) invoke CM-contact service confirmation with the APDU in the D-START User Data parameter as the CM-contact Contact Response parameter value; and


Note.— For CM version 2, iIf a secure D-START request was issued (i.e. the Security Requirements parameter was set to “secured dialogue supporting key managementsecured dialogue supporting security information management” or “secured dialogue”), then the D-START confirmation Security Requirements parameter must be equal to that value. If an unsecure D-START request was issued (i.e. the Security Requirements parameter was set to “no security”), then the D-START confirmation Security Requirements parameter will be equal to that value. A peer CM version 1 peer willmay not set the Security Requirements parameter. However, the local upper layers will convert the absent parameter into a “no security” value. Therefore, the check to see that the received D-START confirmation Security Requirements parameter value is the same as the D-START request Security Requirements parameter value will work for all CM version 2 communicating with both CM version 2 and CM version 1 peers.

2.5.3.3.3.3 Upon receipt of a D-START confirmation, if the CM-ground-ASE is in the FORWARD state, and the D-START User Data parameter is a CMGroundMessage[CMForwardResponse] APDU, and the abstract value of the D-START Result parameter is “rejected (permanent)”, and the abstract value of the D-START Reject Source parameter is “DS-user”, the CM-ground-ASE shall:

3167316831693170317131723173317431753176317731783179318031813182318331843185318631873188318931903191319231933194319531963197319831993200320132023203320432053206320732083209321032113212321332143215321632173218


a) stop timer tforward;

b) if the abstract value of the D-START User Data parameter is “service-not-supported” and, if CM version 2, the abstract value of the D-START confirmation Security Requirements parameter is the same as was set in the D-START request, invoke a CM-forward service confirmation with the CM-forward Result parameter set to the abstract value “service-not-supported”;

c) if the abstract value of the D-START User Data parameter is “incompatible-version” and, if CM version 2, the abstract value of the D-START confirmation Security Requirements parameter is the same as was set in the D-START request, invoke a CM-forward service confirmation with the DS-User Version Number parameter value as the CM-forward CM-ASE Version Number parameter and set the CM-forward Result parameter abstract value to “incompatible-version”;

d) if the abstract value of the D-START User Data parameter is “success” and, if CM version 2, the abstract value of the D-START confirmation Security Requirements parameter is the same as was set in the D-START request, invoke a CM-forward service confirmation with the CM-forward Result parameter set to the abstract value “success”; and


Note.— For CM version 2, iIf a secure D-START request was issued (i.e. the Security Requirements parameter was set to “secured dialogue supporting key managementsecured dialogue supporting security information management”), then the D-START confirmation Security Requirements parameter must be equal to that value. If an unsecure D-START request was issued (i.e. the Security Requirements parameter was set to “no security”), then the D-START confirmation Security Requirements parameter will be equal to that value. A peer CM version 1 peer will may not set the Security Requirements parameter. However, the local upper layers will convert the absent parameter into a “no security” value. Therefore, the check to see that the received D-START confirmation Security Requirements parameter value is the same as the D-START request Security Requirements parameter value will work for all CM version 2 communicating with both CM version 2 and CM version 1 peers.

2.5.3.3.4 D-DATA indication

2.5.3.3.4.1 Upon receipt of a D-DATA indication, if the CM-ground-ASE is in the CONTACT DIALOGUE state, and the APDU contained in the D-DATA User Data parameter is a CMAircraftMessage[CMContactResponse] APDU, the CM-ground-ASE shall:

a) stop timer tcontact;

b) invoke CM-contact service confirmation with the APDU contained in the D-DATA User Data parameter as the CM-contact Contact Response parameter value; and


2.5.3.3.4.2 For CM version 2, upon receipt of a D-DATA indication, if the CM-ground-ASE is in the DIALOGUE state, and the APDU contained in the D-DATA User Data parameter is a CMAircraftMessage[CMServerFacilityQueryRequest] APDU, the CM-ground-ASE shall:

a) invoke CM-server-facility-query service indication with the APDU contained in the D-DATA User Data parameter as the CM-server-facility-query Server Facility Query Request parameter value; and

b) enter the SERVER QUERY DIALOGUE state.

3219322032213222322332243225322632273228322932303231323232333234323532363237323832393240324132423243324432453246324732483249325032513252325332543255325632573258325932603261326232633264326532663267326832693270


2.5.3.3.4.3 For CM version 2, upon receipt of a D-DATA indication, if the CM-ground-ASE is in the CONTACT DIALOGUE state, and the APDU contained in the D-DATA User Data parameter is a CMAircraftMessage[CMServerFacilityQueryRequest] APDU, the CM-ground-ASE shall:

a) discard the D-DATA indication; and

b) remain in the CONTACT DIALOGUE state.

Note.— This is the collision case for the CM-contact and CM-server-facility-query services. In this case, the CM-ground-ASE ignores the CM-server-facility-query indication and continues with the CM-contact service. The peer aircraft with abandon the CM-server-facility-query service and proceed with the CM-contact service.

2.5.3.3.4.4 For CM version 2, upon receipt of a D-DATA indication, if the CM-ground-ASE is in the END state, and the APDU contained in the D-DATA User Data parameter is a CMAircraftMessage[CMServerFacilityQueryRequest] APDU, the CM-ground-ASE shall:

a) discard the D-DATA indication; and

b) remain in the END state.

Note.— This is the collision case for the CM-end and CM-server-facility-query services. In this case, the CM-ground-ASE ignores the CM-server-facility-query indication and continues with the CM-end service. The peer aircraft with abandon the CM-server-facility-query service and proceed with the CM-end service.

2.5.3.3.5 D-END confirmation

Upon receipt of a D-END confirmation, if the CM-ground-ASE is in the END state and the abstract value of the D-END Result is “accepted”, the CM-ground-ASE shall:

a) stop timer tend; and

b) enter the IDLE state.

2.5.3.3.6 CM-logon and CM-server-facility-query service response

2.5.3.3.6.1 Upon receipt of a CM-logon service response, if the CM-ground-ASE is in the LOGON state, and if version 1 CM or if version 2 CM emulating a version 1 CM, the CM-ground-ASE shall:

a) create a CMGroundMessage APDU with a cmLogonResponse APDU element based on the CM-logon Logon Response parameter value; and

b) invoke D-START response with the CMGroundMessage APDU as the D-START User Data parameter value; and

c) if the CM-logon Maintain Dialogue parameter is provided by the CM-ground-user:

1) set the abstract value “accepted” as the D-START Result parameter value; and


3271327232733274327532763277327832793280328132823283328432853286328732883289329032913292329332943295329632973298329933003301330233033304330533063307330833093310331133123313331433153316331733183319332033213322


d) if the CM-logon Maintain Dialogue parameter is not provided by the CM-ground-user:

1) set the abstract value “rejected (permanent)” as the D-START Result parameter value; and


2.5.3.3.6.2 For CM version 2 not communicating with a version 1 CM, upon receipt of a CM-logon service response, if the CM-ground-ASE is in the LOGON state, the CM-ground-ASE shall:

a) create a CMGroundMessage APDU with a cmSecureLogonResponse APDU element based on the CM-logon Logon Response parameter value; and


1) the CMGroundMessage APDU as the D-START User Data parameter value; and

2) the D-START Security Requirements parameter value set to the same value as was received in the D-START indication; and

c) if the CM-logon Maintain Dialogue parameter is provided by the CM-ground-user:



d) if the CM-logon Maintain Dialogue parameter is not provided by the CM-ground-user:



Note.— The CM version number is not included in the D-START response primitive if the CM-ground-ASE version number is less than or equal to the CM-air-ASE version number.

2.5.3.3.6.3 For CM version 2, upon receipt of a CM-server-facility-query response, if the CM-ground-ASE is in the SERVER QUERY state, the CM-ground-ASE shall:

a) create a CMGroundMessage APDU with a cmServerFacilityQueryResponse APDU element based on the CM-server-facility-query Server Facility Query Response parameter value; and



2) the D-START Security Requirements parameter value set to the same value as was received in the D-START indication; and

c) if the CM-server-facility-query Maintain Dialogue parameter is provided by the CM-ground-user:



3323332433253326332733283329333033313332333333343335333633373338333933403341334233433344334533463347334833493350335133523353335433553356335733583359336033613362336333643365336633673368336933703371337233733374


d) if the CM-server-facility-query Maintain Dialogue parameter is not provided by the CM-ground-user:



2.5.3.3.6.4 For CM version 2, upon receipt of a CM-server-facility-query response, if the CM-ground-ASE is in the SERVER QUERY DIALOGUE state, the CM-ground-ASE shall:

a) create a CMGroundMessage APDU with a cmServerFacilityQueryResponse APDU element based on the CM-server-facility-query Server Facility Query Response parameter value;

b) invoke D-DATA request with the CMGroundMessage APDU as the D-DATA User Data parameter value; and


2.5.3.3.7 CM-update and CM-server-facility-update service request

2.5.3.3.7.1 Upon receipt of a CM-update service request, if the CM-ground-ASE is in the IDLE state, the CM-ground-ASE shall:

a) if version 1 CM, or if version 2 CM and the Security Required parameter is set to the abstract value “no Security”, create a CMGroundMessage APDU with a cmUpdate APDU element based on the CM-update Update Information parameter value;

b) if version 2 CM and the Security Required parameter is not set to the abstract value “no Security”, create a CMGroundMessage APDU with a cmSecureUpdate APDU element based on the CM-update Update Information parameter value;

cb) invoke D-START request with:

1) the CM-update Aircraft Address parameter value as the D-START Called Peer ID parameter value;

2) the CM-update Facility Designation parameter value as the D-START Calling Peer ID parameter value;


i) if provided, the CM-update service Class of Communication Service parameter value as the D-START Routing Class parameter value;




5) if CM version 2, the CM-update Security Required parameter value as the D-START Security

3375337633773378337933803381338233833384338533863387338833893390339133923393339433953396339733983399340034013402340334043405340634073408340934103411341234133414341534163417341834193420342134223423342434253426


Requirements parameter value; d) start timer tupdate; and

e) enter the UPDATE state.

2.5.3.3.7.2 Upon receipt of a CM-update service request, if the CM-ground-ASE is in the DIALOGUE state, the CM-ground-ASE shall:

a) if version 1 CM, or if version 2 CM emulating a version 1 CM, create a CMGroundMessage APDU with a cmUpdate APDU element based on the CM-update Update Information parameter value;

b) if CM version 2 not emulating a version 1 CM, create a CMGroundMessage APDU with a cmSecureUpdate APDU element based on the CM-update Update Information parameter value;

cb) invoke D-DATA request with the CMGroundMessage APDU as the D-DATA User Data parameter value; and

dc) remain in the DIALOGUE state.

2.5.3.3.7.3 For CM version 2, upon receipt of a CM-server-update service request, if the CM-ground-ASE is in the IDLE state, the CM-ground-ASE shall:

a) create a CMGroundMessage APDU with a cmServerFacilityUpdate APDU element based on the CM-server-facility-update Server Facility Update parameter value;


1) the CM-server-facility-update Aircraft Address parameter value as the D-START Called Peer ID parameter value;

2) the CM-server-facility-update Facility Designation parameter value as the D-START Calling Peer ID parameter value;


i) if provided, the CM-server-facility-update service Class of Communication Service parameter value as the D-START Routing Class parameter value;




5) the CM-server-facility-update Security Required parameter value as the D-START Security Requirements parameter value;

c) start timer tupdate; and

d) enter the UPDATE state.

3427342834293430343134323433343434353436343734383439344034413442344334443445344634473448344934503451345234533454345534563457345834593460346134623463346434653466346734683469347034713472347334743475347634773478


3479


2.5.3.3.7.4 For CM version 2, upon receipt of a CM-server-facility-update service request, if the CM-ground-ASE is in the DIALOGUE state, the CM-ground-ASE shall:

a) create a CMGroundMessage APDU with a cmServerFacilityUpdate APDU element based on the CM-server-facility-update Server Facility Update parameter value;

b) invoke D-DATA request with the CMGroundMessage APDU as the D-DATA User Data parameter value; and

c) remain in the DIALOGUE state.

2.5.3.3.8 CM-contact service request

2.5.3.3.8.1 Upon receipt of a CM-contact service request, if the CM-ground-ASE is in the IDLE state, the CM-ground-ASE shall:

a) create a CMGroundMessage APDU with a cmContactRequest APDU element based on the CM-contact Contact Request parameter value;


1) the CM-contact Aircraft Address parameter value as the D-START Called Peer ID parameter value;

2) the CM-contact Facility Designation parameter value as the D-START Calling Peer ID parameter value;


i) if provided, the CM-contact service Class of Communication Service parameter value as the D-START Routing Class parameter value;



4) if CM version 2, the CM-contact Security Required parameter as the D-START Security Requirements parameter value; and

5) the CMGroundMessage APDU as the D-START User Data parameter value;

c) start timer tcontact; and

d) enter the CONTACT state.

2.5.3.3.8.2 Upon receipt of a CM-contact service request, if the CM-ground-ASE is in the DIALOGUE state, the CM-ground-ASE shall:

3480348134823483348434853486348734883489349034913492349334943495349634973498349935003501350235033504350535063507350835093510351135123513351435153516351735183519352035213522352335243525352635273528352935303531


a) create a CMGroundMessage APDU with a cmContactRequest APDU element based on the CM-contact Contact Request parameter value;

b) invoke D-DATA request with the CMGroundMessage APDU as the D-DATA User Data parameter value;

c) start timer tcontact; and

d) enter the CONTACT DIALOGUE state.

2.5.3.3.9 CM-end service request

Upon receipt of a CM-end service request, if the CM-ground-ASE is in the DIALOGUE state, the CM-ground-ASE shall:

a) invoke D-END request;

b) start timer tend; and

c) enter the END state.

2.5.3.3.10 CM-forward service request

Upon receipt of a CM-forward service request, if the CM-ground-ASE is in the IDLE state, the CM-ground-ASE shall:

a) create a CMGroundMessage APDU with a cmForwardRequest APDU element or, if CM version 2 and the Emulated Version parameter is not provided, a cmEnhancedForwardRequest APDU element based on the CM-forward service Forward Request parameter value;


1) the CM-forward Called Facility Designation parameter value as the D-START Called Peer ID parameter value;

2) the CM-forward Calling Facility Designation parameter value as the D-START Calling Peer ID parameter value;

3) for CM version 2, if the Emulated Version parameter is not provided, the sending CM-ground-ASE version number as the D-START DS-User Version Number parameter value;

4) for CM version 2, if the Emulated Version parameter is provided, the Emulated Version parameter value as the D-START DS-User Version Number parameter value;

53) if CM version 2 and the Security Required parameter is provided, the CM-forward Security Required parameter value as the D-START Security Requirements parameter value;


i) if provided, the CM-forward service Class of Communication Service parameter value as the D-START Routing Class parameter value;

3532353335343535353635373538353935403541354235433544354535463547354835493550355135523553355435553556355735583559356035613562356335643565356635673568356935703571357235733574357535763577357835793580358135823583



iii) the abstract value of “low” as the D-START RER parameter value; and

75) the CMGroundMessage APDU as the D-START User Data parameter value;

c) start timer tforward; and

d) enter the FORWARD state.

2.5.3.3.11 CM-user-abort service request

Upon receipt of a CM-user-abort service request, if the CM-ground-ASE is not in the IDLE state, the CM-ground-ASE shall:

a) stop any timer, if set;

b) invoke D-ABORT request with the D-ABORT Originator parameter set to the abstract value “user”; and


2.5.3.3.12 D-ABORT indication

Upon receipt of a D-ABORT indication, if the CM-ground-ASE is not in the IDLE state, the CM-ground-ASE shall:


b) if the CM-ground-user is an active user, then:

1) if the D-ABORT Originator parameter contains the abstract value “user”, invoke CM-user-abort service indication; or

2) if the D-ABORT Originator parameter does not contain the abstract value “user”, invoke CM-provider-abort service indication with the APDU contained in the D-ABORT User Data parameter as the CM-provider-abort service Reason parameter value; and

c) enter IDLE state.

2.5.3.3.13 D-P-ABORT indication

Upon receipt of a D-P-ABORT indication, if the CM-ground-ASE is not in the IDLE state, the CM-ground-ASE shall:


b) if the CM-ground-user is an active user, invoke CM-provider-abort service indication with the CM-provider-abort Reason parameter set to the abstract value “communication-service-failure”; and


3584358535863587358835893590359135923593359435953596359735983599360036013602360336043605360636073608360936103611361236133614361536163617361836193620362136223623362436253626362736283629363036313632363336343635


2.5.4 Exception handling

2.5.4.1 Timer expiration

If a CM-ASE detects that a timer has expired, that CM-ASE shall:

a) stop all timers;

b) interrupt any current activity;

c) if the CM-ASE is a CM-air-ASE, create a CMAircraftMessage APDU with a cmAbortReason [timer-expired] APDU message element;

d) if the CM-ASE is a CM-ground-ASE, create a CMGroundMessage APDU with a cmAbortReason [timer-expired] APDU message element;

e) invoke D-ABORT request with:

1) the abstract value “provider” as the D-ABORT Originator parameter value; and

2) the APDU as the D-ABORT User Data parameter value;

f) if the CM-user is an active user, invoke CM-provider-abort service indication with the abstract value “timer-expired” as the CM-provider-abort Reason parameter value; and

g) enter the IDLE state.

2.5.4.2 Unrecoverable system error

If a CM-ASE has an unrecoverable system error, the CM-ASE should:

a) stop all timers;

b) if the CM-ASE is a CM-air-ASE, create a CMAircraftMessage APDU with a cmAbortReason [undefined-error] APDU message element;

c) if the CM-ASE is a CM-ground-ASE, create a CMGroundMessage APDU with a cmAbortReason [undefined-error] APDU message element;

d) invoke D-ABORT request with:



e) if the CM-user is an active user, invoke CM-provider-abort service indication with the abstract value “undefined-error” as the CM-provider-abort Reason parameter value; and

3636363736383639364036413642364336443645364636473648364936503651365236533654365536563657365836593660366136623663366436653666366736683669367036713672367336743675367636773678367936803681368236833684368536863687


f) enter the IDLE state.

2.5.4.3 Invalid PDU

2.5.4.3.1 If the User Data parameter of a D-START indication or D-DATA indication does not contain a valid PDU as defined in 2.5.3.1.3 and 2.5.3.1.4, the CM-ASE shall:

a) stop all timers;

b) if the CM-ASE is a CM-air-ASE, create a CMAircraftMessage APDU with a cmAbortReason [invalid-PDU] APDU message element;

c) if the CM-ASE is a CM-ground-ASE, create a CMGroundMessage APDU with a cmAbortReason [invalid-PDU] APDU message element;




e) if the CM-user is an active user, invoke CM-provider-abort service indication with the abstract value “invalid-PDU” as the CM-provider-abort Reason parameter value; and


2.5.4.3.2 If the User Data parameter of a D-START confirmation does not contain a valid PDU as defined in 2.5.3.1.3 and 2.5.3.1.4, the CM-ASE shall:

a) stop all timers;

b) if the CM-ASE is a CM-air-ASE and if the D-START Result parameter is set to the abstract value “accepted”, then:

1) create a CMAircraftMessage APDU with a cmAbortReason [invalid-PDU] APDU message element; and

2) invoke D-ABORT request with:

i) the abstract value “provider” as the D-ABORT Originator parameter value; and

ii) the APDU as the D-ABORT User Data parameter value;

c) if the CM-user is an active user, invoke CM-provider-abort service indication with the abstract value “invalid-PDU” as the CM-provider-abort Reason parameter value; and

d) enter the IDLE state.

2.5.4.4 Not permitted PDU or DS primitive

3688368936903691369236933694369536963697369836993700370137023703370437053706370737083709371037113712371337143715371637173718371937203721372237233724372537263727372837293730373137323733373437353736373737383739


2.5.4.4.1 If the User Data parameter of a D-START indication or D-DATA indication is a valid PDU; however, it is not a permitted PDU as defined within 2.5.3.1.2, the CM-ASE shall:

a) stop all timers;

b) if the CM-ASE is a CM-air-ASE, create a CMAircraftMessage APDU with a cmAbortReason [protocol-error] APDU message element;

c) if the CM-ASE is a CM-ground-ASE, create a CMGroundMessage APDU with a cmAbortReason [protocol-error] APDU message element;




e) if the CM-user is an active user, invoke CM-provider-abort service indication with the abstract value “protocol-error” as the CM-provider-abort Reason parameter value; and


2.5.4.4.2 If the User Data parameter of a D-START confirmation is a valid PDU; however, it is not a permitted PDU as defined within 2.5.3.1.2, the CM-ASE shall:

a) stop all timers;

b) if the D-START Result parameter is set to the abstract value “accepted”:

1) if the CM-ASE is a CM-air-ASE, create a CMAircraftMessage APDU with a cmAbortReason [protocol-error] APDU message element;

2) if the CM-ASE is a CM-ground-ASE, create a CMGroundMessage APDU with a cmAbortReason [protocol-error] APDU message element; and




c) if the CM-user is an active user, invoke CM-provider-abort service indication with the abstract value “protocol-error” as the CM-provider-abort Reason parameter value; and


2.5.4.4.3 Upon receipt of a DS primitive for which there are no instructions in 2.5.3 (i.e. the primitive was not expected or was expected under other conditions or with other parameter values), the CM-ASE shall:

a) stop all timers;

b) if the CM-ASE is a CM-air-ASE, create a CMAircraftMessage APDU with a cmAbortReason

3740374137423743374437453746374737483749375037513752375337543755375637573758375937603761376237633764376537663767376837693770377137723773377437753776377737783779378037813782378337843785378637873788378937903791


[protocol-error] APDU message element;379237933794


c) if the CM-ASE is a CM-ground-ASE, create a CMGroundMessage APDU with a cmAbortReason [protocol-error] APDU message element;

d) if a dialogue exists, invoke D-ABORT request with:



e) if the CM-user is an active user, invoke CM-provider-abort service indication with the abstract value “protocol-error” as the CM-provider-abort Reason parameter value; and


2.5.4.5 D-START confirmation Result or Reject Source parameter values not as expected

2.5.4.5.1 If the CM-ground-ASE receives a D-START confirmation with the D-START Result parameter having the abstract value of “accepted”, the CM-ground-ASE shall:

a) stop all timers;

b) create a CMGroundMessage APDU with a cmAbortReason [dialogue-acceptance-not-permitted] APDU message element;

c) invoke D-ABORT request with:



d) if the CM-ground-user is an active user, invoke CM-provider-abort service indication with the abstract value “dialogue-acceptance-not-permitted” as the CM-provider-abort Reason parameter value; and


2.5.4.5.2 If the CM-ASE receives a D-START confirmation with the D-START Result parameter having the abstract value of “rejected (transient)”, or if the D-START Reject Source parameter has the abstract value of “DS-provider”, the CM-ASE shall:

a) stop all timers;

b) if the CM-user is an active user, invoke CM-provider-abort service indication with the abstract value “communication-service-error” APDU as the CM-provider-abort Reason parameter value; and


2.5.4.6 D-END confirmation not as expected

If the CM-ground-ASE receives a D-END confirmation with the D-END Result parameter that does not have the abstract value of “accepted”, the CM-ground-ASE shall:

3795379637973798379938003801380238033804380538063807380838093810381138123813381438153816381738183819382038213822382338243825382638273828382938303831383238333834383538363837383838393840384138423843384438453846


a) stop all timers;

b) create a CMGroundMessage APDU with a cmAbortReason [dialogue-end-not-accepted] APDU message element;



2) the APDU as the D-ABORT User Data parameter value; and


2.5.4.7 D-START indication Quality of Service parameter not as expected

If the abstract value of the D-START Priority QOS parameter is not “flight regularity communications”, or the abstract value of the D-START RER QOS parameter is not “low”, or the abstract value of the D-START Routing Class QOS parameter does not identify the traffic category “air traffic service communications (ATSC)”, the CM-ASE shall:

a) stop all timers;

b) if the CM-ASE is a CM-air-ASE, create a CMAircraftMessage APDU with a CMAbortReason [invalid-QOS-parameter] APDU message element;

c) if the CM-ASE is a CM-ground-ASE, create a CMGroundMessage APDU with a CMAbortReason [invalid-QOS-parameter] APDU message element;



2) the APDU as the D-ABORT User Data parameter value; and


2.5.4.8 Expected PDU not provided

2.5.4.8.1 If the User Data parameter of a D-START indication, D-START confirmation (with the Result parameter set to the abstract value “accepted”), or D-DATA indication is not provided where it is expected, the CM-ASE shall:

a) stop all timers;

b) if the CM-ASE is a CM-air-ASE, create a CMAircraftMessage APDU with a cmAbortReason [expected-PDU-missing] APDU message element;

c) if the CM-ASE is a CM-ground-ASE, create a CMGroundMessage APDU with a cmAbortReason [expected-PDU-missing] APDU message element;

384738483849385038513852385338543855385638573858385938603861386238633864386538663867386838693870387138723873387438753876387738783879388038813882388338843885388638873888388938903891389238933894389538963897





e) invoke a CM-provider-abort service indication with the abstract value “expected-PDU-missing”; and


2.5.4.8.2 If the User Data parameter of a D-START confirmation (with the Result parameter set to the abstract value “rejected (transient)” or “rejected (permanent)”) is not provided where it is expected, the CM-ASE shall:

a) stop all timers;

b) invoke a CM-provider-abort service indication with the abstract value “expected-PDU-missing”; and


2.5.4.9 D-START Security Requirements parameter not as expected

Note.— This section applies to CM version 2 only. This is for the case when the D-START Security Requirements parameter does not meet the local security policy.

2.5.4.9.1 Upon receipt of a D-START indication with the Security Requirements parameter not consistent with the local security policy, or upon receipt of a D-START confirmation with the Security Requirements parameter not equal to the value that was set in the D-START request, the CM-ASE shall:

a) stop all timers;

b) if the dialogue with the peer is still open:

1) if the CM-ASE is a CM-air-ASE, create a CMAircraftMessage APDU with a cmAbortReason [communication-service-failure] APDU message element;

2) if the CM-ASE is a CM-ground-ASE, create a CMGroundMessage APDU with a cmAbortReason [communication-service-failure] APDU message element; and




c) if the CM-user is active, invoke a CM-provider-abort service indication with the abstract value “communication-service-failure”; and


3898389939003901390239033904390539063907390839093910391139123913391439153916391739183919392039213922392339243925392639273928392939303931393239333934393539363937393839393940394139423943394439453946394739483949


2.5.5 CM-ASE state tables

2.5.5.1 Priority

2.5.5.1.1 If the state tables for the CM-ground-ASE and the CM-air-ASE at Tables 2-14 117 and 2-15128, respectively, conflict with textual statements made elsewhere in this manual, the textual statements shall take precedence.

2.5.5.1.2 In the state tables at Tables 2-14 117 and 2-15128, the statement “cannot occur” means that if the implementation conforms to the SARPs, it is impossible for this event to occur. If the event does occur, this implies that there is an error in the implementation. If such a situation is detected, it is suggested that the ASE abort with the error “unrecoverable system error”.

2.5.5.1.3 In the state tables at Tables 2-14 117 and 2-15128, the statement “not permitted” means that the implementation must prevent this event from occurring through some local means. If the event does occur, this implies that there is an error in the implementation. If such a situation is detected, it is suggested that the ASE perform a local rejection of the request rather than aborting the dialogue.

39503951395239533954395539563957395839593960396139623963396439653966396739683969

Manual on D

etailed Technical S

pecifications for the Aeronautical

2-88(A

TN) using

ISO

/OS

I Standards

and Protocols

Table 2-14117. CM-ground-ASE state table

STATE →

EVENT ↓ IDLE LOGON UPDATE CONTACT DIALOGUECONTACT DIALOGUE END FORWARD

SERVER QUERY

(version 2)

SERVER QUERY

DIALOGUE(version 2)

DIALOGUE Service Events

D-START IndicationVersion Number is greater than the CM-ground-ASE version number, ground-ground forwarding supported

●D-START response→IDLE

cannot occur cannot occur cannot occur cannot occur cannot occur cannot occur cannot occur cannot occur cannot occur

D-START IndicationVersion Number is less than or equal to the CM-ground-ASE version number, User Data = CMLogonRequest, ground-ground forwarding supported

●CM-logon indication→LOGON


D-START Indication, User Data = CMServerFacilityQueryRequest(version 2)

●CM-server-facility-query indication→SERVER QUERY


D-START Indication Version Number is less than or equal to the CM-ground-ASE version number,User Data = CMForwardRequest or CMEnhancedForwardRequest, ground-ground forwarding supported(version 2)

●CM-forward indication●D-START response→IDLE


D-START Indication, ground-ground forwarding is not supported, User Data = CMForwardRequest or CMEnhancedForward Request(version 2)



39703971

Part I. A

ir-Ground A

pplicationsC

hapter 2. Context M

anagement

Application

STATE →


SERVER QUERY

(version 2)

SERVER QUERY

DIALOGUE(version 2)

D-START ConfirmationResult “rejected (permanent)” and Reject Source “DS-user”, D-START User Data parameter not provided

cannot occur cannot occur ●Stop timer tupdate

→IDLE

cannot occur cannot occur cannot occur cannot occur cannot occur cannot occur cannot occur

D-START ConfirmationResult “rejected (permanent)” and Reject Source “DS-user”, D-START User Data = CMContactResponse

cannot occur cannot occur cannot occur ●Stop timer tcontact

●CM-contact confirmation→IDLE

cannot occur cannot occur cannot occur cannot occur cannot occur cannot occur

D-START ConfirmationResult “rejected (permanent)” and Reject Source “DS-user”, D-START User Data = CMForwardResponse or CMEnhancedForward Request (version 2)

cannot occur cannot occur cannot occur cannot occur cannot occur cannot occur cannot occur ●Stop timer tforward

●CM-forward confirmation→IDLE

cannot occur cannot occur

D-DATA Indication, D-DATA User Data = CMContactResponse

cannot occur cannot occur cannot occur cannot occur cannot occur ●CM contact confirmation●Stop timer tcontact

→DIALOGUE

cannot occur cannot occur cannot occur cannot occur

D-DATA Indication, D-DATA User Data = CMServerFacilityQueryRequest (version 2)

cannot occur cannot occur cannot occur cannot occur cannot occur ●Discard D-DATA indication→CONTACT DIALOGUE

●Discard D-DATA indication→END

cannot occur cannot occur ●CM server facility query indication→DIALOGUE

D-END ConfirmationResult “accepted”

cannot occur cannot occur cannot occur cannot occur cannot occur cannot occur ●stop timer tend

→IDLEcannot occur cannot occur cannot occur

CM-User Events

CM-update Request or CM-server-facility-update Request (version 2)

●D-START request●Start timer tupdate

→UPDATE

not permitted not permitted not permitted ●D-DATA request→DIALOGUE

not permitted not permitted not permitted not permitted not permitted

CM-contact Request ●D-START request●Start timer tcontact

→CONTACT

not permitted not permitted not permitted ●D-DATA request●Stop timer tcontact

→CONTACT DIALOGUE


Manual on D

etailed Technical S

pecifications for the Aeronautical

2-90(A

TN) using

ISO

/OS

I Standards

and Protocols

STATE →


SERVER QUERY

(version 2)

SERVER QUERY

DIALOGUE(version 2)

CM-forward Request ●D-START request●Start timer tforward

→FORWARD

not permitted not permitted not permitted not permitted not permitted not permitted not permitted not permitted not permitted

CM-logon Response Maintain Dialogue not supplied by CM-ground-user

not permitted ●D-START response→IDLE

not permitted not permitted not permitted not permitted not permitted not permitted not permitted not permitted

CM-logon Response Maintain Dialogue “accepted”

not permitted ●D-START response→DIALOGUE

not permitted not permitted not permitted not permitted not permitted not permitted not permitted not permitted

CM-server-facility-query Response Maintain Dialogue not supplied by CM-ground-user(version 2)

not permitted not permitted not permitted not permitted not permitted not permitted not permitted not permitted ●D-START response→IDLE

not permitted

CM-server-facility-query Response Maintain Dialogue “accepted” (version 2)

not permitted not permitted not permitted not permitted not permitted not permitted not permitted not permitted ●D-START response→DIALOGUE

not permitted

CM-end Request not permitted not permitted not permitted not permitted ●D-END request●Start timer tend

→END


ABORT Events

CM-user-abort Request not permitted ●D-ABORT request→IDLE

●stop timer tupdate

●D-ABORT request→IDLE

●stop timer tcontact



●D-ABORT request●Stop timer tcontact

→IDLE

not permitted ●stop timer tforward


●stop timer tsrv_query




D-ABORT IndicationOriginator is “provider”

cannot occur ●CM-provider-abort indication→IDLE


●CM-provider-abort indication→IDLE




●CM-provider-abort indication●Stop timer tcontact

→IDLE

●stop timer tend

→IDLE●stop timer tforward






D-ABORT Indication Originator is “user”

cannot occur ●CM-user-abort indication→IDLE


●CM-user-abort indication→IDLE




●CM-user-abort indication●Stop timer tcontact

→IDLE

●stop timer tend⇒IDLEcannot occur ●stop timer

tsrv_query




Part I. A

ir-Ground A

pplicationsC

hapter 2. Context M

anagement

Application

STATE →


SERVER QUERY

(version 2)

SERVER QUERY

DIALOGUE(version 2)

D-P-ABORT Indication cannot occur ●CM-provider-abort indication→IDLE






●CM-provider-abort indication●Stop timer tcontact

→IDLE

●stop timer tend

→IDLE●stop timer tforward






Tupdate Expires cannot occur cannot occur ●D-ABORT request●CM-provider-abort indication→IDLE

cannot occur cannot occur cannot occur cannot occur cannot occur cannot occur cannot occur

Tcontact Expires cannot occur cannot occur cannot occur ●D-ABORT request●CM-provider-abort indication→IDLE

cannot occur ●D-ABORT request●CM-provider-abort indication→IDLE


Tend Expires cannot occur cannot occur cannot occur cannot occur cannot occur cannot occur ●D-ABORT request→IDLE

cannot occur cannot occur cannot occur

Tforward Expires cannot occur cannot occur cannot occur cannot occur cannot occur cannot occur cannot occur ●D-ABORT request●CM-provider-abortindication→IDLE


39723973


Table 2-15128. CM-air-ASE state table

STATE →EVENT ↓ IDLE LOGON CONTACT DIALOGUE

CONTACT DIALOGUE

SERVER QUERY

(version 2)

SERVER QUERY

DIALOGUE (version 2)

DIALOGUE Service Events

D-START IndicationUser Data CMUpdate or CMSecureUpdate (version 2)

●CM-update indication●D-START response→IDLE

cannotoccur

cannotoccur

cannotoccur

cannotoccur

cannotoccur

cannotoccur

D-START IndicationUser Data CMServerFacilityUpdate (version 2)

●CM-server-facility-update indication●D-START response→IDLE

cannotoccur

cannotoccur

cannotoccur

cannotoccur

cannotoccur

cannotoccur

D-START IndicationUser Data CMContactRequest

●CM-contact indication→CONTACT

cannotoccur

cannotoccur

cannotoccur

cannotoccur

cannotoccur

cannotoccur

D-START ConfirmationResult “rejected (permanent)” and Reject Source “DS-user”

cannotoccur

●Stop timer tlogon

●CM-logon confirmation→IDLE

cannotoccur

cannotoccur

cannotoccur

cannotoccur

cannotoccur

D-START ConfirmationResult “accepted”User Data CMLogonResponse or CMSecureLogonResponse (version 2)

cannotoccur

●Stop timer tlogon

●CM-logon confirmation→DIALOGUE

cannotoccur

cannotoccur

cannotoccur

cannotoccur

cannotoccur

D-START ConfirmationResult “rejected (permanent)” and Reject Source “DS-user” User Data CMServerFacilityQueryResponse (version 2)

cannotoccur

cannotoccur

cannotoccur

cannotoccur

cannotoccur

●Stop timer tsrv_query

●CM-logon confirmation→IDLE

cannotoccur

D-START ConfirmationResult “accepted”User Data CMServerFacilityQueryResponse (version 2)

cannotoccur

cannotoccur

cannotoccur

cannotoccur

cannotoccur

●Stop timer tsrv_query

●CM-logon confirmation→DIALOGUE

cannotoccur

D-DATA IndicationUser Data CMUpdate

cannotoccur

cannotoccur

cannotoccur

●CM-update indication→DIALOGUE

cannotoccur

cannotoccur

●Discard D-DATA indication→SERVER QUERY DIALOGUE

D-DATA IndicationUser Data CMContactRequest

cannotoccur

cannotoccur

cannotoccur

●CM-contact indication→CONTACT DIALOGUE

cannotoccur

cannotoccur


●CM-server-facility-query confirmation●CM-contact indication→CONTACT DIALOGUE

39743975



CONTACT DIALOGUE

SERVER QUERY

(version 2)

SERVER QUERY


D-DATA IndicationUser Data CMServerFacilityQueryResponse (version 2)

cannotoccur

cannotoccur

cannotoccur

cannotoccur

cannotoccur

cannotoccur


●CM-server-facility-query confirmation→ DIALOGUE

D-DATA IndicationUser Data CMServerFacilityUpdate (version 2)

cannotoccur

cannotoccur

cannotoccur

cannotoccur

cannotoccur

cannotoccur

●Discard D-DATA indication→SERVER QUERY DIALOGUE

D-END Indication cannotoccur

cannotoccur

cannotoccur

●CM-end indication●D-END response→IDLE

cannotoccur

cannotoccur


●CM-server-facility-query confirmation●CM-end indication●D-END response→IDLE

CM-User Events

CM-contact Response notpermitted

notpermitted


not permitted ●D-DATA request→DIALOGUE

notpermitted

notpermitted

CM-logon Request ●D-START request●Start timer tlogon

→LOGON

notpermitted

notpermitted

notpermitted

notpermitted

notpermitted

notpermitted

CM-server-facility-query Request (version 2)

●D-START request●Start timer tsrv_query

→SERVER QUERY

notpermitted

notpermitted

●D-DATA request●Start timer tsrv_query

→SERVER QUERY DIALOGUE

notpermitted

notpermitted

notpermitted

ABORT Events

CM-user-abort Request notpermitted

●stop timer tlogon









D- ABORT Indication Originator is “provider”

cannotoccur












CONTACT DIALOGUE

SERVER QUERY

(version 2)

SERVER QUERY


D-ABORT Indication Originator is “user”

cannotoccur










D-P-ABORT Indication cannotoccur





●CM-provider-abort indication⇒IDLE





Tlogon Expires cannotoccur

●D-ABORT request●CM-provider-abort indication→IDLE

cannotoccur

cannotoccur

cannotoccur

cannotoccur

cannotoccur

Tsrv_query Expires cannotoccur

cannotoccur

cannotoccur

cannotoccur

cannotoccur



2.6 COMMUNICATION REQUIREMENTS

2.6.1 Encoding rules

2.6.1.1 The CM application shall apply the Packed Encoding Rules (PER) encoding as defined in ISO/IEC 8825-2, using the basic unaligned variant to encode/decode the ASN.1 message structure and content specified in 2.4.

2.6.1.2 When encoded CM APDUs are treated as bit-oriented values that are not padded to an integral number of octets, the length determinant includes only the significant bits of the encoding corresponding to the ASN.1 type.

2.6.2 Dialogue service requirements

2.6.2.1 Primitive requirements

Where dialogue service primitives, i.e. D-START, D-DATA, D-END, D-ABORT and D-P-ABORT, are described as being invoked in 2.5, the CM-ground-ASE and the CM-air-ASE shall exhibit external behaviour consistent with the dialogue service, as described in Part III of this manual, having been implemented and its primitives invoked.

2.6.2.2 ATN Quality of Service requirements

2.6.2.2.1 The Priority Quality of Service parameter of the D-START for CM shall be the abstract value of “flight regularity communications”.

3976397739783979398039813982398339843985398639873988398939903991399239933994399539963997399839994000400140024003


2.6.2.2.2 The RER Quality of Service parameter of the D-START for CM shall be set to the abstract value of “low”.

2.6.2.2.3 The CM-ASE shall map the Class of Communication Service parameter abstract values to the ATSC routing class abstract value part of the D-START Quality of Service parameter as presented in Table 2-16139.

Table 2-16139. Mapping between class of communication and routing class abstract values

Class of communication abstract value Routing class abstract value

A Traffic follows Class A ATSC route(s)

B Traffic follows Class B ATSC route(s)

C Traffic follows Class C ATSC route(s)

D Traffic follows Class D ATSC route(s)

E Traffic follows Class E ATSC route(s)

F Traffic follows Class F ATSC route(s)

G Traffic follows Class G ATSC route(s)

H Traffic follows Class H ATSC route(s)

Note.— ATSC class values are defined in Part IV of this manual.

2.6.2.3 ATN Security Requirements parameter

2.6.2.3.1 CM version 1 does not use this parameter.Note. – The specific security mechanisms that may provide the security functionality are out of scope for this document. The Security Requirements parameter is provided so that additional security provisions may be invoked if local constraints require security.

2.6.2.3.12 For CM version 2, tThe Security Requirements parameter of the D-START shall be set to either “secured dialogue supporting key managementsecured dialogue supporting security information management” or “no security” for the CM-logon service.

2.6.2.3.3 For CM version 2, the Security Requirements parameter of the D-START shall be set to either “secured dialogue supporting key management”, “secured dialogue” or “no security” for the CM-update service, CM-server-facility-update service and CM-server-facility-query service.

Note.— The value “secured dialogue supporting key managementsecured dialogue supporting security information management” is intended to be used if there has not been a previous CM-logon performed with the peer CM application. This is in order to establish the session key (see Part IV of this manual for more details). The value “secured dialogue” is used if there has been a previous CM-logon performed with the peer CM application. However, the specific security provisions to provide this functionality are outside the scope of this document.

2.6.2.3.42 For CM version 2, tThe Security Requirements parameter of the D-START shall be set to either “secured dialogue” or “no security” for the CM-contact service.

2.6.2.3.35 For CM version 2, tThe Security Requirements parameter of the D-START shall be set to either “secured dialogue” or “no security” for the CM-forward service.

40044005400640074008400940104011

4012401340144015401640174018401940204021402240234024402540264027402840294030403140324033403440354036403740384039404040414042


2.7 CM-USER REQUIREMENTS

Note.— Requirements imposed on CM-users concerning CM messages and interfacing with the CM-ASEs are presented in 2.7.

2.7.1 CM-air-user requirements

2.7.1.1 General CM-air-user requirements

2.7.1.1.1 A version 2 CM-air-user shall be prohibited from invoking any CM version 2-specific service or using any CM version 2 parameters (other than the Security Required parameter) with a version 1 CM ground system.

2.7.1.1.21 When a CM-air-user invokes the CM-logon or, if CM version 2, the CM-server-facility-query service and requires a particular class of communication service, it sets the Class of Communication Service parameter to be the class of communication it requires.

2.7.1.1.32 When the CM-air-user invokes a CM-logon or, if CM version 2, the CM-server-facility-query service and has no preference for the class of communication service to be used, the Class of Communication Service parameter does not need to be provided.

2.7.1.1.43 When the CM-air-user invokes the CM-logon or, if CM version 2, the CM-server-facility-query service for version 2, it sets the Security Required parameter as appropriate to the local security policy.


2.7.1.1.54 For each CM-air-ASE invocation, the CM-air-user establishes a correlation between a CM-air-ASE invocation and the facility designation.

2.7.1.1.65 Upon the initiation of a CM-logon or, if CM version 2, the CM-server-facility-query service request, or upon receipt of a CM-update or, if CM version 2, the CM-server-facility-update service indication or a CM-contact service indication, the ASE invocation correlation is based on the facility designation in the Facility Designation parameter of the respective CM service.

2.7.1.1.76 The correlation is maintained for the duration of the ASE invocation.

2.7.1.1.8 When communicating with a version 1 CM ground system, the CM-air-user shall be prohibited from:

a) sending a CM-server-facility-query request; and

b) using the Security Required parameter with any value other than “no security”.

2.7.1.2 CM-logon service requirements

2.7.1.2.1 Only the CM-air-user is permitted to initiate the CM-logon service.

2.7.1.2.2 For version 2 CM, eEither secure or unsecure CM-logon services may be performed.

4043404440454046404740484049405040514052405340544055405640574058405940604061406240634064406540664067406840694070407140724073407440754076407740784079408040814082408340844085408640874088408940904091409240934094



2.7.1.2.3 When invoking the CM-logon service request, the CM-air-user shall provide the following as part of the CMLogonRequest:

a) its CM long TSAP;

b) the aircraft’s flight identification;

c) information on each application for which it requires a data link service as follows:

1) for air-only-initiated services: application name and version number for all the versions that can be supported; and

2) for applications that can be ground-initiated: application name, version number and address for all the versions that can be supported;

d) the facility designation of the facility with which the CM-air-user wishes to exchange application information (if required); and

e) flight information data as required by the ground system.

Note.— The facility designation is only used if the CM-air-user wants to explicitly identify a facility other than the one contained in the Facility Designation parameter of the CM-logon service for which it requires application information.

2.7.1.2.4 The CM-air-user should only use the facilityDesignation field of the CMLogonRequest if requesting information for a facility other than the one specified in the Facility Designation parameter of the CM-logon service.

2.7.1.2.5 When invoking the CM-logon service request, if any router domain part (RDP) for a given application address is different than the CM RDP, the CM-air-user shall use the long TSAP for each application address provided.

Note.— The long TSAP = RDP + short TSAP. The short TSAP = ARS + LOC + SYS + NSEL + TSEL. The RDP = VER + ADM + RDF.

2.7.1.2.6 When invoking the CM-logon service request, the ARS component of the short TSAP shall contain the ICAO 24-bit aircraft address.

Note.— If there is more than one routing domain on the aircraft, the LOC field is used to differentiate one from the other(s).

2.7.1.2.7 For CM version 2, when invoking a CM-logon request, if the CM-air-user needs to use a previous CM-air-ASE version, the CM-air-user shall set the Emulated Version parameter value to the required version number.

Note.— This may be done for a variety of reasons, including a priori knowledge of a lower-versioned CM ground system.

2.7.1.2.8 For CM version 2, when the CM-air-user provides the Emulated Version parameter, the Emulated Version parameter value shall be less than the actual CM-air-ASE version number.

Note.— This is to ensure that services not supported by a peer CM ground system will not be invoked.

4095409640974098409941004101410241034104410541064107410841094110411141124113411441154116411741184119412041214122412341244125412641274128412941304131413241334134413541364137413841394140414141424143414441454146


2.7.1.2.9 For CM version 2, if the CM-air-ASE is operating in a lower-versioned emulation mode, the CM-air-user shall only invoke or accept CM services supported by that CM-ASE Version Number.

Note.— This means that the CM-air-user must not invoke any services or use any parameters not known to the lower-versioned peer CM ground system.

2.7.1.2.710 Upon receipt of a CM-logon service confirmation, the CM-air-user shall create the actual TSAP for each type of ground application information contained in the Logon Response based on the IDP and long TSAP for each application as defined in 2.4.

Note 1.— The actual TSAP = IDP + long TSAP. The IDP = AFI + IDI.

4147414841494150415141524153415441554156415741584159


Note 2.— If the Version Number parameter is not provided and the Logon Response parameter is provided but is empty, this means that the CM-ground-user has rejected the logon. This may be for operational reasons (e.g. optional information that is required for a particular airspace was missing in the CM-logon request) or for technical reasons (e.g. there is a problem with the ground system that prevents it from providing the information). This case will NOT be due to a version number incompatibility, since in that case only the Version Number is provided. If a CM-logon service is rejected, the CM-air-user may evaluate possible reasons for the rejection and retry the CM-logon service.

2.7.1.2.11 Upon receipt of a CM-logon service confirmation, the CM-air-user shall make the information contained in the CMLogonResponse or, if CM version 2, the CMSecureLogonResponse available to the other applications (i.e. ADS-C and, CPDLC and FIS), as well as to the DS-provider.

Note.— In the case of the CMSecureLogonResponse, the information to be made available to other applications includes key information, if provided. Only a version 2 CM will receive a CMSecureLogonResponse.

2.7.1.2.12 Upon receipt of a Logon Response from a CM-logon service confirmation from a ground facility for which CM information has previously been received, the CM-air-user shall only replace the previous information for which new logon information has been received.

Note 1.— If the facility designation field of the Logon Request was provided, then the information contained in the Logon Response parameter corresponds to that facility designation. If the facility designation field of the Logon Request was not provided, then the information contained in the Logon Response parameter corresponds to the Facility Designation parameter of the CM-logon service.

Note 2.— If the facility designation field of the Logon Request was provided and no application information is returned in the Logon Response parameter, this means that the CM-ground-user does not have access to the information for the requested facility, or that the requested facility does not support any of the proposed applications.

2.7.1.2.13 For CM version 2, upon receipt of a CM-logon service confirmation with the CM-ASE Version Number provided, the CM-air-user should invoke a CM-logon service request using the Emulated Version parameter as defined in 2.7.1.2.7.

Note.— If the CM-ASE Version Number is provided in the CM-logon service confirmation, it means that the CM-air-ASE version number is greater than the CM-ground-ASE version number. In order for the CM-air-ASE to perform a successful CM-logon service with that lower-versioned CM ground system, the Emulated Version parameter must be used. This option is only available to CM version 2.

2.7.1.3 CM-update service requirements

2.7.1.3.1 If a CM-update service indication is received, then the information contained in the Update Information parameter corresponds to the facility designation contained in the Facility Designation parameter or, if a dialogue exists, the facility with which the dialogue is in place.

2.7.1.3.2 Upon receipt of Update Information from a CM-update service indication from a ground facility designation for which CM information has previously been received, the CM-air-user shall only replace the previous information for which updated information has been received.

2.7.1.3.3 Upon receipt of a CM-update service indication, the CM-air-user shall create the actual TSAP for each type of ground application information contained in the Update Information based on the IDP and long TSAP for each application as defined in 2.4.

Note.— The actual TSAP = IDP + long TSAP. The IDP = AFI + IDI.

4160416141624163416441654166416741684169417041714172417341744175417641774178417941804181418241834184418541864187418841894190419141924193419441954196419741984199420042014202420342044205420642074208420942104211


2.7.1.3.4 The CM-air-user shall make the updated information contained in the Update Information available to the other applications (i.e. ADS-C and, CPDLC and FIS), as well as to the DS-provider.

Note.— In the case of the CMSecureUpdate for CM version 2, the information to be made available to other applications includes key information, if provided.

2.7.1.4 CM-contact service requirements

2.7.1.4.1 Upon receipt of a CM-contact indication, the CM-air-user should invoke the CM-logon request with the indicated ground system within 0.5 seconds.

2.7.1.4.2 Upon receipt of a CM-logon confirmation when performing the CM-contact service, the CM-air-user shall invoke a CM-contact response.

2.7.1.4.3 Upon receipt of a CM-logon confirmation when performing the CM-contact service, the CM-air-user should invoke a CM-contact response within 0.5 seconds.

2.7.1.4.4 Upon receipt of a CM-contact service indication, the CM-air-user shall attempt to initiate a CM-logon service request with the indicated ground system.

Note.— If a CM-logon service request is initiated, the CM-air-user will comply with the CM-logon requirements as stated in 2.7.1.1. However, the facility designation will not be provided as part of the CMLogonRequest in this case.

2.7.1.4.5 In addition to the above CM-logon service requirements, upon receipt of a CM-logon service response from the indicated facility designation, or if no CM-logon service request can be initiated, the CM-air-user shall invoke the CM-contact service response indicating the success or lack thereof of the CM-logon service request.

2.7.1.5 CM-server-facility-query service requirements

2.7.1.5.1 Only the CM-air-user is permitted to initiate the CM-server-facility-query service.

2.7.1.5.2 Either secure or unsecure CM-server-facility-query services may be performed. The CM-server-facility-query service is only available to version 2 CM-users.

2.7.1.5.3 When invoking the CM-server-facility-query request, the CM-air-user shall provide the following as part of the CMServerFacilityQueryRequest:

a) its CM long TSAP;

b) the aircraft’s flight identification;

c) information on each application for which it requires a data link service as follows:

1) for air-only-initiated services: application name and version number for all the versions that can be supported; and

2) for applications that can be ground-initiated: application name, version number and address for all the versions that can be supported;

4212421342144215421642174218421942204221422242234224422542264227422842294230423142324233423442354236423742384239424042414242424342444245424642474248424942504251425242534254425542564257425842594260426142624263


d) the facility designations of up to eight facilities from which the aircraft desires application information; and

e) flight information data as required by the ground system.

2.7.1.5.4 When invoking the CM-server-facility-query service request, if any RDP for a given application address is different than the CM RDP, the CM-air-user shall use the long TSAP for each application address provided.

Note.— The long TSAP = RDP + short TSAP. The short TSAP = ARS + LOC + SYS + NSEL + TSEL. The RDP = VER + ADM + RDF.

2.7.1.5.5 When invoking the CM-server-facility-query service request, the ARS component of the short TSAP shall contain the ICAO 24-bit aircraft address.

Note.— If there is more than one routing domain on the aircraft, the LOC field is used to differentiate one from the other(s).

2.7.1.5.6 Upon receipt of a CM-server-facility-query service confirmation, the CM-air-user shall create the actual TSAP for each type of ground application information contained in the Server Facility Query Response based on the IDP and long TSAP for each application as defined in 2.4.

Note 1.— The actual TSAP = IDP + long TSAP. The IDP = AFI + IDI.

Note 2.— The CM-air-user establishes a correlation between the addresses received in the CM-server-facility-query service confirmation and the facilities to which they belong. The CM-air-user may then perform data link services with the applications at those facilities.

2.7.1.5.7 Upon receipt of a CM-server-facility-query service confirmation, the CM-air-user shall make the information for each facility contained in the Server Facility Query Response available to the other applications (i.e. ADS-C and, CPDLC and FIS), as well as to the DS-provider.

Note.— The information to be made available to other applications includes key information, if provided.

2.7.1.5.8 Upon receipt of a Server Facility Query Response that contains information for a ground facility for which CM information has previously been received, the CM-air-user shall only replace the previous information for which new logon information has been received.

2.7.1.6 CM-server-facility-update service requirements

2.7.1.6.1 The CM-server-facility-update service is only available to CM version 2.

2.7.1.6.2 Upon receipt of a Server Facility Update Information that contains information for a ground facility for which CM information has previously been received, the CM-air-user shall only replace the previous information for which updated information has been received.

2.7.1.6.3 Upon receipt of a CM-server-facility-update service indication, the CM-air-user shall create the actual TSAP for each type of ground application information contained in the Server Facility Update Information based on the IDP and long TSAP for each application as defined in 2.4.


4264426542664267426842694270427142724273427442754276427742784279428042814282428342844285428642874288428942904291429242934294429542964297429842994300430143024303430443054306430743084309431043114312431343144315


2.7.1.6.4 The CM-air-user shall make the updated information contained in the Server Facility Update Information available to the other applications (i.e. ADS, CPDLC and FIS), as well as to the DS-provider.

Note.— The information to be made available to other applications includes key information, if provided.

2.7.1.57 CM-user-abort service requirements

2.7.1.57.1 When it is required that a CM-air-user abort the current service or maintained dialogue, the CM-air-user initiates a CM-user-abort request.

2.7.1.57.2 A CM-air-user may need to abort the current service or maintained dialogue for several reasons, including the detection of an unrecoverable error situation and the local policies. The user abort request and indication primitives do not indicate the reason of the abort.

2.7.2 CM-ground-user requirements

2.7.2.1 General CM-ground-user requirements

2.7.2.1.1 A CM-ground-user shall invoke the CM-logon service, CM-update service, CM-contact service, and CM-end service and, if CM version 2, the CM-server-facility-query service and CM-server-facility-update service only when communicating with a CM-air-user.

2.7.2.1.2 A CM-ground-user shall invoke the CM-forward service only when communicating with another CM-ground-user.

2.7.2.1.3 A version 2 CM-ground-user shall be prohibited from invoking any CM version 2-specific service or using any CM version 2 parameters (other than the Security Required parameter) with a version 1 CM ground or air system.

2.7.2.1.4 When communicating with a version 1 CM aircraft, the CM-ground-user shall be prohibited from:

a) sending a CM-server-facility-query response;

b) sending a CM-server-facility-update request;

c) sending a CM-logon response with a CMSecureLogonResponse parameter;

d) sending a CM-update request with a CMSecureUpdate parameter; and

e) using the Security Required parameter with any value other than “no security”.

Note.— In some cases the Security Required parameter may not be provided.

2.7.2.1.5 When communicating with a version 1 CM ground system, the CM-ground-user shall be prohibited from:

a) sending a CM-forward request with a CMEnhancedForwardRequest parameter; and

b) using the Security Required parameter with any value other than “no security”.

4316431743184319432043214322432343244325432643274328432943304331433243334334433543364337433843394340434143424343434443454346434743484349435043514352435343544355435643574358435943604361436243634364436543664367


2.7.2.1.36 For version 2 services requiring key informationsecuirty (CM-logon, CM-server-facility-query, CM-update and CM-server-facility-update), the CM-ground-user shall obtain the authentic copy of the key agreement public key and domain usage informationperform the necessary security functions for each application that requires security.

Note 1. – The specific security mechanisms that may provide the security functionality are out of scope for this document.

Note 2. – The Directory Service, if available, may also be utilized for security provisions. The Directory Service implementation and policy is local implementation.

Note.— The certification of the keys themselves is handled by the secure DS-provider, as described in Part III of this manual. However, the CM-user is responsible for validating the key agreement public key certificates. The certification of the keys themselves may be handled through direct invocation of system security object (SSO) services.

2.7.2.1.7 For CM version 2, the CM-ground-user should use the ATN directory service as defined in Part IV of this manual to obtain key agreement public key and domain usage information.

Note 1.— Directory implementation and policy is local implementation.

Note 2.— The CM-ground-user may choose to update aircraft information held in a central directory. This may be done by use of the ATN directory service as defined in Part IV of this manual.

Note 3.— When a CM-ground-user invokes the CM-update service, CM-contact service, or CM-forward service or, if CM version 2, the CM-server-facility-update service and requires a particular class of communication service, it will set the Class of Communication Service parameter to be the class of communication it requires.

Note 4.— When the CM-ground-user invokes a CM-update service, CM-contact service, or CM-forward service or, if CM version 2, the CM-server-facility-update service and has no preference for the class of communication service to be used, the Class of Communication Service parameter does not need to be provided.

Note 5.— When a CM-ground-user specifies the Class of Communication Service parameter and the dialogue is in place, the Class of Communication parameter is ignored.

Note 6.— When the CM-ground-user invokes the CM-update service, CM-server-facility-update service, CM-contact service or CM-forward request service for CM version 2, it sets the Security Required parameter as appropriate to the local security policy.

Note 7.— For each CM-ground-ASE invocation, the CM-ground-user establishes a correlation between a CM-ground-ASE invocation and the ICAO 24-bit aircraft address.

Note 8.— Upon the initiation of a CM-update or, if CM version 2, CM-server-facility-update service request or CM-contact service request, or upon receipt of a CM-logon or, if CM version 2, CM-server-facility-query service indication, the ASE invocation correlation is based on the ICAO 24-bit aircraft address in the Aircraft Address parameter of the respective CM service.

Note 9.— The correlation is maintained for the duration of the ASE invocation.

436843694370437143724373437443754376437743784379438043814382438343844385438643874388438943904391439243934394439543964397439843994400440144024403440444054406440744084409441044114412441344144415441644174418


2.7.2.2 CM-logon service requirements

2.7.2.2.1 Upon receipt of a CM-logon indication, the CM-ground-user should invoke the CM-logon response within 0.5 seconds.

2.7.2.2.2 Upon receipt of a CM-logon service indication, the CM-ground-user shall make the aircraft application information contained in the Logon Request available to the other applications (i.e. ADS-C and, CPDLC and FIS), as well as to the DS-provider.

4419442044214422442344244425442644274428


2.7.2.2.3Upon receipt of a CM-logon service indication, the CM-ground-user shall create the actual TSAP for each type of aircraft application information contained in the Logon Request based on the IDP and long TSAP for each application, as defined in 2.4.


2.7.2.2.4 Upon receipt of a Logon Request from a CM-logon service indication from an aircraft for which CM information has previously been received and is still being maintained, the CM-ground-user shall update the aircraft information accordingly.

2.7.2.2.5 Upon receipt of a CM-logon service indication from a CM version 1 peer, the CM-ground-user shall invoke a CM-logon service response with a CMLogonResponse containing:

a) application names, addresses and version numbers for the requested applications that can be air-initiated for all versions that the ground and aircraft systems can support; and

b) application names and version numbers for the requested ground-only-initiated applications that the ground system can support.

Note.— This is the case for a version 1 CM aircraft performing the CM-logon service. The CM-ground-user can determine the version of the peer by an indication of the Version Number parameter in the CM-logon indication if the CM-air-ASE version is lower than the CM-ground-ASE version (as is the case for a CM version 2 CM-ground-ASE communicating with a version 1 CM-air-ASE), or by the absence of the Version Number parameter in the CM-logon indication if the CM-air-ASE version is the same as the CM-ground-ASE version (as is the case for a version 1 CM-ground-ASE communicating with a version 1 CM-air-ASE or a version 2 CM-air-ASE in emulation mode).

2.7.2.2.6 For CM version 2, uUpon receipt of a CM-logon service indication with the Security Required parameter provided with the value “secured dialogue supporting key managementsecured dialogue supporting security information management”, the CM-ground-user shall invoke the necessary security mechanisms to provide the secured dialogue service.a CM-logon service response with a CMSecureLogonResponse containing:

Note. – The specific security mechanisms that may provide the security functionality are out of scope for this document. a) the facility designation of the facility to which the information applies;

Note.— The facility designation is only provided if the information is for a facility other than the responding facility.

b) application names, addresses, version numbers, and optionally, authentic key agreement public keys and domain usage indications for the requested applications that can be air-initiated for all versions that the ground and aircraft systems can support; and

c) application names, version numbers, and optionally, authentic key agreement public keys and domain usage indications for the requested ground-only-initiated applications that the ground system can support.

2.7.2.2.7 For CM version 2, upon receipt of a CM-logon service indication with the Security Required parameter provided with the value “no security” and when communicating with a version 1 CM peer, the CM-ground-user shall invoke a CM-logon service response with a CMSecureLogonResponse containing:

a) the facility designation of the facility to which the information applies;


4429443044314432443344344435443644374438443944404441444244434444444544464447444844494450445144524453445444554456445744584459446044614462446344644465446644674468446944704471447244734474447544764477447844794480


b) application names, addresses and version numbers for the requested applications that can be air-initiated for all versions that the ground and aircraft systems can support; and

c) application names and version numbers for the requested ground-only-initiated applications that the ground system can support.

Note.— A CM-air-user will not provide security information if an unsecure dialogue is being maintained.

2.7.2.2.87 When communicating with a CM version 1 peer, iIf the facility designation is present in the Logon Request parameter, then the application information contained in the Logon Response shall correspond to that facility designation.

Note 1.— The information for the requested facility may be obtained through the use of the ATN directory service (see Part IV of this manual).

Note 2.— If a CM-ground-user does not have access to the information for the requested facility, no application information is returned.

2.7.2.2.98 When communicating with a CM version 1 peer, iIf the facility designation is not present in the Logon Request parameter, then the application information contained in the Logon Response shall correspond to the responding CM-ground-user’s facility designation.

2.7.2.2.910 When invoking the CM-logon service response, if any RDP for a given application address is different than the CM RDP, the CM-ground-user shall use the long TSAP for each application address provided.

Note 1.— The long TSAP = RDP + short TSAP. The short TSAP = ARS (optional) + LOC + SYS + NSEL + TSEL. The RDP = VER + ADM + RDF.

Note 2.— If there is more than one routing domain on the ground, the ARS field is used to differentiate one from the other(s). If there is not more than one routing domain on the ground, the ARS field need not be used.

Note 3.— The value of the ARS field is a 24-bit unsigned binary number that uniquely identifies the addressed system in a single routing domain and is assigned by the state or organization identified in the ADM field.

2.7.2.2.101 When the CM-ground-user requires a CM dialogue to be maintained, the CM-ground-user shall set the CM-logon service response Maintain Dialogue parameter if, and only if, the dialogue maintain service is supported.

2.7.2.2.1211 If a CM-ground-user wishes to reject a CM-logon service indication for any reason, the CM-ground-user shall invoke a CM-logon service response with a Logon Response containing no information.

Note 1.— This may be done for either operational reasons (e.g. optional information that is required for a particular airspace is missing or information for the requested facility is not available) or technical reasons other than version incompatibility (e.g. there is a problem with the ground system and the service is not available). (These example reasons are not meant to constitute an exhaustive list.)

Note 2.— This will not be done if the CM-air-ASE and CM-ground-ASE versions are incompatible. In that case, the CM-ground-ASE will reject the D-START indication, as detailed in 2.5, before it reaches the CM-ground-user.

2.7.2.3 CM-update service requirements

4481448244834484448544864487448844894490449144924493449444954496449744984499450045014502450345044505450645074508450945104511451245134514451545164517451845194520452145224523452445254526452745284529453045314532


2.7.2.3.1 Only the CM-ground-user is permitted to initiate the CM-update-service.

2.7.2.3.2 For version 2 CM, eEither secure or unsecure CM-update services may be performed.

Note. – Indication of security is conveyed through the use of the Security Requirements parameter. The specific security mechanisms that may provide the security functionality are out of scope for this document.

2.7.2.3.3 When invoking the CM-update service request with version 1 CM aircraft, the CM-ground-user shall provide a CMUpdate containing application names, addresses and version numbers for each of the data link applications being updated.

Note 1.— This applies to both CM version 1 and CM version 2.

Note 2.— The CM-update service only corresponds to a ground facility’s local applications.

2.7.2.3.4 For CM version 2, when invoking the CM-update service request with version 2 CM aircraft, if use of security is requested, the CM-ground-user shall provide a CMSecureUpdate containing:



b) application names, addresses, version numbers, and optionally, authentic key agreement public keys and domain usage indications for the requested applications that can be air-initiated for all versions that the ground and aircraft systems can support; and

c) application names, version numbers, and optionally, authentic key agreement public keys and domain usage indications for the requested ground-only-initiated applications that the ground system can support.

2.7.2.3.5 For CM version 2, when invoking the CM-update service request with version 2 CM aircraft, if use of security is not requested, the CM-ground-user shall provide a CMSecureUpdate containing:



b) application names, addresses and version numbers for the requested applications that can be air-initiated for all versions that the ground and aircraft systems can support; and

c) application names and version numbers for the requested ground-only-initiated applications that the ground system can support.

2.7.2.3.46 When invoking the CM-update service request, the CM-ground-user shall use the long TSAP for each application address provided.

2.7.2.45 CM-contact service requirements

2.7.2.54.1 Only the CM-ground-user is permitted to initiate the CM-contact-service.

4533453445354536453745384539454045414542454345444545454645474548454945504551455245534554455545564557455845594560456145624563456445654566456745684569457045714572457345744575457645774578457945804581458245834584


2.7.2.45.2 For version 2 CM, eEither secure or unsecure CM-contact services may be performed.


2.7.2.45.3 When invoking the CM-contact service request, the CM-ground-user shall provide a CMContactRequest containing the facility designation of the ground facility that the ground requests the aircraft to contact.

2.7.2.65 CM-end service requirements

2.7.2.65.1 Only the CM-ground-user is permitted to initiate the CM-end-service.

2.7.2.65.2 If the CM-ground-user establishes a CM dialogue with the CM-logon Maintain Dialogue parameter set, the CM-ground-user is responsible for closing the CM dialogue with the CM-end service.

2.7.2.76 CM-forward service requirements

2.7.2.76.1 Only the CM-ground-user is permitted to initiate the CM-forward service.

2.7.2.76.2 For version 2 CM, eEither secure or unsecure CM-forward services may be performed.


2.7.2.76.3 When requesting the CM-forward service for version 1 CM, the CM-ground-user shall provide a CMForwardRequest containing all of the information from either a CM-logon request message or a CM-forward request message, whichever is more recent.

Note.— This applies to both CM version 1 and CM version 2 in emulation mode.

2.7.2.6.4 For CM version 2, when requesting the CM-forward service for version 2 CM, the CM-ground-user shall provide a CMEnhancedForwardRequest containing all of the information from either a CM-logon request message or a CM-forward request message, whichever is more recent, and an indication of the aircraft’s CM version number applicable to the forwarded information.

2.7.2.6.5 For CM version 2, when invoking a CM-forward request, if the CM-ground-user needs to use a previous CM-ground-ASE version, the CM-ground-user shall set the Emulated Version parameter value to the required version number.

Note.— This may be done for a variety of reasons, including a priori knowledge of a lower-versioned CM ground system.

2.7.2.6.6 When a CM version 2 performs an emulated CM version 1 CM-forward request, the initiating CM-ground-user should provide the CM version 2 information in the CMForwardRequest.

Note.— This is done in case the CM version 1 ground system subsequently performs a CM-forward with a CM version 2 ground system. The receiving CM version 2 ground system will then be able to take full advantage of the aircraft’s capabilities.

2.7.2.6.7 For CM version 2, when the CM-ground-user provides the Emulated Version parameter, the Emulated

4585458645874588458945904591459245934594459545964597459845994600460146024603460446054606460746084609461046114612461346144615461646174618461946204621462246234624462546264627462846294630463146324633463446354636


Version parameter value shall be less than the actual CM-ground-ASE version number.

Note.— This is to ensure that parameters not supported by a peer CM ground system will not be used.

2.7.2.76.48 Upon receipt of a CM-forward service indication, the CM-ground-user shall make the aircraft application information contained in the Forward Request available to the other applications (i.e. ADS-C and, CPDLC and FIS), as well as to the DS-provider.

2.7.2.76.59 Upon receipt of a CM-forward service indication, the CM-ground-user shall create the actual TSAP for each type of aircraft application information contained in the Forward Request based on the IDP and long TSAP for each application as defined in 2.4.


2.7.2.76.610 Upon receipt of a forward request from a CM-forward service indication concerning an aircraft identifier for which CM information has previously been received and is still being maintained, the CM-ground-user shall update the aircraft information accordingly.

2.7.2.76.711 Upon receipt of a forward request from a CM-forward service indication, the receiving CM-ground-user should invoke a CM-update service request with the indicated aircraft, if the update service is supported.

2.7.2.7 CM-server-facility-query service requirements

2.7.2.7.1 The CM-server-facility-query service applies to CM version 2 only.

2.7.2.7.2 Upon receipt of a CM-server-facility-query service indication, the CM-ground-user shall make the aircraft application information contained in the Server Facility Query Request available to the other applications (i.e. ADS-C and, CPDLC and FIS), as well as to the DS-provider.

2.7.2.7.3 Upon receipt of a CM-server-facility-query service indication, the CM-ground-user shall create the actual TSAP for each type of aircraft application information contained in the Server Facility Query Request based on the IDP and long TSAP for each application as defined in 2.4.


2.7.2.7.4 Upon receipt of a Server Facility Query Request from a CM-server-facility-query service indication from an aircraft for which CM information has previously been received and is still being maintained, the CM-ground-user shall update the aircraft information accordingly.

2.7.2.7.5 Upon receipt of a CM-server-facility-query service indication, if the CM-ground-user does not support the ability to retrieve other facilities’ application information, or if the ability to retrieve other facilities’ application information is temporarily unavailable, the CM-ground-user shall invoke a CM-server-facility-query service response indicating the reason.

Note.— This is done via the “InfoUnavailable” ASN.1 choice. In this case, either non-support of the server may be indicated (the “serverNotSupported” option) or temporary unavailability of server access may be indicated (the “serverUnavailable” option). The “serviceInterrupted” option is only used by the CM-air-ASE during a collision condition.

2.7.2.7.6 Upon receipt of a CM-server-facility-query service indication, the CM-ground-user shall invoke a CM-server-facility-query service response with a Server Facility Query Response containing application information for each facility designation, if available, as follows:

4637463846394640464146424643464446454646464746484649465046514652465346544655465646574658465946604661466246634664466546664667466846694670467146724673467446754676467746784679468046814682468346844685468646874688


a) the facility designation for which each set of application information is relevant;

b) application names, addresses and version numbers for the requested applications that can be air-initiated for all versions that the ground and aircraft systems can support;

c) application names and version numbers for the requested ground-only-initiated applications that the ground system can support; and

d) if the CM-server-facility-query service indication Security Required parameter contained the abstract value “secured dialogue supporting key management” or “secured dialogue” (i.e. if secure services are requested and supported), key and domain usage information for each application that requires security.

Note.— If information for a particular facility is not available, then no application information for that facility will be returned to the aircraft.

2.7.2.7.7 For the CM-server-facility-query service, the CM-ground-user should use the ATN directory service to obtain application information relating to other facilities.

2.7.2.7.8 The CM-ground-user should only return information for the facility designations specified in the Server Facility Query Request, if available.

2.7.2.7.9 When invoking the CM-server-facility-query service response, if any RDP for a given facility’s application address is different than the CM RDP, the CM-ground-user shall use the long TSAP for each application address provided.

Note 1.— The long TSAP = RDP + short TSAP. The short TSAP = ARS (optional) + LOC + SYS + NSEL + TSEL. The RDP = VER + ADM + RDF.

Note 2.— If there is more than one routing domain on the ground, the ARS field is used to differentiate one from the other(s). If there is not more than one routing domain on the ground, the ARS field need not be used.

Note 3.— The value of the ARS field is a 24-bit unsigned binary number that uniquely identifies the addressed system in a single routing domain and is assigned by the state or organization identified in the ADM field.

2.7.2.7.10 When the CM-ground-user requires a CM dialogue to be maintained, the CM-ground-user shall set the CM-server-facility-query service response Maintain Dialogue parameter if, and only if, the dialogue maintain service is supported.

2.7.2.8 CM-server-facility-update service requirements

2.7.2.8.1 Only the CM-ground-user is permitted to initiate the CM-server-facility-update service. This service applies to CM version 2 only.

2.7.2.8.2 When invoking the CM-server-facility-update service request, the CM-ground-user shall provide a Server Facility Update Information containing:

a) the facility designation for which each set of application information is relevant;

b) application names, addresses and version numbers for the requested applications that can be

4689469046914692469346944695469646974698469947004701470247034704470547064707470847094710471147124713471447154716471747184719472047214722472347244725472647274728472947304731473247334734473547364737473847394740


air-initiated for all versions that the ground and aircraft systems can support; c) application names and version numbers for the requested ground-only-initiated applications that the

ground system can support; and

d) if secure services are requested and supported, key and domain usage information for each application that requires security.

2.7.2.8.3 For the CM-server-facility-update service, the CM-ground-user should use the ATN directory service to obtain application information relating to other facilities.

2.7.2.8.4 When invoking the CM-server-facility-update service request, the CM-ground-user shall use the long TSAP for each application address provided.

2.7.2.89 CM-user-abort service requirements

2.7.2.89.1 When it is required that a CM-ground-user abort the current service or maintained dialogue, the CM-ground-user initiates a CM-user-abort request.

2.7.2.89.2 A CM-ground-user may need to abort the current service or maintained dialogue for several reasons, including the detection of an unrecoverable error situation and the local policies. The user abort request and indication primitives do not indicate the reason of the abort.

2.7.3 Parameter value unit, range and resolution

2.7.3.1 A CM-user shall interpret parameter value unit, range and resolution as defined in 2.4.

2.8 SUBSETTING RULES

2.8.1 General

Note.— This section specifies conformance requirements that all implementations of the CM protocol obey.

2.8.1.1 An implementation of either the CM ground-based service or the CM air-based service claiming conformance shall support the CM protocol features as shown in Tables 2-17 140 and 2-18151.

2.8.1.2 The “status” column indicates the level of support required for conformance to the CM-ASE protocol. The values are as follows:

“M” mandatory support is required;

“O” optional support is permitted for conformance to the CM protocol;

“N/A” the item is not applicable; and

“C.n” the item is conditional where n is the number which identifies the condition which is applicable.

4741474247434744474547464747474847494750475147524753475447554756475747584759476047614762476347644765476647674768476947704771477247734774477547764777477847794780478147824783478447854786478747884789479047914792


Table 2-17140. CM protocol versions implemented

Version Status Associated predicate

Version 1 MC V1

Version 2 C V2

C: A conformant implementation shall support one, and only one, of these two options.

Note.— A version 2 CM inherently has the capability to emulate a version 1 CM.

Table 2-18151. CM Operational functional units

CM state Status Associated predicate

The CM system acts as an airborne system C.1 CM/air

The CM system acts as a ground system C.1 CM/ground

The CM ground system can update application information

If (CM/ground), then O, else N/A G-UP-FU

The CM ground system can request the aircraft to initiate a logon with a specified CM ground system

If (CM/ground), then O, else N/A G-CO-FU

The CM-ground-user can process forwarded aircraft information

If (CM/ground), then O, else N/A G-FO-FU

The CM ground system can forward aircraft information to another CM ground system

If (CM/ground), then O, else N/A G-FO-IN

The CM-ground-user can initiate a server facility update with a specified air system

If (CM/ground), then O, else N/A G-SF-FU

The CM-ground-user can process a server facility query

If (CM/ground), then O, else N/A G-SQ-FU

The CM-air-user can process an update request

If (CM/air), then O, else N/A A-UP-FU

The CM-air-user can process a contact request If (CM/air), then O, else N/A A-CO-FU

The CM-air-user can initiate a server facility query with a specified ground system

If (CM/air), then O, else N/A A-SF-FU

The CM-air-user can process a server facility update

If (CM/air), then O, else N/A A-SU-FU

C.1: A conformant implementation will support one, and only one, of these two options.

Note 1.— A conformant CM-air implementation will consist of at least the core functionality (CM/air) with, optionally, any combination of the A-UP-FU and, A-CO-FU, A-SF-FU and A-SU-FU functional units. If only the core

479347944795

47964797479847994800480148024803

480448054806480748084809


functionality is supported, then logon exchanges can be initiated with ground systems, received contact requests are rejected with the reason “contact not successful”, received update and server-facility-update requests are processed by the CM-air-ASE but ignored by the CM-air-user, and the capability to maintain dialogue is supported. Mandatory support for security is inherent in any CM version 2 implementation.

Note 2.— A conformant CM-ground implementation will consists of at least the core functionality (CM/ground) with, optionally, any combination of the G-FO-IN, G-FO-FU, G-CO-FU, and G-UP-FU, G-SF-FU and G-SQ-FU. If only the core functionality is supported, then logon exchanges are supported with an aircraft, received forward requests are rejected with reason “service not supported”, received server facility queries are rejected with “server not supported”, and the capability to maintain dialogue optionally is supported. Mandatory support for security is inherent in any CM version 2 implementation.

4810481148124813481448154816481748184819482048214822


Note 3.— The templates of the Protocol/Operational Implementation Conformance Statements (P/OICS) provide the capability to detail all implementation particulars to a much deeper level than can be given by the functional unit descriptions of 2.8. All details for both air and ground implementations can be found in completed P/OICS for particular States’ or industries’ implementations.

______________________

482348244825482648274828482948304831

Chapter 3

CONTROLLER-PILOT DATA LINKCOMMUNICATIONS APPLICATION

3.1 INTRODUCTION

3.1.1 Overview

3.1.1.1 This chapter is designed as follows:

• Section 3.1 — INTRODUCTION: Besides outlining the material covered in Chapter 3, this section provides a description of the functions of the CPDLC application.

• Section 3.2 — GENERAL REQUIREMENTS: This section focuses on the CPDLC version number and error-processing requirements.

• Section 3.3 — THE ABSTRACT SERVICE: The description of the abstract service provided by the CPDLC application service element (CPDLC-ASE) is contained in this section.

• Section 3.4 — FORMAL DEFINITIONS OF MESSAGES: This section contains the formal definitions of messages exchanged by CPDLC-ASEs using Abstract Syntax Notation One (ASN.1).

• Section 3.5 — PROTOCOL DEFINITION: This section describes the exchanges of messages allowed by the CPDLC protocol, as well as time constraints. It also provides CPDLC-ASE protocol descriptions and state tables.

• Section 3.6 — COMMUNICATION REQUIREMENTS: The requirements that the CPDLC application imposes on the underlying communication system are covered in this section.

• Section 3.7 — CPDLC-USER REQUIREMENTS: This section contains requirements imposed on the user of the CPDLC-ASE service, and message description tables.

• Section 3.8 — SUBSETTING RULES: This section defines the conformant subsets for the CPDLC-ASE.

3.1.1.2 Throughout this manual, references to the CPDLC message refer to the actual CPDLC message as generated by, and delivered to, the CPDLC-users (operational content of the CPDLC message). References to CPDLC/IC data refer to CPDLC data to which an integrity check (IC) (checksum) has been added before sending the CPDLC message.

3-1

4832

4833

4834

4835483648374838483948404841484248434844484548464847484848494850485148524853485448554856485748584859486048614862486348644865486648674868486948704871487248734874487548764877


3.1.2 Description of the functions of the CPDLC application

3.1.2.1 Controller-pilot message exchange function

The controller-pilot message exchange function defines a method for a controller and a pilot to exchange CPDLC messages via data link. This function provides CPDLC messages for the following cases:

a) general information exchange;

b) clearance for:

1) delivery;

2) request; and

3) response;

c) altitude/identity surveillance;

d) monitoring of current/planned position;

e) advisories for:

1) request; and

2) delivery;

f) system management functions; and

g) emergency situations.

3.1.2.2 Transfer of data authority function

The transfer of data authority function provides the capability for the current data authority to designate another ground system as the next data authority. A CPDLC dialogue can be opened with or by the next data authority at a time before that next data authority becomes the current data authority. This capability is intended to prevent a loss of communication that would occur if the next data authority were prevented from actually setting up a dialogue with an aircraft until it became the current data authority. The designation of a next data authority is accomplished using a CPDLC message.

3.1.2.23 Downstream clearance function

The downstream clearance function provides the capability for an aircraft to contact an air traffic service unit that is not the current data authority for the purpose of receiving a downstream clearance. This information is exchanged using CPDLC message(s).

3.1.2.34 Ground forward function

The ground forward function provides the capability for a ground system to forward information received in a CPDLC

487848794880488148824883488448854886488748884889489048914892489348944895489648974898489949004901490249034904490549064907490849094910491149124913491449154916491749184919492049214922492349244925492649274928492949304931

Part I. Air-Ground ApplicationsChapter 3. Controller-Pilot Data Link Communications Application 3-3

message to another ground system. The ground forward function can be used by the current data authority to forward an aircraft request to the next data authority so that the aircraft does not need to issue the same request again. This function can also be used by a downstream data authority to pass a message to a current data authority for transmission by the current data authority to an aircraft. This information is exchanged using a CPDLC message or messages. It is a one-way forwarding of information with an indication of success, failure or non-support from the receiving ground system. The CPDLC ground forward function does not use the CPDLC integrity check.

3.2 GENERAL REQUIREMENTS

3.2.1 CPDLC-ASE version number

The CPDLC-air-ASE and CPDLC-ground-ASE version numbers shall both be set to one.

3.2.2 Error-processing requirements

3.2.2.1 In the event of information input by the CPDLC-user being incompatible with that which is able to be processed by the system, the CPDLC-user shall be notified.

3.2.2.2 In the event of a CPDLC-user invoking a CPDLC service primitive when the CPDLC-ASE is not in a state specified in 3.5, the CPDLC-user shall be notified.

3.3 THE ABSTRACT SERVICE

3.3.1 Service description

3.3.1.1 An implementation of either the CPDLC ground-based service or the CPDLC air-based service shall exhibit external behaviour consistent with having implemented a CPDLC-ground-ASE or CPDLC-air-ASE, respectively, with the abstract service interface primitives defined in this section, making them available to the CPDLC-ground-user or CPDLC-air-user, respectively.

3.3.1.2 There is no requirement to implement the CPDLC-ASE abstract service in a CPDLC product; however, it is necessary to implement the ground-based and air-based system in such a way that it will be impossible to detect (from the peer system) whether or not the interface has been built.

3.3.1.3 This section defines the abstract service interface for the CPDLC service. The CPDLC-ASE abstract service is described in this section from the viewpoint of the CPDLC-air-user, the CPDLC-ground-user and the CPDLC service provider.

3.3.1.4 This section defines the static behaviour (i.e. the format) of the CPDLC abstract service. Its dynamic behaviour (i.e. how it is used) is described in 3.7.

3.3.1.5 Figure 3-1 shows the functional model of the CPDLC application. The various elements identified in this model are the following:

a) the CPDLC-user;

493249334934493549364937

4938

493949404941494249434944494549464947494849494950495149524953495449554956

4957

495849594960496149624963496449654966496749684969497049714972497349744975497649774978497949804981498249834984


b) the CPDLC application entity (CPDLC-AE) service interface;

c) the CPDLC-AE;

d) the CPDLC control function (CPDLC-CF);

e) the CPDLC application service element (CPDLC-ASE) service interface;

f) the CPDLC-ASE; and


Figure 3-1. Functional model of the CPDLC application

3.3.1.6 The CPDLC-user represents the operational part of the CPDLC system. This user does not perform the communication functions but relies on a communication service provided to it via the CPDLC-AE through the CPDLC-AE service interface. The individual actions possible through the CPDLC-AE service interface are called service primitives.

3.3.1.7 The CPDLC-AE consists of several elements including the CPDLC-ASE and the CPDLC-CF.

3.3.1.8 The CPDLC-ASE is the element in the communication system that executes the CPDLC-specific protocol. In other words, it takes care of the CPDLC-specific service primitive sequencing actions, message creation, timer management, and error and exception handling. The actual encoding and decoding of each CPDLC message is handled by the CPDLC-users.

3.3.1.9 The CPDLC-CF is responsible for mapping service primitives received from one element (such as the CPDLC-ASE and the CPDLC-user) to service primitives of other abstract elements.

3.3.1.10 The CPDLC-ASE has two abstract boundaries with the CPDLC-CF: the CPDLC-ASE service and the DS. The CPDLC-CF maps CPDLC-AE service primitives to other abstract elements in the CPDLC-AE and the underlying communication service and vice versa.

C PDL C-air-useror

CPDLC -groun d-u se r

Con tro l fu nc tio n

C PDL Cs

app lica tione rv ice e le m e n t

CPD LC app lica tion en tity

Con tro l func tio nD ia lo gu e serv ice interface

C PDL Celem en t serv ice interface

app lication serv ice

CPDL Cserv ice inte rfa ce

a pp lication entity

49854986498749884989499049914992499349944995499649974998

5000500150025003500450055006500750085009501050115012501350145015501650175018501950205021


3.3.2 The CPDLC-ASE abstract service

3.3.2.1 The CPDLC-ASE abstract service shall consist of a subset of the following services as allowed by the subsetting rules in 3.8:

a) CPDLC-start service as defined in 3.3.3;

b) DSC-start service as defined in 3.3.4;

c) CPDLC-message service as defined in 3.3.5;

d) CPDLC-end service as defined in 3.3.6;

e) DSC-end service as defined in 3.3.7;

f) CPDLC-forward service as defined in 3.3.8;

g) CPDLC-user-abort service as defined in 3.3.9; and

h) CPDLC-provider-abort service as defined in 3.3.10.

3.3.2.2 For a given primitive, the presence of each parameter is described by one of the following values in the parameter tables in 3.3:

blank not present;


C(=) conditional upon the value of the parameter to the immediate left being both present and equal;

M mandatory;

M(=) mandatory, and equal to the value of the parameter to the immediate left; or

U user option.

3.3.2.3 The following abbreviations are used in Chapter 3 of this manual:

Req request; data is input by the CPDLC-user initiating the service to its respective ASE;

Ind indication; data is indicated by the receiving ASE to its respective CPDLC-user;

Rsp response; data is input by the receiving CPDLC-user to its respective ASE; and

Cnf confirmation; data is confirmed by the initiating ASE to its respective CPDLC-user.

3.3.2.4 An unconfirmed service allows a message to be transmitted in one direction without providing a corresponding response.

3.3.2.5 A confirmed service provides end-to-end confirmation that a message sent by one user was received by its peer user.

5022502350245025502650275028502950305031503250335034503550365037503850395040504150425043504450455046504750485049505050515052505350545055505650575058505950605061506250635064506550665067506850695070507150725073


3.3.2.6 An abstract syntax is a syntactical description of a parameter that does not imply a specific implementation. Only when the CPDLC-ASE maps a parameter onto an APDU field, or vice versa, is the abstract syntax of the parameter described by using the ASN.1 at 3.4 for this field.

3.3.3 CPDLC-start service

3.3.3.1 General

3.3.3.1.1 The CPDLC-start service is used by the CPDLC-air-user or CPDLC-ground-user to establish a CPDLC dialogue. It is a confirmed service.

3.3.3.1.2 Once a CPDLC dialogue is established, it remains open until explicitly closed (see CPDLC-end service at 3.3.6 and CPDLC-abort services at 3.3.9 and 3.3.10).

3.3.3.1.3 The CPDLC-start service shall contain the primitives and parameters as presented in Table 3-1.

Table 3-1. CPDLC-start service parameters


Called Peer Identifier M

Calling Peer Identifier M M(=)

CPDLC Message Set Version NumberASN.1 Version Number

U C(=)

CPDLC/IC Data M M(=)

Response CPDLC/IC Data M M(=)

Result M M(=)

Class of Communication Service U M

Security Required U

3.3.3.2 Called Peer Identifier parameter

3.3.3.2.1 If the service is ground-initiated, the Called Peer Identifier parameter contains the addressed ICAO 24-bit aircraft address.

3.3.3.2.2 If the service is air-initiated, the Called Peer Identifier parameter contains the addressed ground system’s facility designation.

3.3.3.2.3 If the service is ground-initiated, the Called Peer Identifier parameter value shall conform to the abstract syntax of the ICAO 24-bit aircraft address.

3.3.3.2.4 If the service is air-initiated, the Called Peer Identifier parameter value shall conform to the abstract syntax four- to eight-character facility designation.

507450755076507750785079508050815082508350845085508650875088508950905091509250935094

5095509650975098509951005101510251035104510551065107510851095110


3.3.3.3 Calling Peer Identifier parameter

3.3.3.3.1 If the service is ground-initiated, the Calling Peer Identifier parameter contains the sending ground system’s facility designation.

3.3.3.3.2 If the service is air-initiated, the Calling Peer Identifier parameter contains the sending ICAO 24-bit aircraft address.

3.3.3.3.3 If the service is ground-initiated, the Calling Peer Identifier parameter value shall conform to the abstract syntax four- to eight-character facility designation.

3.3.3.3.4 If the service is air-initiated, the Calling Peer Identifier parameter value shall conform to the abstract syntax of the ICAO 24-bit aircraft address.

3.3.3.4 CPDLC Message Set Version Number ASN.1 Version Number parameter

Note. – ThisThe CPDLC Message Set Version Number parameter contains the version number of the CPDLC message set. This is not the CDPLC ASE Version Number, nor is it the PM CPDLC Version Number.3.3.3.4.1 This parameter contains the version number of the CPDLC-ASE and identifies the user data abstract syntax..

1The CPDLC Message Set Version Number parameter shall conform to an abstract integer value from 1 to 255.When provided by the CPDLC-user, the ASN.1 Version Number parameter shall conform to an abstract integer value from 1 to 255.

3.3.3.5 CPDLC/IC Data parameter

3.3.3.5.1 The CPDLC-user uses this parameter to send CPDLC/IC Data to its peer user.

3.3.3.5.2 If the CPDLC-start request primitive is invoked by the CPDLC-ground-user, the CPDLC/IC Data parameter value shall conform to the ASN.1 abstract syntax ICUplinkMessage.

3.3.3.5.3 If the CPDLC-start request primitive is invoked by the CPDLC-air-user, the CPDLC/IC Data parameter value shall conform to the ASN.1 abstract syntax ICDownlinkMessage.

Note.— The CPDLC/IC Data parameter usually contains an embedded operational CPDLC message, but this is not present in some cases. It always contains an IC field.

3.3.3.6 Response CPDLC/IC Data parameter

3.3.3.6.1 The Response CPDLC/IC Data parameter is used either to provide a reason for rejecting a CPDLC dialogue or to provide a means of verifying that a CPDLC dialogue establishment request has been received and accepted by the intended peer. In the latter case, the response includes either a LACK or no message element. This is to ensure a rapid response to a CPDLC-start. However, the CPDLC-ASE is not required to police this requirement. The air or ground CPDLC-user is instead required to ensure that the Response parameter includes either an allowed CPDLC message or no CPDLC message.

3.3.3.6.2 If the CPDLC-start response primitive is invoked by the CPDLC-ground-user, the Response CPDLC/IC Data parameter value shall conform to the ASN.1 abstract syntax ICUplinkMessage.

5111511251135114511551165117511851195120512151225123512451255126512751285129513051315132513351345135513651375138513951405141514251435144514551465147514851495150515151525153515451555156515751585159516051615162


3.3.3.6.3 If the CPDLC-start response primitive is invoked by the CPDLC-air-user, the Response CPDLC/IC Data parameter value shall conform to the ASN.1 abstract syntax ICDownlinkMessage.

Note.— A response may, and often does, contain no CPDLC message. It always includes an IC field.


3.3.3.7.1 The Result parameter is used to indicate whether or not a requested CPDLC dialogue is accepted.

3.3.3.7.2 This parameter shall have one of two abstract values: “accepted” or “rejected”.


3.3.3.8.1 This parameter contains the value of the required class of communication service. If not specified by the CPDLC-user, this indicates that there is no routing preference.

3.3.3.8.2 This parameter is used by the CPDLC-ground-user to determine if the Class of Communication value is acceptable for the establishment of a CPDLC dialogue.

3.3.3.8.3 The parameter indicated to the peer CPDLC-user is that provided by the CPDLC-user if specified by the user; otherwise, it indicates that no routing preference was requested by the CPDLC dialogue initiator.

3.3.3.8.4 Where specified by the CPDLC-user, the Class of Communication Service parameter shall have one of the following abstract values: “A”, “B”, “C”, “D”, “E”, “F”, “G” or “H”.

3.3.3.8.5 When this parameter is provided by the CPDLC-user, the same value shall be indicated to the peer CPDLC-user; otherwise, the abstract value “ATSC - no traffic type policy preference” is indicated.


Note. – Indication of security is conveyed through the use of the Security Required parameter. The specific security mechanisms that may provide the security functionality are out of scope for this document.

3.3.3.9.1 The Security Required parameter contains the value of the required level of security, if specified by the CPDLC-user.

3.3.3.9.2 If the received Security Required parameter is not as expected per the local security policy, the receiving CPDLC-ASE will abort.

3.3.3.9.3 Where specified by the CPDLC-user, the Security Required parameter shall have one of the following abstract values: “no security” or “secured exchange”.

Note.— Where not specified by the CPDLC-user, this indicates that there is no security required.

3.3.4 DSC-start service

5163516451655166516751685169517051715172517351745175517651775178517951805181518251835184518551865187518851895190519151925193519451955196519751985199520052015202520352045205520652075208520952105211521252135214


3.3.4.1 General

3.3.4.1.1 The DSC-start service is used by the CPDLC-air-user to establish a DSC dialogue for the purpose of providing downstream clearances. It is a confirmed service.

3.3.4.1.2 Once a DSC dialogue is established, it remains open until explicitly closed (see DSC-end service at 3.3.7 and CPDLC-abort services at 3.3.9 and 3.3.10).

3.3.4.1.3 The DSC-start service shall contain the primitives and parameters as presented in Table 3-2.

Table 3-2. DSC-start service parameters



Aircraft Address M M(=)

CPDLC Message Set Version Number U C(=)


Response CPDLC/IC Data M M(=)

Result M M(=)

Class of Communication Service U M

Security Required U






3.3.4.3.2 This parameter contains the ICAO 24-bit aircraft address.

3.3.4.4 CPDLC Message Set Version Number parameter

Note.— The CPDLC Message Set Version Number parameter contains the version number of the CPDLC-ASE and identifies the user data abstract syntax.

When provided by the CPDLC-user, the CPDLC Message Set Version Number parameter shall conform to an abstract integer value from 1 to 255.

5215521652175218521952205221522252235224522552265227

5228522952305231523252335234523552365237523852395240524152425243524452455246524752485249525052515252



3.3.4.5.1 The CPDLC-air-user uses this parameter to send CPDLC/IC Data to a CPDLC-ground-user.

3.3.4.5.2 The CPDLC/IC Data parameter value shall conform to the ASN.1 abstract syntax ICDownlinkMessage.

Note.— The CPDLC/IC Data parameter usually contains an embedded operational CPDLC message, but this is not present in some cases. It always contains an IC field.

3.3.4.6 Response CPDLC/IC Data parameter

3.3.4.6.1 The Response CPDLC/IC Data parameter is used either to provide a reason for rejecting a DSC dialogue or to provide a means of verifying that a DSC dialogue establishment has been received and accepted by the intended peer. In the latter case, the response includes either a LACK or no message element. This is to ensure a rapid response to a DSC-start. However, the CPDLC-ground-ASE is not required to police this requirement. The CPDLC-ground-user is instead required to ensure that the Response parameter includes either a LACK or no CPDLC message.

525352545255525652575258525952605261526252635264526552665267526852695270527152725273


3.3.4.6.2 The Response CPDLC/IC Data parameter shall conform to the ASN.1 abstract syntax ICUplinkMessage.

Note.— A response may, and often does, contain no CPDLC message. It always includes an IC field.


3.3.4.7.1 The Result parameter is used to indicate whether or not a requested DSC dialogue is accepted.

3.3.4.7.2 The Result parameter value shall have one of two abstract values: “accepted” or “rejected”.


3.3.4.8.1 This parameter contains the value of the required class of communication service. If not specified by the CPDLC-air-user, this indicates that there is no routing preference.

3.3.4.8.2 This parameter is used by the CPDLC-ground-user to determine if the Class of Communication value is acceptable for the establishment of a DSC dialogue.

3.3.4.8.3 If provided by the user, the parameter indicated to the peer user is that provided by the user; otherwise, it indicates that no routing preference was requested by the CPDLC dialogue initiator.

3.3.4.8.4 Where specified by the CPDLC-air-user, the Class of Communication Service parameter shall have one of the following abstract values: “A”, “B”, “C”, “D”, “E”, “F”, “G” or “H”.

3.3.4.8.5 When this parameter is provided by the CPDLC-user, the same value shall be indicated to the peer CPDLC-user; otherwise, the abstract value “ATSC - no traffic type policy preference” is indicated.



3.3.4.9.1 The Security Required parameter contains the value of the required level of security, if specified by the CPDLC-air-user.

3.3.4.9.2 If the received Security Required parameter is not as expected per the local security policy, the receiving CPDLC-ground-ASE will abort.

3.3.4.9.3 Where specified by the CPDLC-air-user, the Security Required parameter shall have one of the following abstract values: “no security” or “secured exchange”.

Note.— Where not specified by the CPDLC-air-user, this indicates that there is no security required.

3.3.5 CPDLC-message service

3.3.5.1 General

5274527552765277527852795280528152825283528452855286528752885289529052915292529352945295529652975298529953005301530253035304530553065307530853095310531153125313531453155316531753185319532053215322532353245325


3.3.5.1.1 The CPDLC-message service can be used for pilot/controller message exchange once a dialogue is established. It is an unconfirmed service.

3.3.5.1.2 The CPDLC-message service shall contain the primitives and parameters as presented in Table 3-3.

Table 3-3. CPDLC-message service parameters




3.3.5.2.1 This parameter contains a CPDLC/IC Data value.

3.3.5.2.2 If the CPDLC-message service is invoked by the CPDLC-ground-user, the CPDLC/IC Data parameter value shall conform to the ASN.1 abstract syntax ICUplinkMessage.

3.3.5.2.3 If the CPDLC-message service is invoked by the CPDLC-air-user, the CPDLC/IC Data parameter value shall conform to the ASN.1 abstract syntax ICDownlinkMessage.

3.3.5.2.4 The CPDLC/IC Data parameter provided by the CPDLC-user always contains both an embedded operational CPDLC message and an IC field.

3.3.6 CPDLC-end service

3.3.6.1 General

3.3.6.1.1 The CPDLC-end service is used by the CPDLC-ground-user to end a CPDLC dialogue with a CPDLC-air-user. It is a confirmed service.

3.3.6.1.2 The CPDLC-end service shall contain the primitives and parameters as presented in Table 3-4.

Table 3-4. CPDLC-end service parameters


CPDLC/IC Data M M(=) M M(=)

Result M M(=)



3.3.6.2.2 The CPDLC/IC Data parameter value shall conform to the ASN.1 abstract syntax ICUplinkMessage, if

53265327532853295330533153325333

53345335533653375338533953405341534253435344534553465347534853495350535153525353535453555356535753585359536053615362

5363536453655366536753685369


provided by the CPDLC-ground-user.

3.3.6.2.3 The CPDLC/IC Data parameter value shall conform to the ASN.1 abstract syntax ICDownlinkMessage, if provided by the CPDLC-air-user.

3.3.6.2.4 The CPDLC/IC Data parameter value does not necessarily contain an embedded operational CPDLC message. It always includes an IC field.


3.3.6.3.1 This parameter is used to indicate whether or not a request to terminate a CPDLC dialogue is accepted.

3.3.6.3.2 The Result parameter shall have one of two abstract values: “accepted” or “rejected”.

3.3.7 DSC-end service

3.3.7.1 General

3.3.7.1.1 The DSC-end service is used by the CPDLC-air-user to end a DSC dialogue with a CPDLC-ground-user. It is a confirmed service.

3.3.7.1.2 The DSC-end service shall contain the primitives and parameters as presented in Table 3-5.

Table 3-5. DSC-end service parameters


CPDLC/IC Data M M(=) M M(=)

Result M M(=)



3.3.7.2.2 The CPDLC/IC Data parameter value shall conform to the ASN.1 abstract syntax ICUplinkMessage, if provided by the CPDLC-ground-user.

3.3.7.2.3 The CPDLC/IC Data parameter value shall conform to the ASN.1 abstract syntax ICDownlinkMessage, if provided by the CPDLC-air-user.

3.3.7.2.4 The CPDLC/IC Data parameter value does not necessarily contain an embedded operational CPDLC message. It always includes an IC field.


3.3.7.3.1 This parameter is used to indicate whether or not a request to terminate a DSC dialogue is accepted.

5370537153725373537453755376

5377537853795380538153825383538453855386

538753885389539053915392539353945395539653975398

53995400540154025403540454055406540754085409541054115412

54135414541554165417


3.3.7.3.2 The Result parameter shall have one of two abstract values: “accepted” or “rejected”.

3.3.8 CPDLC-forward service

3.3.8.1 General

3.3.8.1.1 The CPDLC-forward service is used by a CPDLC-ground-user to send a CPDLC message to another CPDLC-ground-user. Its primary use is for the forwarding of aircraft requests.

3.3.8.1.2 If the CPDLC-forward service is supported by the receiving ground system, and the sending CPDLC-ground-ASE and receiving CPDLC-ground-ASE version numbers are equal, the CPDLC-forward service shall contain the primitives and parameters as presented in Table 3-6.

Table 3-6. CPDLC-forward service parameters(service supported, versions equal)

Parameter name Req Ind Cnf


Calling Facility Designation M M(=)

CPDLC Message M M(=)


Security Required U

Result M

3.3.8.1.3 If the CPDLC-forward service is not supported by the receiving ground system, or if the CPDLC-forward service is supported by the receiving ground system but the sending CPDLC-ground-ASE and receiving CPDLC-ground-ASE version numbers are not equal, the CPDLC-forward service shall contain the primitives and parameters as presented in Table 3-7.

Table 3-7. CPDLC-forward service parameters(service not supported or versions not equal)



Calling Facility Designation M

ASE Version Number C

CPDLC Message M


Security Required U

54185419542054215422542354245425542654275428542954305431543254335434543554365437

5438543954405441544254435444544554465447


Result M

3.3.8.2 Called Facility Designation parameter


3.3.8.2.2 The Called Facility Designation parameter value shall conform to the abstract syntax four- to eight-character facility designation.

3.3.8.3 Calling Facility Designation parameter

3.3.8.3.1 This parameter contains the sending ground system’s facility designation.

3.3.8.3.2 The Calling Facility Designation parameter value shall conform to the abstract syntax four- to eight-character facility designation.

3.3.8.4 ASE Version Number parameter

3.3.8.4.1 This parameter contains the version number of the CPDLC-ASE.

3.3.8.4.2 When provided by the CPDLC-ground-ASE, the ASE Version Number parameter shall conform to the abstract integer value in the range of 1-255.

3.3.8.4.3 Only if the sending CPDLC-ground-ASE version number is not equal to the receiving CPDLC-ground-ASE version number shall the receiving CPDLC-ground-ASE version number be confirmed to the sending CPDLC-ground-user.

Note.— If the sending CPDLC-ground-ASE version number is the same as the receiving CPDLC-ground-ASE version number, the Version Number parameter is not present in the indication given to the receiving CPDLC-ground-user or in the confirmation given to the sending CPDLC-ground-user.

3.3.8.5 CPDLC Message parameter

3.3.8.5.1 The sending CPDLC-ground-user uses this parameter to forward a CPDLC message to another CPDLC-ground-user.

3.3.8.5.2 The CPDLC Message parameter value shall conform to the ASN.1 abstract syntax ATCForwardMessage.


3.3.8.6.1 This parameter contains the value of the required class of communication service. If not specified by the CPDLC-ground-user, this indicates that there is no routing preference.

3.3.8.6.2 Where specified by the CPDLC-ground-user, the Class of Communication Service parameter shall have one of the following abstract values: “A”, “B”, “C”, “D”, “E”, “F”, “G” or “H”.

544854495450545154525453545454555456545754585459546054615462546354645465546654675468546954705471547254735474547554765477547854795480548154825483548454855486548754885489549054915492549354945495549654975498




3.3.8.7.1 The Security Required parameter contains the value of the required level of security, if specified by the CPDLC-ground-user.3.3.8.7.2 If the received Security Required parameter is not as expected per the local security policy, the receiving CPDLC-ground-ASE will abort.

3.3.8.7.3 Where specified by the CPDLC-ground-user, the Security Required parameter shall have one of the following abstract values: “no security” or “secured exchange”.

Note.— Where not specified by the CPDLC-ground-user, this indicates that there is no security required.


3.3.8.8.1 The Result parameter contains the result of the CPDLC-forward service. It will indicate success (service supported and matching versions), service unsupported, or version number incompatibility.

3.3.8.8.2 The Result parameter value shall conform to the ASN.1 abstract syntax ATCForwardResponse.

3.3.9 CPDLC-user-abort service

3.3.9.1 General

3.3.9.1.1 This service provides the capability for either the CPDLC-air-user or the CPDLC-ground-user to abort communication with its peer. It can be invoked at any time the CPDLC-user is aware that the CPDLC service is in operation. The CPDLC-user-abort service can be used for operational or technical reasons. It is an unconfirmed service. Messages in transit may be lost during this operation.

3.3.9.1.2 If the service is invoked prior to complete establishment of the dialogue, the CPDLC-user-abort indication may not be provided. A CPDLC-provider-abort indication may result instead.

3.3.9.1.3 The CPDLC-user-abort service shall contain the primitives and parameters as presented in Table 3-8.

Table 3-8. CPDLC-user-abort service parameters


Reason U M


3.3.9.2.1 The Reason parameter is used to indicate a reason for aborting the CPDLC or DSC dialogue.

549955005501550255035504550555065507550855095510551155125513551455155516551755185519552055215522552355245525552655275528552955305531553255335534553555365537553855395540

554155425543554455455546


3.3.9.2.2 If provided by the CPDLC-user, the parameter indicated to the peer CPDLC-user is that provided by the CPDLC-user; otherwise, it is what the ASE supplies.

3.3.9.2.3 The Reason parameter value shall conform to the ASN.1 abstract syntax CPDLCUserAbortReason.

3.3.9.2.4 When this parameter is provided by the CPDLC-user, the same value shall be indicated to the peer CPDLC-user.

3.3.10 CPDLC-provider-abort service

3.3.10.1 General

3.3.10.1.1 This service provides the capability for the CPDLC service provider to inform its active users that it can no longer provide the CPDLC service. Messages in transit may be lost during this operation.

3.3.10.1.2 The CPDLC-provider-abort service shall contain the primitives and parameters as presented in Table 3-9.

Table 3-9. CPDLC-provider-abort service parameters

Parameter name Ind

Reason M


3.3.10.2.1 This parameter identifies the reason for the abort.

3.3.10.2.2 The Reason parameter shall conform to the ASN.1 abstract syntax CPDLCProviderAbortReason.

3.4 1FORMAL DEFINITIONS OF MESSAGES

3.4.1 Encoding/decoding rules

3.4.1.1 A CPDLC-air-ASE shall be capable of encoding AircraftPDUs APDUs and decoding GroundPDUs APDUs as defined in the ASN.1 module CPDLCAPDUsVersion1 specified in 3.4.2.

Note 1.— The ICUplinkMessage and ICDownlinkMessage ASN.1 types both contain an IC field and the EncodedCPDLCMessage type, which both resolve to a BIT STRING type. Even though this BIT STRING is specified as containing a PER-encoded ATCUplinkMessage or a PER-encoded ATCDownlinkMessage, there is no requirement on the CPDLC-air-ASE to verify this. The CPDLC-air-user is responsible for encoding a valid ATCDownlinkMessage and for verifying the correctness of a received ATCUplinkMessage.

3.4.1.2 The CPDLC-air-user shall be capable of encoding ATCDownlinkMessage types and decoding ATCUplinkMessage types, as defined in the ASN.1 module CPDLCMessageSetVersion1 specified in 3.4.3.

5547554855495550555155525553555455555556555755585559556055615562556355645565556655675568

55695570557155725573557455755576557755785579558055815582558355845585558655875588558955905591559255935594


3.4.1.23 A CPDLC-ground-ASE shall be capable of encoding GroundPDUs APDUs and decoding AircraftPDUs APDUs as defined in the ASN.1 module CPDLCAPDUsVersion1 specified in 3.4.2.

Note 1.— The ICUplinkMessage and ICDownlinkMessage ASN.1 types both contain an IC field and the CPDLCMessage type, which both resolve to a BIT STRING type. Even though this BIT STRING is specified as containing a PER-encoded ATCUplinkMessage or a PER-encoded ATCDownlinkMessage, there is no requirement on the CPDLC-ground-ASE to verify this. The CPDLC-ground-user is responsible for encoding a valid ATCUplinkMessage and for verifying the correctness of a received ATCDownlinkMessage.

Note 2.— The ForwardMessage ASN.1 type contains the uplink or downlink CPDLC message element data type, which both resolve to a BIT STRING type. Even though this BIT STRING is specified as containing a PER-encoded ATCUplinkMessageData or a PER-encoded ATCDownlinkMessageData, there is no requirement on the CPDLC-ground-ASE to verify this. The CPDLC-ground-user is responsible for encoding and verifying the correctness of valid ATCDownlinkMessageData and ATCUplinkMessageData.

3.4.1.4 The CPDLC-ground-user shall be capable of encoding ATCUplinkMessage types and decoding ATCDownlinkMessage types as defined in the ASN.1 module CPDLCMessageSetVersion1 specified in 3.4.3.

3.4.1.5 The CPDLC-ground-user shall be capable of encoding and decoding ATCUplinkMessageData and ATCDownlinkMessageData types as defined in the ASN.1 module CPDLCMessageSetVersion1 specified in 3.4.3.

3.4.2 CPDLC ASN.1 abstract syntax

The abstract syntax of the CPDLC protocol data units shall comply with the description contained in the ASN.1 module CPDLCAPDUsVersion1 (conforming to ISO/IEC 8824), as defined hereinafter:

CPDLCAPDUsVersion1 DEFINITIONS::=

BEGIN

IMPORTS DateTimeGroup, AircraftFlightIdentification, AircraftAddress FROM CPDLCMessageSetVersion1;

-- ------------------------------------------------------------------------------------ Ground Generated Messages - Top level-- ----------------------------------------------------------------------------------GroundPDUs ::= CHOICE

{abortUser [0] CPDLCUserAbortReason,abortProvider [1] CPDLCProviderAbortReason,startup [2] ICUplinkMessage,send [3] ICUplinkMessage,forward [4] ATCForwardMessage,forwardresponse [5] ATCForwardResponse,...

5595559655975598559956005601560256035604560556065607560856095610561156125613561456155616561756185619562056215622562356245625562656275628562956305631563256335634563556365637563856395640564156425643564456455646


}

ICUplinkMessage<blank> ::= SEQUENCE{algorithmIdentifier [0] AlgorithmIdentifier OPTIONAL,embeddedMessage [1] EncodedCPDLCMessage OPTIONAL,

-- PER encoded ATCUplinkMessage-- (see Module CPDLCMessageSetVersion1)

5647564856495650565156525653565456555656


integrityCheck [2] BIT STRING,...}

ATCForwardMessage ::= SEQUENCE{forwardHeader ForwardHeader,forwardMessage ForwardMessage}

ForwardHeader ::= SEQUENCE{dateTime DateTimeGroup,aircraftID AircraftFlightIdentification,aircraftAddress AircraftAddress}

ForwardMessage ::= CHOICE{upElementIDs [0] BIT STRING,

--PER encoded ATCUplinkMessageData,-- (see Module CPDLCMessageSetVersion1)

downElementIDs [1] BIT STRING--PER encoded ATCDownlinkMessageData,-- (see Module CPDLCMessageSetVersion1)

}

ATCForwardResponse ::= ENUMERATED{success (0),service-not-supported (1),version-not-equal (2),...}

-- ------------------------------------------------------------------------------------ Aircraft Generated Messages - Top level-- ----------------------------------------------------------------------------------

AircraftPDUs::= CHOICE{abortUser [0] CPDLCUserAbortReason,abortProvider [1] CPDLCProviderAbortReason,startdown [2] StartDownMessage,send [3] ICDownlinkMessage,...}

56575658565956605661566256635664566556665667566856695670567156725673567456755676567756785679568056815682568356845685568656875688568956905691569256935694569556965697569856995700570157025703570457055706


StartDownMessage ::= SEQUENCE{mode Mode DEFAULT cpdlc,startDownlinkMessage ICDownlinkMessage}

Mode ::= ENUMERATED{cpdlc (0),dsc (1)}

ICDownlinkMessage<blank>::= SEQUENCE{algorithmIdentifier [0] AlgorithmIdentifier OPTIONAL,embeddedMessage [1] EncodedCPDLCMessage OPTIONAL,

--PER encoded ATCDownlinkMessage,-- (see Module CPDLCMessageSetVersion1)

integrityCheck [2] BIT STRING,...}

-- ------------------------------------------------------------------------------------ Uplink and Downlink messages - Common Elements-- ----------------------------------------------------------------------------------

AircraftAddress ::= BIT STRING (SIZE(24))

AircraftFlightIdentification ::= IA5String (SIZE (2..8))

AlgorithmIdentifier ::= RELATIVE-OID --root is {icao-arc atn-algorithms(9)}-- see Doc 9880, Part IV, for OID root assignment

EncodedCPDLCMessage ::= BIT STRING

CPDLCUserAbortReason ::= ENUMERATED{undefined (0),no-message-identification-numbers-available (1),duplicate-message-identification-numbers (2),no-longer-next-data-authority (3),current-data-authority-abort (4),commanded-termination (5),invalid-response (6),time-out-of-synchronization (7),unknown-integrity-check (8),validation-failure (9),unable-to-decode-message (10),invalid-pdu (11),invalid-CPDLC-message (12),...

5707570857095710571157125713571457155716571757185719572057215722572357245725572657275728572957305731573257335734573557365737573857395740574157425743574457455746574757485749575057515752575357545755575657575758


}575957605761


CPDLCProviderAbortReason ::= ENUMERATED{timer-expired (0),undefined-error (1),invalid-PDU (2),protocol-error (3),communication-service-error (4),communication-service-failure (5),invalid-QOS-parameter (6),expected-PDU-missing (7),...}

Date ::= SEQUENCE { year Year, month Month, day Day }

DateTimeGroup ::= SEQUENCE { date Date, timehhmmss Timehhmmss }

Day ::= INTEGER (1..31) --unit = Day, Range (1..31), resolution = 1

Month ::= INTEGER (1..12) --unit = Month, Range (1..12), resolution = 1

Time ::= SEQUENCE { hours TimeHours, minutes TimeMinutes }

TimeHours ::= INTEGER (0..23) -- unit = Hour, Range (0..23), resolution = 1

Timehhmmss ::= SEQUENCE { hoursminutes Time, seconds TimeSeconds }

TimeMinutes ::= INTEGER (0..59) -- unit = Minute, Range (0..59), resolution = 1

TimeSeconds ::= INTEGER (0..59) -- unit = Second, Range (0..59), resolution = 1

5762576357645765576657675768576957705771577257735774577557765777577857795780578157825783578457855786578757885789579057915792579357945795579657975798579958005801580258035804580558065807580858095810581158125813


Year ::= INTEGER (1996..2095) -- unit = Year, Range (1996..2095), resolution = 1

END

3.4.3 CPDLC message ASN.1 abstract syntax

The abstract syntax of CPDLC messages shall comply with the description contained in the ASN.1 module CPDLCMessageSetVersion1 (conforming to ISO/IEC 8824), as defined hereinafter.

Note.— The object identifier “cpdlc-message-AS-v1", as defined below, identifies the CPDLC Message Set Version 1:

cpdlc-message-AS-v1 ::= OBJECT IDENTIFIER {iso(1) identified organization(3) icao(27) user message abstract syntax(10) cpdlc(1) version1(1)

CPDLCMessageSetVersion1 DEFINITIONS::=

BEGIN

ATCUplinkMessage ::= SEQUENCE { header ATCMessageHeader, messageData ATCUplinkMessageData }

ATCUplinkMessageData ::= SEQUENCE { elementIds SEQUENCE SIZE (1..5) OF ATCUplinkMsgElementId, constrainedData SEQUENCE { routeClearanceData SEQUENCE SIZE (1..2) OF RouteClearance OPTIONAL, ... } OPTIONAL }

58145815581658175818581958205821582258235824582558265827582858295830583158325833583458355836583758385839584058415842584358445845584658475848584958505851585258535854


ATCDownlinkMessage ::= SEQUENCE { header ATCMessageHeader, messageData ATCDownlinkMessageData }

ATCDownlinkMessageData ::= SEQUENCE { elementIds SEQUENCE SIZE (1..5) OF ATCDownlinkMsgElementId, constrainedData SEQUENCE { routeClearanceData SEQUENCE SIZE (1..2) OF RouteClearance OPTIONAL, ... } OPTIONAL }

-- ------------------------------------------------------------------------------------ Uplink and Downlink messages - Common Elements-- ----------------------------------------------------------------------------------

ATCMessageHeader ::= SEQUENCE { messageIdNumber [0] MsgIdentificationNumber, messageRefNumber [1] MsgReferenceNumber OPTIONAL, dateTime [2] DateTimeGroup, logicalAck [3] LogicalAck DEFAULT notRequired }

MsgIdentificationNumber ::= INTEGER (0..63)

MsgReferenceNumber ::= INTEGER (0..63)

LogicalAck ::= ENUMERATED { required (0), notRequired (1) }-- ------------------------------------------------------------------------------------ Uplink message element -- ----------------------------------------------------------------------------------

ATCUplinkMsgElementId ::= CHOICE {-- UNABLE Urg(N)/Alr(M)/Resp(N) uM0NULL [0] NULL,

-- STANDBY Urg(N)/Alr(L)/Resp(N) uM1NULL [1] NULL,

5855585658575858585958605861586258635864586558665867586858695870587158725873587458755876587758785879588058815882588358845885588658875888588958905891589258935894589558965897589858995900590159025903590459055906


-- REQUEST DEFERRED Urg(N)/Alr(L)/Resp(N) uM2NULL [2] NULL,

-- ROGER Urg(N)/Alr(L)/Resp(N) uM3NULL [3] NULL,

-- AFFIRM Urg(N)/Alr(L)/Resp(N) uM4NULL [4] NULL,

-- NEGATIVE Urg(N)/Alr(L)/Resp(N) uM5NULL [5] NULL,

-- EXPECT [level] Urg(L)/Alr(L)/Resp(R) uM6Level [6] Level,

-- EXPECT CLIMB AT [time] Urg(L)/Alr(L)/Resp(R) uM7Time [7] Time,

-- EXPECT CLIMB AT [position] Urg(L)/Alr(L)/Resp(R) uM8Position [8] Position,

-- EXPECT DESCENT AT [time] Urg(L)/Alr(L)/Resp(R) uM9Time [9] Time,

-- EXPECT DESCENT AT [position] Urg(L)/Alr(L)/Resp(R) uM10Position [10] Position,

-- EXPECT CRUISE CLIMB AT [time] Urg(L)/Alr(L)/Resp(R) uM11Time [11] Time,

-- EXPECT CRUISE CLIMB AT [position] Urg(L)/Alr(L)/Resp(R) uM12Position [12] Position,

-- AT [time] EXPECT CLIMB TO [level] Urg(L)/Alr(L)/Resp(R) uM13TimeLevel [13] TimeLevel,

-- AT [position] EXPECT CLIMB TO [level] Urg(L)/Alr(L)/Resp(R) uM14PositionLevel [14] PositionLevel,

-- AT [time] EXPECT DESCENT TO [level] Urg(L)/Alr(L)/Resp(R) uM15TimeLevel [15] TimeLevel,

-- AT [position] EXPECT DESCENT TO [level] Urg(L)/Alr(L)/Resp(R) uM16PositionLevel [16] PositionLevel,

-- AT [time] EXPECT CRUISE CLIMB TO [level] Urg(L)/Alr(L)/Resp(R) uM17TimeLevel [17] TimeLevel,

-- AT [position] EXPECT CRUISE CLIMB TO [level] Urg(L)/Alr(L)/Resp(R) uM18PositionLevel [18] PositionLevel,

5907590859095910591159125913591459155916591759185919592059215922592359245925592659275928592959305931593259335934593559365937593859395940594159425943594459455946594759485949595059515952595359545955595659575958


-- MAINTAIN [level] Urg(N)/Alr(M)/Resp(W/U) uM19Level [19] Level,

-- CLIMB TO [level] Urg(N)/Alr(M)/Resp(W/U) uM20Level [20] Level,

-- AT [time] CLIMB TO [level] Urg(N)/Alr(M)/Resp(W/U) uM21TimeLevel [21] TimeLevel,

-- AT [position] CLIMB TO [level] Urg(N)/Alr(M)/Resp(W/U) uM22PositionLevel [22] PositionLevel,

-- DESCEND TO [level] Urg(N)/Alr(M)/Resp(W/U) uM23Level [23] Level,

-- AT [time] DESCEND TO [level] Urg(N)/Alr(M)/Resp(W/U) uM24TimeLevel [24] TimeLevel,

-- AT [position] DESCEND TO [level] Urg(N)/Alr(M)/Resp(W/U) uM25PositionLevel [25] PositionLevel,

-- CLIMB TO REACH [level] BY [time] Urg(N)/Alr(M)/Resp(W/U) uM26LevelTime [26] LevelTime,

-- CLIMB TO REACH [level] BY [position] Urg(N)/Alr(M)/Resp(W/U) uM27LevelPosition [27] LevelPosition,

-- DESCEND TO REACH [level] BY [time] Urg(N)/Alr(M)/Resp(W/U) uM28LevelTime [28] LevelTime,

-- DESCEND TO REACH [level] BY [position] Urg(N)/Alr(M)/Resp(W/U) uM29LevelPosition [29] LevelPosition,

-- MAINTAIN BLOCK [level] TO [level] Urg(N)/Alr(M)/Resp(W/U) uM30LevelLevel [30] LevelLevel,

-- CLIMB TO AND MAINTAIN BLOCK [level] TO [level] -- Urg(N)/Alr(M)/Resp(W/U) uM31LevelLevel [31] LevelLevel,

-- DESCEND TO AND MAINTAIN BLOCK [level] TO [level] -- Urg(N)/Alr(M)/Resp(W/U) uM32LevelLevel [32] LevelLevel,

-- Reserved Urg(L)/Alr(L)/Resp(Y) uM33NULL [33] NULL,

-- CRUISE CLIMB TO [level] Urg(N)/Alr(M)/Resp(W/U) uM34Level [34] Level,

-- CRUISE CLIMB ABOVE [level] Urg(N)/Alr(M)/Resp(W/U) uM35Level [35] Level,

5959596059615962596359645965596659675968596959705971597259735974597559765977597859795980598159825983598459855986598759885989599059915992599359945995599659975998599960006001600260036004600560066007600860096010


-- EXPEDITE CLIMB TO [level] Urg(U)/Alr(M)/Resp(W/U) uM36Level [36] Level,

-- EXPEDITE DESCENT TO [level] Urg(U)/Alr(M)/Resp(W/U) uM37Level [37] Level,

-- IMMEDIATELY CLIMB TO [level] Urg(D)/Alr(H)/Resp(W/U) uM38Level [38] Level,

-- IMMEDIATELY DESCEND TO [level] Urg(D)/Alr(H)/Resp(W/U) uM39Level [39] Level,



-- EXPECT TO CROSS [position] AT [level] Urg(L)/Alr(L)/Resp(R) uM42PositionLevel [42] PositionLevel,

-- EXPECT TO CROSS [position] AT OR ABOVE [level] -- Urg(L)/Alr(L)/Resp(R) uM43PositionLevel [43] PositionLevel,

-- EXPECT TO CROSS [position] AT OR BELOW [level]-- Urg(L)/Alr(L)/Resp(R) uM44PositionLevel [44] PositionLevel,

-- EXPECT TO CROSS [position] AT AND MAINTAIN [level]-- Urg(L)/Alr(L)/Resp(R) uM45PositionLevel [45] PositionLevel,

-- CROSS [position] AT [level] Urg(N)/Alr(M)/Resp(W/U) uM46PositionLevel [46] PositionLevel,

-- CROSS [position] AT OR ABOVE [level] Urg(N)/Alr(M)/Resp(W/U) uM47PositionLevel [47] PositionLevel,

-- CROSS [position] AT OR BELOW [level] Urg(N)/Alr(M)/Resp(W/U) uM48PositionLevel [48]PositionLevel,

-- CROSS [position] AT AND MAINTAIN [level] Urg(N)/Alr(M)/Resp(W/U) uM49PositionLevel [49] PositionLevel,

-- CROSS [position] BETWEEN [level] AND [level] Urg(N)/Alr(M)/Resp(W/U) uM50PositionLevelLevel [50] PositionLevelLevel,

-- CROSS [position] AT [time] Urg(N)/Alr(M)/Resp(W/U) uM51PositionTime [51] PositionTime,

6011601260136014601560166017601860196020602160226023602460256026602760286029603060316032603360346035603660376038603960406041604260436044604560466047604860496050605160526053605460556056605760586059606060616062


-- CROSS [position] AT OR BEFORE [time] Urg(N)/Alr(M)/Resp(W/U) uM52PositionTime [52] PositionTime,

-- CROSS [position] AT OR AFTER [time] Urg(N)/Alr(M)/Resp(W/U) uM53PositionTime [53] PositionTime,

-- CROSS [position] BETWEEN [time] AND [time] Urg(N)/Alr(M)/Resp(W/U) uM54PositionTimeTime [54] PositionTimeTime,

-- CROSS [position] AT [speed] Urg(N)/Alr(M)/Resp(W/U) uM55PositionSpeed [55] PositionSpeed,

-- CROSS [position] AT OR LESS THAN [speed] Urg(N)/Alr(M)/Resp(W/U) uM56PositionSpeed [56] PositionSpeed,

-- CROSS [position] AT OR GREATER THAN [speed]-- Urg(N)/Alr(M)/Resp(W/U) uM57PositionSpeed [57] PositionSpeed,

-- CROSS [position] AT [time] AT [level] Urg(N)/Alr(M)/Resp(W/U) uM58PositionTimeLevel [58] PositionTimeLevel,

-- CROSS [position] AT OR BEFORE [time] AT [level] Urg(N)/Alr(M)/Resp(W/U) uM59PositionTimeLevel [59] PositionTimeLevel,

-- CROSS [position] AT OR AFTER [time] AT [level] Urg(N)/Alr(M)/Resp(W/U) uM60PositionTimeLevel [60] PositionTimeLevel,

-- CROSS [position] AT AND MAINTAIN [level] AT [speed] -- Urg(N)/Alr(M)/Resp(W/U) uM61PositionLevelSpeed [61] PositionLevelSpeed,

-- AT [time] CROSS [position] AT AND MAINTAIN [level]-- Urg(N)/Alr(M)/Resp(W/U) uM62TimePositionLevel [62] TimePositionLevel,

-- AT [time] CROSS [position] AT AND MAINTAIN [level] AT [speed]-- Urg(N)/Alr(M)/Resp(W/U) uM63TimePositionLevelSpeed [63] TimePositionLevelSpeed,

-- OFFSET [specifiedDistance] [direction] OF ROUTE Urg(N)/Alr(M)/Resp(W/U) uM64DistanceSpecifiedDirection [64] DistanceSpecifiedDirection,

-- AT [position] OFFSET [specifiedDistance] [direction] OF ROUTE-- Urg(N)/Alr(M)/Resp(W/U) uM65PositionDistanceSpecifiedDirection [65] PositionDistanceSpecifiedDirection,

-- AT [time] OFFSET [specifiedDistance] [direction] OF ROUTE-- Urg(N)/Alr(M)/Resp(W/U) uM66TimeDistanceSpecifiedDirection [66] TimeDistanceSpecifiedDirection,

6063606460656066606760686069607060716072607360746075607660776078607960806081608260836084608560866087608860896090609160926093609460956096609760986099610061016102610361046105610661076108610961106111611261136114


-- PROCEED BACK ON ROUTE Urg(N)/Alr(M)/Resp(W/U) uM67NULL [67] NULL,

-- REJOIN ROUTE BY [position] Urg(N)/Alr(M)/Resp(W/U) uM68Position [68] Position,

-- REJOIN ROUTE BY [time] Urg(N)/Alr(M)/Resp(W/U) uM69Time [69] Time,

-- EXPECT BACK ON ROUTE BY [position] Urg(L)/Alr(L)/Resp(R) uM70Position [70] Position,

-- EXPECT BACK ON ROUTE BY [time] Urg(L)/Alr(L)/Resp(R) uM71Time [71] Time,

-- RESUME OWN NAVIGATION Urg(N)/Alr(M)/Resp(W/U) uM72NULL [72] NULL,

-- [DepartureClearance] Urg(N)/Alr(M)/Resp(W/U) uM73DepartureClearance [73] DepartureClearance,

-- PROCEED DIRECT TO [position] Urg(N)/Alr(M)/Resp(W/U) uM74Position [74] Position,

-- WHEN ABLE PROCEED DIRECT TO [position] Urg(N)/Alr(M)/Resp(W/U) uM75Position [75] Position,

-- AT [time] PROCEED DIRECT TO [position] Urg(N)/Alr(M)/Resp(W/U) uM76TimePosition [76] TimePosition,

-- AT [position] PROCEED DIRECT TO [position] Urg(N)/Alr(M)/Resp(W/U) uM77PositionPosition [77] PositionPosition,

-- AT [level] PROCEED DIRECT TO [position] Urg(N)/Alr(M)/Resp(W/U) uM78LevelPosition [78] LevelPosition,

-- CLEARED TO [position] VIA [routeClearance] Urg(N)/Alr(M)/Resp(W/U) uM79PositionRouteClearance [79] PositionRouteClearanceIndex,

-- CLEARED [routeClearance] Urg(N)/Alr(M)/Resp(W/U) uM80RouteClearance [80] RouteClearanceIndex,

-- CLEARED [procedureName] Urg(N)/Alr(M)/Resp(W/U) uM81ProcedureName [81] ProcedureName,

-- CLEARED TO DEVIATE UP TO [specifiedDistance] [direction] OF ROUTE-- Urg(N)/Alr(M)/Resp(W/U) uM82DistanceSpecifiedDirection [82] DistanceSpecifiedDirection,

-- AT [position] CLEARED [routeClearance] Urg(N)/Alr(M)/Resp(W/U) uM83PositionRouteClearance [83] PositionRouteClearanceIndex,

6115611661176118611961206121612261236124612561266127612861296130613161326133613461356136613761386139614061416142614361446145614661476148614961506151615261536154615561566157615861596160616161626163616461656166


-- AT [position] CLEARED [procedureName] Urg(N)/Alr(M)/Resp(W/U) uM84PositionProcedureName [84] PositionProcedureName,

-- EXPECT [routeClearance] Urg(L)/Alr(L)/Resp(R) uM85RouteClearance [85] RouteClearanceIndex,

-- AT [position] EXPECT [routeClearance] Urg(L)/Alr(L)/Resp(R) uM86PositionRouteClearance [86] PositionRouteClearanceIndex,

-- EXPECT DIRECT TO [position] Urg(L)/Alr(L)/Resp(R) uM87Position [87] Position,

-- AT [position] EXPECT DIRECT TO [position] Urg(L)/Alr(L)/Resp(R) uM88PositionPosition [88]PositionPosition,

-- AT [time] EXPECT DIRECT TO [position] Urg(L)/Alr(L)/Resp(R) uM89TimePosition [89] TimePosition,

-- AT [level] EXPECT DIRECT TO [position] Urg(L)/Alr(L)/Resp(R) uM90LevelPosition [90] LevelPosition,

-- HOLD AT [position] MAINTAIN [level] INBOUND TRACK [degrees][direction] -- TURNS [legtype] Urg(N)/Alr(M)/Resp(W/U) uM91HoldClearance [91] HoldClearance,

-- HOLD AT [position] AS PUBLISHED MAINTAIN [level]-- Urg(N)/Alr(M)/Resp(W/U) uM92PositionLevel [92] PositionLevel,

-- EXPECT FURTHER CLEARANCE AT [time] Urg(L)/Alr(L)/Resp(R) uM93Time [93] Time,

-- TURN [direction] HEADING [degrees] Urg(N)/Alr(M)/Resp(W/U) uM94DirectionDegrees [94] DirectionDegrees,

-- TURN [direction] GROUND TRACK [degrees] Urg(N)/Alr(M)/Resp(W/U) uM95DirectionDegrees [95] DirectionDegrees,

-- CONTINUE PRESENT HEADING Urg(N)/Alr(M)/Resp(W/U) uM96NULL [96] NULL,

-- AT [position] FLY HEADING [degrees] Urg(N)/Alr(M)/Resp(W/U) uM97PositionDegrees [97] PositionDegrees,

-- IMMEDIATELY TURN [direction] HEADING [degrees]-- Urg(D)/Alr(H)/Resp(W/U) uM98DirectionDegrees [98] DirectionDegrees,

-- EXPECT [procedureName] Urg(L)/Alr(L)/Resp(R) uM99ProcedureName [99] ProcedureName,

6167616861696170617161726173617461756176617761786179618061816182618361846185618661876188618961906191619261936194619561966197619861996200620162026203620462056206620762086209621062116212621362146215621662176218


-- AT [time] EXPECT [speed] Urg(L)/Alr(L)/Resp(R) uM100TimeSpeed [100] TimeSpeed,

-- AT [position] EXPECT [speed] Urg(L)/Alr(L)/Resp(R) uM101PositionSpeed [101] PositionSpeed,

-- AT [level] EXPECT [speed] Urg(L)/Alr(L)/Resp(R) uM102LevelSpeed [102] LevelSpeed,

-- AT [time] EXPECT [speed] TO [speed] Urg(L)/Alr(L)/Resp(R) uM103TimeSpeedSpeed [103] TimeSpeedSpeed,

-- AT [position] EXPECT [speed] TO [speed] Urg(L)/Alr(L)/Resp(R) uM104PositionSpeedSpeed [104] PositionSpeedSpeed,

-- AT [level] EXPECT [speed] TO [speed] Urg(L)/Alr(L)/Resp(R) uM105LevelSpeedSpeed [105] LevelSpeedSpeed,

-- MAINTAIN [speed] Urg(N)/Alr(M)/Resp(W/U) uM106Speed [106] Speed,

-- MAINTAIN PRESENT SPEED Urg(N)/Alr(M)/Resp(W/U) uM107NULL [107] NULL,

-- MAINTAIN [speed] OR GREATER Urg(N)/Alr(M)/Resp(W/U) uM108Speed [108] Speed,

-- MAINTAIN [speed] OR LESS Urg(N)/Alr(M)/Resp(W/U) uM109Speed [109] Speed,

-- MAINTAIN [speed] TO [speed] Urg(N)/Alr(M)/Resp(W/U) uM110SpeedSpeed [110] SpeedSpeed,

-- INCREASE SPEED TO [speed] Urg(N)/Alr(M)/Resp(W/U) uM111Speed [111] Speed,

-- INCREASE SPEED TO [speed] OR GREATER Urg(N)/Alr(M)/Resp(W/U) uM112Speed [112] Speed,

-- REDUCE SPEED TO [speed] Urg(N)/Alr(M)/Resp(W/U) uM113Speed [113] Speed,

-- REDUCE SPEED TO [speed] OR LESS Urg(N)/Alr(M)/Resp(W/U) uM114Speed [114] Speed,

-- DO NOT EXCEED [speed] Urg(N)/Alr(M)/Resp(W/U) uM115Speed [115] Speed,

-- RESUME NORMAL SPEED Urg(N)/Alr(M)/Resp(W/U) uM116NULL [116] NULL,

6219622062216222622362246225622662276228622962306231623262336234623562366237623862396240624162426243624462456246624762486249625062516252625362546255625662576258625962606261626262636264626562666267626862696270


-- CONTACT [unitname] [frequency] Urg(N)/Alr(M)/Resp(W/U) uM117UnitNameFrequency [117] UnitNameFrequency,

-- AT [position] CONTACT [unitname] [frequency] Urg(N)/Alr(M)/Resp(W/U) uM118PositionUnitNameFrequency [118] PositionUnitNameFrequency,

-- AT [time] CONTACT [unitname] [frequency] Urg(N)/Alr(M)/Resp(W/U) uM119TimeUnitNameFrequency [119] TimeUnitNameFrequency,

-- MONITOR [unitname] [frequency] Urg(N)/Alr(M)/Resp(W/U) uM120UnitNameFrequency [120] UnitNameFrequency,

-- AT [position] MONITOR [unitname] [frequency] Urg(N)/Alr(M)/Resp(W/U) uM121PositionUnitNameFrequency [121] PositionUnitNameFrequency,

-- AT [time] MONITOR [unitname] [frequency] Urg(N)/Alr(M)/Resp(W/U) uM122TimeUnitNameFrequency [122] TimeUnitNameFrequency,

-- SQUAWK [code] Urg(N)/Alr(M)/Resp(W/U) uM123Code [123] Code,

-- STOP SQUAWK Urg(N)/Alr(M)/Resp(W/U) uM124NULL [124] NULL,

-- SQUAWK MODE CHARLIE Urg(N)/Alr(M)/Resp(W/U) uM125NULL [125] NULL,

-- STOP SQUAWK MODE CHARLIE Urg(N)/Alr(M)/Resp(W/U) uM126NULL [126] NULL,

-- REPORT BACK ON ROUTE Urg(N)/Alr(L)/Resp(W/U) uM127NULL [127] NULL,

-- REPORT LEAVING [level] Urg(N)/Alr(L)/Resp(W/U) uM128Level [128] Level,

-- REPORT MAINTAINING [level] Urg(N)/Alr(L)/Resp(W/U) uM129Level [129] Level,

-- REPORT PASSING [position] Urg(N)/Alr(L)/Resp(W/U) uM130Position [130] Position,

-- REPORT REMAINING FUEL AND PERSONS ON BOARD-- Urg(U)/Alr(M)/Resp(Y) uM131NULL [131] NULL,

-- REPORT POSITION Urg(N)/Alr(M)/Resp(Y) uM132NULL [132] NULL,

-- REPORT PRESENT LEVEL Urg(N)/Alr(M)/Resp(Y) uM133NULL [133] NULL,

6271627262736274627562766277627862796280628162826283628462856286628762886289629062916292629362946295629662976298629963006301630263036304630563066307630863096310631163126313631463156316631763186319632063216322


-- REPORT [speedtype] [speedtype] [speedtype]SPEED Urg(N)/Alr(M)/Resp(Y) uM134SpeedTypeSpeedTypeSpeedType [134] SpeedTypeSpeedTypeSpeedType,

-- CONFIRM ASSIGNED LEVEL Urg(N)/Alr(L)/Resp(Y) uM135NULL [135] NULL,

-- CONFIRM ASSIGNED SPEED Urg(N)/Alr(L)/Resp(Y) uM136NULL [136] NULL,

-- CONFIRM ASSIGNED ROUTE Urg(N)/Alr(L)/Resp(Y) uM137NULL [137] NULL,

-- CONFIRM TIME OVER REPORTED WAYPOINT Urg(N)/Alr(L)/Resp(Y) uM138NULL [138] NULL,

-- CONFIRM REPORTED WAYPOINT Urg(N)/Alr(L)/Resp(Y) uM139NULL [139] NULL,

-- CONFIRM NEXT WAYPOINT Urg(N)/Alr(L)/Resp(Y) uM140NULL [140] NULL,

-- CONFIRM NEXT WAYPOINT ETA Urg(N)/Alr(L)/Resp(Y) uM141NULL [141] NULL,

-- CONFIRM ENSUING WAYPOINT Urg(N)/Alr(L)/Resp(Y) uM142NULL [142] NULL,

-- CONFIRM REQUEST Urg(N)/Alr(L)/Resp(Y) uM143NULL [143] NULL,

-- CONFIRM SQUAWK Urg(N)/Alr(L)/Resp(Y) uM144NULL [144] NULL,

-- REPORT HEADING Urg(N)/Alr(M)/Resp(Y) uM145NULL [145] NULL,

-- REPORT GROUND TRACK Urg(N)/Alr(M)/Resp(Y) uM146NULL [146] NULL,

-- REQUEST POSITION REPORT Urg(N)/Alr(M)/Resp(Y ) uM147NULL [147] NULL,

-- WHEN CAN YOU ACCEPT [level] Urg(N)/Alr(L)/Resp(Y) uM148Level [148] Level,

-- CAN YOU ACCEPT [level] AT [position] Urg(N)/Alr(L)/Resp(A/N) uM149LevelPosition [149] LevelPosition,

-- CAN YOU ACCEPT [level] AT [time] Urg(N)/Alr(L)/Resp(A/N) uM150LevelTime [150] LevelTime,

6323632463256326632763286329633063316332633363346335633663376338633963406341634263436344634563466347634863496350635163526353635463556356635763586359636063616362636363646365636663676368636963706371637263736374


-- WHEN CAN YOU ACCEPT [speed] Urg(N)/Alr(L)/Resp(Y) uM151Speed [151] Speed,

-- WHEN CAN YOU ACCEPT [specifiedDistance] [direction] OFFSET-- Urg(N)/Alr(L)/Resp(Y) uM152DistanceSpecifiedDirection [152] DistanceSpecifiedDirection,

-- ALTIMETER [altimeter] Urg(N)/Alr(L)/Resp(R) uM153Altimeter [153] Altimeter,

-- RADAR SERVICE TERMINATED Urg(N)/Alr(L)/Resp(R) uM154NULL [154] NULL,

-- RADAR CONTACT [position] Urg(N)/Alr(M)/Resp(R) uM155Position [155] Position,

-- RADAR CONTACT LOST Urg(N)/Alr(M)/Resp(R) uM156NULL [156] NULL,

-- CHECK STUCK MICROPHONE [frequency] Urg(U)/Alr(M)/Resp(N) uM157Frequency [157] Frequency,

-- ATIS [atiscode] Urg(N)/Alr(L)/Resp(R) uM158AtisCode [158] ATISCode,

-- ERROR [errorInformation] Urg(U)/Alr(M)/Resp(N) uM159ErrorInformation [159] ErrorInformation,

-- NEXT DATA AUTHORITY [facility] Urg(L)/Alr(N)/Resp(N) uM160Facility [160] Facility,

-- END SERVICE Urg(L)/Alr(N)/Resp(N) uM161NULL [161] NULL,

-- SERVICE UNAVAILABLE Urg(L)/Alr(L)/Resp(N ) uM162NULL [162] NULL,

-- [facilitydesignation] Urg(L)/Alr(N)/Resp(N) uM163FacilityDesignation [163] FacilityDesignation,

-- WHEN READY Urg(L)/Alr(N)/Resp(N) uM164NULL [164] NULL,

-- THEN Urg(L)/Alr(N)/Resp(N) uM165NULL [165] NULL,

-- DUE TO [traffictype]TRAFFIC Urg(L)/Alr(N)/Resp(N) uM166TrafficType [166] TrafficType,

-- DUE TO AIRSPACE RESTRICTION Urg(L)/Alr(N)/Resp(N) uM167NULL [167] NULL,

6375637663776378637963806381638263836384638563866387638863896390639163926393639463956396639763986399640064016402640364046405640664076408640964106411641264136414641564166417641864196420642164226423642464256426


-- DISREGARD Urg(U)/Alr(M)/Resp(R) uM168NULL [168] NULL,

-- [freetext] Urg(N)/Alr(L)/Resp(R) uM169FreeText [169] FreeText,

-- [freetext] Urg(D)/Alr(H)/Resp(R) uM170FreeText [170] FreeText,

-- CLIMB AT [verticalRate] MINIMUM Urg(N)/Alr(M)/Resp(W/U) uM171VerticalRate [171] VerticalRate,

-- CLIMB AT [verticalRate] MAXIMUM Urg(N)/Alr(M)/Resp(W/U) uM172VerticalRate [172] VerticalRate,

-- DESCEND AT [verticalRate] MINIMUM Urg(N)/Alr(M)/Resp(W/U) uM173VerticalRate [173] VerticalRate,

-- DESCEND AT [verticalRate] MAXIMUM Urg(N)/Alr(M)/Resp(W/U) uM174VerticalRate [174] VerticalRate,

-- REPORT REACHING [level] Urg(N)/Alr(L)/Resp(W/U) uM175Level [175] Level,

-- MAINTAIN OWN SEPARATION AND VMC Urg(N)/Alr(M)/Resp(W/U) uM176NULL [176] NULL,

-- AT PILOTS DISCRETION Urg(L)/Alr(L)/Resp(N) uM177NULL [177] NULL,


-- SQUAWK IDENT Urg(N)/Alr(M)/Resp(W/U) uM179NULL [179] NULL,

-- REPORT REACHING BLOCK [level] TO [level] Urg(N)/Alr(L)/Resp(W/U) uM180LevelLevel [180] LevelLevel,

-- REPORT DISTANCE [tofrom] [position] Urg(N)/Alr(M)/Resp(Y) uM181ToFromPosition [181] ToFromPosition,

-- CONFIRM ATIS CODE Urg(N)/Alr(L)/Resp(Y) uM182NULL [182] NULL,

-- [freetext] Urg(N)/Alr(M)/Resp(N) uM183FreeText [183] FreeText,

-- AT [time] REPORT DISTANCE [tofrom] [position] Urg(N)/Alr(L)/Resp(Y) uM184TimeToFromPosition [184] TimeToFromPosition,

6427642864296430643164326433643464356436643764386439644064416442644364446445644664476448644964506451645264536454645564566457645864596460646164626463646464656466646764686469647064716472647364746475647664776478


-- AFTER PASSING [position] CLIMB TO [level] Urg(N)/Alr(M)/Resp(W/U) uM185PositionLevel [185] PositionLevel,

-- AFTER PASSING [position] DESCEND TO [level] Urg(N)/Alr(M)/Resp(W/U) uM186PositionLevel [186] PositionLevel,

-- [freetext] Urg(L)/Alr(N)/Resp(N) uM187FreeText [187] FreeText,

-- AFTER PASSING [position] MAINTAIN [speed] Urg(N)/Alr(M)/Resp(W/U) uM188PositionSpeed [188] PositionSpeed,

-- ADJUST SPEED TO [speed] Urg(N)/Alr(M)/Resp(W/U) uM189Speed [189] Speed,

-- FLY HEADING [degrees] Urg(N)/Alr(M)/Resp(W/U) uM190Degrees [190] Degrees,

-- ALL ATS TERMINATED Urg(N)/Alr(M)/Resp(R) uM191NULL [191] NULL,

-- REACH [level] BY [time] Urg(N)/Alr(M)/Resp(W/U) uM192LevelTime [192] LevelTime,

-- IDENTIFICATION LOST Urg(N)/Alr(M)/Resp(R) uM193NULL [193] NULL,

-- [freetext] Urg(N)/Alr(L)/Resp(Y) uM194FreeText [194] FreeText,

-- [freetext] Urg(L)/Alr(L)/Resp(R) uM195FreeText [195] FreeText,

-- [freetext] Urg(N)/Alr(M)/Resp(W/U) uM196FreeText [196] FreeText,

-- [freetext] Urg(U)/Alr(M)/Resp(W/U) uM197FreeText [197] FreeText,

-- [freetext] Urg(D)/Alr(H)/Resp(W/U) uM198FreeText [198] FreeText,

-- [freetext] Urg(N)/Alr(L)/Resp(N) uM199FreeText [199] FreeText,

-- REPORT REACHING Urg(N)/Alr(L)/Resp(W/U) uM200NULL [200] NULL,

-- Not Used Urg(L)/Alr(L)/Resp(N) uM201NULL [201] NULL,

6479648064816482648364846485648664876488648964906491649264936494649564966497649864996500650165026503650465056506650765086509651065116512651365146515651665176518651965206521652265236524652565266527652865296530


-- Not Used Urg(L)/Alr(L)/Resp(N) uM202NULL [202] NULL,

-- [freetext] Urg(N)/Alr(M)/Resp(R) uM203FreeText [203] FreeText,

-- [freetext] Urg(N)/Alr(M)/Resp(Y) uM204FreeText [204] FreeText,

-- [freetext] Urg(N)/Alr(M)/Resp(A/N) uM205FreeText [205] FreeText,

-- [freetext] Urg(L)/Alr(N)/Resp(Y) uM206FreeText [206] FreeText,

-- [freetext] Urg(L)/Alr(L)/Resp(Y) uM207FreeText [207] FreeText,

-- [freetext] Urg(L)/Alr(L)/Resp(N) uM208FreeText [208] FreeText,

-- REACH [level] BY [position] Urg(N)/Alr(M)/Resp(W/U) uM209LevelPosition [209] LevelPosition,

-- IDENTIFIED [position] Urg(N)/Alr(M)/Resp(R) uM210Position [210] Position,

-- REQUEST FORWARDED Urg(N)/Alr(L)/Resp(N) uM211NULL [211] NULL,

-- [facilitydesignation] ATIS [atiscode] CURRENT Urg(N)/Alr(L)/Resp(R) uM212FacilityDesignationATISCode [212] FacilityDesignationATISCode,

-- [facilitydesignation] ALTIMETER [altimeter] Urg(N)/Alr(L)/Resp(R) uM213FacilityDesignationAltimeter [213] FacilityDesignationAltimeter,

-- RVR RUNWAY [runway] [rvr] Urg(N)/Alr(M)/Resp(R) uM214RunwayRVR [214] RunwayRVR,

-- TURN [direction][degrees] Urg(N)/Alr(M)/Resp(W/U) uM215DirectionDegrees [215] DirectionDegrees,

-- REQUEST FLIGHT PLAN Urg(N)/Alr(M)/Resp(Y) uM216NULL [216] NULL,

-- REPORT ARRIVAL Urg(N)/Alr(M)/Resp(Y) uM217NULL [217] NULL,

-- REQUEST ALREADY RECEIVED Urg(L)/Alr(N)/Resp(N) uM218NULL [218] NULL,

6531653265336534653565366537653865396540654165426543654465456546654765486549655065516552655365546555655665576558655965606561656265636564656565666567656865696570657165726573657465756576657765786579658065816582


-- STOP CLIMB AT [level] Urg(U)/Alr(M)/Resp(W/U) uM219Level [219] Level,

-- STOP DESCENT AT [level] Urg(U)/Alr(M)/Resp(W/U) uM220Level [220] Level,

-- STOP TURN HEADING [degrees] Urg(U)/Alr(M)/Resp(W/U) uM221Degrees [221] Degrees,

-- NO SPEED RESTRICTION Urg(L)/Alr(L)/Resp(R) uM222NULL [222] NULL,

-- REDUCE TO MINIMUM APPROACH SPEED Urg(N)/Alr(M)/Resp(W/U) uM223NULL [223] NULL,

-- NO DELAY EXPECTED Urg(N)/Alr(L)/Resp(R) uM224NULL [224] NULL,

-- DELAY NOT DETERMINED Urg(N)/Alr(L)/Resp(R) uM225NULL [225] NULL,

-- EXPECTED APPROACH TIME [time] Urg(N)/Alr(L)/Resp(R) uM226Time [226] Time,

-- LOGICAL ACKNOWLEDGEMENT Urg(N)/Alr(M)/Resp(N) uM227NULL [227] NULL,

-- REPORT ETA [position] Urg(L)/Alr(L)/Resp(Y) uM228Position [228] Position,

-- REPORT ALTERNATE AERODROME Urg(L)/Alr(L)/Resp(Y) uM229NULL [229] NULL,

-- IMMEDIATELY Urg(D)/Alr(H)/Resp(N) uM230NULL [230] NULL,

-- STATE PREFERRED LEVEL Urg(L)/Alr(L)/Resp(Y) uM231NULL [231] NULL,

-- STATE TOP OF DESCENT Urg(L)/Alr(L)/Resp(Y) uM232NULL [232] NULL,

-- USE OF LOGICAL ACKNOWLEDGEMENT PROHIBITED-- Urg(N)/Alr(M)/Resp(N) uM233NULL [233] NULL,

-- FLIGHT PLAN NOT HELD Urg(L)/Alr(L)/Resp(N) uM234NULL [234] NULL,

-- ROGER 7500 Urg(U)/Alr(H)/Resp(N) uM235NULL [235] NULL,

6583658465856586658765886589659065916592659365946595659665976598659966006601660266036604660566066607660866096610661166126613661466156616661766186619662066216622662366246625662666276628662966306631663266336634


-- LEAVE CONTROLLED AIRSPACE Urg(N)/Alr(M)/Resp(W/U) uM236NULL [236] NULL,

-- REQUEST AGAIN WITH NEXT UNIT Urg(N)/Alr(L)/Resp(N) uM237NULL [237] NULL,

... }

-------------------------------------------------------------------------------------- Downlink message element -- ----------------------------------------------------------------------------------

ATCDownlinkMsgElementId ::= CHOICE {-- WILCO Urg(N)/Alr(M)/Resp(N) dM0NULL [0] NULL,

-- UNABLE Urg(N)/Alr(M)/Resp(N) dM1NULL [1] NULL,

-- STANDBY Urg(N)/Alr(M)/Resp(N) dM2NULL [2] NULL,

-- ROGER Urg(N)/Alr(M)/Resp(N) dM3NULL [3] NULL,

-- AFFIRM Urg(N)/Alr(M)/Resp(N) dM4NULL [4] NULL,

-- NEGATIVE Urg(N)/Alr(M)/Resp(N) dM5NULL [5] NULL,

-- REQUEST [level] Urg(N)/Alr(L)/Resp(Y) dM6Level [6] Level,

-- REQUEST BLOCK [level] TO [level] Urg(N)/Alr(L)/Resp(Y) dM7LevelLevel [7] LevelLevel,

-- REQUEST CRUISE CLIMB TO [level] Urg(N)/Alr(L)/Resp(Y) dM8Level [8] Level,

-- REQUEST CLIMB TO [level] Urg(N)/Alr(L)/Resp(Y) dM9Level [9] Level,

-- REQUEST DESCENT TO [level] Urg(N)/Alr(L)/Resp(Y) dM10Level [10] Level,

-- AT [position] REQUEST CLIMB TO [level] Urg(N)/Alr(L)/Resp(Y) dM11PositionLevel [11] PositionLevel,

6635663666376638663966406641664266436644664566466647664866496650665166526653665466556656665766586659666066616662666366646665666666676668666966706671667266736674667566766677667866796680668166826683668466856686


-- AT [position] REQUEST DESCENT TO [level] Urg(N)/Alr(L)/Resp(Y) dM12PositionLevel [12] PositionLevel,

-- AT [time] REQUEST CLIMB TO [level] Urg(N)/Alr(L)/Resp(Y) dM13TimeLevel [13] TimeLevel,

-- AT [time] REQUEST DESCENT TO [level] Urg(N)/Alr(L)/Resp(Y) dM14TimeLevel [14] TimeLevel,

-- REQUEST OFFSET [specifiedDistance] [direction] OF ROUTE-- Urg(N)/Alr(L)/Resp(Y) dM15DistanceSpecifiedDirection [15] DistanceSpecifiedDirection,

-- AT [position] REQUEST OFFSET [specifiedDistance] [direction] OF ROUTE-- Urg(N)/Alr(L)/Resp(Y) dM16PositionDistanceSpecifiedDirection [16] PositionDistanceSpecifiedDirection,

-- AT [time] REQUEST OFFSET [specifiedDistance] [direction] OF ROUTE-- Urg(N)/Alr(L)/Resp(Y) dM17TimeDistanceSpecifiedDirection [17] TimeDistanceSpecifiedDirection,

-- REQUEST [speed] Urg(N)/Alr(L)/Resp(Y) dM18Speed [18] Speed,

-- REQUEST [speed] TO [speed] Urg(N)/Alr(L)/Resp(Y) dM19SpeedSpeed [19] SpeedSpeed,

-- REQUEST VOICE CONTACT Urg(N)/Alr(L)/Resp(Y) dM20NULL [20] NULL,

-- REQUEST VOICE CONTACT [frequency] Urg(N)/Alr(L)/Resp(Y) dM21Frequency [21] Frequency,

-- REQUEST DIRECT TO [position] Urg(N)/Alr(L)/Resp(Y) dM22Position [22] Position,

-- REQUEST [procedureName] Urg(N)/Alr(L)/Resp(Y) dM23ProcedureName [23] ProcedureName,

-- REQUEST CLEARANCE [routeClearance] Urg(N)/Alr(L)/Resp(Y) dM24RouteClearance [24] RouteClearanceIndex,

-- REQUEST [clearanceType] CLEARANCE Urg(N)/Alr(L)/Resp(Y) dM25ClearanceType [25] ClearanceType,

-- REQUEST WEATHER DEVIATION TO [position] VIA [routeClearance]-- Urg(N)/Alr(M)/Resp(Y) dM26PositionRouteClearance [26] PositionRouteClearanceIndex,

-- REQUEST WEATHER DEVIATION UP TO [specifiedDistance] [direction] OF ROUTE-- Urg(N)/Alr(M)/Resp(Y) dM27DistanceSpecifiedDirection [27] DistanceSpecifiedDirection,

6687668866896690669166926693669466956696669766986699670067016702670367046705670667076708670967106711671267136714671567166717671867196720672167226723672467256726672767286729673067316732673367346735673667376738


-- LEAVING [level] Urg(N)/Alr(L)/Resp(N) dM28Level [28] Level,

-- CLIMBING TO [level] Urg(N)/Alr(L)/Resp(N) dM29Level [29]Level,

-- DESCENDING TO [level] Urg(N)/Alr(L)/Resp(N) dM30Level [30] Level,

-- PASSING [position] Urg(N)/Alr(L)/Resp(N) dM31Position [31] Position,

-- PRESENT LEVEL [level] Urg(N)/Alr(L)/Resp(N) dM32Level [32] Level,

-- PRESENT POSITION [position] Urg(N)/Alr(L)/Resp(N) dM33Position [33] Position,

-- PRESENT SPEED [speed] Urg(N)/Alr(L)/Resp(N) dM34Speed [34] Speed,

-- PRESENT HEADING [degrees] Urg(N)/Alr(L)/Resp(N) dM35Degrees [35] Degrees,

-- PRESENT GROUND TRACK [degrees] Urg(N)/Alr(L)/Resp(N) dM36Degrees [36] Degrees,

-- MAINTAINING [level] Urg(N)/Alr(L)/Resp(N) dM37Level [37] Level,

-- ASSIGNED LEVEL [level] Urg(N)/Alr(M)/Resp(N) dM38Level [38] Level,

-- ASSIGNED SPEED [speed] Urg(N)/Alr(M)/Resp(N) dM39Speed [39] Speed,

-- ASSIGNED ROUTE [routeClearance] Urg(N)/Alr(M)/Resp(N) dM40RouteClearance [40] RouteClearanceIndex,

-- BACK ON ROUTE Urg(N)/Alr(M)/Resp(N) dM41NULL [41] NULL,

-- NEXT WAYPOINT [position] Urg(N)/Alr(L)/Resp(N) dM42Position [42] Position,

-- NEXT WAYPOINT ETA [time] Urg(N)/Alr(L)/Resp(N) dM43Time [43] Time,

-- ENSUING WAYPOINT [position] Urg(N)/Alr(L)/Resp(N) dM44Position [44] Position,

6739674067416742674367446745674667476748674967506751675267536754675567566757675867596760676167626763676467656766676767686769677067716772677367746775677667776778677967806781678267836784678567866787678867896790


-- REPORTED WAYPOINT [position] Urg(N)/Alr(L)/Resp(N) dM45Position [45] Position,

-- REPORTED WAYPOINT [time] Urg(N)/Alr(L)/Resp(N) dM46Time [46] Time,

-- SQUAWKING [code] Urg(N)/Alr(L)/Resp(N) dM47Code [47] Code,

-- POSITION REPORT [positionreport] Urg(N)/Alr(M)/Resp(N) dM48PositionReport [48] PositionReport,

-- WHEN CAN WE EXPECT [speed] Urg(L)/Alr(L)/Resp(Y) dM49Speed [49] Speed,

-- WHEN CAN WE EXPECT [speed] TO [speed] Urg(L)/Alr(L)/Resp(Y) dM50SpeedSpeed [50] SpeedSpeed,

-- WHEN CAN WE EXPECT BACK ON ROUTE Urg(L)/Alr(L)/Resp(Y) dM51NULL [51] NULL,

-- WHEN CAN WE EXPECT LOWER LEVEL Urg(L)/Alr(L)/Resp(Y) dM52NULL [52] NULL,

-- WHEN CAN WE EXPECT HIGHER LEVEL Urg(L)/Alr(L)/Resp(Y) dM53NULL [53] NULL,

-- WHEN CAN WE EXPECT CRUISE CLIMB TO [level]-- Urg(L)/Alr(L)/Resp(Y) dM54Level [54] Level,

-- PAN PAN PAN Urg(U)/Alr(H)/Resp(Y) dM55NULL [55] NULL,

-- MAYDAY MAYDAY MAYDAY Urg(D)/Alr(H)/Resp(Y) dM56NULL [56] NULL,

-- [remainingFuel] OF FUEL REMAINING AND [personsonboard] PERSONS ON BOARD-- Urg(U)/Alr(H)/Resp(Y) dM57RemainingFuelPersonsOnBoard [57] RemainingFuelPersonsOnBoard,

-- CANCEL EMERGENCY Urg(U)/Alr(M)/Resp(Y) dM58NULL [58] NULL,

-- DIVERTING TO [position] VIA [routeClearance] Urg(U)/Alr(H)/Resp(Y) dM59PositionRouteClearance [59] PositionRouteClearanceIndex,

-- OFFSETTING [specifiedDistance] [direction] OF ROUTE Urg(U)/Alr(H)/Resp(Y) dM60DistanceSpecifiedDirection [60] DistanceSpecifiedDirection,

-- DESCENDING TO [level] Urg(U)/Alr(H)/Resp(Y) dM61Level [61] Level,

6791679267936794679567966797679867996800680168026803680468056806680768086809681068116812681368146815681668176818681968206821682268236824682568266827682868296830683168326833683468356836683768386839684068416842


-- ERROR [errorInformation] Urg(U)/Alr(L)/Resp(N) dM62ErrorInformation [62] ErrorInformation,

-- NOT CURRENT DATA AUTHORITY Urg(L)/Alr(L)/Resp(N) dM63NULL [63] NULL,

-- [facilitydesignation] Urg(L)/Alr(L)/Resp(N) dM64FacilityDesignation [64] FacilityDesignation,

-- DUE TO WEATHER Urg(L)/Alr(L)/Resp(N) dM65NULL [65] NULL,

-- DUE TO AIRCRAFT PERFORMANCE Urg(L)/Alr(L)/Resp(N) dM66NULL [66] NULL,

-- [freetext] Urg(N)/Alr(L)/Resp(N) dM67FreeText [67] FreeText,

-- [freetext] Urg(D)/Alr(H)/Resp(Y) dM68FreeText [68] FreeText,

-- REQUEST VMC DESCENT Urg(N)/Alr(L)/Resp(Y) dM69NULL [69] NULL,

-- REQUEST HEADING [degrees] Urg(N)/Alr(L)/Resp(Y) dM70Degrees [70] Degrees,

-- REQUEST GROUND TRACK [degrees] Urg(N)/Alr(L)/Resp(Y) dM71Degrees [71] Degrees,

-- REACHING [level] Urg(N)/Alr(L)/Resp(N) dM72Level [72] Level,

-- [versionnumber] Urg(L)/Alr(L)/Resp(N) dM73Versionnumber [73] VersionNumber,

-- REQUEST TO MAINTAIN OWN SEPARATION AND VMC-- Urg(L)/Alr(L)/Resp(Y) dM74NULL [74] NULL,

-- AT PILOTS DISCRETION Urg(L)/Alr(L)/Resp(N) dM75NULL [75] NULL,

-- REACHING BLOCK [level] TO [level] Urg(N)/Alr(L)/Resp(N) dM76LevelLevel [76] LevelLevel,

-- ASSIGNED BLOCK [level] TO [level] Urg(N)/Alr(M)/Resp(N) dM77LevelLevel [77] LevelLevel,

-- AT [time] [distance] [tofrom] [position] Urg(N)/Alr(L)/Resp(N) dM78TimeDistanceToFromPosition [78] TimeDistanceToFromPosition,

6843684468456846684768486849685068516852685368546855685668576858685968606861686268636864686568666867686868696870687168726873687468756876687768786879688068816882688368846885688668876888688968906891689268936894


-- ATIS [atiscode] Urg(N)/Alr(L)/Resp(N) dM79AtisCode [79] ATISCode,

-- DEVIATING UP TO [specifiedDistance] [direction] OF ROUTE-- Urg(U)/Alr(H)/Resp(Y) dM80DistanceSpecifiedDirection [80] DistanceSpecifiedDirection,

-- WE CAN ACCEPT [level] AT [time] Urg(L)/Alr(L)/Resp(N) dM81LevelTime [81] LevelTime,

-- WE CANNOT ACCEPT [level] Urg(L)/Alr(L)/Resp(N) dM82Level [82] Level,

-- WE CAN ACCEPT [speed] AT [time] Urg(L)/Alr(L)/Resp(N) dM83SpeedTime [83] SpeedTime,

-- WE CANNOT ACCEPT [speed] Urg(L)/Alr(L)/Resp(N) dM84Speed [84] Speed,

-- WE CAN ACCEPT [specifiedDistance] [direction] AT [time]-- Urg(L)/Alr(L)/Resp(N) dM85DistanceSpecifiedDirectionTime [85] DistanceSpecifiedDirectionTime,

-- WE CANNOT ACCEPT [specifiedDistance] [direction] Urg(L)/Alr(L)/Resp(N) dM86DistanceSpecifiedDirection [86] DistanceSpecifiedDirection,

-- WHEN CAN WE EXPECT CLIMB TO [level] Urg(L)/Alr(L)/Resp(Y) dM87Level [87] Level,

-- WHEN CAN WE EXPECT DESCENT TO [level] Urg(L)/Alr(L)/Resp(Y) dM88Level [88] Level,

-- MONITORING [unitname] [frequency] Urg(U)/Alr(M)/Resp(N) dM89UnitnameFrequency [89] UnitNameFrequency,

-- [freetext] Urg(N)/Alr(M)/Resp(N) dM90FreeText [90] FreeText,

-- [freetext] Urg(N)/Alr(L)/Resp(Y) dM91FreeText [91] FreeText,

-- [freetext] Urg(L)/Alr(L)/Resp(Y) dM92FreeText [92] FreeText,

-- [freetext] Urg(U)/Alr(H)/Resp(N) dM93FreeText [93] FreeText,

-- [freetext] Urg(D)/Alr(H)/Resp(N) dM94FreeText [94] FreeText,

-- [freetext] Urg(U)/Alr(M)/Resp(N) dM95FreeText [95] FreeText,

6895689668976898689969006901690269036904690569066907690869096910691169126913691469156916691769186919692069216922692369246925692669276928692969306931693269336934693569366937693869396940694169426943694469456946


-- [freetext] Urg(U)/Alr(L)/Resp(N) dM96FreeText [96] FreeText,

-- [freetext] Urg(L)/Alr(L)/Resp(N) dM97FreeText [97] FreeText,

-- [freetext] Urg(N)/Alr(N)/Resp(N) dM98FreeText [98] FreeText,

-- CURRENT DATA AUTHORITY Urg(L)/Alr(L)/Resp(N) dM99NULL [99] NULL,

-- LOGICAL ACKNOWLEDGEMENT Urg(N)/Alr(M)/Resp(N) dM100NULL [100] NULL,

-- REQUEST END OF SERVICE Urg(L)/Alr(L)/Resp(Y) dM101NULL [101] NULL,

-- LANDING REPORT Urg(N)/Alr(N)/Resp(N) dM102NULL [102] NULL,

-- CANCELLING IFR Urg(N)/Alr(L)/Resp(Y) dM103NULL [103] NULL,

-- ETA[position][time] Urg(L)/Alr(L)/Resp(N) dM104PositionTime [104] PositionTime,

-- ALTERNATE AERODROME[airport] Urg(L)/Alr(L)/Resp(N) dM105Airport [105] Airport,

-- PREFERRED LEVEL[level] Urg(L)/Alr(L)/Resp(N) dM106Level [106] Level,

-- NOT AUTHORIZED NEXT DATA AUTHORITY Urg(L)/Alr(L)/Resp(N) dM107NULL [107] NULL,

-- DE-ICING COMPLETE Urg(L)/Alr(L)/Resp(N) dM108NULL [108] NULL,

-- TOP OF DESCENT [time] Urg(L)/Alr(L)/Resp(N) dM109Time [109] Time,

-- TOP OF DESCENT [position] Urg(L)/Alr(L)/Resp(N) dM110Position [110] Position,

-- TOP OF DESCENT [time] [position] Urg(L)/Alr(L)/Resp(N) dM111TimePosition [111] TimePosition,

-- SQUAWKING 7500 Urg(U)/Alr(H)/Resp(N) dM112NULL [112] NULL,

6947694869496950695169526953695469556956695769586959696069616962696369646965696669676968696969706971697269736974697569766977697869796980698169826983698469856986698769886989699069916992699369946995699669976998


-- [speedType] [speedType] [speedType] SPEED [speed] Urg(N)/Alr(L)/Resp(N) dM113SpeedTypeSpeedTypeSpeedTypeSpeed [113]SpeedTypeSpeedTypeSpeedTypeSpeed, ... }

AircraftAddress ::= BIT STRING (SIZE(24))

AircraftFlightIdentification ::= IA5String (SIZE (2..8))

Airport ::= IA5String (SIZE (4))

Altimeter ::= CHOICE { altimeterEnglish [0] AltimeterEnglish, altimeterMetric [1] AltimeterMetric }

AltimeterEnglish ::= INTEGER (2200..3200) -- unit = Inches Mercury, Range (22.00 .. 32.00), resolution = 0.01

AltimeterMetric ::= INTEGER (7500..12500) -- unit = Hectopascal, Range (750.0..1250.0), resolution = 0.1

ATISCode ::= IA5String (SIZE (1))

ATSRouteDesignator ::= IA5String (SIZE (2..7))

ATWAlongTrackWaypoint ::= SEQUENCE { position [0] Position, aTWDistance [1] ATWDistance, speed [2] Speed OPTIONAL, aTWLevels [3] ATWLevelSequence OPTIONAL }

ATWLevel ::= SEQUENCE { atw ATWLevelTolerance, level Level }

ATWLevelSequence ::= SEQUENCE SIZE (1..2) OF ATWLevel

ATWLevelTolerance ::= ENUMERATED { at (0), atorabove (1), atorbelow (2) }

6999700070017002700370047005700670077008700970107011701270137014701570167017701870197020702170227023702470257026702770287029703070317032703370347035703670377038703970407041704270437044704570467047704870497050


ATWDistance ::= SEQUENCE { atwDistanceTolerance ATWDistanceTolerance, distance Distance }

ATWDistanceTolerance ::= ENUMERATED { plus (0), minus (1) }

ClearanceType ::= ENUMERATED { noneSpecified (0), approach (1), departure (2), further (3), start-up (4), pushback (5), taxi (6), take-off (7), landing (8), oceanic (9), en-route (10), downstream (11), ... }

Code ::= SEQUENCE SIZE (4) OF CodeOctalDigit

CodeOctalDigit ::= INTEGER (0..7)

ControlledTime ::= SEQUENCE { time Time, timeTolerance TimeTolerance }

Date ::= SEQUENCE { year Year, month Month, day Day }

DateTimeGroup ::= SEQUENCE { date Date, timehhmmss Timehhmmss }

7051705270537054705570567057705870597060706170627063706470657066706770687069707070717072707370747075707670777078707970807081708270837084708570867087708870897090709170927093709470957096709770987099710071017102


Day ::= INTEGER (1..31) --unit = Day, Range (1..31), resolution = 1

DegreeIncrement ::= INTEGER (1..20) --unit = Degree, Range (1..20), resolution = 1

Degrees ::= CHOICE { degreesMagnetic [0] DegreesMagnetic, degreesTrue [1] DegreesTrue }

DegreesMagnetic ::= INTEGER (1..360) --unit = degree, Range (1..360), resolution = 1

DegreesTrue ::= INTEGER (1..360) --unit = degree, Range (1..360), resolution = 1DepartureClearance ::= SEQUENCE { aircraftFlightIdentification [0] AircraftFlightIdentification, clearanceLimit [1] Position, flightInformation [2] FlightInformation OPTIONAL, furtherInstructions [3] FurtherInstructions OPTIONAL }

DepartureMinimumInterval ::= INTEGER (1..150) --unit = Minute, Range (0.1..15.0), resolution = 0.1

Direction ::= ENUMERATED { left (0), right (1), eitherSide (2), north (3), south (4), east (5), west (6), northEast (7), northWest (8), southEast (9), southWest (10) }

DirectionDegrees ::= SEQUENCE { direction Direction, degrees Degrees }

71037104710571067107710871097110711171127113711471157116711771187119712071217122712371247125712671277128712971307131713271337134713571367137713871397140714171427143714471457146714771487149715071517152


Distance ::= CHOICE { distanceNm [0] DistanceNm, distanceKm [1] DistanceKm }

DistanceKm ::= INTEGER (0..8000) -- unit = Kilometer, Range (0..2000), resolution = 0.25

DistanceNm ::= INTEGER (0..9999) -- unit = Nautical Mile, Range (0..999.9), resolution = 0.1

DistanceSpecified ::= CHOICE { distanceSpecifiedNm [0] DistanceSpecifiedNm, distanceSpecifiedKm [1] DistanceSpecifiedKm }

DistanceSpecifiedDirection ::= SEQUENCE { distanceSpecified DistanceSpecified, direction Direction }

DistanceSpecifiedDirectionTime ::= SEQUENCE { distanceSpecifiedDirection DistanceSpecifiedDirection, time Time }

DistanceSpecifiedKm ::= INTEGER (1..500) -- unit = Kilometer, Range (1..500), resolution = 1

DistanceSpecifiedNm ::= INTEGER (1..250) -- unit = Nautical Mile, Range (1..250), resolution = 1

ErrorInformation ::= ENUMERATED { unrecognizedMsgReferenceNumber (0), logicalACKNOWLEDGEMENTNotAccepted (1), insufficientResources (2), invalidMessageElementCombination (3), invalidMessageElement (4), ... }

Facility ::= CHOICE { noFacility [0] NULL, facilityDesignation [1] FacilityDesignation }

7153715471557156715771587159716071617162716371647165716671677168716971707171717271737174717571767177717871797180718171827183718471857186718771887189719071917192719371947195719671977198719972007201720272037204


FacilityDesignation ::= IA5String (SIZE (4..8))

FacilityFunction ::= ENUMERATED { center (0), approach (1), tower (2), final (3), groundControl (4), clearanceDelivery (5), departure (6), control (7), radio (8), ... }

FacilityDesignationAltimeter ::= SEQUENCE { facilityDesignation FacilityDesignation, altimeter Altimeter }

FacilityDesignationATISCode ::= SEQUENCE { facilityDesignation FacilityDesignation, aTISCode ATISCode }

FacilityName ::= IA5String (SIZE (3..18))

Fix ::= IA5String (SIZE (1..5))

FixName ::= SEQUENCE { name [0] Fix, latlon [1] LatitudeLongitude OPTIONAL }

FlightInformation ::= CHOICE { routeOfFlight [0] RouteInformation, levelsOfFlight [1] LevelsOfFlight, routeAndLevels [2] RouteAndLevels }

FreeText ::= IA5String (SIZE (1..256))

Frequency ::= CHOICE { frequencyhf [0] Frequencyhf, frequencyvhf [1] Frequencyvhf,

7205720672077208720972107211721272137214721572167217721872197220722172227223722472257226722772287229723072317232723372347235723672377238723972407241724272437244724572467247724872497250725172527253725472557256


frequencyuhf [2] Frequencyuhf, frequencysatchannel [3] Frequencysatchannel }

Frequencyhf ::= INTEGER (2850..28000)-- unit = Kilohertz, Range (2850..28000), resolution = 1

Frequencysatchannel ::= NumericString (SIZE (12)) -- Frequencysatchannel corresponds to a 12-digit telephone number

Frequencyuhf ::= INTEGER (9000..15999) -- unit = Megahertz, Range (225.000..399.975), resolution = 0.025

Frequencyvhf ::= INTEGER (23600..27398) -- unit = Megahertz, Range (118.000..136.990), resolution = 0.005

FurtherInstructions ::= SEQUENCE { code [0] Code OPTIONAL, frequencyDeparture [1] UnitNameFrequency OPTIONAL, clearanceExpiryTime [2] Time OPTIONAL, airportDeparture [3] Airport OPTIONAL, airportDestination [4] Airport OPTIONAL, timeDeparture [5] TimeDeparture OPTIONAL, runwayDeparture [6] Runway OPTIONAL, revisionNumber [7] RevisionNumber OPTIONAL, aTISCode [8] ATISCode OPTIONAL }

Holdatwaypoint ::= SEQUENCE { position [0] Position, holdatwaypointspeedlow [1] Speed OPTIONAL, aTWlevel [2] ATWLevel OPTIONAL, holdatwaypointspeedhigh [3] Speed OPTIONAL, direction [4] Direction OPTIONAL, degrees [5] Degrees OPTIONAL, eFCtime [6] Time OPTIONAL, legtype [7] LegType OPTIONAL }

HoldClearance ::= SEQUENCE { position [0] Position, level [1] Level, degrees [2] Degrees, direction [3] Direction, legType [4] LegType OPTIONAL }

Humidity ::= INTEGER (0..100)-- unit = Percent humidity, Range (0..100), resolution = 1

7257725872597260726172627263726472657266726772687269727072717272727372747275727672777278727972807281728272837284728572867287728872897290729172927293729472957296729772987299730073017302730373047305730673077308


InterceptCourseFrom ::= SEQUENCE { fromSelection InterceptCourseFromSelection, degrees Degrees }

InterceptCourseFromSelection ::= CHOICE { publishedIdentifier [0] PublishedIdentifier, latitudeLongitude [1] LatitudeLongitude, placeBearingPlaceBearing [2] PlaceBearingPlaceBearing, placeBearingDistance [3] PlaceBearingDistance }

Icing ::= ENUMERATED { reserved (0), light (1), moderate (2), severe (3) }

Latitude ::= SEQUENCE { latitudeType LatitudeType, latitudeDirection LatitudeDirection }

LatitudeDegrees ::= INTEGER (0..90000) -- unit = Degree, Range (0..90), resolution = 0.001

LatitudeDegreesMinutes ::= SEQUENCE { latitudeWholeDegrees LatitudeWholeDegrees, minutesLatLon MinutesLatLon }

LatitudeDegreesMinutesSeconds ::= SEQUENCE { latitudeWholeDegrees LatitudeWholeDegrees, latlonWholeMinutes LatLonWholeMinutes, secondsLatLon SecondsLatLon }

LatitudeDirection ::= ENUMERATED { north (0), south (1) }

LatitudeWholeDegrees ::= INTEGER (0..89) -- unit = Degree, Range (0..89), resolution = 1

7309731073117312731373147315731673177318731973207321732273237324732573267327732873297330733173327333733473357336733773387339734073417342734373447345734673477348734973507351735273537354735573567357735873597360


LatitudeLongitude ::= SEQUENCE { latitude [0] Latitude OPTIONAL, longitude [1] Longitude OPTIONAL }

LatitudeReportingPoints ::= SEQUENCE { latitudeDirection LatitudeDirection, latitudeDegrees LatitudeDegrees }

LatitudeType ::= CHOICE { latitudeDegrees [0] LatitudeDegrees, latitudeDegreesMinutes [1] LatitudeDegreesMinutes, latitudeDMS [2] LatitudeDegreesMinutesSeconds }

LatLonWholeMinutes ::= INTEGER (0..59) -- unit = Minute, Range (0..59), resolution = 1

LatLonReportingPoints ::= CHOICE { latitudeReportingPoints [0] LatitudeReportingPoints, longitudeReportingPoints [1] LongitudeReportingPoints }

LegDistance ::= CHOICE { legDistanceEnglish [0] LegDistanceEnglish, legDistanceMetric [1] LegDistanceMetric }

LegDistanceEnglish ::= INTEGER (0..50) -- unit = Nautical Mile, Range (0..50), resolution = 1

LegDistanceMetric ::= INTEGER (1..128) -- unit = Kilometer, Range (1..128), resolution = 1

LegTime ::= INTEGER (0..10) --unit = Minute, Range (0..10), resolution = 1

LegType ::= CHOICE { legDistance [0] LegDistance, legTime [1] LegTime }

73617362736373647365736673677368736973707371737273737374737573767377737873797380738173827383738473857386738773887389739073917392739373947395739673977398739974007401740274037404740574067407740874097410


Level ::= CHOICE { singleLevel [0] LevelType, blockLevel [1] SEQUENCE SIZE (2) OF LevelType }

LevelFeet ::= INTEGER (-60..7000) --unit = Feet, Range (-600..70000), resolution = 10

LevelFlightLevel ::= INTEGER (30..700) --unit = Level (100 Feet), Range (030..700), resolution = 1

LevelFlightLevelMetric ::= INTEGER (100..2500) --unit = Level (10 Meters), Range (100..2500), resolution = 1

LevelLevel ::= SEQUENCE SIZE (2) OF Level

LevelMeters ::= INTEGER (-30..25000) --unit = Meter, Range (-30..25000), resolution = 1

LevelPosition ::= SEQUENCE { level Level, position Position }

LevelProcedureName ::= SEQUENCE { level Level, procedureName ProcedureName }

LevelsOfFlight ::= CHOICE { level [0] Level, procedureName [1] ProcedureName, levelProcedureName [2] LevelProcedureName }

LevelSpeed ::= SEQUENCE { level Level, speed Speed }

LevelSpeedSpeed ::= SEQUENCE { level Level, speeds SpeedSpeed }

7411741274137414741574167417741874197420742174227423742474257426742774287429743074317432743374347435743674377438743974407441744274437444744574467447744874497450745174527453745474557456745774587459746074617462


LevelTime ::= SEQUENCE { level Level, time Time } LevelType ::= CHOICE { levelFeet [0] LevelFeet, levelMeters [1] LevelMeters, levelFlightLevel [2] LevelFlightLevel, levelFlightLevelMetric [3] LevelFlightLevelMetric }

Longitude ::= SEQUENCE { longitudeType LongitudeType, longitudeDirection LongitudeDirection }

LongitudeDegrees ::= INTEGER (0..180000) --unit = Degree, Range (0..180), resolution = 0.001

LongitudeDegreesMinutes ::= SEQUENCE { longitudeWholeDegrees LongitudeWholeDegrees, minutesLatLon MinutesLatLon }

LongitudeDegreesMinutesSeconds ::= SEQUENCE { longitudeWholeDegrees LongitudeWholeDegrees, latLonWholeMinutes LatLonWholeMinutes, secondsLatLon SecondsLatLon }

LongitudeDirection ::= ENUMERATED { east (0), west (1) }

LongitudeWholeDegrees ::= INTEGER (0..179) -- unit = Degree, Range (0..179), resolution = 1

LongitudeReportingPoints ::= SEQUENCE { longitudeDirection LongitudeDirection, longitudeDegrees LongitudeDegrees }

7463746474657466746774687469747074717472747374747475747674777478747974807481748274837484748574867487748874897490749174927493749474957496749774987499750075017502750375047505750675077508750975107511751275137514


LongitudeType ::= CHOICE { longitudeDegrees [0] LongitudeDegrees, longitudeDegreesMinutes [1] LongitudeDegreesMinutes, longitudeDMS [2] LongitudeDegreesMinutesSeconds }

MinutesLatLon ::= INTEGER (0..5999) --unit = Minute, Range (0..59.99), resolution = 0.01

Month ::= INTEGER (1..12) --unit = 1 Month, Range (1..12), resolution = 1

Navaid ::= SEQUENCE { name [0] NavaidName, latlon [1] LatitudeLongitude OPTIONAL }

NavaidName ::= IA5String (SIZE (1..4))

PersonsOnBoard ::= INTEGER (1..1024)

PlaceBearing ::= SEQUENCE { publishedIdentifier PublishedIdentifier, degrees Degrees }

PlaceBearingDistance ::= SEQUENCE { publishedIdentifier PublishedIdentifier, degrees Degrees, distance Distance }

PlaceBearingPlaceBearing ::= SEQUENCE SIZE (2) OF PlaceBearing

Position ::= CHOICE { fixName [0] FixName, navaid [1] Navaid, airport [2] Airport, latitudeLongitude [3] LatitudeLongitude, placeBearingDistance [4] PlaceBearingDistance }

PositionDegrees ::= SEQUENCE { position Position, degrees Degrees }

7515751675177518751975207521752275237524752575267527752875297530753175327533753475357536753775387539754075417542754375447545754675477548754975507551755275537554755575567557755875597560756175627563756475657566


PositionDistanceSpecifiedDirection ::= SEQUENCE { position Position, distanceSpecifiedDirection DistanceSpecifiedDirection }

PositionLevel ::= SEQUENCE { position Position, level Level }

PositionLevelLevel ::= SEQUENCE { position Position, levels LevelLevel }

PositionLevelSpeed ::= SEQUENCE { positionlevel PositionLevel, speed Speed }

PositionPosition ::= SEQUENCE SIZE (2) OF Position

PositionProcedureName ::= SEQUENCE { position Position, procedureName ProcedureName }

PositionReport ::= SEQUENCE { positioncurrent [0] Position, timeatpositioncurrent [1] Time, level [2] Level, fixnext [3] Position OPTIONAL, timeetaatfixnext [4] Time OPTIONAL, fixnextplusone [5] Position OPTIONAL, timeetaatdestination [6] Time OPTIONAL, remainingFuel [7] RemainingFuel OPTIONAL, temperature [8] Temperature OPTIONAL, winds [9] Winds OPTIONAL, turbulence [10] Turbulence OPTIONAL, icing [11] Icing OPTIONAL, speed [12] Speed OPTIONAL, speedground [13] SpeedGround OPTIONAL, verticalChange [14] VerticalChange OPTIONAL, trackAngle [15] Degrees OPTIONAL, heading [16] Degrees OPTIONAL, distance [17] Distance OPTIONAL,

7567756875697570757175727573757475757576757775787579758075817582758375847585758675877588758975907591759275937594759575967597759875997600760176027603760476057606760776087609761076117612761376147615761676177618


humidity [18] Humidity OPTIONAL, reportedWaypointPosition [19] Position OPTIONAL, reportedWaypointTime [20] Time OPTIONAL, reportedWaypointLevel [21] Level OPTIONAL }

PositionRouteClearanceIndex ::= SEQUENCE { position Position, routeClearanceIndex RouteClearanceIndex }

PositionSpeed ::= SEQUENCE { position Position, speed Speed }

PositionSpeedSpeed ::= SEQUENCE { position Position, speeds SpeedSpeed }

PositionTime ::= SEQUENCE { position Position, time Time }

PositionTimeLevel ::= SEQUENCE { positionTime PositionTime, level Level }

PositionTimeTime ::= SEQUENCE { position Position, times TimeTime }

PositionUnitNameFrequency ::= SEQUENCE { position Position, unitname UnitName, frequency Frequency }

Procedure ::= IA5String (SIZE (1..20))

7619762076217622762376247625762676277628762976307631763276337634763576367637763876397640764176427643764476457646764776487649765076517652765376547655765676577658765976607661766276637664766576667667766876697670


ProcedureName ::= SEQUENCE { type [0] ProcedureType, procedure [1] Procedure, transition [2] ProcedureTransition OPTIONAL }

ProcedureTransition ::= IA5String (SIZE (1..5))

ProcedureType ::= ENUMERATED { arrival (0), approach (1), departure (2) }

PublishedIdentifier ::= CHOICE { fixName [0] FixName, navaid [1] Navaid }

RemainingFuel ::= Time

RemainingFuelPersonsOnBoard ::= SEQUENCE { remainingFuel RemainingFuel, personsOnBoard PersonsOnBoard }

ReportingPoints ::= SEQUENCE { latLonReportingPoints [0] LatLonReportingPoints, degreeIncrement [1] DegreeIncrement OPTIONAL }

RevisionNumber ::= INTEGER (1..16)

RouteAndLevels ::= SEQUENCE { routeOfFlight RouteInformation, levelsOfFlight LevelsOfFlight }

RouteClearance ::= SEQUENCE { airportDeparture [0] Airport OPTIONAL, airportDestination [1] Airport OPTIONAL, runwayDeparture [2] Runway OPTIONAL, procedureDeparture [3] ProcedureName OPTIONAL, runwayArrival [4] Runway OPTIONAL,

7671767276737674767576767677767876797680768176827683768476857686768776887689769076917692769376947695769676977698769977007701770277037704770577067707770877097710771177127713771477157716771777187719772077217722


procedureApproach [5] ProcedureName OPTIONAL, procedureArrival [6] ProcedureName OPTIONAL, routeInformations [7] SEQUENCE SIZE (1..128) OF RouteInformation OPTIONAL, routeInformationAdditional [8] RouteInformationAdditional OPTIONAL }

RouteClearanceIndex ::= INTEGER (1..2) -- RouteClearanceIndex identifies the position of the RouteClearance data -- in the ASN.1 type for -- ATC UplinkMessage, constrained Data, routeClearance Data -- ATC DownlinkMessage, constrained Data, routeClearance Data

RouteInformation ::= CHOICE { publishedIdentifier [0] PublishedIdentifier, latitudeLongitude [1] LatitudeLongitude, placeBearingPlaceBearing [2] PlaceBearingPlaceBearing, placeBearingDistance [3] PlaceBearingDistance, aTSRouteDesignator [4] ATSRouteDesignator }

RouteInformationAdditional ::= SEQUENCE { aTWAlongTrackWaypoints [0] SEQUENCE SIZE (1..8) OF ATWAlongTrackWaypoint OPTIONAL, reportingpoints [1] ReportingPoints OPTIONAL, interceptCourseFroms [2] SEQUENCE SIZE (1..4) OF InterceptCourseFrom OPTIONAL, holdAtWaypoints [3] SEQUENCE SIZE (1..8) OF Holdatwaypoint OPTIONAL, waypointSpeedLevels [4] SEQUENCE SIZE (1..32) OF WaypointSpeedLevel OPTIONAL, rTARequiredTimeArrivals [5] SEQUENCE SIZE (1..32) OF RTARequiredTimeArrival OPTIONAL }

RTARequiredTimeArrival ::= SEQUENCE { position [0] Position, rTATime [1] RTATime, rTATolerance [2] RTATolerance OPTIONAL }

RTATime ::= SEQUENCE { time Time, timeTolerance TimeTolerance }

7723772477257726772777287729773077317732773377347735773677377738773977407741774277437744774577467747774877497750775177527753775477557756775777587759776077617762776377647765776677677768776977707771777277737774


RTATolerance ::= INTEGER (1..150) --unit= Minute, Range (0.1..15.0), resolution = 0.1

Runway ::= SEQUENCE { direction RunwayDirection, configuration RunwayConfiguration }

RunwayDirection ::= INTEGER (1..36)

RunwayConfiguration ::= ENUMERATED { left (0), right (1), center (2), none (3) }

RunwayRVR ::= SEQUENCE { runway Runway, rVR RVR }

RVR ::= CHOICE { rVRFeet [0] RVRFeet, rVRMeters [1] RVRMeters }

RVRFeet ::= INTEGER (0..6100) -- unit = Feet, Range (0..6100), resolution = 1

RVRMeters ::= INTEGER (0..1500) -- unit = Meters (0..1500), resolution = 1

SecondsLatLon ::= INTEGER (0..59) --unit = Second, Range (0.. 59), resolution = 1

Speed ::= CHOICE { speedIndicated [0] SpeedIndicated, speedIndicatedMetric [1] SpeedIndicatedMetric, speedTrue [2] SpeedTrue, speedTrueMetric [3] SpeedTrueMetric, speedGround [4] SpeedGround, speedGroundMetric [5] SpeedGroundMetric, speedMach [6] SpeedMach }

7775777677777778777977807781778277837784778577867787778877897790779177927793779477957796779777987799780078017802780378047805780678077808780978107811781278137814781578167817781878197820782178227823782478257826


SpeedIndicated ::= INTEGER (0..400) -- unit = Knots, Range (0..400), resolution = 1

SpeedIndicatedMetric ::= INTEGER (0..800) -- unit = Kilometers/Hour, Range (0..800), resolution = 1

SpeedGround ::= INTEGER (-50..2000) -- unit = Knots, Range (-50..2000), resolution = 1

SpeedGroundMetric ::= INTEGER (-100..4000) -- unit = Kilometers/Hour, Range (-100..4000), resolution = 1

SpeedMach ::= INTEGER (500..4000) -- unit = Mach Range (0.5 to 4.0), resolution = 0.001

SpeedSpeed ::= SEQUENCE SIZE (2) OF Speed

SpeedTime ::= SEQUENCE { speed Speed, time Time }

SpeedTrue ::= INTEGER (0..2000) -- unit = Knots, Range (0..2000), resolution = 1

SpeedTrueMetric ::= INTEGER (0..4000) -- unit = Kilometers/Hour, Range (0..4000), resolution = 1

SpeedType ::= ENUMERATED { noneSpecified (0), indicated (1), true (2), ground (3), mach (4), approach (5), cruise (6), minimum (7), maximum (8), ... }

SpeedTypeSpeedTypeSpeedType ::= SEQUENCE SIZE (3) OF SpeedType SpeedTypeSpeedTypeSpeedTypeSpeed ::= SEQUENCE { speedTypes SpeedTypeSpeedTypeSpeedType, speed Speed }

7827782878297830783178327833783478357836783778387839784078417842784378447845784678477848784978507851785278537854785578567857785878597860786178627863786478657866786778687869787078717872787378747875787678777878


Temperature ::= INTEGER (-100..100) -- unit = Degree Celsius, Range (-100..100), resolution = 1

Time ::= SEQUENCE { hours TimeHours, minutes TimeMinutes }

TimeLevel ::= SEQUENCE { time Time, level Level }

TimeDeparture ::= SEQUENCE { timeDepartureAllocated [0] Time OPTIONAL, timeDepartureControlled [1] ControlledTime OPTIONAL, timeDepartureClearanceExpected [2] Time OPTIONAL, departureMinimumInterval [3] DepartureMinimumInterval OPTIONAL }

TimeDistanceSpecifiedDirection ::= SEQUENCE { time Time, distanceSpecifiedDirection DistanceSpecifiedDirection }

TimeDistanceToFromPosition ::= SEQUENCE { time Time, distance Distance, tofrom ToFrom, position Position }

Timehhmmss ::= SEQUENCE { hoursminutes Time, seconds TimeSeconds }

TimeHours ::= INTEGER (0..23) -- unit = Hour, Range (0..23), resolution = 1

TimeUnitNameFrequency ::= SEQUENCE { time Time, unitName UnitName, frequency Frequency }

7879788078817882788378847885788678877888788978907891789278937894789578967897789878997900790179027903790479057906790779087909791079117912791379147915791679177918791979207921792279237924792579267927792879297930


TimeMinutes ::= INTEGER (0..59) -- unit = Minute, Range (0..59), resolution = 1

TimePosition ::= SEQUENCE { time Time, position Position }

TimePositionLevel ::= SEQUENCE { timeposition TimePosition, level Level }

TimePositionLevelSpeed ::= SEQUENCE { timeposition TimePosition, levelspeed LevelSpeed }

TimeSeconds ::= INTEGER (0..59) -- unit = Second, Range (0..59), resolution = 1

TimeSpeed ::= SEQUENCE { time Time, speed Speed }

TimeSpeedSpeed ::= SEQUENCE { time Time, speedspeed SpeedSpeed }

TimeTime ::= SEQUENCE SIZE (2) OF Time

TimeToFromPosition ::= SEQUENCE { time Time, tofrom ToFrom, position Position }

TimeTolerance ::= ENUMERATED { at (0), atorafter (1), atorbefore (2) }

7931793279337934793579367937793879397940794179427943794479457946794779487949795079517952795379547955795679577958795979607961796279637964796579667967796879697970797179727973797479757976797779787979798079817982


ToFrom ::= ENUMERATED { to (0), from (1) }

ToFromPosition ::= SEQUENCE { toFrom ToFrom, position Position }

TrafficType ::= ENUMERATED { noneSpecified (0), oppositeDirection (1), sameDirection (2), converging (3), crossing (4), diverging (5), ... }

Turbulence ::= ENUMERATED { light (0), moderate (1), severe (2) }

UnitName ::= SEQUENCE { facilityDesignation [0] FacilityDesignation, facilityName [1] FacilityName OPTIONAL, facilityFunction [2] FacilityFunction }

UnitNameFrequency ::= SEQUENCE { unitName UnitName, frequency Frequency }

VersionNumber ::= INTEGER (0..15)

VerticalChange ::= SEQUENCE { direction VerticalDirection, rate VerticalRate }

7983798479857986798779887989799079917992799379947995799679977998799980008001800280038004800580068007800880098010801180128013801480158016801780188019802080218022802380248025802680278028802980308031803280338034


VerticalDirection ::= ENUMERATED { up (0), down (1) }

VerticalRate ::= CHOICE { verticalRateEnglish [0] VerticalRateEnglish, verticalRateMetric [1] VerticalRateMetric }

VerticalRateEnglish ::= INTEGER (0..3000) -- unit = Feet/Minute, Range (0..30000), resolution = 10

VerticalRateMetric ::= INTEGER (0..1000) -- unit = Meters/Minute, Range (0..10000), resolution = 10

WaypointSpeedLevel ::= SEQUENCE { position [0] Position, speed [1] Speed OPTIONAL, aTWLevels [2] ATWLevelSequence OPTIONAL }

WindDirection ::= INTEGER (1..360) -- unit = Degree, Range (1..360), resolution = 1

Winds ::= SEQUENCE { direction WindDirection, speed WindSpeed }

WindSpeed ::= CHOICE { windSpeedEnglish [0] WindSpeedEnglish, windSpeedMetric [1] WindSpeedMetric }

WindSpeedEnglish ::= INTEGER (0..255) -- unit = Knot, Range (0..255), resolution = 1

WindSpeedMetric ::= INTEGER (0..511) -- unit = Kilometer/Hour, Range (0..511), resolution = 1

Year ::= INTEGER (1996..2095) -- unit = Year, Range (1996..2095), resolution = 1END

8035803680378038803980408041804280438044804580468047804880498050805180528053805480558056805780588059806080618062806380648065806680678068806980708071807280738074807580768077807880798080808180828083808480858086


3.5 1PROTOCOL DEFINITION

3.5.1 Sequence rules

3.5.1.1 With the exception of abort primitives, only the sequence of primitives illustrated in Figures 3-2 to 3-19 shall be permitted.

3.5.1.2 Figures 3-2 to 3-19 define the valid sequences of primitives that are possible to be invoked during the operation of the CPDLC application. The figures show the relationship in time between the service request and the resulting indication and, if applicable, the subsequent response and resulting confirmation.

3.5.1.3 Abort primitives may interrupt and terminate any of the normal message sequences outlined in the rest of Section 3.5.

3.5.1.4 Primitives are processed in the order in which they are received.

Figure 3-2. Sequence diagram for CPDLC-start service— Air-initiated

TI

ME

CPDLC -groun d-u se r CPDLC serv ice p rov ider C PDL C -a ir-user

D - S T A R T In d

D - S T A R T R s p

D - S T A R T R e q

D - S T A R T C n f

t s ta r t

C P D L C - s ta r t In d

C P D L C - s ta r t R s p

C P D L C - s ta r t R e q

C P D L C - s ta r t C n f

80878088808980908091809280938094809580968097809880998100810181028103810481058106

8108810981108111


Figure 3-3. Sequence diagram for CPDLC-start service— Ground-initiated

Figure 3-4. Sequence diagram for DSC-start service

TI

ME


D - S T A R T In d

D - S T A R T R s p

D - S T A R T R e q

D - S T A R T C n f

ts ta r t

C P D L C - s ta r t In d

C P D L C - s ta r t R s p

C P D L C - s ta r t R e q

C P D L C - s ta r t C n f

TI

ME

CPDLC -groun d-u se r CPDLC se rv ice prov id er C PDL C-air-user

D - S T A R T In d

D - S T A R T R s p

D - S T A R T R e q

D - S T A R T C n f

t s ta r t

D S C - s ta r t I n d

D S C - s t a r t R s p

D S C - s t a r t R e q

D S C - s t a r t C n f

81138114811581168117

81198120


Figure 3-5. Sequence diagram for CPDLC-message service— Air-initiated

Figure 3-6. Sequence diagram for CPDLC-message service— Ground-initiated

TI

ME

CPDLC -groun d-u se r CPDLC se rv ice prov id er C PDL C-air-user

C P D L C - m e s s a g e In d

C P D L C - m e s s a g e R e q

D - D AT A In d

D - D AT A R e q

TI

ME

CPDLC-groun d-u se r CPDL C serv ice p rov id er C PDL C-air-user

D - D AT A In d

C P D L C - m e s s a g e In d

C P D L C - m e s s a g e R e q

D - D AT A R e q

81228123812481258126

812881298130


Figure 3-7. Sequence diagram for CPDLC-end service

Figure 3-8. Sequence diagram for DSC-end service

TI

ME


D - E N D I n d

D - R s pE N D

D - R e qE N D

D - C n fE N D

C P D L C - I n de n d

C P D L C - R s pe n d

C P D L C - e n d R e q

C P D L C - C n fe n d

TI

ME


D - I n dE N D

D - R s pE N D

D - E N D R e q

D - C n fE N D

D S C - e n d In d

D S C - e n d R s p

D S C - e n d R e q

D S C - e n d C n f

8132813381348135

81378138


Figure 3-9. Sequence diagram for CPDLC-forward service— Ground forwarding supported, ASE version numbers the same

Figure 3-10. Sequence diagram for CPDLC-forward service— Ground forwarding not supported, or

— Ground forwarding supported and ASE version numbers not the same

TI

ME

t s ta r t

C P D L C - fo r w a r d R e q

C P D L C - fo r w a r d C n f

C P D L C - fo r w a r d I n d

D - S T A R T In d

D - S T A R T R s p

D - S T A R T R e q

D - S T A R T C n f

Se nd ingCPDL C-gro un d-u se r CPDL C serv ice p rov id er

Rece iv ing-g roun d-userCPDLC

TI

ME

t s ta r t

C P D L C - fo r w a r d R e q

C P D L C - fo r w a r d C n f

D - S T A R T In d

D - S T A R T R s p

D - S T A R T R e q

D - S T A R T C n f

Se nd ingCPDL C-gro un d-u se r CPDL C serv ice p rov id er

Rece iv ing-g roun d-userCPDLC

81408141814281438144

8146814781488149


Figure 3-11. Sequence diagram for CPDLC-user-abort service— CPDLC-air-user initiated

Figure 3-12. Sequence diagram for CPDLC-user-abort service— CPDLC-ground-user initiated

TI

ME


D - A B O R T In d

D - R e qA B O R T

C P D L C - u s e r- a b o rt In d

C P D L C - u s e r- a b o rt R e q

TI

ME


D - A B O R T R e q

D - In dA B O R T

C P D L C - u s e r- a b o rt R e q

C P D L C - u s e r- a b o rt In d

81518152815381548155

815781588159


Figure 3-13. Sequence diagram for CPDLC-provider-abort service— dialogue service abort

Figure 3-14. Sequence diagram for CPDLC-provider-abort service— CPDLC-air-ASE abort

TI

ME

D - P - A B O R T In d D - P - A B O R T In d

CPDLC -groun d-u se r CPDL C serv ice p rov ider CPDLC -a ir-user

C P D L C - p r o v id e r -a b o r t In dC P D L C - p r o v id e r -a b o r t In d

TI

ME

D - In dA B O R T

D - R e qA B O R T

C P D L C - p r o v id e r -a b o r t In d


CPDL C-gro un d-use r C PDL C serv ice p rov ider CPDL C -a ir-user

81618162816381648165

816781688169


Figure 3-15. Sequence diagram for CPDLC-provider-abort service— CPDLC-ground-ASE abort

Figure 3-16. Sequence diagram for CPDLC-user-abort service— Sending CPDLC-ground-user initiated

TI

ME

D - In dA B O R T

D - R e qA B O R T



CPDLC -ground-u se r CPDLC serv ice p rov id er CPDLC -air-user

TI

ME

C P D L C - u s e r- a b o r t R e qD - A B O R T In d

D - A B O R T R e q

Se nd ingCPDL C-groun d-u se r CPDL C serv ice p rov ider

Rece iv ing-g roun d-userCPD LC

81718172817381748175

817781788179


Figure 3-17. Sequence diagram for CPDLC-provider-abort service— Dialogue service abort

Figure 3-18. Sequence diagram for CPDLC-provider-abort service— Receiving CPDLC-ground-ASE abort

TI

ME


D - P - In dA B O R TD - P - A B O R T In d

Se nd ingCPDL C-groun d-u se r CPDL C serv ice p rov ider

Rece iv ing-g roun d-userCPD LC

TI

ME

D - In dA B O R T

D - A B O R T R e q

Se ndingCPDL C-groun d-u se r CPDL C serv ice p rov ider

Receiving-g roun d-userCPD LC


81818182818381848185

81878188


Figure 3-19. Sequence diagram for CPDLC-provider-abort service— Sending CPDLC-ground-ASE abort

3.5.2 CPDLC service provider timers

3.5.2.1 A CPDLC-ASE shall be capable of detecting when a timer expires.

3.5.2.2 Table 3-10 lists the time constraints related to the CPDLC application. Each time constraint requires a timer to be set in the CPDLC protocol machine.

3.5.2.3 If the timer expires before the final event has occurred, a CPDLC-ASE takes appropriate action as defined in 3.5.4.1.

3.5.2.4 The timer values should be as indicated in Table 3-10.

Table 3-10. CPDLC service provider timers

CPDLC service Timer Timer value Timer start event Timer stop event

CPDLC-start tstart 6 minutes D-START request D-START confirmation

DSC-start tstart 6 minutes D-START request D-START confirmation

CPDLC-forward tstart 6 minutes D-START request D-START confirmation

Note.— The receipts of CPDLC-user-abort requests, D-ABORT indications or D-P-ABORT indications are also timer stop events.

TI

ME

D - R e qA B O R T

D - In dA B O R TC P D L C - p r o v id e r -a b o r t In d

Send ingCPDL C-ground-u ser CPDLC serv ice p rov ider

Rece iving-g roun d-userCPDLC

8190819181928193819481958196819781988199820082018202820382048205820682078208

82098210821182128213


3.5.3 CPDLC-air-ASE protocol description


3.5.3.1.1 If no actions are described for a CPDLC service primitive when a CPDLC-air-ASE is in a specific state, then the invocation of that service primitive shall be prohibited while the CPDLC-air-ASE is in that state.

3.5.3.1.2 Upon receipt of a PDU, if no actions are described for the arrival of that PDU when a CPDLC-air-ASE is in a specific state, then that PDU is considered not permitted and exception handling procedures as described in 3.5.4.4 shall apply.

3.5.3.1.3 If a PDU is received that cannot be decoded, then exception handling procedures for an invalid PDU as described in 3.5.4.3 shall apply.

3.5.3.1.4 If a PDU is not received when one is required, then exception handling procedures as described in 3.5.4.3 shall apply.

3.5.3.1.5 The states defined for the CPDLC-air-ASE are the following:

a) IDLE;

b) START-REQ;

c) START-IND;

d) DIALOGUE; and

e) END.

3.5.3.1.6 The CPDLC-air-user is an active user from the time:

a) the CPDLC-air-user invokes the CPDLC-start service request until it:

1) receives a CPDLC-start service confirmation with the Result parameter equal to the abstract value “rejected”; or

2) invokes a CPDLC-end service response with the Result parameter set to the abstract value “accepted”; or

3) invokes a CPDLC-user-abort service request; or

4) receives a CPDLC-user-abort service indication; or

5) receives a CPDLC-provider-abort service indication; or

b) the CPDLC-air-user receives the CPDLC-start service indication until it:

1) invokes a CPDLC-start service response with the Result parameter equal to the abstract value “rejected”; or

2) invokes a CPDLC-end service response with the Result parameter set to the abstract value “accepted”; or

82148215821682178218821982208221822282238224822582268227822882298230823182328233823482358236823782388239824082418242824382448245824682478248824982508251825282538254825582568257825882598260826182628263826482658266





c) the CPDLC-air-user invokes the DSC-start service request until it:

1) receives a DSC-start service confirmation with the Result parameter equal to the abstract value “rejected”; or

2) receives a DSC-end service confirmation with the Result parameter equal to the abstract value “accepted”; or



5) receives a CPDLC-provider-abort service indication.

3.5.3.1.7 On initiation, the CPDLC-air-ASE shall be in the IDLE state.

3.5.3.1.8 The CPDLC-air-ASE contains a Boolean called DSC. DSC has the abstract value “true” when the dialogue is a DSC dialogue and has the abstract value “false” otherwise.

3.5.3.1.9 On the initiation of a CPDLC-air-ASE, DSC shall be set to the abstract value “false”.

3.5.3.2 D-START indication

Upon receipt of a D-START indication, if the CPDLC-air-ASE is in the IDLE state, and the D-START User Data parameter contains a GroundPDUs [ICUplinkMessage(startup)] APDU, and the D-START QOS Priority parameter has the abstract value “high priority flight safety messages”, and the D-START QOS Residual Error Rate parameter has the abstract value “low”, and the D-START QOS Routing Class parameter has one of the abstract values specified in Table 3-13 (see 3.6.2.2), and the D-START Calling Peer ID parameter is a valid four- to eight-character facility designation, and the D-START Security Requirements parameter is consistent with the local security policy, the CPDLC-air-ASE shall:

a) invoke CPDLC-start service indication with:

1) the D-START Calling Peer ID parameter value as the CPDLC-start service Calling Peer Identifier parameter value;

2) the D-START QOS Routing Class parameter value as the CPDLC-start service Class of Communication parameter value; and

3) if the D-START DS-User Version Number parameter is present, the D-START DS-User Version Number parameter is present as the CPDLC Message Set Version Number ASN.1 Version Number parameter value; and

4) the GroundPDUs APDU element as the CPDLC-start service CPDLC/IC Data parameter value;

and

8267826882698270827182728273827482758276827782788279828082818282828382848285828682878288828982908291829282938294829582968297829882998300830183028303830483058306830783088309831083118312831383148315831683178318


b) enter the START-IND state.

3.5.3.3 D-START confirmation

3.5.3.3.1 Upon receipt of a D-START confirmation, if the CPDLC-air-ASE is in the START-REQ state, and the D-START Result parameter has the abstract value “accepted”, and DSC has the abstract value “false”, and the D-START User Data parameter contains a GroundPDUs [ICUplinkMessage(send)] APDU, and the D-START Security Requirements parameter value is the same as the one set for the D-START request, the CPDLC-air-ASE shall:

a) stop timer tstart;

b) invoke CPDLC-start service confirmation with:

1) the APDU contained in the D-START User Data parameter as the CPDLC-start service Response CPDLC/IC Data parameter value; and

2) the abstract value “accepted” as the CPDLC-start service Result parameter value; and


3.5.3.3.2 Upon receipt of a D-START confirmation, if the CPDLC-air-ASE is in the START-REQ state, and the D-START Result parameter has the abstract value “rejected (permanent)”, and the D-START Reject Source parameter has the abstract value “DS-user”, and DSC has the abstract value “false”, and the D-START User Data parameter contains a GroundPDUs [ICUplinkMessage(send)] APDU, and the D-START Security Requirements parameter value is the same as the one set for the D-START request, the CPDLC-air-ASE shall:




2) the abstract value “rejected” as the CPDLC-start service Result parameter value; and


3.5.3.3.3 Upon receipt of a D-START confirmation, if the CPDLC-air-ASE is in the START-REQ state, and the D-START Result parameter has the abstract value “accepted”, and DSC has the abstract value “true”, and the D-START User Data parameter contains a GroundPDUs [ICUplinkMessage(send)] APDU, and the D-START Security Requirements parameter value is the same as the one set for the D-START request, the CPDLC-air-ASE shall:


b) invoke DSC-start service confirmation with:

1) the APDU contained in the D-START User Data parameter as the DSC-start service Response CPDLC/IC Data parameter value; and

2) the abstract value “accepted” as the DSC-start service Result parameter value; and

8319832083218322832383248325832683278328832983308331833283338334833583368337833883398340834183428343834483458346834783488349835083518352835383548355835683578358835983608361836283638364836583668367836883698370



3.5.3.3.4 Upon receipt of a D-START confirmation, if the CPDLC-air-ASE is in the START-REQ state, and the D-START Result parameter has the abstract value “rejected (permanent)”, and the D-START Reject Source parameter has the abstract value “DS-user”, and DSC has the abstract value “true”, and the D-START User Data parameter contains a GroundPDUs [ICUplinkMessage(send)] APDU, the CPDLC-air-ASE shall:


b) invoke DSC-start service confirmation with:

1) the APDU contained in the D-START User Data parameter as the DSC-start service Response CPDLC/IC Data parameter value; and

2) the abstract value “rejected” as the DSC-start service Result parameter value;

c) set DSC to the abstract value “false”; and


3.5.3.4 D-DATA indication

3.5.3.4.1 Upon receipt of a D-DATA indication, if the CPDLC-air-ASE is in the DIALOGUE state, and the APDU contained in the D-DATA User Data parameter is a GroundPDUs [ICUplinkMessage(send)] APDU, the CPDLC-air-ASE shall:

a) invoke CPDLC-message service indication with the APDU contained in the D-DATA User Data parameter as the CPDLC-message service CPDLC/IC Data parameter value; and

b) remain in the DIALOGUE state.

3.5.3.4.2 Upon receipt of a D-DATA indication, if the CPDLC-air-ASE is in the END state, and DSC has the abstract value “true”, and the APDU contained in the D-DATA User Data parameter is a GroundPDUs [ICUplinkMessage(send)] APDU, the CPDLC-air-ASE shall:



3.5.3.5 D-END indication

Upon receipt of a D-END indication, if the CPDLC-air-ASE is in the DIALOGUE state, and DSC has the abstract value “false”, and the D-END User Data parameter contains a GroundPDUs [ICUplinkMessage(send)] APDU, the CPDLC-air-ASE shall:

a) invoke CPDLC-end service indication with the APDU contained in the D-END User Data parameter as the CPDLC-end service CPDLC/IC Data parameter value; and

8371837283738374837583768377837883798380838183828383838483858386838783888389839083918392839383948395839683978398839984008401840284038404840584068407840884098410841184128413841484158416841784188419842084218422


b) enter the END state.

3.5.3.6 D-END confirmation

3.5.3.6.1 Upon receipt of a D-END confirmation, if the CPDLC-air-ASE is in the END state, and the D-END Result parameter has the abstract value “accepted”, and DSC has the abstract value “true”, and the D-END User Data parameter contains a GroundPDUs [ICUplinkMessage(send)] APDU, the CPDLC-air-ASE shall:

a) invoke DSC-end service confirmation with:

1) the APDU contained in the D-END User Data parameter as the DSC-end service CPDLC/IC Data parameter value; and

2) the abstract value “accepted” as the CPDLC-end service Result parameter value;

b) set DSC to the abstract value “false”; and


3.5.3.6.2 Upon receipt of a D-END confirmation, if the CPDLC-air-ASE is in the END state, and the D-END Result parameter has the abstract value “rejected”, and DSC has the abstract value “true”, and the D-END User Data parameter contains a GroundPDUs [ICUplinkMessage(send)] APDU, the CPDLC-air-ASE shall:

a) invoke DSC-end service confirmation with:

1) the APDU contained in the D-END User Data parameter as the DSC-end service CPDLC/IC Data parameter value; and

2) the abstract value “rejected” as the CPDLC-end service Result parameter value; and

b) enter the DIALOGUE state.

3.5.3.7 CPDLC-start service request

Upon receipt of a CPDLC-start service request, if the CPDLC-air-ASE is in the IDLE state, the CPDLC-air-ASE shall:

a) create an AircraftPDUs APDU with a StartDownMessage APDU element containing:

1) the abstract value “cpdlc” as the mode; and

2) the CPDLC/IC Data parameter as the ICDownlinkMessage;


1) the CPDLC-start service Called Peer Identifier parameter value as the D-START Called Peer ID parameter value;

2) the CPDLC-start service Calling Peer Identifier parameter value as the D-START Calling Peer ID parameter value;

8423842484258426842784288429843084318432843384348435843684378438843984408441844284438444844584468447844884498450845184528453845484558456845784588459846084618462846384648465846684678468846984708471847284738474


3) the CPDLC-start service CPDLC Message Set Version Number parameter value if specified by the CPDLC-user as the D-START DS-User Version Number parameter value;

4) the CPDLC-start service Security Required parameter value if specified by the CPDLC-user or otherwise the abstract value “no security” as the D-START Security Requirements parameter value;


i) if provided, the CPDLC-start service Class of Communication parameter value as the D-START QOS Routing Class parameter value; and

ii) the abstract value of “high priority flight safety messages” as the D-START QOS Priority parameter value; and

iii) the abstract value of “low” as the D-START QOS Residual Error Rate parameter value; and

6) the APDU as the D-START User Data parameter value;

c) start timer tstart; and

d) enter the START-REQ state.

3.5.3.8 CPDLC-start service response

3.5.3.8.1 Upon receipt of a CPDLC-start service response, if the CPDLC-air-ASE is in the START-IND state, and the CPDLC-start service Result parameter has the abstract value “accepted”, and DSC has the abstract value “false”, the CPDLC-air-ASE shall:

a) create an AircraftPDUs APDU with an ICDownlinkMessage APDU element based on the Response CPDLC/IC Data parameter;

b) invoke D-START response with the following:


2) the abstract value received in the D-START indication Security Requirements parameter as the D-START Security Requirements parameter value; and

3) the abstract value “accepted” as the D-START Result parameter value; and


3.5.3.8.2 Upon receipt of a CPDLC-start service response, if the CPDLC-air-ASE is in the START-IND state, and the CPDLC-start service Result parameter has the abstract value “rejected”, and DSC has the abstract value “false”, the CPDLC-air-ASE shall:

a) create an AircraftPDUs APDU with an ICDownlinkMessage APDU element based on the Response CPDLC/IC Data parameter;


84758476847784788479848084818482848384848485848684878488848984908491849284938494849584968497849884998500850185028503850485058506850785088509851085118512851385148515851685178518851985208521852285238524852585268527




3) the abstract value “rejected (permanent)” as the D-START Result parameter value; and


3.5.3.9 DSC-start service request

Upon receipt of a DSC-start service request, if the CPDLC-air-ASE is in the IDLE state, the CPDLC-air-ASE shall:

a) create an AircraftPDUs APDU with a StartDownMessage APDU element containing:

1) the abstract value “dsc” as the mode; and

2) the CPDLC/IC Data parameter as the ICDownlinkMessage;


1) the DSC-start service Facility Designation parameter value as the D-START Called Peer ID parameter value;

2) the DSC-start service Aircraft Address parameter value as the D-START Calling Peer ID parameter value;

3) the DSC-start service CPDLC Message Set Version Number parameter value if specified by the CPDLC-user as the D-START DS-User Version Number parameter value;

4) the DSC-start service Security Required parameter value if specified by the CPDLC-air-user or otherwise the abstract value “no security” as the D-START Security Requirements parameter value;


i) if provided, the DSC-START service Class of Communication parameter value as the D-START QOS Routing Class parameter value;




c) set DSC to the abstract value “true”;

d) start timer tstart; and

e) enter the START-REQ state.

8528852985308531853285338534853585368537853885398540854185428543854485458546854785488549855085518552855385548555855685578558855985608561856285638564856585668567856885698570857185728573857485758576857785788579


3.5.3.10 CPDLC-message service request

3.5.3.10.1 Upon receipt of a CPDLC-message service request and the CPDLC/IC Data parameter contains a CPDLC message, if the CPDLC-air-ASE is in the DIALOGUE state, the CPDLC-air-ASE shall:

a) create an AircraftPDUs APDU with an ICDownlinkMessage APDU element based on the CPDLC-message service CPDLC/IC Data parameter;

b) invoke D-DATA request with the APDU as the D-DATA User Data parameter value; and

c) remain in the DIALOGUE state.3.5.3.10.2 Upon receipt of a CPDLC-message service request and the CPDLC/IC Data parameter contains a CPDLC message, if the CPDLC-air-ASE is in the END state and DSC has the abstract value “false”, the CPDLC-air-ASE shall:

a) create an AircraftPDUs APDU with an ICDownlinkMessage APDU element based on the CPDLC-message service CPDLC/IC Data parameter;


c) remain in the END state.

3.5.3.11 CPDLC-end service response

3.5.3.11.1 Upon receipt of a CPDLC-end service response, if the CPDLC-air-ASE is in the END state, and the CPDLC-end service Result parameter has the abstract value “accepted”, and DSC has the abstract value “false”, the CPDLC-air-ASE shall:

a) create an AircraftPDUs APDU with an ICDownlinkMessage APDU element based on the CPDLC-end service CPDLC/IC Data parameter;

b) invoke D-END response with:

1) the APDU as the D-END User Data parameter value; and

2) the abstract value “accepted” as the D-END Result parameter value; and


3.5.3.11.2 Upon receipt of a CPDLC-end service response, if the CPDLC-air-ASE is in the END state, and the CPDLC-end service Result parameter has the abstract value “rejected”, and DSC has the abstract value “false”, the CPDLC-air-ASE shall:

a) create an AircraftPDUs APDU with an ICDownlinkMessage APDU element based on the CPDLC-end service CPDLC/IC Data parameter;



2) the abstract value “rejected” as the D-END Result parameter value; and

8580858185828583858485858586858785888589859085918592859385948595859685978598859986008601860286038604860586068607860886098610861186128613861486158616861786188619862086218622862386248625862686278628862986308631



3.5.3.12 DSC-end service request

Upon receipt of a DSC-end service request, if the CPDLC-air-ASE is in the DIALOGUE state and DSC has the abstract value “true”, the CPDLC-air-ASE shall:

a) create an AircraftPDUs APDU with an ICDownlinkMessage APDU element based on the DSC-end service CPDLC/IC Data parameter;

b) invoke D-END request with the APDU as the D-END User Data parameter value; and


3.5.3.13 CPDLC-user-abort service request

Upon receipt of a CPDLC-user-abort service request, if the CPDLC-air-ASE is not in the IDLE state, the CPDLC-air-ASE shall:

a) stop any timer;

b) if the CPDLC-user-abort service Reason parameter is provided, create an AircraftPDUs APDU with a CPDLCUserAbortReason APDU element based on the CPDLC-user-abort service Reason parameter;

c) if the CPDLC-user-abort service Reason parameter is not provided, create an AircraftPDUs APDU with a CPDLCUserAbortReason [undefined] APDU element;


1) the D-ABORT Originator parameter set to the abstract value “user”; and


e) if DSC has the abstract value “true”, set DSC to the abstract value “false”; and


3.5.3.14 D-ABORT indication

3.5.3.14.1 Upon receipt of a D-ABORT indication, if the CPDLC-air-ASE is not in the IDLE state, and the D-ABORT Originator parameter is “user”, and the D-ABORT User Data parameter contains a GroundPDUs [CPDLCUserAbortReason] APDU, the CPDLC-air-ASE shall:

a) stop any timer;

8632863386348635863686378638863986408641864286438644864586468647864886498650865186528653865486558656865786588659866086618662866386648665866686678668866986708671867286738674867586768677867886798680


b) if the CPDLC-air-user is an active user, invoke CPDLC-user-abort service indication with the APDU contained in the D-ABORT User Data parameter as the CPDLC-user-abort service Reason parameter value;

c) if DSC has the abstract value “true”, set DSC to the abstract value “false”; and


3.5.3.14.2 Upon receipt of a D-ABORT indication, if the CPDLC-air-ASE is not in the IDLE state, and the D-ABORT Originator parameter is “provider”, and the D-ABORT User Data parameter is provided, and the D-ABORT User Data parameter contains a GroundPDUs [CPDLCProviderAbortReason] APDU, the CPDLC-air-ASE shall:

a) stop any timer;

b) if the CPDLC-air-user is an active user, invoke CPDLC-provider-abort service indication with the D-ABORT User Data parameter as the CPDLC-provider-abort service Reason parameter value, if provided;



3.5.3.15 D-P-ABORT indication

Upon receipt of a D-P-ABORT indication, if the CPDLC-air-ASE is not in the IDLE state, the CPDLC-air-ASE shall:

a) stop any timer;

b) if the CPDLC-air-user is an active user, invoke CPDLC-provider-abort service indication with the CPDLC-provider-abort service Reason parameter set to the abstract value “communication-service-failure”;



3.5.4 CPDLC-air-ASE exception handling

3.5.4.1 A timer expires

If a CPDLC-air-ASE detects that a timer has expired, that CPDLC-air-ASE shall:

a) interrupt any current activity;

b) create an AircraftPDUs APDU with a CPDLCProviderAbortReason [timer-expired] APDU message element;


868186828683868486858686868786888689869086918692869386948695869686978698869987008701870287038704870587068707870887098710871187128713871487158716871787188719872087218722872387248725872687278728872987308731




d) if the CPDLC-air-user is an active user, invoke CPDLC-provider-abort service indication with the abstract value “timer-expired” as the CPDLC-provider-abort service Reason parameter value;




If a CPDLC-air-ASE has an unrecoverable system error, the CPDLC-air-ASE should:

a) stop any timer;

b) create an AircraftPDUs APDU with a CPDLCProviderAbortReason [undefined-error] APDU message element;




d) if the CPDLC-air-user is an active user, invoke CPDLC-provider-abort service indication with the abstract value “undefined-error” as the CPDLC-provider-abort service Reason parameter value;



3.5.4.3 Invalid PDU

3.5.4.3.1 If the User Data parameter of a D-END confirmation with the Result parameter set to the abstract value “rejected”, or the User Data parameter of a D-START confirmation with the Result parameter set to the abstract value "accepted", or the User Data parameter of a D-START indication, a D-DATA indication or a D-END indication does not contain a valid PDU, the CPDLC-air-ASE shall:

a) stop any timer;

b) create an AircraftPDUs APDU with a CPDLCProviderAbortReason [invalid-PDU] APDU message element;



8732873387348735873687378738873987408741874287438744874587468747874887498750875187528753875487558756875787588759876087618762876387648765876687678768876987708771877287738774877587768777877887798780878187828783



d) if the CPDLC-air-user is an active user, invoke CPDLC-provider-abort service indication with the abstract value “invalid-PDU” as the CPDLC-provider-abort service Reason parameter value;



3.5.4.3.2 If the User Data parameter of a D-START confirmation with the Result parameter set to the abstract value “rejected (permanent)”, or a D-END confirmation with the Result parameter set to the abstract value “accepted” is not a valid PDU, then the CPDLC-air-ASE shall:

a) stop any timer;

b) if the CPDLC-air-user is an active user, invoke CPDLC-provider-abort service indication with the CPDLC-provider-abort service Reason parameter set to the abstract value “invalid-PDU”;



3.5.4.4 Protocol error

3.5.4.4.1 If the User Data parameter of a D-START indication, D-START confirmation, D-DATA indication or D-END indication is a valid PDU; however, it is not a PDU for which action is described within a given state in 3.5.3, the CPDLC-air-ASE shall:

a) stop any timer;

b) create an AircraftPDUs APDU with a CPDLCProviderAbortReason [protocol-error] APDU message element;




d) if the CPDLC-air-user is an active user, invoke CPDLC-provider-abort service indication with the abstract value “protocol-error” as the CPDLC-provider-abort service Reason parameter value;



3.5.4.4.2 If the User Data parameter of a D-END confirmation is a valid PDU; however, it is not a permitted PDU as defined in 3.5.3, the CPDLC-air-ASE shall:

a) stop any timer;

8784878587868787878887898790879187928793879487958796879787988799880088018802880388048805880688078808880988108811881288138814881588168817881888198820882188228823882488258826882788288829883088318832883388348835


b) if the D-END Result parameter is set to the abstract value “rejected”, then:

1) create an AircraftPDUs APDU with a CPDLCProviderAbortReason [protocol-error] APDU message element; and




c) if the CPDLC-air-user is an active user, invoke CPDLC-provider-abort service indication with the abstract value “protocol-error” as the CPDLC-provider-abort service Reason parameter value;

d) if DSC has the abstract value “true”, set DSC to the abstract value “false”; and


3.5.4.4.3 Upon receipt of a DS primitive for which there are no instructions in 3.5.3 (i.e. the primitive was not expected or was expected under other conditions or with other parameter values), the CPDLC-air-ASE shall:

a) stop any timer;

b) create an AircraftPDUs APDU with a CPDLCProviderAbortReason [protocol-error] APDU message element;

c) if a dialogue exists, invoke D-ABORT request with:



d) if the CPDLC-air-user is an active user, invoke CPDLC-provider-abort service indication with the abstract value “protocol-error” as the CPDLC-provider-abort service Reason parameter value;



3.5.4.5 D-START confirmation Result parameter or Reject Source parameter not as expected

If a D-START confirmation Result parameter has the abstract value of “rejected (transient)” or if the Reject Source parameter has the abstract value of “DS-provider”, the CPDLC-air-ASE shall:

a) stop any timer;

b) if the CPDLC-air-user is an active user, invoke CPDLC-provider-abort service indication with the CPDLC-provider-abort service Reason parameter set to the abstract value “communication-service-error”;


8836883788388839884088418842884388448845884688478848884988508851885288538854885588568857885888598860886188628863886488658866886788688869887088718872887388748875887688778878887988808881888288838884888588868887




If a D-START indication QOS Priority parameter does not have the abstract value of “high priority flight safety messages”, or if the QOS Residual Error Rate parameter does not have the abstract value of “low”, or if the QOS Routing Class parameter does not have one of the abstract values specified in Table 3-13 (see 3.6.2.2), the CPDLC-air-ASE shall:

a) stop any timer;

b) create an AircraftPDUs APDU with a CPDLCProviderAbortReason [invalid-QOS-parameter] APDU message element;






3.5.4.7 Expected PDU missing

If the User Data parameter of a D-START indication or confirmation, a D-DATA indication, or a D-END indication or confirmation does not contain a PDU, the CPDLC-air-ASE shall:

a) stop any timer;

b) create an AircraftPDUs APDU with a CPDLCProviderAbortReason [expected-PDU-missing] APDU message element;




d) if the CPDLC-air-user is an active user, invoke CPDLC-provider-abort service indication with the abstract value “not-permitted-PDU” as the CPDLC-provider-abort service Reason parameter value;



8888888988908891889288938894889588968897889888998900890189028903890489058906890789088909891089118912891389148915891689178918891989208921892289238924892589268927892889298930893189328933893489358936



Note.— This section applies to the case when the D-START Security Requirements parameter does not meet the local security policy.

Upon receipt of a D-START indication with the Security Requirements parameter not consistent with the local security policy, or upon receipt of a D-START confirmation with the Security Requirements parameter not equal to the value that was set in the D-START request, the CPDLC-air-ASE shall:

a) stop all timers;


1) create an AircraftPDUs APDU with a CPDLCProviderAbortReason [communication-service-failure] APDU message element; and




c) if the CPDLC-air-user is active, invoke CPDLC-provider-abort service indication with the abstract value “communication-service-failure” as the CDPLC-provider-abort service Reason parameter value;



3.5.5 CPDLC-ground-ASE protocol description


3.5.5.1.1 If no actions are described for a CPDLC service primitive when a CPDLC-ground-ASE is in specific state, then the invocation of that service primitive shall be prohibited while the CPDLC-ground-ASE is in that state.

3.5.5.1.2 Upon receipt of a PDU, if no actions are described for the arrival of that PDU when a CPDLC-ground-ASE is in a specific state, then that PDU is considered not permitted and exception handling procedures as described in 3.5.6.4 shall apply.

3.5.5.1.3 If a PDU is received that cannot be decoded, then exception handling procedures as described in 3.5.6.3 for invalid PDU shall apply.

3.5.5.1.4 If a PDU is not received when one is required, then exception handling procedures as described in 3.5.6.3 shall apply.

8937893889398940894189428943894489458946894789488949895089518952895389548955895689578958895989608961896289638964896589668967896889698970897189728973897489758976897789788979898089818982898389848985


3.5.5.1.5 The states defined for the CPDLC-ground-ASE are the following:

a) IDLE;

b) START-REQ;

c) START-IND;

d) DIALOGUE;

e) END; and

f) FORWARD.

3.5.5.1.6 The CPDLC-ground-user is an active user from the time:

a) the CPDLC-ground-user invokes the CPDLC-start service request until it:

1) receives a CPDLC-start service confirmation with the Result parameter equal to the abstract value “rejected”; or

2) receives a CPDLC-end service confirmation with the Result parameter equal to the abstract value “accepted”; or




b) the CPDLC-ground-user receives the CPDLC-start service indication until it:

1) invokes a CPDLC-start service response with the Result parameter set to the abstract value “rejected”; or

2) receives a CPDLC-end service confirmation with the Result parameter equal to the abstract value “accepted”; or




c) the CPDLC-ground-user receives the DSC-start service indication until it:

1) invokes a DSC-start service response with the Result parameter equal to the abstract value “rejected”; or



8986898789888989899089918992899389948995899689978998899990009001900290039004900590069007900890099010901190129013901490159016901790189019902090219022902390249025902690279028902990309031903290339034903590369037



d) the CPDLC-ground-user invokes the CPDLC-forward service request until it:

1) receives a CPDLC-forward service confirmation; or



4) receives a CPDLC-provider-abort service indication.

3.5.5.1.7 On initiation, the CPDLC-ground-ASE shall be in the IDLE state.

3.5.5.1.8 The CPDLC-ground-ASE contains a Boolean called DSC. DSC has the abstract value “true” when the dialogue is a DSC dialogue and has the abstract value “false” otherwise.

3.5.5.1.9 On the initiation of a CPDLC-ground-ASE, DSC shall be set to the abstract value “false”.

3.5.5.2 D-START indication

3.5.5.2.1 Upon receipt of a D-START indication, if the CPDLC-ground-ASE is in the IDLE state, and the abstract value of the D-START Calling Peer ID parameter is the ICAO 24-bit aircraft address, and the D-START User Data parameter contains an AircraftPDUs [StartDownMessage] APDU with the APDU element mode “cpdlc”, and the D-START QOS Priority parameter has the abstract value “high priority flight safety messages” and the D-START QOS Residual Error Rate parameter has the abstract value “low”, and the D-START QOS Routing Class parameter has one of the abstract values specified in Table 3-13 (see 3.6.2.2), and the D-START Security Requirements parameter is consistent with the local security policy, the CPDLC-ground-ASE shall:

a) invoke CPDLC-start service indication with:

1) the D-START Calling Peer ID parameter value as the CPDLC-start service Calling Peer Identifier parameter value;


3) if the D-START DS-User Version Number parameter is present, the D-START DS-User Version Number parameter is present as the CPDLC Message Set Version Number parameter value; and

4) the AircraftPDUs APDU element as the CPDLC-start service CPDLC/IC Data parameter value; and

b) enter the START-IND state.

9038903990409041904290439044904590469047904890499050905190529053905490559056905790589059906090619062906390649065906690679068906990709071907290739074907590769077907890799080908190829083


3.5.5.2.2 Upon receipt of a D-START indication, if the CPDLC-ground-ASE is in the IDLE state, and the abstract value of the D-START Calling Peer ID parameter is the ICAO 24-bit aircraft address, and the D-START User Data parameter contains an AircraftPDUs [StartDownMessage] APDU with the APDU element mode “dsc”, and the D-START QOS Priority parameter has the abstract value “high priority flight safety messages”, and the D-START QOS Residual Error Rate parameter has the abstract value “low”, and the D-START QOS Routing Class parameter has one of the abstract values specified in Table 3-13 (see 3.6.2.2), and the D-START Security Requirements parameter is consistent with the local security policy, the CPDLC-ground-ASE shall:

a) invoke DSC-start service indication with:

1) the D-START Calling Peer ID parameter value as the DSC-start service Aircraft Address parameter value;


3) if the D-START DS-User Version Number parameter is present, the D-START DS-User Version Number parameter is present as the CPDLC Message Set Version Number parameter value; and

4) the AircraftPDUs APDU as the DSC-start service CPDLC/IC Data parameter value;

b) set DSC to “true”; and

c) enter the START-IND state.

3.5.5.2.3 Upon receipt of a D-START indication, if the CPDLC-ground-ASE is in the IDLE state, and the abstract value of the D-START Calling Peer ID parameter is a Facility Designation, and the D-START User Data parameter contains a GroundPDUs [ATCForwardMessage] APDU, and the CPDLC-ground-ASE supports the CPDLC-forward service, and the D-START QOS Priority parameter has the abstract value “high priority flight safety messages”, and the D-START QOS Residual Error Rate parameter has the abstract value “low”, the CPDLC-ground-ASE shall:

908490859086908790889089909090919092909390949095909690979098909991009101910291039104910591069107910891099110911191129113911491159116


a) if the D-START DS-User Version Number parameter value is equal to the CPDLC-ground-ASE version number and the D-START Security Requirements parameter is consistent with the local security policy:

1) invoke CPDLC-forward service indication with:

i) the D-START Calling Peer ID parameter value as the CPDLC-forward service Calling Facility Designation parameter value; and

ii) the D-START GroundPDUs APDU element as the CPDLC-forward service CPDLC Message parameter value;

2) create a GroundPDUs APDU with an ATCForwardResponse [success] APDU element;


i) the APDU as the D-START User Data parameter value; and

ii) the abstract value “rejected (permanent)” as the D-START Result parameter value; and

4) remain in the IDLE state; and

b) if the D-START DS-User Version Number parameter value is not equal to the CPDLC-ground-ASE version number:

1) create a GroundPDUs APDU with an ATCForwardResponse [version-not-equal] APDU element;


i) the CPDLC-ground-ASE version number as the D-START DS-User Version Number parameter value;

ii) the APDU as the D-START User Data parameter value; and

iii) the abstract value “rejected (permanent)” as the D-START Result parameter value; and

3) remain in the IDLE state.

3.5.5.2.4 Upon receipt of a D-START indication, if the CPDLC-ground-ASE is in the IDLE state, and the abstract value of the D-START Calling Peer ID parameter is a Facility Designation, and the D-START User Data parameter contains a GroundPDUs APDU, and the APDU element is an ATCForwardMessage, and the CPDLC-ground-ASE does not support the CPDLC-forward service, and the D-START Security Requirements parameter is consistent with the local security policy, the CPDLC-ground-ASE shall:

a) create a GroundPDUs APDU with an ATCForwardResponse [service-not-supported] APDU element;


1) the APDU as the D-START User Data parameter value; and


c) remain in the IDLE state.

91179118911991209121912291239124912591269127912891299130913191329133913491359136913791389139914091419142914391449145914691479148914991509151915291539154915591569157915891599160916191629163916491659166916791689169


3.5.5.3 D-START confirmation

3.5.5.3.1 Upon receipt of a D-START confirmation, if the CPDLC-ground-ASE is in the START-REQ state, and the D-START Result parameter has the abstract value “accepted”, and DSC has the abstract value of “false”, and D-START User Data parameter contains an AircraftPDUs [ICDownlinkMessage] APDU, and the D-START Security Requirements parameter value is the same as the one set for the D-START request, the CPDLC-ground-ASE shall:




2) the abstract value “accepted” as the CPDLC-start service Result parameter value; and


3.5.5.3.2 Upon receipt of a D-START confirmation, if the CPDLC-ground-ASE is in the START-REQ state, and the D-START Result parameter has the abstract value “rejected (permanent)”, and the D-START Reject Source parameter has the abstract value “DS-user”, and DSC has the abstract value “false”, and the D-START User Data parameter contains an AircraftPDUs [ICDownlinkMessage] APDU, and the D-START Security Requirements parameter value is the same as the one set for the D-START request, the CPDLC-ground-ASE shall:




2) the abstract value “rejected” as the CPDLC-start service Result parameter value; and


3.5.5.3.3 Upon receipt of a D-START confirmation, if the CPDLC-ground-ASE is in the FORWARD state, and the D-START Result parameter has the abstract value “rejected (permanent)”, and the Reject Source parameter has the abstract value “DS-user”, and the D-START User Data parameter contains a GroundPDUs [ATCForwardResponse] APDU, and the D-START Security Requirements parameter value is the same as the one set for the D-START request, the CPDLC-ground-ASE shall:


b) invoke CPDLC-forward service confirmation with:

1) the D-START GroundPDUs APDU element as the CPDLC-forward service Result parameter value; and

2) if provided, the D-START DS-User Version Number parameter value as the CPDLC-forward service ASE Version Number parameter value; and

9170917191729173917491759176917791789179918091819182918391849185918691879188918991909191919291939194919591969197919891999200920192029203920492059206920792089209921092119212921392149215921692179218921992209221



3.5.5.4 D-DATA indication

3.5.5.4.1 Upon receipt of a D-DATA indication, if the CPDLC-ground-ASE is in the DIALOGUE state, and the APDU contained in the D-DATA User Data parameter is an AircraftPDUs [ICDownlinkMessage] APDU, the CPDLC-ground-ASE shall:


b) remain in the DIALOGUE state.

3.5.5.4.2 Upon receipt of a D-DATA indication, if the CPDLC-ground-ASE is in the END state, and DSC has the abstract value “false”, and the APDU contained in the D-DATA User Data parameter is an AircraftPDUs [ICDownlinkMessage] APDU, the CPDLC-ground-ASE shall:



3.5.5.5 D-END indication

Upon receipt of a D-END indication, if the CPDLC-ground-ASE is in the DIALOGUE state, and DSC has the abstract value “true”, and the D-END User Data parameter contains an AircraftPDUs [ICDownlinkMessage] APDU, the CPDLC-ground-ASE shall:

a) invoke DSC-end service indication with the APDU contained in the D-END User Data parameter as the DSC-end service CPDLC/IC Data parameter value; and

b) enter the END state.

3.5.5.6 D-END confirmation

3.5.5.6.1 Upon receipt of a D-END confirmation, if the CPDLC-ground-ASE is in the END state, and the D-END Result parameter has the abstract value “accepted”, and DSC has the abstract value “false”, and the D-END User Data parameter contains an AircraftPDUs [ICDownlinkMessage] APDU, the CPDLC-ground-ASE shall:

a) invoke CPDLC-end service confirmation with:

1) the APDU contained in the D-END User Data parameter as the CPDLC-end service CPDLC/IC Data parameter value; and

2) the abstract value “accepted” as the CPDLC-end service Result parameter value; and

b) enter the IDLE state.

9222922392249225922692279228922992309231923292339234923592369237923892399240924192429243924492459246924792489249925092519252925392549255925692579258925992609261926292639264926592669267926892699270927192729273


3.5.5.6.2 Upon receipt of a D-END confirmation, if the CPDLC-ground-ASE is in the END state, and the D-END Result parameter has the abstract value “rejected”, and DSC has the abstract value “false”, and the D-END User Data parameter contains an AircraftPDUs [ICDownlinkMessage] APDU, the CPDLC-ground-ASE shall:

a) invoke CPDLC-end service confirmation with:

1) the APDU contained in the D-END User Data parameter as the CPDLC-end service CPDLC/IC Data parameter value; and

2) the abstract value “rejected” as the CPDLC-end service Result parameter value; and

b) enter the DIALOGUE state.

3.5.5.7 CPDLC-start service request

Upon receipt of a CPDLC-start service request, if the CPDLC-ground-ASE is in the IDLE state, the CPDLC-ground-ASE shall:

a) create a GroundPDUs APDU with an UplinkMessage(startup) APDU element containing the CPDLC/IC Data parameter as the UplinkMessage;


1) the CPDLC-start service Called Peer Identifier parameter value as the D-START Called Peer ID parameter value;

2) the CPDLC-start service Calling Peer Identifier parameter value as the D-START Calling Peer ID parameter value;

3) the CPDLC-start service CPDLC Message Set Version Number parameter value if specified by the CPDLC-user as the D-START DS-User Version Number parameter value;

4) the CPDLC-start service Security Required parameter value if specified by the CPDLC-user or otherwise the abstract value “no security” as the D-START Security Requirements parameter value;


i) if provided, the CPDLC-start service Class of Communication parameter value as the D-START QOS Routing Class parameter value; and





d) enter the START-REQ state.

9274927592769277927892799280928192829283928492859286928792889289929092919292929392949295929692979298929993009301930293039304930593069307930893099310931193129313931493159316931793189319932093219322932393249325


3.5.5.8 CPDLC-start service response

3.5.5.8.1 Upon receipt of a CPDLC-start service response, if the CPDLC-ground-ASE is in the START-IND state, and the CPDLC-start service Result parameter has the abstract value “accepted”, and DSC has the abstract value “false”, the CPDLC-ground-ASE shall:

a) create a GroundPDUs APDU with an ICUplinkMessage(send) APDU element based on the Response CPDLC/IC Data parameter;






3.5.5.8.2 Upon receipt of a CPDLC-start service response, if the CPDLC-ground-ASE is in the START-IND state, and the CPDLC-start service Result parameter has the abstract value “rejected”, and DSC has the abstract value “false”, the CPDLC-ground-ASE shall:



1) the APDU element as the D-START User Data parameter value;




3.5.5.9 DSC-start service response

3.5.5.9.1 Upon receipt of a DSC-start service response, if the CPDLC-ground-ASE is in the START-IND state, and the DSC-start service Result parameter has the abstract value “accepted”, and DSC has the abstract value “true”, the CPDLC-ground-ASE shall:




9326932793289329933093319332933393349335933693379338933993409341934293439344934593469347934893499350935193529353935493559356935793589359936093619362936393649365936693679368936993709371937293739374937593769377




c) enter the DIALOGUE state.3.5.5.9.2 Upon receipt of a DSC-start service response, if the CPDLC-ground-ASE is in the START-IND state, and the DSC-start service Result parameter has the abstract value “rejected”, and DSC has the abstract value “true”, the CPDLC-ground-ASE shall:





3) the abstract value “rejected (permanent)” as the D-START Result parameter value;



3.5.5.10 CPDLC-message service request

3.5.5.10.1 Upon receipt of a CPDLC-message service request and the CPDLC/IC Data parameter contains a CPDLC message, if the CPDLC-ground-ASE is in the DIALOGUE state, the CPDLC-ground-ASE shall:

a) create a GroundPDUs APDU with an ICUplinkMessage(send) APDU element based on the CPDLC-message service CPDLC/IC Data parameter;


c) remain in the DIALOGUE state.

3.5.5.10.2 Upon receipt of a CPDLC-message service request and the CPDLC/IC Data parameter contains a CPDLC message, if the CPDLC-ground-ASE is in the END state and DSC has the abstract value “true”, the CPDLC-ground-ASE shall:

a) create a GroundPDUs APDU with an ICUplinkMessage(send) APDU element based on the CPDLC-message service CPDLC/IC Data parameter;


c) remain in the END state.

9378937993809381938293839384938593869387938893899390939193929393939493959396939793989399940094019402940394049405940694079408940994109411941294139414941594169417941894199420942194229423942494259426942794289429


3.5.5.11 CPDLC-end service request

Upon receipt of a CPDLC-end service request, if the CPDLC-ground-ASE is in the DIALOGUE state, and DSC has the abstract value “false”, the CPDLC-ground-ASE shall:

a) create a GroundPDUs APDU with an ICUplinkMessage(send) APDU element based on the CPDLC-end service CPDLC/IC Data parameter;

b) invoke D-END request with the APDU as the D-END User Data parameter value; and


3.5.5.12 DSC-end service response

3.5.5.12.1 Upon receipt of a DSC-end service response, if the CPDLC-ground-ASE is in the END state, and DSC has the abstract value “true”, and the DSC-end service Result parameter has the abstract value “accepted”, the CPDLC-ground-ASE shall:

a) create a GroundPDUs APDU with an ICUplinkMessage(send) APDU element based on the DSC-end service CPDLC/IC Data parameter;



2) the abstract value “accepted” as the D-END Result parameter value;



3.5.5.12.2 Upon receipt of a DSC-end service response, if the CPDLC-ground-ASE is in the END state, and DSC has the abstract value “true”, and the DSC-end service Result parameter has the abstract value “rejected”, the CPDLC-ground-ASE shall:

a) create a GroundPDUs APDU with an ICUplinkMessage(send) APDU element based on the DSC-end service CPDLC/IC Data parameter;



2) the abstract value “rejected” as the D-END Result parameter value; and


3.5.5.13 CPDLC-forward service request

Upon receipt of a CPDLC-forward service request, if the CPDLC-ground-ASE is in the IDLE state, the CPDLC-ground-ASE shall:

9430943194329433943494359436943794389439944094419442944394449445944694479448944994509451945294539454945594569457945894599460946194629463946494659466946794689469947094719472947394749475947694779478947994809481


a) create a GroundPDUs APDU with an ATCForwardMessage APDU element based on the CPDLC-forward service CPDLC Message parameter;


1) the CPDLC-forward service Called Facility Designation parameter value as the D-START Called Peer ID parameter value;

2) the CPDLC-start service Calling Facility Designation parameter value as the D-START Calling Peer ID parameter value;

3) the CPDLC-forward service Security Required parameter value if specified by the CPDLC-user or otherwise the abstract value “no security” as the D-START Security Requirements parameter value;


i) if provided, the CPDLC-forward service Class of Communication parameter value as the D-START QOS Routing Class parameter value;





d) enter the FORWARD state.

3.5.5.14 CPDLC-user-abort service request

Upon receipt of a CPDLC-user-abort service request, if the CPDLC-ground-ASE is not in the IDLE state, the CPDLC-ground-ASE shall:

a) stop any timer;

b) if the CPDLC-user-abort service Reason parameter is provided, create a GroundPDUs APDU with a CPDLCUserAbortReason APDU element based on the CPDLC-user-abort service Reason parameter;

c) if the CPDLC-user-abort service Reason parameter is not provided, create a GroundPDUs APDU with a CPDLCUserAbortReason [undefined] APDU element;


1) the D-ABORT Originator parameter set to the abstract value “user”; and




94829483948494859486948794889489949094919492949394949495949694979498949995009501950295039504950595069507950895099510951195129513951495159516951795189519952095219522952395249525952695279528952995309531953295339534


3.5.5.15 D-ABORT indication

3.5.5.15.1 Upon receipt of a D-ABORT indication, if the CPDLC-ground-ASE is not in the IDLE state, and the D-ABORT Originator parameter is “user”, and the D-ABORT User Data parameter contains an AircraftPDUs [CPDLCUserAbortReason] APDU, the CPDLC-ground-ASE shall:

a) stop any timer;

b) if the CPDLC-ground-user is an active user, invoke CPDLC-user-abort service indication with the APDU contained in the D-ABORT User Data parameter as the CPDLC-user-abort service Reason parameter value;



3.5.5.15.2 Upon receipt of a D-ABORT indication, if the CPDLC-ground-ASE is not in the IDLE state, and the D-ABORT Originator parameter is “provider”, and the D-ABORT User Data parameter is provided, and the D-ABORT User Data parameter contains either an AircraftPDUs [CPDLCProviderAbortReason] APDU or a GroundPDUs [CPDLCProviderAbortReason] APDU, the CPDLC-ground-ASE shall:

a) stop any timer;

b) if the CPDLC-ground-user is an active user, invoke CPDLC-provider-abort service indication with the D-ABORT User Data parameter as the CPDLC-provider-abort service Reason parameter value, if provided;



3.5.5.16 D-P-ABORT indication

Upon receipt of a D-P-ABORT indication, if the CPDLC-ground-ASE is not in the IDLE state, the CPDLC-ground-ASE shall:

a) stop any timer;

b) if the CPDLC-ground-user is an active user, invoke CPDLC-provider-abort service indication with the CPDLC-provider-abort service Reason parameter set to the abstract value “communication-service-failure”;



3.5.6 CPDLC-ground-ASE exception handling

9535953695379538953995409541954295439544954595469547954895499550955195529553955495559556955795589559956095619562956395649565956695679568956995709571957295739574957595769577957895799580958195829583958495859586


3.5.6.1 A timer expires

If a CPDLC-ground-ASE detects that a timer has expired, that CPDLC-ground-ASE shall:

a) interrupt any current activity;

b) create a GroundPDUs APDU with a CPDLCProviderAbortReason [timer-expired] APDU message element;




d) if the CPDLC-ground-user is an active user, invoke CPDLC-provider-abort service indication with the abstract value “timer-expired” as the CPDLC-provider-abort service Reason parameter value”;




If a CPDLC-ground-ASE has an unrecoverable system error, the CPDLC-ground-ASE should:

a) stop any timer;

b) create a GroundPDUs APDU with a CPDLCProviderAbortReason [undefined-error] APDU message element;




d) if the CPDLC-ground-user is an active user, invoke CPDLC-provider-abort service indication with the abstract value “undefined-error” as the CPDLC-provider-abort service Reason parameter value”;



3.5.6.3 Invalid PDU

3.5.6.3.1 If the User Data parameter of a D-END confirmation with the Result parameter set to the abstract value “rejected”, or the User Data parameter of a D-START confirmation with the Result parameter set to the abstract value "accepted", or the User Data parameter of a D-START indication, a D-DATA indication or a D-END indication does not contain a valid PDU, the CPDLC-ground-ASE shall:

9587958895899590959195929593959495959596959795989599960096019602960396049605960696079608960996109611961296139614961596169617961896199620962196229623962496259626962796289629963096319632963396349635963696379638


a) stop any timer;

b) create a GroundPDUs APDU with a CPDLCProviderAbortReason [invalid-PDU] APDU message element;

9639964096419642964396449645





d) if the CPDLC-ground-user is an active user, invoke CPDLC-provider-abort service indication with the abstract value “invalid-PDU” as the CPDLC-provider-abort service Reason parameter value;



3.5.6.3.2 If the User Data parameter of a D-START confirmation with the Result parameter set to the abstract value “rejected (permanent)”, or a D-END confirmation with the Result parameter set to the abstract value “accepted” is not a valid PDU, the CPDLC-ground-ASE shall:

a) stop any timer;

b) if the CPDLC-ground-user is an active user, invoke CPDLC-provider-abort service indication with the CPDLC-provider-abort service Reason parameter set to the abstract value “invalid-PDU”;



3.5.6.4 Protocol error

3.5.6.4.1 If the User Data parameter of a D-START indication, a D-START confirmation, a D-DATA indication or a D-END indication is a valid PDU; however, it is not a PDU for which action is described within a given state as defined in 3.5.5, the CPDLC-ground-ASE shall:

a) stop any timer;

b) create a GroundPDUs APDU with a CPDLCProviderAbortReason [protocol-error] APDU message element;




d) if the CPDLC-ground-user is an active user, invoke CPDLC-provider-abort service indication with the abstract value “protocol-error” as the CPDLC-provider-abort service Reason parameter value;



9646964796489649965096519652965396549655965696579658965996609661966296639664966596669667966896699670967196729673967496759676967796789679968096819682968396849685968696879688968996909691969296939694969596969697


3.5.6.4.2 If the User Data parameter of a D-END confirmation is a valid PDU; however, it is not a permitted PDU for which action is described within a given state as defined in 3.5.5, the CPDLC-ground-ASE shall:

a) stop any timer;

b) if the D-END Result parameter is set to the abstract value “rejected”, then:

1) create a GroundPDUs APDU with a CPDLCProviderAbortReason [protocol-error] APDU message element; and




c) if the CPDLC-ground-user is an active user, invoke CPDLC-provider-abort service indication with the abstract value “protocol-error” as the CPDLC-provider-abort service Reason parameter value;



3.5.6.4.3 Upon receipt of a DS primitive for which there are no instructions in 3.5.3 (i.e. the primitive was not expected or was expected under other conditions or with other parameter values), the CPDLC-ground-ASE shall:

a) stop any timer;

b) create a GroundPDUs APDU with a CPDLCProviderAbortReason [protocol-error] APDU message element;

c) if a dialogue exists, invoke D-ABORT request with:



d) if the CPDLC-ground-user is an active user, invoke CPDLC-provider-abort service indication with the abstract value “protocol-error” as the CPDLC-provider-abort service Reason parameter value;



3.5.6.5 D-START confirmation Result parameter or Reject Source parameter not as expected

If a D-START confirmation Result parameter has the abstract value of “rejected (transient)”, or if the Reject Source parameter has the abstract value of “DS-provider”, the CPDLC-ground-ASE shall:

969896999700970197029703970497059706970797089709971097119712971397149715971697179718971997209721972297239724972597269727972897299730973197329733973497359736973797389739974097419742974397449745974697479748


a) stop any timer;

b) if the CPDLC-ground-user is an active user, invoke CPDLC-provider-abort service indication with the CPDLC-provider-abort service Reason parameter set to the abstract value “communication-service-error”;




If a D-START indication QOS Priority parameter does not have the abstract value of “high priority flight safety messages”, or if the QOS Residual Error Rate parameter does not have the abstract value of “low”, or if the QOS Routing Class parameter does not have one of the abstract values specified in Table 3-13 (see 3.6.2.2), the CPDLC-ground-ASE shall:

a) stop any timer;

b) create a GroundPDUs APDU with a CPDLCProviderAbortReason [invalid-QOS-parameter] APDU message element;






3.5.6.7 Expected PDU missing

If the User Data parameter of a D-START indication or confirmation, a D-DATA indication, or a D-END indication or confirmation does not contain a PDU, the CPDLC-ground-ASE shall:

a) stop any timer;

b) create a GroundPDUs APDU with a CPDLCProviderAbortReason [expected-PDU-missing] APDU message element;




d) if the CPDLC-ground-user is an active user, invoke CPDLC-provider-abort service indication with the abstract value “not-permitted-PDU” as the CPDLC-provider-abort service Reason parameter value;

9749975097519752975397549755975697579758975997609761976297639764976597669767976897699770977197729773977497759776977797789779978097819782978397849785978697879788978997909791979297939794979597969797979897999800





Note.— This section applies to the case when the D-START Security Requirements parameter does not meet the local security policy.

Upon receipt of a D-START indication with the Security Requirements parameter not consistent with the local security policy, or upon receipt of a D-START confirmation with the Security Requirements parameter not equal to the value that was set in the D-START request, the CPDLC-ground-ASE shall:

a) stop all timers;


1) create a GroundPDUs APDU with a CPDLCProviderAbortReason [communication-service-failure] APDU message element; and




c) if the CPDLC-ground-user is active, invoke CPDLC-provider-abort service indication with the abstract value “communication-service-failure” as the CDPLC-provider-abort service Reason parameter value;



3.5.7 CPDLC-ASE state tables

3.5.7.1 Priority

3.5.7.1.1 If the state tables for the CPDLC-air-ASE and the CPDLC-ground-ASE at Tables 3-11 and 3-12, respectively, conflict with textual statements made elsewhere in this manual, the textual statements shall take precedence.

3.5.7.1.2 In the state tables at Tables 3-11 and 3-12, the statement “cannot occur” means that if the implementation conforms to the SARPs, it is impossible for this event to occur. If the event does occur, this implies that there is an error in the implementation. If such a situation is detected, it is suggested that the ASE abort with the error “unrecoverable system error”.

3.5.7.1.3 In the state tables at Tables 3-11 and 3-12, the statement “not permitted” means that the implementation must prevent this event from occurring through some local means. If the event does occur, this implies that there is an error in the implementation. If such a situation is detected, it is suggested that the ASE perform a local rejection of the request rather than aborting the dialogue.

98019802980398049805980698079808980998109811981298139814981598169817981898199820982198229823982498259826982798289829983098319832983398349835983698379838983998409841984298439844984598469847984898499850985198529853


Table 3-11. CPDLC-air-ASE state table

STATE →EVENT ↓ IDLE START-REQ START-IND DIALOGUE END

Dialogue Service Events

D-START IndicationAPDU = ICUplinkMessage(startup)

● CPDLC-start indication→START-IND


D-START ConfirmationResult “accepted”,DSC = “false”APDU = ICUplinkMessage (send)

cannot occur ●Stop timer tstart

● CPDLC-start confirmation→DIALOGUE


D-START ConfirmationResult “rejected (permanent)” and Reject Source “DS-user”,DSC = “false”APDU = ICUplinkMessage(send)


● CPDLC-start confirmation→IDLE


D-START ConfirmationResult “accepted”,DSC = “true”APDU = ICUplinkMessage (send)


● DSC-start confirmation,→DIALOGUE


D-START ConfirmationResult “rejected (permanent)” and Reject Source “DS-user”,DSC = “true”APDU = ICUplinkMessage(send)


● DSC-start confirmation●Set DSC = “false”→IDLE


D-DATA IndicationAPDU = ICUplinkMessage (send)

cannot occur cannot occur cannot occur ●CPDLC-message indication→DIALOGUE

●if DSC = “true”● CPDLC-message indication→END

●else cannot occur

D-END Indication DSC = “false"APDU = ICUplinkMessage(send)

cannot occur cannot occur cannot occur ● CPDLC-end indication→END

cannot occur

D-END ConfirmationDSC = “true”Result “accepted”APDU = ICUplinkMessage (send)

cannot occur cannot occur cannot occur cannot occur ● DSC-end confirmation●Set DSC “false”→IDLE

D-END ConfirmationDSC = “true”Result “rejected”APDU = ICUplinkMessage(send)

cannot occur cannot occur cannot occur cannot occur ● DSC-end confirmation→DIALOGUE

98549855



CPDLC-User Events

CPDLC-start Request ●D-START request●Start timer tstart

→START-REQ

not permitted not permitted not permitted not permitted

CPDLC-start ResponseDSC = “false”Result “accepted”

not permitted not permitted ●D-START response→DIALOGUE

not permitted not permitted

CPDLC-start ResponseDSC = “false”Result “rejected”

not permitted not permitted ●D-START response→IDLE


DSC-start Request ●D-START request●set DSC = “true”●Start timer tstart

→START-REQ

not permitted not permitted not permitted not permitted

CPDLC-message Request not permitted not permitted not permitted ●D-DATA request→DIALOGUE

●if DSC = “false”●D-DATA request→END

●else not permitted

CPDLC-end Service ResponseDSC = “false”Result “accepted”

cannot occur cannot occur cannot occur not permitted ●D-END response→IDLE

CPDLC-end Service ResponseDSC = “false”Result “rejected”

cannot occur cannot occur cannot occur not permitted ●D-END response→DIALOGUE

DSC-end RequestDSC = “true”

not permitted not permitted not permitted ●D-END request→END

not permitted

ABORT Events

CPDLC-user-abort Request

not permitted ●Stop timer tstart, if set●D-ABORT request●If DSC = “true”, set DSC = “false”→IDLE

●Stop timer tstart, if set●D-ABORT request●If DSC = “true”, set DSC = “false”→IDLE

●D-ABORT request●If DSC = “true”, set DSC = “false”→IDLE

●D-ABORT request●If DSC = “true”, set DSC = “false”→IDLE

D-ABORT IndicationOriginator “user”

cannot occur ●Stop timer Tstart, if set●If active user: CPDLC-user-abort indication●If DSC = “true”, set DSC = “false”→IDLE

●Stop timer Tstart, if set●If active user: CPDLC-user-abort indication●If DSC = “true”, set DSC = “false”→IDLE

●If active user: CPDLC-user-abort indication●If DSC = “true”, set DSC = “false”→IDLE

●If active user: CPDLC-user-abort indication●If DSC = “true”, set DSC = “false”→IDLE



D-ABORT IndicationOriginator “provider”

cannot occur ●Stop timer Tstart, if set●If active user: CPDLC-provider-abort indication●If DSC = “true”, set DSC “false”→IDLE

●Stop timer Tstart, if set●If active user: CPDLC-provider-abort indication●If DSC = “true”, set DSC “false”→IDLE

●If active user: CPDLC-provider-abort indication●If DSC = “true”, set DSC “false”→IDLE

●If active user: CPDLC-provider-abort indication●If DSC = “true”, set DSC “false”→IDLE

D-P-ABORT Indication cannot occur ●Stop timer tstart, if set●If active user: CPDLC-provider-abort indication●If DSC = “true”, set DSC = “false”→IDLE

●Stop timer tstart, if set●If active user: CPDLC-provider-abort indication●If DSC = “true”, set DSC = “false”→IDLE

●If active user: CPDLC-provider-abort indication●If DSC = “true”, set DSC = “false”→IDLE

●If active user: CPDLC-provider-abort indication●If DSC = “true”, set DSC = “false”→IDLE

Tstart Expires cannot occur ●D-ABORT request● CPDLC-provider-abort indication●If DSC = “true”, set DSC = “false”→IDLE


Table 3-12. CPDLC-ground-ASE state table

STATE →

EVENT ↓ IDLE START-REQ START-IND DIALOGUE END FORWARD

Dialogue Service Events

D-START IndicationAPDU Aircraftmode “cpdlc”

● CPDLC-start indication→START-IND

cannot occur cannot occur cannot occur cannot occur cannot occur

D-START IndicationAPDU Aircraftmode “dsc”

● DSC-start indication,●Set DSC = “true”→START-IND


D-START IndicationAPDU Forwardversion equal and function supported

● CPDLC-forward indication●D-START response→IDLE


D-START IndicationAPDU Forwardversion not equal or function not supported



9856985798589859


STATE →


D-START ConfirmationResult “accepted”DSC = “false”


● CPDLC-start confirmation→DIALOGUE


D-START ConfirmationResult “rejected (permanent)” and Reject Source “DS-user”DSC = “false”


● CPDLC-start confirmation→IDLE

cannot occur cannot occur cannot occur ●Stop timer tstart

●CPDLC-forward confirmation→IDLE

D-DATA Indication cannot occur cannot occur cannot occur ●CPDLC-message indication→DIALOGUE

●if DSC = “false●CPDLC-message indication→END


cannot occur

D-END IndicationDSC = “true”

cannot occur cannot occur cannot occur ●DSC-end indication→END


D-END ConfirmationDSC = “false”Result “accepted”

cannot occur cannot occur cannot occur cannot occur ●CPDLC-end confirmation→IDLE

cannot occur

D-END ConfirmationDSC = “false”Result “rejected”

cannot occur cannot occur cannot occur cannot occur ●CPDLC-end confirmation→DIALOGUE

cannot occur

CPDLC-User Events

CPDLC-start Request ●D-START request●Start timer tstart

→START-REQ


CPDLC-start ResponseDSC = “false”Result “accepted”


not permitted not permitted not permitted

CPDLC-start ResponseDSC = “false”Result “rejected”

not permitted not permitted ●D-START response→IDLE


DSC-start ResponseDSC = “true”Result “accepted”



DSC-start ResponseDSC = “true”Result “rejected”

not permitted not permitted ●D-START response●Set DSC = “false”→IDLE



STATE →


CPDLC-message Request

not permitted not permitted not permitted ●D-DATA request→DIALOGUE

●If DSC = “true”●D-DATA request→END


not permitted

CPDLC-end RequestDSC = “false”

not permitted not permitted not permitted ●D-END request→END


DSC-end Service ResponseDSC = “true”Result “accepted”

cannot occur cannot occur cannot occur not permitted ●D-END response●Set DSC = “false”→IDLE

not permitted

DSC-end Service ResponseDSC = “true”Result “rejected”

cannot occur cannot occur cannot occur not permitted ●D-END response→DIALOGUE

not permitted

CPDLC-forward Request

●D-START request●Start timer tstart

→FORWARD


ABORT Events

CPDLC-user-abort Request

not permitted ●Stop timer tstart, if set●D-ABORT request●If DSC = “true”, set DSC= “false”→IDLE

●Stop timer tstart, if set●D-ABORT request●If DSC = “true”, set DSC= “false”→IDLE

●D-ABORT request●If DSC = “true”, set DSC= “false”→IDLE

●D-ABORT request●If DSC = “true”, set DSC= “false”→IDLE

●Stop timer tstart, if set●D-ABORT request→IDLE

D-ABORT Indication Originator “provider”

cannot occur ●Stop timer Tstart, if set●If active user: CPDLC-provider-abort indication●If DSC = “true”, set DSC= “false”→IDLE

●Stop timer Tstart, if set●If active user: CPDLC-provider-abort indication●If DSC = “true”, set DSC= “false”→IDLE

●If active user: CPDLC-provider-abort indication●If DSC = “true”, set DSC= “false”→IDLE


●Stop timer Tstart, if set●If active user: CPDLC-provider-abort indication→IDLE

D-ABORT IndicationOriginator “user”

cannot occur ●Stop timer Tstart, if set●If active user: CPDLC-user-abort indication●If DSC = “true”, set DSC= “false”→IDLE

●Stop timer Tstart, if set●If active user: CPDLC-user-abort indication●If DSC = “true”, set DSC= “false”→IDLE

●If active user: CPDLC-user-abort indication●If DSC = “true”, set DSC= “false”→IDLE

●If active user: CPDLC-user-abort indication●If DSC = “true”, set DSC= “false”→IDLE

●Stop timer Tstart, if set●If active user: CPDLC-user-abort indication→IDLE


STATE →


D-P-ABORT Indication

cannot occur ●Stop timer tstart, if set●If active user: CPDLC-provider-abort indication●If DSC = “true”, set DSC= “false”→IDLE

●Stop timer tstart, if set●If active user: CPDLC-provider-abort indication●If DSC = “true”, set DSC= “false”→IDLE



●Stop timer tstart, if set●If active user: CPDLC-provider-abort indication→IDLE

Tstart Expires cannot occur ●D-ABORT request● CPDLC-provider-abort indication●If DSC = “true”, set DSC= “false”→IDLE

cannot occur cannot occur cannot occur ●D-ABORT request● CPDLC-provider-abort indication→IDLE

3.6 COMMUNICATION REQUIREMENTS

3.6.1 Encoding rules

3.6.1.1 The CPDLC application shall apply PER encoding as defined in ISO/IEC 8825-2, using the basic unaligned variant to encode/decode the ASN.1 CPDLC message structure and content specified in 3.4.

3.6.1.2 When CPDLC APDUs are treated as bit-oriented values that are not padded to an integral number of octets, the length determinant includes only the significant bits of the encoding corresponding to the ASN.1 type.

3.6.2 Dialogue service requirements

3.6.2.1 Primitive requirements

Where dialogue service primitives, i.e. D-START, D-DATA, D-END, D-ABORT and D-P-ABORT, are described as being invoked in 3.5, the CPDLC-ground-ASE and the CPDLC-air-ASE shall exhibit external behaviour consistent with the dialogue service, as described in Part III of this manual, having been implemented and its primitives invoked.

3.6.2.2 Quality of Service requirements

3.6.2.2.1 The application service priority for CPDLC shall have the abstract value of “high priority flight safety messages”.

3.6.2.2.2 The RER Quality of Service parameter of the D-START for CPDLC shall be set to the abstract value of “low”.

9860986198629863

9865986698679868986998709871987298739874987598769877987898799880988198829883988498859886988798889889989098919892


3.6.2.2.3 The CPDLC-ASE shall map the CPDLC-start service or DSC-start service Class of Communication parameter abstract value to the ATSC routing class abstract value part of the D-START Quality of Service parameter as presented in Table 3-13.

Table 3-13. Mapping between class of communication and routing class abstract values

Class of communication abstract value Routing class abstract value

No preference No traffic type policy preference









Note.— ATSC class values are defined in Part IV of this manual.

3.6.2.3 ATN Security Requirements parameter

The Security Requirements parameter of the D-START shall be set to either “secured exchange” or “no security” for the CPDLC-start, DSC-start and CPDLC-forward services.


3.7 CPDLC-USER REQUIREMENTS

3.7.1 General

Note 1.— Requirements imposed on CPDLC-users concerning CPDLC messages and interfacing with the CPDLC-ASEs are presented in this section.

Note 2.— Where reference is made to the “CPDLC-user”, this implies both the CPDLC-air-user and the CPDLC-ground-user.

Note 3.— “CPDLC/IC Data” is:

a) what the CPDLC-user provides to the CPDLC-service as the CPDLC/IC Data or Response CPDLC/IC Data parameter when invoking a CPDLC-service request or response primitive; or

9893989498959896989798989899

99009901990299039904990599069907990899099910991199129913991499159916991799189919992099219922992399249925992699279928


b) what the CPDLC-user receives in the same parameters from the CPDLC-service indication or confirmation primitives.

992999309931


Note 4.— A “CPDLC message” is an uplink or downlink message exchanged between CPDLC-users as part of the CPDLC/IC Data.

Note 5.— The terms “CPDLC message”, “message”, “uplink message” and “downlink message” are used interchangeably and equate to a CPDLC message. When the terms “send” and “transmit” are used, it means that the CPDLC-user has invoked a CPDLC-service request or response primitive. When the term “receive” is used, it means that a CPDLC indication or confirmation primitive parameter containing a CPDLC/IC Data value has been provided by the CPDLC-service.

Note 6.— A CPDLC-air-user uses the contents of an uplink CPDLC/IC Data item to verify that it has been delivered to the correct destination, as identified by the combination of flight identification and ICAO 24-bit aircraft address, and is from the appropriate data authority, and that it was encoded and decoded by the CPDLC-users using the same CPDLC abstract syntax version.

Note 7.— A CPDLC-ground-user uses the contents of a downlink CPDLC/IC Data item to verify that it has been delivered to the correct destination and is from the expected aircraft, as identified by the combination of flight identification and ICAO 24-bit aircraft address, and that it was encoded and decoded by the CPDLC-users using the same CPDLC abstract syntax version.

Note 8.— The verification of correct delivery is performed by the CPDLC-user and not by the CPDLC-ASE. This avoids placing any reliance on the communications protocols or their implementation for a proof of correct delivery or a proof that data integrity has been maintained.

Note 9.— Use of an integrity check generation/validation algorithm other than the ATN message checksum specified in Chapter 6 of this manual is out of scope of this specification and requires prior agreement by both CPDLC-air-users and CPDLC-ground-users.

3.7.1.1 General CPDLC-service requirements

3.7.1.1.1 A CPDLC-ground-user shall invoke CPDLC-start service, DSC-start service, CPDLC-message service, CPDLC-end service and DSC-end service only when communicating with a CPDLC-air-user.

3.7.1.1.2 A CPDLC-ground-user shall invoke CPDLC-forward service only when communicating with another CPDLC-ground-user.

3.7.1.1.3 When a CPDLC-user invokes the CPDLC-start service, the DSC-start service or the CPDLC-forward service and requires a particular class of communication service, the CPDLC-user sets the Class of Communication Service parameter.

3.7.1.1.4 When a CPDLC-user does not require a particular class of communication, the user does not set the Class of Communication Service parameter.

3.7.1.1.5 When the CPDLC-user requires secure or unsecure services, the user sets the Security Required parameter as appropriate.

3.7.2 CPDLC/IC Data generation requirements

Note.— When it is required that a CPDLC-user send a CPDLC message within the CPDLC/IC Data parameter of a CPDLC-start, a DSC-start, a CPDLC message, a CPDLC-end, or a DSC-end primitive, it is implied that the CPDLC message is encoded within an ICUplinkMessage or ICDownlinkMessage as specified in this section.3.7.2.1 Downlink CPDLC/IC Data

9932993399349935993699379938993999409941994299439944994599469947994899499950995199529953995499559956995799589959996099619962996399649965996699679968996999709971997299739974997599769977997899799980998199829983


3.7.2.1.1 The CPDLC-air-user shall compose a downlink CPDLC/IC Data value from: a) an optional identifier for the algorithm used to compute the integrity check;

b) an optional downlink CPDLC message; and

c) an integrity check.

Note 1.— The algorithm identifier identifies both the algorithm used to generate the checksum and the data over which the checksum is generated. In the default case, the algorithm used to compute the checksum is the default ATN message checksum generation algorithm, and the data over which the checksum is generated is the PseudoCPDLCMessage, specified in 3.7.3.

Note 2.— The integrity check can be generated even when a CPDLC message is not present. With the default integrity check, the sender and receiver can still be verified.

3.7.2.1.2 Unless it is has been agreed by means outside of this specification that an alternative integrity check generation algorithm be used, the CPDLC-air-user shall compute the integrity check using the default integrity check generation algorithm as specified in Chapter 6.

3.7.2.1.3 The default integrity check generation algorithm shall be the computation of the integrity check using the default ATN message checksum specified in Chapter 6 over the PseudoCPDLCMessage specified in 3.7.3.

3.7.2.1.4 When a downlink CPDLC message is provided in a CPDLC/IC Data or Response CPDLC/IC Data parameter, it shall be created by the CPDLC-air-user from an ATCDownlinkMessage, as defined in 3.4.3, and encoded using the basic unaligned PER variant.

Note.— When the CPDLC message is treated as bit-oriented values that are not padded to an integral number of octets, the length determinant includes only the significant bits of the encoding corresponding to the ASN.1 type.

3.7.2.1.5 When the value of the integrity check is computed using the default integrity check generation algorithm specified in Chapter 6, the CPDLC-air-user shall omit the algorithm identifier on the first downlink CPDLC/IC Data value or set it to the algorithm identifier “atn-default-checksum”.

3.7.2.1.6 When an integrity check generation algorithm other than the default is used, the CPDLC-air-user shall set the algorithm identifier on the first downlink CPDLC/IC Data value to the value of the relative object identifier (OID) that identifies the integrity check generation algorithm used, as specified in Chapter 6.

3.7.2.1.7 In subsequent downlink CPDLC/IC Data values, the CPDLC-air-user shall omit the algorithm identifier.

3.7.2.2 Uplink CPDLC/IC Data

3.7.2.2.1 The CPDLC-ground-user shall compose an uplink CPDLC/IC Data value from:

a) an optional identifier for the algorithm used to compute the integrity check;

b) an optional uplink CPDLC message; and

c) an integrity check. Note.— The integrity check can be generated even when a CPDLC message is not present. With the

9984998599869987998899899990999199929993999499959996999799989999

10000100011000210003100041000510006100071000810009100101001110012100131001410015100161001710018100191002010021100221002310024100251002610027100281002910030100311003210033100341003510036


default integrity check, the sender and receiver can still be verified.

3.7.2.2.2 Unless it is has been agreed by means outside of this specification that an alternative integrity check algorithm is to be used, the CPDLC-ground-user shall compute the integrity check using the default integrity check generation algorithm as specified in Chapter 6.

3.7.2.2.3 When an uplink CPDLC message is provided in a CPDLC/IC Data or Response CPDLC/IC Data parameter, it shall be created by the CPDLC-ground-user from an ATCUplinkMessage, as defined in 3.4.3, and encoded using the basic unaligned PER variant.

Note.— When the CPDLC message is treated as bit-oriented values that are not padded to an integral number of octets, the length determinant includes only the significant bits of the encoding corresponding to the ASN.1 type.

3.7.2.2.4 When the value of the integrity check is computed using the default integrity check generation algorithm specified in Chapter 6, the CPDLC-ground-user shall omit the algorithm identifier on the first uplink CPDLC/IC Data value or set it to the algorithm identifier “atn-default-checksum”.

3.7.2.2.5 When an integrity check generation algorithm other than the default is used, the CPDLC-ground-user shall set the algorithm identifier on the first uplink CPDLC/IC Data value to the value of the relative OID that identifies the integrity check generation algorithm used, as specified in Chapter 6.

3.7.2.2.6 In subsequent uplink CPDLC/IC Data values, the CPDLC-ground-user shall omit the algorithm identifier.

3.7.3 The integrity check

3.7.3.1 General

3.7.3.1.1 The message to be used by the sending CPDLC-user to generate the integrity check shall consist of the unaligned basic PER encoding of the ASN.1 PseudoCPDLCMessage data type created from:

a) the aircraft flight identification assigned to the CPDLC-air-user, expressed in canonical form as defined in 3.7.3.2;

b) the ICAO 24-bit aircraft address assigned to the CPDLC-air-user;

c) the ground facility designator that identifies the CPDLC-ground-user for the CPDLC or DSC dialogue, being the same as that used for the Called Peer Identifier or Calling Peer Identifier parameter of the CPDLC-start service or DSC-start service used to initiate the CPDLC or DSC dialogue;

d) the abstract syntax identifier of the CPDLC message used for the current CPDLC or DSC dialogue; and

e) the unaligned basic PER-encoded value of the ATCUplinkMessage or ATCDownlinkMessage, as appropriate, if any such message is present.

Note 1.— The ground facility designator is used as the Called Peer Identifier for air-initiated CPDLC or DSC dialogues and as the Calling Peer Identifier for ground-initiated CPDLC dialogues.

Note 2.— The PseudoCPDLCMessage is created solely for the purposes of integrity check computation

10037100381003910040100411004210043100441004510046100471004810049100501005110052100531005410055100561005710058100591006010061100621006310064100651006610067100681006910070100711007210073100741007510076100771007810079100801008110082100831008410085100861008710088


and is never exchanged over a CPDLC or DSC dialogue.

3.7.3.1.2 The PseudoCPDLCMessage data type shall comply with the ASN.1 module ATCMessageIntegrityCheckVersion1, as defined hereinafter:

ATCMessageIntegrityCheckVersion1 DEFINITIONS ::=

BEGIN

IMPORTSAircraftFlightIdentification,AircraftAddress,FacilityDesignation FROM CPDLCMessageSetVersion1;

PseudoCPDLCMessage ::= SEQUENCE{flightID AircraftFlightIdentification,aircraftAddress AircraftAddress,facilityDesignator FacilityDesignation,cPDLCMessageAbstractSyntax OBJECT IDENTIFIER,embeddedMessage EncodedCPDLCMessage OPTIONAL}

EncodedCPDLCMessage ::= BIT STRING

END

3.7.3.2 Aircraft flight identification

Note.— The integrity check can only be correctly verified if both CPDLC-ground-users and CPDLC-air-users use the same aircraft flight identification expressed in exactly the same syntax. Either the aircraft registration (tail number) or the flight identification can be used but, in either case, the form used must be identical to that given in the associated flight plan (see Doc 4444, Appendix 2).

3.7.3.2.1 The aircraft flight identification (FlightID) shall be the aircraft identification as given in Field 7 of the filed flight plan.

3.7.3.2.2 When the aircraft registration marking is used as the FlightID, the FlightID shall be the registration marking of the aircraft expressed as a character string (maximum seven characters) using upper case IA5 alphabetic and numeric characters only and without any spaces or hyphens.

3.7.3.2.3 When the flight identification is used as the FlightID, the FlightID shall be a character string (maximum seven characters) using upper case IA5 alphabetic and numeric characters only and without any spaces or hyphens, and formed from the three-letter ICAO designator for the aircraft operating agency (see Designators for Aircraft Operating Agencies, Aeronautical Authorities and Services (Doc 8585)) followed by the flight number expressed as a numeric string with no leading zeroes.

Note.— Although the ASN.1 definition of the AircraftFlightIdentification permits the FlightID to be expressed as a character string of up to eight characters, Doc 4444 places a limit of seven characters on the aircraft flight identification in the flight plan.

3.7.4 CPDLC message generation requirements

10089100901009110092100931009410095100961009710098100991010010101101021010310104101051010610107101081010910110101111011210113101141011510116101171011810119101201012110122101231012410125101261012710128101291013010131101321013310134101351013610137101381013910140


3.7.4.1 General

3.7.4.1.1 A Response CPDLC/IC Data is a message which is a reply to a received message. It contains a message reference number identical to the message identification number of the message to which it refers. Only a Response CPDLC/IC Data contains a message reference number.

3.7.4.1.2 Message response attributes dictate if a response is required or prohibited; and if a response is required, they dictate the permitted Response CPDLC/IC Data.

3.7.4.1.3 A closure Response CPDLC/IC Data is a reply to a message or a series of messages which terminates a sequence of message exchanges. However due to the multiple element capability of a CPDLC message, a closure message may contain message element(s), in addition to the required closure message element, that initiates a new sequence of messages.

3.7.4.1.4 The CPDLC message specified in this section is the uplink or downlink message exchanged between the peer CPDLC-users. It is exchanged in PER-encoded form as the embeddedMessage element of a CPDLC/IC Data value.

3.7.4.2 Message composition

3.7.4.2.1 A CPDLC message shall be composed of a message header and from one to five message elements.

3.7.4.2.2 For air-ground messages, the message header shall be composed of a message identification number, a message reference number (if required), a time stamp and a logical ACKNOWLEDGEMENT requirement (optional).

3.7.4.2.3 For ground-ground messages, the message header shall be composed of a time stamp, the aircraft flight identification and the aircraft address to which the message refers.

3.7.4.2.4 A message element shall consist of a message element identifier, data as indicated by the specified message element, and associated message element attributes.

3.7.4.2.5 For each CPDLC message the CPDLC-user sends air-ground, it shall provide the following information:

a) a message identification number;

b) a message reference number only if the message is a Response CPDLC/IC Data;

c) date and time;

d) a logical ACKNOWLEDGEMENT indication, if required;

e) from one to five message element identifiers; and

f) data as required for each message element identification included.

3.7.4.2.6 For each CPDLC message the CPDLC-user sends ground-ground, it shall provide the following information:

a) the aircraft flight identification to which the ground-ground message refers;

10141101421014310144101451014610147101481014910150101511015210153101541015510156101571015810159101601016110162101631016410165101661016710168101691017010171101721017310174101751017610177101781017910180101811018210183101841018510186101871018810189101901019110192


b) date and time;

c) from one to five message element identifiers; and

d) data as required for each message element identification included.

3.7.4.3 Message identification number

3.7.4.3.1 A message identification number pertains to a single peer-to-peer dialogue.

3.7.4.3.2 Message identification numbers used by a CPDLC ground system for uplink messages to an aircraft have no relationship to the message identification numbers used by the same ground system with another aircraft.

3.7.4.3.3 Similarly, message identification numbers used by a CPDLC aircraft for downlink messages to a CPDLC ground system have no relationship to the message identification numbers used by the same aircraft with another ground system.

3.7.4.3.4 There is no relationship between message identification numbers assigned and managed by a CPDLC ground system and those message identification numbers assigned and managed by the aircraft.

3.7.4.3.5 The message identification number provided by the CPDLC-user shall be different from any other message identification number currently in use.

3.7.4.3.6 A message identification number shall be deemed currently in use until:

a) if the message does not allow a response, the message is sent; or

b) if the message requires a response, the closure response is received.

3.7.4.3.7 If a CPDLC or DSC dialogue is terminated, all message identification numbers pertaining to that dialogue shall be considered available.

3.7.4.4 Message elements that cannot be combined with other message elements in a message

3.7.4.4.1 The LOGICAL ACKNOWLEDGEMENT message element (uplink message element 227 and downlink message element 100) shall be sent only as a single message element CPDLC message.

3.7.4.4.2 The NEXT DATA AUTHORITY [facility] message element (uplink message element 160) shall be sent only as a single message element CPDLC message.

3.7.4.5 Restriction on route clearance variable message elements

A CPDLC message shall contain no more than two message elements with the [routeClearance] variable.

10193101941019510196101971019810199102001020110202102031020410205102061020710208102091021010211102121021310214102151021610217102181021910220102211022210223102241022510226102271022810229102301023110232102331023410235102361023710238102391024010241


3.7.5 CPDLC/IC Data receipt requirements

3.7.5.1 Downlink CPDLC/IC Data

3.7.5.1.1 On receipt of a downlink CPDLC/IC Data value, the integrity check verification procedure shall be performed before any other CPDLC message processing.

3.7.5.1.2 On receipt of the first downlink CPDLC/IC Data value, the CPDLC-ground-user shall verify the integrity check verification procedure using:

a) the ATN message checksum verification procedure specified in Chapter 6 of this manual if the downlink CPDLC/IC Data does not contain an algorithm identifier or if it contains the algorithm identifier “atn-default-checksum”; or

b) the specified algorithm if the downlink CPDLC/IC Data contains any other algorithm identifier.

3.7.5.1.3 On receipt of a subsequent downlink CPDLC/IC Data value, the CPDLC-ground-user shall:

a) ignore the specified algorithm if the downlink CPDLC/IC Data contains an algorithm identifier; and

b) verify the integrity check using the integrity check verification procedure used for the preceding downlink CPDLC/IC Data value.

3.7.5.1.4 On receipt of a downlink CPDLC/IC Data value containing an unrecognized integrity check algorithm identifier, the CPDLC-ground-user shall:

a) discard the received downlink CPDLC/IC Data; and

b) invoke the CPDLC-user-abort request primitive with the Reason parameter set to CPDLCUserAbortReason value [unknown-integrity-check].

Note.— This includes the case when a CPDLC-start or a DSC-start indication is received with a downlink CPDLC/IC Data value that includes an unrecognized algorithm identifier.

3.7.5.1.5 When the integrity check verification procedure fails, the CPDLC-ground-user shall:

a) discard the received downlink CPDLC/IC Data; and

b) invoke the CPDLC-user-abort request primitive with the Reason parameter set to CPDLCUserAbortReason value [validation-failure].

Note.— This includes the case when a CPDLC-start or a DSC-start indication is received with a downlink CPDLC/IC Data value and the integrity check verification procedure fails.

3.7.5.1.6 If the integrity check verification procedure of a downlink CPDLC/IC Data value succeeds, then the embeddedMessage element of the downlink CPDLC/IC Data shall be decoded as an ATCDownlinkMessage using unaligned basic PER, and processed by the CPDLC-ground-user, as specified in 3.7.6 and 3.7.8.

3.7.5.1.7 If the CPDLC message received in a downlink CPDLC/IC Data value cannot be successfully decoded as an ATCDownlinkMessage, then the CPDLC-ground-user shall:

10242102431024410245102461024710248102491025010251102521025310254102551025610257102581025910260102611026210263102641026510266102671026810269102701027110272102731027410275102761027710278102791028010281102821028310284102851028610287102881028910290102911029210293


a) discard the received downlink CPDLC message; and

b) invoke the CPDLC-user-abort request primitive with the Reason parameter set to CPDLCUserAbortReason value [unable-to-decode-message].

3.7.5.2 Uplink CPDLC/IC Data

3.7.5.2.1 On receipt of an uplink CPDLC/IC Data value, the integrity check verification procedure shall be performed before any other CPDLC message processing.

3.7.5.2.2 On receipt of the first uplink CPDLC/IC Data, the CPDLC-air-user shall verify the integrity check verification procedure using:

a) the ATN message checksum verification procedure specified in Chapter 6 of this manual if the uplink CPDLC/IC Data does not contain an algorithm identifier or if it contains the algorithm identifier “atn-default-checksum”; or

b) the specified algorithm if the uplink CPDLC/IC Data contains any other algorithm identifier.

3.7.5.2.3 On receipt of a subsequent uplink CPDLC/IC Data value, the CPDLC-air-user shall:

a) ignore the specified algorithm if the uplink CPDLC/IC Data contains an algorithm identifier; and

b) verify the integrity check using the integrity check verification procedure used for the preceding uplink CPDLC/IC Data value.

3.7.5.2.4 On receipt of an uplink CPDLC/IC Data value containing an unrecognized integrity check algorithm identifier, the CPDLC-air-user shall:

a) discard the received uplink CPDLC/IC Data; and

b) invoke the CPDLC-user-abort request primitive with the Reason parameter set to CPDLCUserAbortReason value [unknown-integrity-check].

Note.— This includes the case when a CPDLC-start indication is received with an uplink CPDLC/IC Data value that includes an unrecognized algorithm identifier.

3.7.5.2.5 When the integrity check verification procedure fails, the CPDLC-air-user shall:

a) discard the received uplink CPDLC/IC Data; and

b) invoke the CPDLC-user-abort request primitive with the Reason parameter set to CPDLCUserAbortReason value [validation-failure].

Note.— This includes the case when a CPDLC-start indication is received with an uplink CPDLC/IC Data value and the integrity check verification procedure fails.

3.7.5.2.6 If the integrity check verification procedure of an uplink CPDLC/IC Data value succeeds, then the embeddedMessage element of the uplink CPDLC/IC Data shall be decoded as an ATCUplinkMessage using unaligned basic PER, and processed by the CPDLC-air-user as specified in 3.7.6 and 3.7.7.

10294102951029610297102981029910300103011030210303103041030510306103071030810309103101031110312103131031410315103161031710318103191032010321103221032310324103251032610327103281032910330103311033210333103341033510336103371033810339103401034110342103431034410345


3.7.5.2.7 If the CPDLC message received in an uplink CPDLC/IC Data value cannot be successfully decoded as an ATCUplinkMessage, then the CPDLC-air-user shall:

a) discard the received uplink CPDLC message; and

b) invoke the CPDLC-user-abort request primitive with the Reason parameter set to CPDLCUserAbortReason value [unable-to-decode-message].

3.7.6 CPDLC message receipt requirements

Note.— The CPDLC message specified in this section is the uplink or downlink message exchanged between peer CPDLC-users. It is exchanged in PER-encoded form as the embeddedMessage element of a CPDLC/IC Data value. Before the CPDLC message is processed as specified here, it will have successfully passed the integrity check verification procedure.

3.7.6.1 Message attributes

3.7.6.1.1 Message attributes dictate certain message handling requirements for the CPDLC-user receiving a message. Each CPDLC message has Urgency, Alert and Response attributes.

3.7.6.1.2 Message element attribute table entries are listed in order of precedence (i.e. a precedence value of 1 is highest followed by 2, etc.).

3.7.6.1.3 When a message contains a single message element, the message attributes shall be the message element attributes.

3.7.6.1.4 When a message contains multiple message elements, the highest precedence message element attribute for each attribute type associated with any element in the message shall be the message attribute for each attribute type for the entire message.

3.7.6.2 Urgency requirements

3.7.6.2.1 The Urgency (URG) attribute delineates the queuing requirements for received messages that are displayed to the end-user. The same Urgency attribute types are used for both air-ground and ground-ground messages.

3.7.6.2.2 Each message element shall have the associated Urgency attributes and precedence as defined in Table 3-14.

Table 3-14. Urgency attribute (air-ground and ground-ground)

Type Description Precedence

D Distress 1

U Urgent 2

N Normal 3

103461034710348103491035010351103521035310354103551035610357103581035910360103611036210363103641036510366103671036810369103701037110372103731037410375103761037710378103791038010381103821038310384103851038610387103881038910390


L Low 4

3.7.6.2.3 When a CPDLC-user queues received messages, messages with the highest Urgency type shall be placed at the beginning of the queue.

3.7.6.2.4 When a CPDLC-user queues received messages, messages with the same Urgency type shall be queued in order of receipt.

3.7.6.3 Alerting requirements

3.7.6.3.1 The Alert (ALRT) attribute delineates the type of end-user alerting required by the CPDLC-user upon message receipt. The same Alert attribute types are used for both air-ground and ground-ground messages.

3.7.6.3.2 Each message element shall have the associated Alert attributes and precedence as defined in Table 3-15.

Table 3-15. Alert attribute (air-ground and ground-ground)

Type Description Precedence

H High 1

M Medium 2

L Low 3

N No alerting required 4

3.7.6.3.3 Upon receipt of a CPDLC message, the CPDLC-user shall provide one of three distinct alerts as determined by the received message Alert attribute.

3.7.6.4 Response attribute

3.7.6.4.1 The Response (RESP) attribute mandates CPDLC-user response requirements for a given message element. The Response CPDLC/IC Data attribute only applies to air-ground messages.

3.7.6.4.2 Each uplink message element shall have the associated Response attributes and precedence as defined in Table 3-16.

Table 3-16. Response attribute (uplink)

Type Response required Valid responses description Precedence

W/U Yes Response required: WILCO, UNABLE, STANDBY, NOT CURRENT DATA AUTHORITY, NOT AUTHORIZED NEXT DATA AUTHORITY, ERROR, LOGICAL ACKNOWLEDGEMENT (only if required)

1

103911039210393103941039510396103971039810399104001040110402104031040410405104061040710408

10409104101041110412104131041410415104161041710418104191042010421104221042310424



A/N Yes Response required: AFFIRM, NEGATIVE, STANDBY, NOT CURRENT DATA AUTHORITY, NOT AUTHORIZED NEXT DATA AUTHORITY, ERROR, LOGICAL ACKNOWLEDGEMENT (only if required)

2

R Yes Response required: ROGER, UNABLE, STANDBY, NOT CURRENT DATA AUTHORITY, NOT AUTHORIZED NEXT DATA AUTHORITY, ERROR, LOGICAL ACKNOWLEDGEMENT (only if required)

3

Y Yes Any CPDLC downlink message, LOGICAL ACKNOWLEDGEMENT (only if required)

4

N No, unless logical ACKNOWLEDGEMENT required

LOGICAL ACKNOWLEDGEMENT (only if required), ERROR, NOT CURRENT DATA AUTHORITY or NOT AUTHORIZED NEXT DATA AUTHORITY

5

3.7.6.4.3 Each downlink message element shall have the associated Response attributes and precedence as defined in Table 3-17.

Table 3-17. Response attribute (downlink)


Y Yes Any CPDLC uplink message,LOGICAL ACKNOWLEDGEMENT (only if required)

1

N No, unless logical ACKNOWLEDGEMENT required

LOGICAL ACKNOWLEDGEMENT (only if required), ERROR, SERVICE UNAVAILABLE, or FLIGHT PLAN NOT HELD

2

3.7.6.5 CPDLC/DSC distinction

Upon receipt of a CPDLC message, the CPDLC-air-user shall provide a distinction between CPDLC messages received from the current data authority and those received from a downstream data authority.

3.7.6.6 Air-ground and ground-ground distinction

Upon receipt of a CPDLC message, the CPDLC-ground-user shall provide a distinction between CPDLC messages received from an aircraft and those received from another ground system.

3.7.6.7 Logical ACKNOWLEDGEMENT prohibited

3.7.6.7.1 Upon receipt of the CPDLC message USE OF LOGICAL ACKNOWLEDGEMENT PROHIBITED, the CPDLC-air-user shall be prohibited from requiring a logical ACKNOWLEDGEMENT for any message sent for the duration of the CPDLC or DSC dialogue.

10425104261042710428104291043010431

1043210433104341043510436104371043810439104401044110442104431044410445104461044710448104491045010451


3.7.6.7.2 If the CPDLC-ground-user receives a CPDLC message requiring a logical ACKNOWLEDGEMENT where the use of logical ACKNOWLEDGEMENT has been prohibited as in 3.7.6.7.1, the CPDLC-ground-user shall invoke the CPDLC-message service with a message containing the ERROR [errorinformation] message element with the [logicalACKNOWLEDGEMENTNotAccepted] value in the CPDLC/IC Data parameter, and discard the content of the received message.3.7.6.8 Message reference numbers

3.7.6.8.1 If a received CPDLC message requires a response, the CPDLC-user shall provide a message reference number for each Response CPDLC/IC Data sent.

3.7.6.8.2 The message reference number shall be identical to the message identification number of the received message to which it refers.

3.7.6.9 Message response requirements

3.7.6.9.1 A message sequence initiated by data link should be closed by data link.

3.7.6.9.2 If a message sequence exchange initiated by data link is subsequently closed by voice, local procedures should be in place to ensure deletion of outstanding data link messages requiring closure.

3.7.6.9.3 A CPDLC-user shall only be permitted to respond to a received message in its entirety.

3.7.6.9.4 Only one closure response shall be permitted for a given message.

3.7.6.9.5 If the CPDLC-air-user has not issued a DSC-end service request primitive, or if the CPDLC-air-user has issued a DSC-end service request primitive for which a DSC-end service confirmation primitive has been received with the Result parameter containing the abstract value “rejected”, then if a message is received that requires a response, the CPDLC-air-user shall either:

a) send any permitted Response CPDLC/IC Datas and then send a closure Response CPDLC/IC Data; or

b) send a closure Response CPDLC/IC Data.

3.7.6.9.6 If the CPDLC-ground-user has not issued a CPDLC-end service request primitive, or if the CPDLC-ground-user has issued a CPDLC-end service request primitive for which a CPDLC-end service confirmation primitive has been received with the Result parameter containing the abstract value “rejected”, then if a message is received that requires a response, the CPDLC-ground-user shall either:

a) send any permitted Response CPDLC/IC Datas and then send a closure Response CPDLC/IC Data; or

b) send a closure Response CPDLC/IC Data.

3.7.6.9.7 For a given message, once the CPDLC-user has sent the closure Response CPDLC/IC Data, no other Response CPDLC/IC Datas shall be sent referring to the given message.

3.7.6.9.8 When a message is received by the CPDLC-user requiring a logical ACKNOWLEDGEMENT response, then:

a) when the CPDLC-user is a CPDLC-air-user, the CPDLC-air-user shall respond with either a CPDLC

10452104531045410455104561045710458104591046010461104621046310464104651046610467104681046910470104711047210473104741047510476104771047810479104801048110482104831048410485104861048710488104891049010491104921049310494104951049610497104981049910500105011050210503


message containing a LOGICAL ACKNOWLEDGEMENT message element or with a message containing an ERROR, NOT CURRENT DATA AUTHORITY or NOT AUTHORIZED NEXT DATA AUTHORITY message element, as appropriate; or

10504105051050610507


b) when the CPDLC-user is a CPDLC-ground-user, the CPDLC-ground-user shall respond with a CPDLC message containing a LOGICAL ACKNOWLEDGEMENT message element or with a message containing an ERROR, SERVICE UNAVAILABLE or FLIGHT PLAN NOT HELD message element, as appropriate.

3.7.6.9.9 A logical ACKNOWLEDGEMENT Response CPDLC/IC Data, if required, shall be sent prior to sending any other related Response CPDLC/IC Data(s), except:

a) when the response is an uplink message, a Response CPDLC/IC Data containing an ERROR, SERVICE UNAVAILABLE or FLIGHT PLAN NOT HELD message element, as appropriate; or

b) when the response is a downlink message, a Response CPDLC/IC Data containing an ERROR, NOT CURRENT DATA AUTHORITY or NOT AUTHORIZED NEXT DATA AUTHORITY message element, as appropriate.

Note.— When case a) or b) occurs, the LOGICAL ACKNOWLEDGEMENT message element is not sent.

3.7.6.9.10 When the CPDLC-air-user receives a message with a W/U RESP attribute, the only permitted responses shall be messages that contain a LOGICAL ACKNOWLEDGEMENT (if required), STANDBY, WILCO, UNABLE, NOT CURRENT DATA AUTHORITY, NOT AUTHORIZED NEXT DATA AUTHORITY or ERROR message element.

3.7.6.9.11 When the CPDLC-air-user receives a message with a W/U RESP attribute, the closure Response CPDLC/IC Data shall contain at least a WILCO, UNABLE, NOT CURRENT DATA AUTHORITY, NOT AUTHORIZED NEXT DATA AUTHORITY or ERROR message element.

3.7.6.9.12 When the CPDLC-air-user receives a message with an A/N RESP attribute, the only permitted responses shall be messages that contain a LOGICAL ACKNOWLEDGEMENT (if required), STANDBY, AFFIRM, NEGATIVE, NOT CURRENT DATA AUTHORITY, NOT AUTHORIZED NEXT DATA AUTHORITY or ERROR message element.

3.7.6.9.13 When the CPDLC-air-user receives a message with an A/N RESP attribute, the closure Response CPDLC/IC Data shall contain at least an AFFIRM, NEGATIVE, NOT CURRENT DATA AUTHORITY, NOT AUTHORIZED NEXT DATA AUTHORITY or ERROR message element.

3.7.6.9.14 When the CPDLC-air-user receives a message with an R RESP attribute, the only permitted responses shall be messages that contain a LOGICAL ACKNOWLEDGEMENT (if required), STANDBY, ROGER, UNABLE, NOT CURRENT DATA AUTHORITY, NOT AUTHORIZED NEXT DATA AUTHORITY or ERROR message element.

3.7.6.9.15 When the CPDLC-air-user receives a message with an R RESP attribute, the closure Response CPDLC/IC Data shall contain at least a ROGER, UNABLE, NOT CURRENT DATA AUTHORITY, NOT AUTHORIZED NEXT DATA AUTHORITY or ERROR message element.

3.7.6.9.16 When the CPDLC-air-user receives a message with a Y RESP attribute, a LOGICAL ACKNOWLEDGEMENT, only when requested, and all other CPDLC messages shall be permitted as a Response CPDLC/IC Data.

3.7.6.9.17 When the CPDLC-air-user receives a message with a Y RESP attribute, the first Response CPDLC/IC Data sent that does not contain a STANDBY or LOGICAL ACKNOWLEDGEMENT shall constitute the closure Response CPDLC/IC Data.

3.7.6.9.18 When the CPDLC-ground-user receives an air-ground message with a Y RESP attribute, a LOGICAL ACKNOWLEDGEMENT, only when requested, and all other CPDLC messages shall be permitted as a Response CPDLC/IC Data.

10508105091051010511105121051310514105151051610517105181051910520105211052210523105241052510526105271052810529105301053110532105331053410535105361053710538105391054010541105421054310544105451054610547105481054910550105511055210553105541055510556105571055810559


3.7.6.9.19 When the CPDLC-ground-user receives an air-ground message with a Y RESP attribute, the first Response CPDLC/IC Data sent that does not contain a STANDBY, REQUEST DEFERRED or LOGICAL ACKNOWLEDGEMENT message element shall constitute the closure Response CPDLC/IC Data.

3.7.6.9.20 When the CPDLC-air-user receives a message with an N RESP attribute but requiring a logical ACKNOWLEDGEMENT, the only permitted response shall be a message that contains a LOGICAL ACKNOWLEDGEMENT, NOT CURRENT DATA AUTHORITY, NOT AUTHORIZED NEXT DATA AUTHORITY or ERROR message element. This Response CPDLC/IC Data is the closure message.

3.7.6.9.21 When the CPDLC-ground-user receives an air-ground message with an N RESP attribute but requiring a logical ACKNOWLEDGEMENT, the only permitted response shall be a message that contains a LOGICAL ACKNOWLEDGEMENT, SERVICE UNAVAILABLE, FLIGHT PLAN NOT HELD or ERROR message element. This Response CPDLC/IC Data is the closure message.

3.7.6.9.22 When the CPDLC-ground-user receives a ground-ground message, the ground-user shall be prohibited from generating a ground-ground Response CPDLC/IC Data.

Note.— Ground-ground forwarding of messages is a one-way exchange on a one-message-per-dialogue basis. There are no message identification or message reference numbers contained in the header of a ground-ground message.

3.7.6.10 Invalid message elements

The CPDLC-ground-user shall be prohibited from sending any CPDLC message containing the uplink message elements 33, 40, 41 or 178.

3.7.6.11 Error conditions

3.7.6.11.1 Duplicate message identification numbers

If a CPDLC message is received containing an identification number identical to that of an identification number currently in use, the CPDLC-user shall invoke the CPDLC-user-abort request service with a CPDLC message containing the CPDLCUserAbortReason with the value [duplicate-message-identification-number] as the Reason parameter.

3.7.6.11.2 Invalid reference number

If the CPDLC-user receives a message containing a message reference number which is not identical to any message identification number currently in use, the CPDLC-user shall:

a) invoke CPDLC-message request with the ERROR [errorinformation] message element with the [unrecognizedMsgReferenceNumber] value in the CPDLC/IC Data parameter; and

b) disregard the received message.

3.7.6.11.3 No available message identification numbers

If the CPDLC-user attempts to send a CPDLC message, and all message identification numbers are currently in use, the CPDLC-user shall invoke the CPDLC-user-abort request with a CPDLC message containing the CPDLCUserAbortReason with the value [no-message-identification-numbers-available] as the Reason parameter.

1056010561105621056310564105651056610567105681056910570105711057210573105741057510576105771057810579

10580

105811058210583105841058510586

10587

1058810589

10590

1059110592105931059410595

10596

1059710598105991060010601106021060310604106051060610607

10608

1060910610106111061210613


3.7.6.11.4 Insufficient resources

If the CPDLC-user receives a message and has insufficient resources to handle the message, the CPDLC-user shall:

a) invoke CPDLC-message request with the ERROR [errorinformation] message element with the [insufficientResources] value in the CPDLC/IC Data parameter; and

b) disregard the received message.

3.7.6.11.5 Invalid message element combination

If a message is received containing:

a) a LOGICAL ACKNOWLEDGEMENT message element in combination with any other message element in a single message;

b) a NEXT DATA AUTHORITY [facility] message element in combination with any other message element in a single message; or

c) a message containing more than two message elements with the [routeClearance] variable,

the CPDLC-user shall invoke the CPDLC-message request with the ERROR [errorinformation] message element with the [invalidMessageElementCombination] value in the CPDLC/IC Data parameter, and disregard the received message.

3.7.6.11.6 Invalid message elements

If the CPDLC-air-user receives a message containing any of the uplink message element identifiers 33, 40, 41 or 178, the CPDLC-air-user shall invoke the CPDLC-message request with the ERROR [errorinformation] message element with the [invalidMessageElement] value in the CPDLC/IC Data parameter, and disregard the received message.

3.7.6.11.7 System management responses

3.7.6.11.7.1 If the CPDLC-air-user sends a message containing the NOT CURRENT DATA AUTHORITY, NOT AUTHORIZED NEXT DATA AUTHORITY or ERROR message element instead of the expected Response CPDLC/IC Data, the NOT CURRENT DATA AUTHORITY, NOT AUTHORIZED NEXT DATA AUTHORITY or ERROR message shall contain the received message identification number as the message reference number.

3.7.6.11.7.2 If the CPDLC-ground-user sends a message containing the SERVICE UNAVAILABLE, FLIGHT PLAN NOT HELD or ERROR message element instead of the expected Response CPDLC/IC Data, the SERVICE UNAVAILABLE, FLIGHT PLAN NOT HELD or ERROR message shall contain the received message identification number as the message reference number.

3.7.6.11.7.3 If the CPDLC-air-user sends a NOT CURRENT DATA AUTHORITY, NOT AUTHORIZED NEXT DATA AUTHORITY or ERROR message in response to a CPDLC message, the received CPDLC message shall be disregarded.

3.7.6.11.7.4 If the CPDLC-ground-user sends a SERVICE UNAVAILABLE, FLIGHT PLAN NOT HELD or ERROR message in response to a CPDLC message, the received CPDLC message shall be disregarded.

10614106151061610617106181061910620106211062210623106241062510626106271062810629106301063110632106331063410635106361063710638106391064010641106421064310644106451064610647106481064910650106511065210653106541065510656106571065810659106601066110662106631066410665


3.7.6.11.8 Invalid message response

3.7.6.11.8.1 If the CPDLC-ground-user sends a message that has a W/U response attribute, and a response to this message is received by the CPDLC-ground-user that does not contain any of the message elements WILCO, UNABLE, STANDBY, LOGICAL ACKNOWLEDGEMENT, NOT CURRENT DATA AUTHORITY, NOT AUTHORIZED NEXT DATA AUTHORITY or ERROR [errorInformation], the CPDLC-ground-user shall invoke CPDLC-user-abort request with a CPDLC message containing the CPDLCUserAbortReason with the value [invalid-response].

3.7.6.11.8.2 If the CPDLC-ground-user sends a message that has an A/N response attribute, and a response to this message is received by the CPDLC-ground-user that does not contain any of the message elements AFFIRM, NEGATIVE, STANDBY, LOGICAL ACKNOWLEDGEMENT, NOT CURRENT DATA AUTHORITY, NOT AUTHORIZED NEXT DATA AUTHORITY or ERROR[errorInformation], the CPDLC-ground-user shall invoke CPDLC-user-abort request with a CPDLC message containing the CPDLCUserAbortReason with the value [invalid-response].

3.7.6.11.8.3 If the CPDLC-ground-user sends a message that has an R response attribute, and a response to this message is received by the CPDLC-ground-user that does not contain any of the message elements ROGER, UNABLE, STANDBY, LOGICAL ACKNOWLEDGEMENT, NOT CURRENT DATA AUTHORITY, NOT AUTHORIZED NEXT DATA AUTHORITY or ERROR [errorInformation], the CPDLC-ground-user shall invoke CPDLC-user-abort request with a CPDLC message containing the CPDLCUserAbortReason with the value [invalid-response].

3.7.6.11.8.4 If the CPDLC-ground-user sends a message that has an N response attribute and requires a logical ACKNOWLEDGEMENT, and a response to this message is received by the CPDLC-ground-user that does not contain any of the message elements LOGICAL ACKNOWLEDGEMENT, NOT CURRENT DATA AUTHORITY, NOT AUTHORIZED NEXT DATA AUTHORITY or ERROR [errorInformation], the CPDLC-ground-user shall invoke CPDLC-user-abort request with a CPDLC message containing the CPDLCUserAbortReason with the value [invalid-response].

3.7.6.11.8.5 If the CPDLC-air-user sends a message that has an N response attribute and requires a logical ACKNOWLEDGEMENT, and a response to this message is received by the CPDLC-air-user that does not contain any of the message elements LOGICAL ACKNOWLEDGEMENT, SERVICE UNAVAILABLE, FLIGHT PLAN NOT HELD or ERROR [errorInformation], the CPDLC-air-user shall invoke CPDLC-user-abort request with a CPDLC message containing the CPDLCUserAbortReason with the value [invalid-response].

3.7.6.11.9 Out of synchronization

If a CPDLC-user receives a message containing a time stamp that is out of synchronization with its own clock, the CPDLC-user shall invoke the CPDLC-user-abort request containing the CPDLCUserAbortReason with the value [time-out-of-synchronization] as the Reason parameter.

Note.— The amount of time out of synchronization that will trigger this event is a local implementation issue.

3.7.6.11.10 Preventing error loops

3.7.6.11.10.1 If the CPDLC-air-user receives a message containing the ERROR message element and the message is found to be in error, the CPDLC-air-user shall disregard the received message and be prohibited from responding with an ERROR message.

3.7.6.11.10.2 If the CPDLC-ground-user receives a message containing the ERROR message element and the message is found to be in error, the CPDLC-ground-user shall disregard the received message and be prohibited from responding with an ERROR message.

10666106671066810669106701067110672106731067410675106761067710678106791068010681106821068310684106851068610687106881068910690106911069210693106941069510696106971069810699107001070110702107031070410705107061070710708107091071010711107121071310714107151071610717


Note 1.— This requirement refers to received ERROR messages that are recognized to be in error by the receiving system.

Note 2.— This requirement is to prevent getting into an infinite loop of sending errors.

3.7.2 CPDLC-air-user requirements

3.7.2.1 The CPDLC-start service

3.7.2.1.1 Invoking the CPDLC-start request

3.7.2.1.1.1 If there is no CPDLC-service, the only CPDLC-service primitives the CPDLC-air-user shall be permitted to invoke are the CPDLC-start request or the DSC-start request.

3.7.7.1.1.2 The CPDLC-air-user shall only be permitted to invoke the CPDLC-start request with:

a) any ground system, if there is no existing CPDLC-service for the CPDLC-air-user; or

b) the next data authority, if the CPDLC-air-user has received a message from the current data authority designating a next data authority.

3.7.2.1.1.2 If a CPDLC-air-user has invoked a CPDLC-start request, the CPDLC-air-user shall be prohibited from invoking any CPDLC-service primitive on the CPDLC dialogue initiated by the CPDLC-start service request, except the CPDLC-user-abort request, until after it has received a CPDLC-start confirmation.

3.7.2.1.2 Receipt of a CPDLC-start indication and invoking CPDLC-start response 3.7.7.1.2.1 Upon receipt of a CPDLC-start service indication, the CPDLC-air-user shall invoke a CPDLC-start service response within 0.5 seconds.

3.7.7.1.2.2 Upon receipt of a CPDLC-start indication, the CPDLC-air-user shall invoke the CPDLC-start response, with the response parameters set as follows:

a) the Result parameter to the abstract value of “accepted” and the Response CPDLC/IC Data parameter to an ICDownlinkMessage containing an embeddedMessage element LOGICAL ACKNOWLEDGEMENT if a logical ACKNOWLEDGEMENT was requested and the received CPDLC message is not in error, or the embeddedMessage element ERROR if the received CPDLC message is in error, if:

1) there is no existing CPDLC-service; or

2) CPDLC-service exists and the request is from either the current data authority or the next data authority;

otherwise:

b) the Result parameter to the abstract value “rejected” and the Response CPDLC/IC Data parameter to an ICDownlinkMessage containing an embeddedMessage with the message element NOT AUTHORIZED NEXT DATA AUTHORITY.

3.7.7.1.2.3 If a CPDLC-start indication is received from either the current data authority or the next data authority and this results in a second CPDLC dialogue being established with a given ground system, the CPDLC-air-user shall invoke

1071810719107201072110722107231072410725107261072710728107291073010731107321073310734107351073610737107381073910740107411074210743107441074510746107471074810749107501075110752107531075410755107561075710758107591076010761107621076310764107651076610767107681076910770


the CPDLC-user-abort request primitive for the first connection with that ground system.

3.7.7.1.2.4 If the CPDLC-air-user sets the CPDLC-start response Result parameter to the abstract value “rejected”, any CPDLC message contained in the CPDLC-start indication CPDLC/IC Data parameter shall be disregarded.

3.7.7.1.2.5 If the CPDLC-air-user sets the CPDLC-start response Result parameter to the abstract value “accepted” and the request is from the current data authority, any CPDLC message contained in the CPDLC-start indication CPDLC/IC Data parameter shall be processed.

3.7.7.1.2.6 If the CPDLC-air-user sets the CPDLC-start response Result parameter to the abstract value “accepted” and the request is from the next data authority, any CPDLC message contained in the CPDLC-start indication CPDLC/IC Data parameter shall be disregarded.

3.7.7.1.2.7 If the CPDLC-air-user sets the CPDLC-start response Result parameter to the abstract value “accepted”, the CPDLC-air-user shall:

a) establish an association between a CPDLC-ASE invocation and a ground system facility designation contained in the CPDLC-start indication Calling Peer Identifier parameter;

b) if there is no current data authority, associate this CPDLC-ASE invocation with the current data authority; or

c) if the facility designation contained in the CPDLC-start indication Calling Peer Identifier parameter is the next data authority, associate the CPDLC-ASE invocation with the next data authority.

If a CPDLC-start indication has been received, the CPDLC-air-user shall be prohibited from invoking any CPDLC-service primitive with this ground system, except the CPDLC-user-abort request, until after it has invoked the CPDLC-start response.

3.7.7.1.3 Receipt of a CPDLC-start confirmation

3.7.7.1.3.1 If a CPDLC-start confirmation has been received with a Result parameter containing the abstract value “accepted”, and the Response parameter contains no CPDLC message or a CPDLC message with either a LOGICAL ACKNOWLEDGEMENT message element or an ERROR message element, the CPDLC-air-user shall:

a) establish an association between a CPDLC-ASE invocation and the ground system facility designation contained in the CPDLC-start request Called Peer Identifier parameter;

b) if there is no current data authority, associate the CPDLC-ASE invocation with the current data authority; or

c) if the facility designation contained in the CPDLC-start request Called Peer Identifier parameter is the next data authority, associate the CPDLC-ASE invocation with the next data authority.

3.7.7.1.3.2 If a CPDLC-start confirmation has been received with a Result parameter containing the abstract value “accepted”, and the Response parameter contains a CPDLC message with a message element other than a LOGICAL ACKNOWLEDGEMENT message element or an ERROR message element, the CPDLC-air-user shall invoke the CPDLC-user-abort request primitive with the Reason parameter set to CPDLCUserAbortReason value [invalid-CPDLC-message]. 3.7.2.2 The DSC-start service

10771107721077310774107751077610777107781077910780107811078210783107841078510786107871078810789107901079110792107931079410795107961079710798107991080010801108021080310804108051080610807108081080910810108111081210813108141081510816108171081810819108201082110822


3.7.2.2.1 Invoking the DSC-start request

3.7.2.2.1.1 Only a CPDLC-air-user shall be permitted to invoke the DSC-start service request primitive.

3.7.2.2.1.2 A CPDLC-air-user shall only be permitted to invoke the DSC-start-service request primitive if the CPDLC-air-user has no existing DSC dialogue.

3.7.2.2.1.3 If a CPDLC-air-user has invoked a DSC-start request, the CPDLC-air-user shall be prohibited from invoking any CPDLC-service primitive on the DSC dialogue initiated by the DSC-start service request, except the CPDLC-user-abort request, until after it has received a DSC-start confirmation.

3.7.2.2.2 Receipt of a DSC-start confirmation

If a DSC-start confirmation has been received with a Result parameter containing the abstract value “accepted”, the CPDLC-air-user shall:

a) establish an association between a CPDLC-ASE invocation and the ground system facility designation contained in the DSC-start request Facility Designation parameter; and

b) associate the CPDLC-ASE invocation with a downstream data authority.

10823108241082510826108271082810829108301083110832108331083410835108361083710838108391084010841108421084310844108451084610847


3.7.2.3 The CPDLC-message service

3.7.2.3.1 Invoking the CPDLC-message request

The CPDLC-air-user shall be prohibited from invoking the CPDLC-message service request primitive with a CPDLC/IC Data parameter not containing a CPDLC message.

3.7.2.3.2 Receipt of a CPDLC-message indication

3.7.7.3.2.1 Upon receipt of a CPDLC-message indication, if the indication is from the current data authority or a downstream data authority, the CPDLC-air-user shall process the embeddedMessage contained in the CPDLC/IC Data parameter.

3.7.7.3.2.2 If a CPDLC-message indication is received from the current data authority containing only the uplink message element NEXT DATA AUTHORITY specifying a facility as the next data authority, the CPDLC-air-user shall do the following in the order listed:

a) check that there is no other next data authority already established;

b) if there is, invoke CPDLC-user-abort request with the established next data authority with the Reason parameter set to CPDLCUserAbortReason value [no-longer-next-data-authority]; and

c) then designate the ground system indicated in the CPDLC message from the CPDLC-message indication as the next data authority.

3.7.7.3.2.3 If a CPDLC-message indication is received from the current data authority containing only the uplink message element NEXT DATA AUTHORITY, indicating a “NULL” for the next data authority, the CPDLC-air-user shall do the following in the order listed:

a) check if there is a next data authority already established;

b) if there is, invoke CPDLC-user-abort request with the established next data authority with the Reason parameter set to CPDLCUserAbortReason value [no-longer-next-data-authority]; and

c) cancel any existing next data authority designation.

3.7.7.3.2.4 If a CPDLC-message indication is received containing the uplink message element NEXT DATA AUTHORITY, and it is not from the current data authority, the CPDLC message shall be disregarded.

3.7.7.3.2.5 Upon receipt of a CPDLC-message indication, if the indication is not from the current data authority or a downstream data authority, the CPDLC-air-user shall:

a) invoke CPDLC-message service request with the CPDLC/IC Data parameter containing a CPDLC message with the message element NOT CURRENT DATA AUTHORITY; and

b) disregard the received CPDLC message contained in the CPDLC-message indication CPDLC/IC Data parameter.

If a CPDLC-message indication is received containing a CPDLC/IC Data parameter with no embeddedMessage element, the CPDLC-air-user shall invoke CPDLC-user-abort request with the Reason parameter set to CPDLCUserAbortReason value [invalid-pdu].

10848108491085010851108521085310854108551085610857108581085910860108611086210863108641086510866108671086810869108701087110872108731087410875108761087710878108791088010881108821088310884108851088610887108881088910890108911089210893108941089510896108971089810899


3.7.2.34 The CPDLC-end service

3.7.2.34.1 The CPDLC-end service request

The CPDLC-air-user shall be prohibited from invoking the CPDLC-end request.

3.7.7.4.2 Receipt of a CPDLC-end indication and invoking a CPDLC-end response

3.7.7.4.2.1 If a CPDLC-end indication is received but it is not from the current data authority, the CPDLC-air-user shall:

a) invoke CPDLC-end response with:

1) the CPDLC/IC Data parameter containing a CPDLC message with the message element NOT CURRENT DATA AUTHORITY; and

2) the Result parameter set to the abstract value “rejected”; and

b) disregard any CPDLC message provided in the CPDLC-end indication CPDLC/IC Data parameter.

3.7.7.4.2.2 A CPDLC-air-user is considered to have uplink open messages when the CPDLC-air-user has received a message(s) for which a response is required and it has not yet sent the closure response to the message(s).

1090010901109021090310904109051090610907109081090910910109111091210913109141091510916109171091810919109201092110922109231092410925


3.7.7.4.2.3 Uplink open messages are not considered in setting out the requirements for the CPDLC-end service. The ground user is aware of any such messages and desires to end the dialogue anyway. Any such messages are considered deleted upon transmission of a CPDLC-end response with the Result parameter set to the abstract value “accepted” on the airborne side, and upon receipt of a CPDLC-end confirmation with the Result parameter set to the abstract value “accepted” on the ground side.

3.7.7.4.2.4 A CPDLC-air-user is considered to have downlink open messages when the CPDLC-air-user has sent any messages that require a response for which it has not received a closure response.

3.7.7.4.2.5 A downlink open message is considered deleted upon transmission of a CPDLC-end response with the Result parameter set to the abstract value “accepted” on the airborne side, and upon receipt of a CPDLC-end confirmation with the Result parameter set to the abstract value “accepted” on the ground side.

3.7.7.4.2.6 Local procedures may dictate when a “rejected” response Result parameter is permitted by the CPDLC-air-user in the cases when section 3.7 gives the CPDLC-air-user a choice between “accepted” or “rejected”.

3.7.7.4.2.7 If a CPDLC-end service response is invoked with an “accepted” Result, this will result in ending the dialogue regardless of any CPDLC messages contained in the CPDLC/IC Data parameter.

3.7.7.4.3 Uplink message contains error

If a CPDLC-end indication is received from the current data authority and there is a CPDLC message in the CPDLC/IC Data parameter that either has the response attribute N and requires a logical ACKNOWLEDGEMENT or has a W/U, A/N, R, or Y response attribute, and an error is detected in the message, then the CPDLC-air-user shall invoke CPDLC-end response with:

a) the CPDLC/IC Data parameter containing a CPDLC message with the message element ERROR [errorInformation]; and

b) the Result parameter set to the abstract value “rejected”.

3.7.7.4.4 No CPDLC message in the CPDLC-end indication

3.7.7.4.4.1 If a CPDLC-end indication is received from the current data authority, and the CPDLC-air-user does not have any downlink open messages, and there is no CPDLC message in the CPDLC/IC Data parameter, then the CPDLC-air-user shall invoke CPDLC-end response with the Result parameter set to the abstract value “accepted”.

3.7.7.4.4.2 If a CPDLC-end indication is received from the current data authority, and the CPDLC-air-user has downlink open messages, and there is no CPDLC message in the CPDLC/IC Data parameter, then the CPDLC-air-user shall invoke CPDLC-end response with the Result parameter set to the abstract value “accepted” or “rejected”.3.7.7.4.5 Message in CPDLC-end indication does not require response

3.7.7.4.5.1 If a CPDLC-end indication is received from the current data authority, and the CPDLC-air-user does not have any downlink open messages, and there is a CPDLC message in the CPDLC/IC Data parameter with the response attribute N and not requiring a logical ACKNOWLEDGEMENT, then the CPDLC-air-user shall invoke CPDLC-end response with the Result parameter set to the abstract value “accepted”.

1092610927109281092910930109311093210933109341093510936109371093810939109401094110942109431094410945109461094710948109491095010951109521095310954109551095610957109581095910960109611096210963109641096510966109671096810969109701097110972


3.7.7.4.5.2 If a CPDLC-end indication is received from the current data authority, and the CPDLC-air-user has downlink open messages, and there is a CPDLC message in the CPDLC/IC Data parameter with the response attribute N and not requiring a logical ACKNOWLEDGEMENT, then the CPDLC-air-user shall invoke CPDLC-end response with the Result parameter set to the abstract value “accepted” or “rejected”.

3.7.7.4.6 CPDLC message in CPDLC-end indication requires only logical ACKNOWLEDGEMENT

3.7.7.4.6.1 If a CPDLC-end indication is received from the current data authority, and the CPDLC-air-user does not have any downlink open messages, and there is a CPDLC message in the CPDLC/IC Data parameter with the response attribute N and requiring a logical ACKNOWLEDGEMENT, and no error is detected in the CPDLC message, then the CPDLC-air-user shall invoke CPDLC-end response with:

a) the CPDLC/IC Data parameter containing a CPDLC message with the message element LOGICAL ACKNOWLEDGEMENT; and

b) the Result parameter set to the abstract value “accepted”.

3.7.7.4.6.2 If a CPDLC-end indication is received from the current data authority, and the CPDLC-air-user has downlink open messages, and there is a CPDLC message in the CPDLC/IC Data parameter with the response attribute N and requiring a logical ACKNOWLEDGEMENT, and no error is detected in the CPDLC message, then the CPDLC-air-user shall invoke CPDLC-end response with:


b) the Result parameter set to the abstract value “accepted” or “rejected”.

3.7.7.4.7 CPDLC message in CPDLC-end indication with W/U, A/N, or R attribute, positive response

3.7.7.4.7.1 In this case, a positive response to a CPDLC message in the CPDLC-end indication also indicates acceptance of the end of the dialogue.

3.7.7.4.7.2 If a CPDLC-end indication is received from the current data authority, and there is a CPDLC message in the CPDLC/IC Data parameter with the response attribute W/U, A/N or R, and no error is detected in the message, then if the CPDLC-air-user chooses to respond positively (WILCO, AFFIRM or ROGER) to the CPDLC message, the CPDLC-air-user shall:

a) if a logical ACKNOWLEDGEMENT is required, invoke CPDLC-message request with the CPDLC/IC Data parameter containing a CPDLC message with only the message element LOGICAL ACKNOWLEDGEMENT;

b) if a STANDBY response is used, invoke CPDLC-message request with the CPDLC/IC Data parameter containing a CPDLC message with at least the message element STANDBY; and

c) invoke CPDLC-end response with:

1) the CPDLC/IC Data parameter containing a CPDLC message with at least the message element WILCO, AFFIRM or ROGER, as appropriate; and

2) the Result parameter set to the abstract value “accepted”.

10973109741097510976109771097810979109801098110982109831098410985109861098710988109891099010991109921099310994109951099610997109981099911000110011100211003110041100511006110071100811009110101101111012110131101411015110161101711018110191102011021110221102311024


3.7.7.4.8 CPDLC message in CPDLC-end indication with W/U, A/N, or R attribute, negative response

3.7.7.4.8.1 In this case, a negative response to a CPDLC message in the CPDLC-end indication also indicates rejection of the end of the dialogue.

3.7.7.4.8.2 If a CPDLC-end indication is received from the current data authority, and there is a CPDLC message in the CPDLC/IC Data parameter with the response attribute W/U, A/N or R, and no error is detected in the message, then if the CPDLC-air-user chooses to respond negatively (UNABLE or NEGATIVE) to the CPDLC message, the CPDLC-air-user shall:




1) the CPDLC/IC Data parameter containing a CPDLC message with at least the message element UNABLE or NEGATIVE, as appropriate; and

2) the Result parameter set to the abstract value “rejected”.

3.7.7.4.9 CPDLC message in CPDLC-end indication with Y response attribute

3.7.7.4.9.1 If a CPDLC-end indication is received from the current data authority, and the CPDLC-air-user does not have any downlink open messages, and there is a CPDLC message in the CPDLC/IC Data parameter with the response attribute Y, and no error is detected in the CPDLC message, the CPDLC-air-user shall:




1) the CPDLC/IC Data parameter containing a CPDLC message with a Y attribute closure CPDLC message; and


3.7.7.4.9.2 If a CPDLC-end indication is received from the current data authority, and the CPDLC-air-user has any downlink open messages, and there is a CPDLC message in the CPDLC/IC Data parameter with the response attribute Y, and no error is detected in the CPDLC message, the CPDLC-air-user shall:


b) if a STANDBY response is used, invoke CPDLC-message request with the CPDLC/IC Data parameter

11025110261102711028110291103011031110321103311034110351103611037110381103911040110411104211043110441104511046110471104811049110501105111052110531105411055110561105711058110591106011061110621106311064110651106611067110681106911070110711107211073110741107511076


containing a CPDLC message with at least the message element STANDBY; and



2) the Result parameter set to the abstract value “accepted” or “rejected”.

3.7.7.4.9.3 Upon invoking a CPDLC-end response with Result parameter set to “accepted”, the CPDLC-air-user shall:

a) delete any association with a ground system and current data authority; and

b) if a ground system is designated as the next data authority and an association with a CPDLC-ASE exists, replace the next data authority association with a current data authority association; or

c) if a ground system is designated as the next data authority and no association with a CPDLC-ASE exists, delete the next data authority association with any ground system.

3.7.7.4.9.4 If the CPDLC-air-ASE associated with the current data authority ceases to exist for any reason other than in response to a CPDLC-end request as specified in 3.7.7.4, any existing next data authority designation and/or association shall cease to exist. 3.7.2.45 The DSC-end service

3.7.2.45.1 The DSC-end request

3.7.2.45.1.1 Only the CPDLC-air-user shall be permitted to invoke the DSC-end request.

3.7.2.45.1.2 If a CPDLC-air-user has invoked a DSC-end service request primitive, the CPDLC-air-user shall be prohibited from invoking any CPDLC-service primitive with this ground system (except the CPDLC-user-abort request primitive) until it receives a DSC-end service confirmation primitive.

3.7.7.6 The CPDLC-user-abort service

3.7.7.6.1 Issuing a CPDLC-user-abort request [commanded-termination]

The CPDLC-air-user shall have the capability to invoke CPDLC-user-abort request with the Reason parameter set to CPDLCUserAbortReason value [commanded-termination].

3.7.7.6.2 Invoking a CPDLC-user-abort request

3.7.7.6.2.1 If the CPDLC-air-user invokes CPDLC-user-abort request with the current data authority, the CPDLC-air-user shall:

11077110781107911080110811108211083110841108511086110871108811089110901109111092110931109411095110961109711098110991110011101111021110311104111051110611107111081110911110111111111211113111141111511116111171111811119111201112111122111231112411125


a) delete any association of a ground system to a current data authority;

b) if a ground system is designated as the next data authority and an association with a CPDLC-ASE exists, invoke CPDLC-user-abort request with the Reason parameter set to the value [current-data-authority-abort]; and

c) delete any association of a ground system to a next data authority.

3.7.7.6.2.2 If the CPDLC-air-user invokes CPDLC-user-abort request with the next data authority and then does not set the Reason parameter as [current-data-authority-abort] or [no-longer-next-data-authority], the CPDLC-air-user shall continue to maintain the association of the ground system to the next data authority.

3.7.7.6.3 Receipt of a CPDLC-abort indication

3.7.7.6.3.1 If the CPDLC-air-user receives a CPDLC-user-abort indication from the current data authority or a CPDLC-provider-abort indication that causes the ASE invocation associated with the current data authority to cease to exist, the CPDLC-air-user shall:

a) delete any association of a ground system to a current data authority;

b) if a ground system is designated as the next data authority and an association with a CPDLC-ASE exists, invoke CPDLC-user-abort request with the Reason parameter set to the value [current-data-authority-abort]; and

c) delete any association of a ground system to a next data authority.

3.7.7.6.3.2 If the CPDLC-air-user receives a CPDLC-user-abort indication from the next data authority or receives a CPDLC-provider-abort indication that causes the ASE invocation associated with the next data authority to cease to exist, the CPDLC-air-user shall continue to maintain the association of the ground system to the next data authority.

3.7.3 CPDLC-ground-user requirements

3.7.3.1 The CPDLC-start service

3.7.3.1.1 Invoking the CPDLC-start request

3.7.3.1.1.1 If there is no CPDLC-service, the only CPDLC-service primitives the CPDLC-ground-user shall be permitted to invoke are the CPDLC-start-request or the CPDLC-forward request.

3.7.3.1.1.2 If a CPDLC-ground-user has invoked a CPDLC-start request, the CPDLC-ground-user shall be prohibited from invoking any CPDLC-service primitive on the CPDLC dialogue initiated by the CPDLC-start service request, except the CPDLC-user-abort request, until after it has received a CPDLC-start confirmation.

111261112711128111291113011131111321113311134111351113611137111381113911140111411114211143111441114511146111471114811149111501115111152111531115411155111561115711158111591116011161111621116311164111651116611167111681116911170111711117211173


3.7.3.1.2 Receipt of a CPDLC-start indication and invoking CPDLC-start response

3.7.3.1.2.1 If a CPDLC-start indication is received from an aircraft with which the ground system currently has a CPDLC dialogue, the CPDLC-ground-user shall:

a) invoke the CPDLC-start response with the Result parameter set to the abstract value “accepted”; and

b) invoke the CPDLC-user-abort request for the first CPDLC dialogue with that aircraft.

3.7.3.1.2.2 The CPDLC-ground-user shall be prohibited from invoking the CPDLC-start response unless and until it has received a CPDLC-start indication.

3.7.8.1.2.3 If the CPDLC-ground-user sets the CPDLC-start response Result parameter to the abstract value “rejected”, then the Response CPDLC/IC Data parameter shall be an ICUplinkMessage containing a CPDLC message with either the SERVICE UNAVAILABLE or FLIGHT PLAN NOT HELD message element as appropriate.

3.7.8.1.2.4 If the CPDLC-ground-user sets the CPDLC-start response Result parameter to the abstract value “rejected”, the CPDLC-ground-user shall disregard any CPDLC message contained in the CPDLC-start indication CPDLC/IC Data parameter.

3.7.8.1.2.5 If the CPDLC-ground-user sets the CPDLC-start response Result parameter to the abstract value “accepted”, any CPDLC message contained in the CPDLC-start indication CPDLC/IC Data parameter shall be processed.

3.7.8.1.2.6 When the CPDLC-ground-user sets the CPDLC-start response Result parameter to the abstract value “accepted”, it shall set the Response CPDLC/IC Data parameter to an ICUplinkMessage containing:

a) a CPDLC message with the message element LOGICAL ACKNOWLEDGEMENT if a logical acknowledgement was requested and the CPDLC message received is not in error;

b) a CPDLC message with the message element ERROR if the CPDLC message received is in error; or

c) no CPDLC message in all other cases.

3.7.8.1.2.7 If the CPDLC-ground-user sets the CPDLC-start response Result parameter to the abstract value “accepted”, the CPDLC-ground-user shall establish an association between a CPDLC-ASE invocation and the ICAO 24-bit aircraft address contained in CPDLC-start indication Calling Peer Identifier parameter. 3.7.3.1.2.3 If a CPDLC-start indication has been received, the CPDLC-ground-user shall be prohibited from invoking any CPDLC-service primitive, except the CPDLC-user-abort request with that aircraft, until after it has invoked the CPDLC-start response.

3.7.8.1.2.9 Upon receipt of a CPDLC-start service indication, the CPDLC-ground-user shall invoke a CPDLC-start service response within 0.5 seconds.

3.7.8.1.3 Receipt of a CPDLC-start confirmation

3.7.8.1.3.1 If a CPDLC-start confirmation has been received with a Result parameter containing the abstract value “accepted”, and the Response parameter contains no CPDLC message or a CPDLC message with either a LOGICAL ACKNOWLEDGEMENT message element, an ERROR message element or a NOT CURRENT DATA AUTHORITY message element, the CPDLC-ground-user shall establish an association between a CPDLC-ASE invocation and the ICAO 24-bit aircraft address contained in CPDLC-start request Called Peer Identifier parameter.

11174111751117611177111781117911180111811118211183111841118511186111871118811189111901119111192111931119411195111961119711198111991120011201112021120311204112051120611207112081120911210112111121211213112141121511216112171121811219112201122111222112231122411225


3.7.8.1.3.2 If a CPDLC-start confirmation has been received with a Result parameter containing the abstract value “accepted”, and the Response parameter contains a CPDLC message with a message element other than a LOGICAL ACKNOWLEDGEMENT message element, an ERROR message element or a NOT CURRENT DATA AUTHORITY message element, the CPDLC-ground-user shall invoke the CPDLC-user-abort request primitive with the Reason parameter set to CPDLCUserAbortReason value [invalid-CPDLC-message].

3.7.3.2 The DSC-start service

3.7.3.2.1 Receipt of a DSC-start indication and invoking DSC-start response

3.7.3.2.1.1 The CPDLC-ground-user shall be prohibited from invoking the DSC-start response unless and until it has received a DSC-start indication.

3.7.3.2.1.2 If a DSC-start indication is received from an aircraft with which the ground system currently has a DSC dialogue, the CPDLC-ground-user shall:

a) invoke the DSC-start response with the Result parameter set to the abstract value “accepted”; and

b) invoke the CPDLC-user-abort request for the first DSC dialogue with that aircraft.

3.7.8.2.1.3 If the CPDLC-ground-user sets the DSC-start response Result parameter to the abstract value “rejected”, then the Response CPDLC/IC Data parameter shall be an ICUplinkMessage containing a CPDLC message with either the SERVICE UNAVAILABLE or FLIGHT PLAN NOT HELD message element, as appropriate.

3.7.8.2.1.4 If the CPDLC-ground-user sets the DSC-start response Result parameter to the abstract value “rejected”, the CPDLC-ground-user shall disregard any CPDLC message contained in the DSC-start indication CPDLC/IC Data parameter.

3.7.8.2.1.5 If the CPDLC-ground-user sets the DSC-start response Result parameter to the abstract value “accepted”, any CPDLC message contained in the DSC-start indication CPDLC/IC Data parameter shall be processed.

3.7.8.2.1.6 If the CPDLC-ground-user sets the DSC-start response Result parameter to the abstract value “accepted”, the CPDLC-ground-user shall establish an association between a CPDLC-ASE invocation and the ICAO 24-bit aircraft address contained in the DSC-start indication Aircraft Address parameter.

3.7.3.2.1.3 If a DSC-start indication has been received, the CPDLC-ground-user shall be prohibited from invoking any CPDLC-service primitive, except the CPDLC-user-abort request, until after it has invoked the DSC-start response.

3.7.8.2.2 Receipt of a DSC-start indication and invoking a DSC-start response

3.7.8.2.2.1 Upon receipt of a DSC-start indication, the CPDLC-ground-user shall invoke a DSC-start response within 0.5 seconds.

3.7.8.2.2.2 Upon receipt of a DSC-start indication, the CPDLC-ground-user shall invoke a DSC-start response with parameters set as follows:

a) the Result parameter is set to the abstract value “accepted” or “rejected”; and

11226112271122811229112301123111232112331123411235112361123711238112391124011241112421124311244112451124611247112481124911250112511125211253112541125511256112571125811259112601126111262112631126411265112661126711268112691127011271112721127311274112751127611277


b) if, and only if, the Result parameter is set to the abstract value “rejected”, then the Response CPDLC/IC Data parameter is set to an ICUplinkMessage containing a CPDLC message with the message element SERVICE UNAVAILABLE or FLIGHT PLAN NOT HELD, as appropriate.

3.7.3.3 The CPDLC-message service

3.7.3.3.1 Invoking the CPDLC-message request

The CPDLC-ground-user shall be prohibited from invoking the CPDLC-message service request primitive with a CPDLC/IC Data parameter not containing a CPDLC message.

3.7.3.3.2 Receipt of a CPDLC-message indication

If a CPDLC-message indication is received containing a CPDLC/IC Data parameter with no embeddedMessage element, the CPDLC-ground-user shall invoke CPDLC-user-abort request with the Reason parameter set to CPDLCUserAbortReason value [invalid-pdu].

3.7.3.34 The CPDLC-end service

3.7.3.34.1 The CPDLC-end request

3.7.3.34.1.1 Only the CPDLC-ground-user shall be permitted to invoke the CPDLC-end request.

3.7.3.34.1.2 If a CPDLC-ground-user has invoked a CPDLC-end service request primitive, the CPDLC-ground-user shall be prohibited from invoking any CPDLC-service primitive with this aircraft, except the CPDLC-user-abort request primitive, until after it has received a CPDLC-end service confirmation primitive.

3.7.3.45 The DSC-end service

3.7.3.45.1 Receipt of a DSC-end indication and invoking DSC-end response

3.7.8.5.1.1 The CPDLC-ground-user is considered to have downlink open messages when the CPDLC-ground-user has received a CPDLC message(s) for which a response is required and it has not yet sent the closure response to the message(s).

3.7.8.5.1.2 Downlink open messages are not considered in setting out the requirements for the DSC-end service. The air user is aware of any such messages, and desires to end the dialogue anyway. Any such messages are considered deleted upon transmission of a DSC-end response with the Result parameter set to the abstract value “accepted” on the ground side, and upon receipt of a DSC-end confirmation with the Result parameter set to the abstract value “accepted” on the airborne side.

3.7.8.5.1.3 The CPDLC-ground-user is considered to have uplink open messages when the CPDLC-ground-user has sent any messages that require a response for which it has not received a closure response.

3.7.8.5.1.4 An uplink open message is considered deleted upon transmission of a DSC-end response with the Result parameter set to the abstract value “accepted” on the ground side, and upon receipt of a DSC-end confirmation with the Result parameter set to the abstract value “accepted” on the airborne side.

1127811279112801128111282112831128411285112861128711288112891129011291112921129311294112951129611297112981129911300113011130211303113041130511306113071130811309113101131111312113131131411315113161131711318113191132011321113221132311324113251132611327113281132911330


3.7.8.5.1.5 Local procedures may dictate when a “rejected” response Result parameter is permitted by the CPDLC-ground-user in the cases when section 3.7 gives the CPDLC-ground-user a choice between “accepted” or “rejected”.3.7.3.5.1.6 If a DSC-end service response is invoked with an “accepted” Result, this will result in ending the dialogue regardless of any CPDLC messages contained in the CPDLC/IC Data parameter.

3.7.8.5.2 Downlink message contains error

If a DSC-end indication is received, and there is a CPDLC message in the CPDLC/IC Data parameter that either has the response attribute N and requires a logical ACKNOWLEDGEMENT or has a Y response attribute, and an error is detected in the CPDLC message, then the CPDLC-ground-user shall invoke DSC-end response with:

a) the CPDLC/IC Data parameter containing CPDLC message with the message element ERROR [errorInformation]; and

b) the Result parameter set to the abstract value “rejected”.

3.7.8.5.3 No CPDLC message in the DSC-end indication

3.7.8.5.3.1 If a DSC-end indication is received, and the CPDLC-ground-user does not have any uplink open messages, and there is no CPDLC message in the CPDLC/IC Data parameter, then the CPDLC-ground-user shall invoke DSC-end response with the Result parameter set to the abstract value “accepted”.

3.7.8.5.3.2 If a DSC-end indication is received, and the CPDLC-ground-user has uplink open messages, and there is no CPDLC message in the CPDLC/IC Data parameter, then the CPDLC-ground-user shall invoke DSC-end response with the Result parameter set to the abstract value “accepted” or “rejected”.

3.7.8.5.4 CPDLC message in DSC-end indication does not require response

3.7.8.5.4.1 If a DSC-end indication is received, and the CPDLC-ground-user does not have any uplink open messages, and there is a CPDLC message in the CPDLC/IC Data parameter with the response attribute N and not requiring a logical ACKNOWLEDGEMENT, then the CPDLC-ground-user shall invoke DSC-end response with the Result parameter set to the abstract value “accepted”.

3.7.8.5.4.2 If a DSC-end indication is received, and the CPDLC-ground-user has uplink open messages, and there is a CPDLC message in the CPDLC/IC Data parameter with the response attribute N and not requiring a logical ACKNOWLEDGEMENT, then the CPDLC-ground-user shall invoke DSC-end response with the Result parameter set to the abstract value “accepted” or “rejected”.

3.7.8.5.5 CPDLC message in DSC-end indication requires only logical ACKNOWLEDGEMENT

3.7.8.5.5.1 If a DSC-end indication is received, and the CPDLC-ground-user does not have any uplink open messages, and there is a CPDLC message in the CPDLC/IC Data parameter with the response attribute N and requiring a logical ACKNOWLEDGEMENT, and no error is detected in the CPDLC message, then the CPDLC-ground-user shall invoke DSC-end response with:

a) the CPDLC/IC Data parameter containing a CPDLC message with the message element LOGICAL

11331113321133311334113351133611337113381133911340113411134211343113441134511346113471134811349113501135111352113531135411355113561135711358113591136011361113621136311364113651136611367113681136911370113711137211373113741137511376113771137811379113801138111382


ACKNOWLEDGEMENT; and

b) the Result parameter set to the abstract value “accepted”.

3.7.8.5.5.2 If a DSC-end indication is received, and the CPDLC-ground-user has uplink open messages, and there is a CPDLC message in the CPDLC/IC Data parameter with the response attribute N and requiring a logical ACKNOWLEDGEMENT, and no error is detected in the CPDLC message, then the CPDLC-ground-user shall invoke DSC-end response with:


b) the Result parameter set to the abstract value “accepted” or “rejected”.

3.7.8.5.6 CPDLC message in DSC-end indication with Y response attribute

3.7.8.5.6.1 If a DSC-end indication is received, and the CPDLC-ground-user does not have any uplink open messages, and there is a CPDLC message in the CPDLC/IC Data parameter with the response attribute Y, and no error is detected in the CPDLC message, the CPDLC-ground-user shall:


b) if a STANDBY response is used, invoke CPDLC-message request with the CPDLC/IC Data parameter containing a CPDLC message with at least the message element STANDBY;

c) if a REQUEST DEFERRED response is used, invoke CPDLC-message request with the CPDLC/IC Data parameter containing a CPDLC message with at least the message element REQUEST DEFERRED; and

d) invoke DSC-end response with:



3.7.8.5.6.2 If a DSC-end indication is received, and the CPDLC-ground-user has uplink open messages, and there is a CPDLC message in the CPDLC/IC Data parameter with the response attribute Y, and no error is detected in the message, the CPDLC-ground-user shall:


b) if a STANDBY response is used, invoke CPDLC-message request with the CPDLC/IC Data parameter containing a CPDLC message with at least the message element STANDBY;

c) if a REQUEST DEFERRED response is used, invoke CPDLC-message request with the CPDLC/IC Data parameter containing a CPDLC message with at least the message element REQUEST

11383113841138511386113871138811389113901139111392113931139411395113961139711398113991140011401114021140311404114051140611407114081140911410114111141211413114141141511416114171141811419114201142111422114231142411425114261142711428114291143011431114321143311434


DEFERRED; and114351143611437


d) invoke DSC-end response with:


2) the Result parameter set to the abstract value “accepted” or “rejected”.

3.7.3.56 The CPDLC-forward service

3.7.3.56.1 Invoking the CPDLC-forward request

3.7.3.56.1.1 Only the CPDLC-ground-user shall be permitted to invoke the CPDLC-forward request.

3.7.3.56.1.2 The CPDLC-ground-user shall include in the CPDLC-forward request CPDLC Message parameter a MessageForward APDU element containing an ATCDownlinkMessageData or an ATCUplinkMessageData encoded using the unaligned basic PER.

3.7.3.67 The CPDLC-user-abort service

3.7.3.67.1 Issuing a CPDLC-user-abort request

The CPDLC-ground-user shall have the capability to invoke a CPDLC-user-abort request with the Reason parameter set to CPDLCUserAbortReason value [commanded-termination].

3.7.9 Message intent

3.7.9.1 Purpose

3.7.9.1.1 This section specifies the message set for CPDLC message attributes, message presentation guidance and data structure presentation guidance. The actual information exchanged between an aircraft and ground peer or between two ground peer CPDLC applications is defined in 3.4; however, 3.4 does not mandate any particular method for presenting this information. The presentation of information to the controller and aircraft crew is a local implementation matter. The message presentation recommendations contained in Doc 4444 are one possible means of presenting the information.

3.7.9.1.2 Uplink and downlink message elements in this manual comply with the provisions of the fifteenth edition of Doc 4444, Appendix 5.

3.7.10 Parameter value unit, range and resolution

A CPDLC-user shall interpret CPDLC message element variables unit, range and resolution as defined in 3.4.

114381143911440114411144211443114441144511446114471144811449114501145111452114531145411455114561145711458114591146011461114621146311464114651146611467114681146911470114711147211473114741147511476114771147811479114801148111482114831148411485114861148711488


3.8 SUBSETTING RULES

3.8.1 General

Note.— This section specifies conformance requirements that all implementations of the CPDLC protocol obey.

3.8.1.1 An implementation of either the CPDLC ground-based service or the CPDLC air-based service claiming conformance to this section shall support the CPDLC protocol features as shown in Tables 3-18 to 3-21.

3.8.1.2 The “status” column indicates the level of support required for conformance to the CPDLC-ASE protocol. The values are as follows:

“M” mandatory support is required;

“O” optional support is permitted for conformance to the CPDLC protocol;

“N/A” the item is not applicable; and

“C.n” the item is conditional where n is the number that identifies the condition that is applicable. The definitions for the conditional statements used in this section are written under the tables in which they first appear.

Table 3-18. Protocol versions implemented

Version Status Associated predicate

Version 1 M None

Table 3-19. CPDLC protocol options

Status Associated predicate

CPDLC-air-ASE C.1 CPDLC/air

CPDLC-ground-ASE C.1 CPDLC/ground

DSC function supported If (CPDLC/air), then O, else M DSC-FU

DSC function supported by CPDLC-ground-user

If (CPDLC/ground), then O, else N/A DSC-USER

Forward function supported by initiating user

If (CPDLC/ground), then O, else N/A FWD-INIT

Forward function supported by receiving user

If (CPDLC/ground), then O, else N/A FWD-USER

C.1: A conformant implementation will support one, and only one, of these two options.

114891149011491114921149311494114951149611497114981149911500115011150211503115041150511506115071150811509115101151111512115131151411515

11516115171151811519

11520115211152211523


Table 3-20. CPDLC-air-ASE conformant configurations

List of predicates Functionality description

I. CPDLC/air A CPDLC-air-ASE supporting just the core (see Note) CPDLC functionality (no downstream clearance capability)

II. CPDLC/air + DSC-FU A CPDLC-air-ASE supporting the core CPDLC functionality and the downstream clearance capability (complete CPDLC-air-ASE functionality)

Note.— The core CPDLC functionality is defined as support for the CPDLC-start, message, and end services plus the abort services.

Table 3-21. CPDLC-ground-ASE conformant configurations


I. CPDLC/ground A CPDLC-ground-ASE supporting the core CPDLC functionality plus:

– functionality for receiving and CPDLC-ground-user rejecting a request for a DSC dialogue

– functionality for receiving and indicating that the forward function is not supported

II. CPDLC/ground + DCS-FU + DSC-USER A CPDLC-ground-ASE supporting the core CPDLC functionality and downstream clearance function plus:

– functionality for receiving and indicating that the ground forward function is not supported

III. CPDLC/ground + DSC-FU + FWD-INIT A CPDLC-ground-ASE supporting the core CPDLC functionality plus:



– functionality for supporting the capability to initiate the ground forwarding of CPDLC messages

IV. CPDLC/ground + DCS-FU + DSC-USER + FWD-INIT

A CPDLC-ground-ASE supporting the core CPDLC functionality and downstream clearance function plus:


– functionality for supporting the capability to initiate the ground forwarding of CPDLC messages

V. CPDLC/ground + DSC-FU FWD-USER A CPDLC-ground-ASE supporting the core CPDLC functionality plus:

– functionality for receiving and CPDLC-ground-user rejecting a request for DSC dialogue

1152411525

11526115271152811529



VI. CPDLC/ground + DCS-FU + DSC-USER + FWD-USER


– functionality for CPDLC-ground-user support for the receipt of CPDLC ground forward messages

VII. CPDLC/ground + DSC-FU + FWD-INIT + FWD-USER

A CPDLC-ground-ASE supporting the core CPDLC functionality plus:


– full CPDLC ground forwarding functionality (initiating and user receiving)

VIII. CPDLC/ground + DSC-FU + DSC-USER + FWD-INIT + FWD-USER


– full CPDLC ground forwarding functionality (initiating and user receiving)

(complete CPDLC-ground-ASE functionality)

______________________

1153011531115321153311534

Chapter 4

FLIGHT INFORMATION SERVICES (FIS)

(PLACEHOLDER FOR NEW APPLICATIONTo be developed.)

______________________

54-1

11535

11536

11537

115381153911540115411154211543115441154511546

Chapter 5

AUTOMATIC DEPENDENT SURVEILLANCE —CONTRACT (ADS-C)

Note.— Structure of 5.1 defines the air-ground communication aspects of ADS-C. 5.2 defines the ground-ground (i.e. ADS-C report forwarding) aspects of ADS-C.

5.1 AUTOMATIC DEPENDENT SURVEILLANCE (CONTRACT) APPLICATION

5.1.1 Introduction

5.1.1.1 The ADS-C air ground application will allow users to obtain positional and other information from suitably equipped aircraft in a timely manner in accordance with their requirements. The ADS-C application is designed to give automatic reports about aircraft to a user. The ADS-C reports give positional as well as other information likely to be of use to the air traffic management function, including air traffic control. The aircraft provides the information to the user under the following circumstances:

a) under a contract (known as a demand contract) agreed with the ground system, the aircraft provides the information as soon as possible and once only;

b) under a contract (known as a periodic contract) agreed with the ground system, the aircraft provides information on a regular basis;

c) under a contract (known as an event contract) agreed with the ground system, the aircraft provides information when certain events are detected by the avionics;

Note 1.— Structure of 5.1: this chapter defines the air-ground communication aspects of the ADS-C application only.

a) 5.1.1: INTRODUCTION contains 5.1's purpose, structure, and a summary of the functions of the ADS-C application.

b) 5.1.2: GENERAL REQUIREMENTS contains backwards compatibility and error processing requirements.

[c)] 5.1.3: THE ABSTRACT SERVICE contains the description of the abstract service provided by the application service elements (ASE) defined for the ADS-C application.

c)[d)] 5.1.4: FORMAL DEFINITION OF MESSAGES contains the formal definition of Application Protocol Data Unit exchanged by ADS-C ASEs using Abstract Syntax Notation Number One (ASN.1).

54-1

11547

11548

11549

11550115511155211553

115541155511556

1155711558

11559115601156111562115631156411565115661156711568115691157011571115721157311574115751157611577115781157911580115811158211583115841158511586115871158811589115901159111592

Manual on Detailed Technical Specifications for the Aeronautical45-2 Telecommunication Network (ATN) Using ISO/OSI Standards and Protocols

[e)] 5.1.5: PROTOCOL DEFINITION describes the exchanges of messages allowed by the ADS-C protocol, as well as time constraints and the exception handling procedures associated with these exchanges. 5.1.5 describes also the ADS-C protocol in terms of state tables.

d)[f)] 5.1.6: COMMUNICATION REQUIREMENTS contains the requirements that the ADS-C ASE application imposes on the underlying communication system.

e)[g)] 5.1.7: ADS-USER REQUIREMENTS outlines the requirements that a user of an ADS-C ASE must meet.

f)[h)] 5.1.8: SUBSETTING RULES provides rules for subsetting the ADS-C application.

Note 2.— General Functionality

[a)] The avionics are capable of supporting contracts with at least four ATC ground systems simultaneously; they are also capable of supporting one demand, one event and one periodic contract with each ground system simultaneously.

[b)] It will be necessary for an implementation to provide information which is both accurate and timely in the ADS-C reports; however, quantification of the age and accuracy of the information is beyond the scope of 5.1.

a)[c)] The ground system can request that authentication and data integrity services be performed to ensure the identity of participating entities is as claimed and to ensure that ADS-C data is not altered or destroyed in an unauthorized manner.

Note 3.— Establishment and Operation of a Demand Contract

a) Functional Description

1) This function allows the ground system to establish a demand contract with an aircraft. Realisation of the contract involves the sending of a single report from an aircraft to the ground system.

[2)] Any number of demand contracts may be sequentially established with an aircraft. Basic information is sent with the report. Optionally, at the request of the ground system, other information may also be sent. Under emergency and/or urgency conditions, additional information are sent.

[3)] The ground system sends a demand contract request message to the avionics. This contains an indication of which optional information blocks are required. The avionics then determines whether or not there are errors in the request, and if there are no errors, whether or not it is able to comply with the request. If the avionics can comply with the demand contract request it sends the ADS-C report in a contract accept message as soon as possible. If there are errors in the contract request, or if the avionics cannot comply with the request, it sends a contract reject message to the ground system indicating the reason for its inability to accept the contract. If the avionics can partially comply with the request, it sends a non-compliance notification message indicating those parts of the contract with which it cannot comply, and then it sends an ADS-C report message.

2)[4)] If the avionics cannot send the report within the contract response time, it sends a

11593115941159511596115971159811599116001160111602116031160411605116061160711608116091161011611116121161311614116151161611617116181161911620116211162211623116241162511626116271162811629116301163111632116331163411635116361163711638116391164011641116421164311644

Part I. Air-Ground ApplicationsChapter 54. Flight information serviceAutomatic Dependant Surveillance (FISADS-C) 4-3

positive acknowledgement message first to indicate its acceptance of the contract.

b) Message Descriptions

[1)] The demand contract request message stipulates which of the optional information fields are to be included in the ADS-C report.

[2)] Each ADS-C report message always contains basic information.

[3)] Optionally, anThe ADS-C report message contains information blocks and an indication of the emergency and/or urgency status.

1)[4)] A contract accept message indicates acceptance of the contract and contains an ADS-C report.

2)[5)] A positive acknowledgement message indicates acceptance of the contract and contains no further information.

3)[6)] A contract reject message contains an indication of the reason why the contract has not been accepted.

[7)] A non-compliance notification message contains an indication of which optional information fields cannot be sent.

Note 4.— Establishment and Operation of an Event Contract


11645116461164711648116491165011651116521165311654116551165611657116581165911660116611166211663116641166511666116671166811669116701167111672


1) This function allows the ground system to establish an event contract with the aircraft. Realisation of the contract involves the sending of reports from the aircraft to the ground system when certain agreed events occur. The definition of the events is outside the scope of 5.1

[2)] Only one event contract may exist between the ground system and avionics at any one time, but this may contain multiple event types. A set of basic information is sent with every report, and depending on the event that triggered the sending of the report, other information blocks may also be included. The contract that is agreed states the event types that are to trigger reports and also any values needed to clarify those event types. Under emergency and/or urgency conditions, additional information are sent.

[3)] It is possible to request one or more of the event types

[4)] Acceptance of an event contract request implicitly cancels an existing event contract, if one exists.

[5)] The ground system sends an event contract request to the avionics. This contains the types of event to be reported on and the necessary parameters for that event (e.g. if the event is a level range deviation, then the upper and lower thresholds must be sent). The avionics then determines whether or not there are errors in the request, and if not, whether or not it is able to comply with the request. If the avionics can comply with the event contract request it sends any required baseline ADS-C report in a contract accept message. If the contracted event occurs, an ADS-C report is sent.

2)[6)] If there are errors in the event contract request, or if the avionics cannot comply with the request, it sends a contract reject message to the ground system indicating the reason for its inability to accept the contract within contract response time.

3)[7)] If the avionics can partially comply with the request, it sends a non-compliance notification indicating those parts of the contract with which it cannot comply. If a contracted event occurs with which it can comply, an ADS-C report is sent.

[8)] Depending of the type of event, if the event occurs, either a report is sent every 60 secondsperiodically while the limit(s) specified in the contract are exceeded or a single report is sent every time the event occurs.

11673116741167511676116771167811679116801168111682116831168411685116861168711688116891169011691116921169311694116951169611697116981169911700117011170211703117041170511706117071170811709


b) Message Descriptions

1) The event contract request message contains an indication of the events to be reported on, together with clarifying information.

[2)] The ADS-C report message has the same structure as in the operation of a demand contract, containing the basic information and an indication of the emergency and/or urgency status. The inclusion of data blocks can beis driven by the type of the triggering event(s). The definition of the reports is outside the scope of 5.1

2)[3)] A contract accept message indicates acceptance of the contract and contains an ADS-C report.

3)[4)] A positive acknowledgement message indicates acceptance of the contract and contains no further information.

4)[5)] A contract reject message contains an indication of the reason why the contract has not been accepted.

5)[6)] A non-compliance notification message contains an indication of the events which the avionics cannot detect.

11710117111171211713117141171511716117171171811719117201172111722117231172411725117261172711728117291173011731


Note 5.— Establishment and Operation of a Periodic Contract


1) This function allows the ground system to establish a periodic contract with the aircraft. Realisation of the contract involves the sending of reports from the aircraft to the ground system at regular intervals (the reporting rate).

[2)] Only one periodic contract may exist between a ground system and the avionics at any one time. A set of basic information is sent with every report. Optionally, at the request of the ground system, other information blocks may also be sent; they may only be sent at a time interval which is a multiple of the reporting rate. The contract that is agreed includes the reporting rate, the optional blocks of information to be sent and the rate at which they are to be sent.

[3)] The ground system sends a periodic contract request message to the avionics. This message contains the basic reporting rate and an indication of which optional information blocks are required and how often they are to be sent relative to the basic rate (i.e. every time, every second report, every third report etc.). The avionics then determines whether or not there are errors in the request, and if not, whether or not it is able to comply with the request. If the avionics can comply with the periodic contract request it sends its first report in a contract accept message, and then sends other ADS-C reports at the intervals requested. If it cannot send the first report within the contract response time, it sends a positive acknowledgement message first to indicate its acceptance of the contract.

2)[4)] Acceptance of a periodic contract request implicitly cancels any existing periodic contract.

3)[5)] If there are errors in the periodic contract request message, or if the avionics cannot accept the contract, it sends a contract reject message to the ground system indicating the reason for its inability to accept the contract within the contract response time.

[6)] If the avionics can partially comply with the request, it sends a non-compliance notification message indicating those parts of the contract with which it cannot comply. It then sends ADS-C reports at a rate with which it can comply, and containing information requested with which it can comply. Non-compliance can be caused by either inability to meet the requested reporting rate, and/or inability to supply the requested information.

1173211733117341173511736117371173811739117401174111742117431174411745117461174711748117491175011751117521175311754117551175611757117581175911760117611176211763117641176511766117671176811769117701177111772


[b)] Message Descriptions

1) The periodic contract request message may optionally contain the reporting interval and the modulus for the optional information blocks

Moduli indicate the multiple of the reporting rate that the information block is sent at (e.g. meteorological information modulus of 5 means that the meteorological information block is sent with every 5th report).

2) The ADS-C report message has the same structure as in the operation of a demand contract.

3) A contract accept message indicates acceptance of the contract and contains an ADS-C report.

4) A positive acknowledgement message indicates acceptance of the contract and contains no further information.

5) A contract reject message contains an indication of the reason why the contract has not been accepted.

6) A non-compliance notification message contains an indication of which optional information fields cannot be sent, and/or indicates that the requested periodic report cannot be met.

Note 6.— Cancellation of Contracts


1) This function allows the ground system explicitly to cancel a contract that is in operation. The ground system sends a cancel contract message to the avionics. The avionics cancels the contract and acknowledges the cancellation.

2) Implicit cancellation occurs when a periodic contract is in place, and then the ground system establishes a new periodic contract - the first one is implicitly cancelled on the establishment of the second; similarly with event contracts. Demand contracts are implicitly cancelled when the report is sent. There are no additional information flows associated with implicit cancellation.

3) The ground system may also cancel all contracts in a single cancel all contracts message. The avionics cancels all contracts and acknowledges the cancellation.


1) The cancel contract message contains an indication of the contract to be cancelled.

2) The cancel all contracts message contains no additional information.

3) A positive acknowledgement message contains no additional information.

117731177411775117761177711778117791178011781117821178311784117851178611787117881178911790117911179211793117941179511796117971179811799118001180111802118031180411805118061180711808118091181011811118121181311814118151181611817118181181911820118211182211823


4) A negative acknowledgement message contains an indication that no such contract existed (i.e. if a periodic contract was attempted to be cancelled when no periodic contract was active).

Note 7.— Operation of an Emergency and/or Urgency Alert

[a)] Functional Description

[1)] This function allows the avionics to provide all ground systems with which it has existing contracts (established or being established) with an emergency and/or urgency alert (either on instruction from the pilot or on its own initiative).

[2)] For a demand contract, the avionics sends the ADS-C report with the emergency and/or urgency condition included.

[3)] Any existing periodic and event contract remains in force with the same contract terms. The avionics sends an unsolicited ADS-C report containing the basic group information and the emergency and/or urgency condition. Then the avionics includes the emergency and/or urgency condition in all the ADS-C report it sends to all ground systems with which it has event or periodic contracts.


The ADS-C report messages sent when the aircraft in emergency and/or urgency condition has the same structure as in the operation of a demand, event or periodic contract, containing position, time and FOM. However the emergency and/or urgency condition is always included.

Note 8.— Modification of the Emergency and/or Urgency Condition


[1)] This function allows the aircraft to inform the ground systems with which it has a periodic or an event contract that the emergency and/or urgency condition has changed.

[2)] The avionics sends an unsolicited ADS-C report containing the basic group information with the new emergency and/or urgency condition.


The ADS-C report messages sent when the aircraft has modified the emergency and/or urgency condition has the same structure as in the operation of a demand, event or periodic contract, containing position, time and FOM. However the emergency and/or urgency condition is always included.

Note 9.— Cancellation of the Emergency and/or Urgency Condition


1182511826118271182811829118301183111832118331183411835118361183711838118391184011841118421184311844118451184611847118481184911850118511185211853118541185511856118571185811859118601186111862118631186411865118661186711868118691187011871118721187311874


[1)] This function allows the aircraft to inform the ground systems with which it has a periodic or an event contract that the emergency and/or urgency condition has been cancelled.

[2)] The avionics sends an unsolicited ADS-C report containing the basic group information with the emergency and/or urgency condition set to ‘emergency cancelled’.


The ADS-C report messages sent when the aircraft has cancelled the emergency and/or urgency condition has the same structure as in the operation of a demand, event or periodic contract, containing position, time and FOM. However the emergency and/or urgency condition is always included.

1187511876118771187811879118801188111882118831188411885118861188711888


5.1.2 General Requirements

5.1.2.1 ADS-C ASE Version Number

The ADS-air-ASE and the ADS-ground-ASE version numbers shall both be set to one.

5.1.2.2 Error Processing Requirements

5.1.2.2.1 In the event of information input by the ADS-user being incompatible with that able to be processed by the system, the user shall be notified.

5.1.2.2.2 In the event of an ADS-user invoking an ADS-C service primitive, when the ADS-C ASE is not in a state specified in 5.1.5, the user shall be notified.

118891189011891118921189311894118951189611897118981189911900119011190211903


5.1.3 The Abstract Service

5.1.3.1 Service Description

5.1.3.1.1 An implementation of either the ADS-C ground based service or the ADS-C air based service shall exhibit behaviour consistent with having implemented an ADS-ground-ASE, or ADS-air-ASE respectively.

5.1.3.1.2 This section defines the abstract service interface for the ADS-C service. The ADS-C ASE abstract service is described in this section from the viewpoint of the ADS-air-user, the ADS-ground-user and the ADS-C service-provider.

5.1.3.1.3 This section defines the static behaviour (i.e. the format) of the ADS-C service. Its dynamic behaviour (i.e. how it is used) is described in 5.7.

5.1.3.1.4 Figure 5-1 shows the functional model of the ADS-C Application. The functional modules identified in this model are the following:

a) the ADS-user,

b) the ADS-C Application Entity (ADS-AE) service interface,

c) the ADS-AE,

d) the ADS-C Control Function (ADS-CF),

e) the ADS-C application service element (ADS-C ASE) service interface,

f) the ADS-C ASE, and


Figure 5-1: Functional Model of the ADS-C Application

5.1.3.1.5 The ADS-user represents the operational part of the ADS-C system. This user does not perform the communication functions but relies on a communication service provided to it via the ADS-AE through the ADS-AE service interface. The individual actions at this interface are called ADS-AE service primitives. Similarly, individual actions at other interfaces in the communication system are called service primitives at these interfaces.

119041190511906119071190811909119101191111912119131191411915119161191711918119191192011921119221192311924119251192611927119281192911930119311193211933119341193511936

119371193811939119401194111942119431194411945


5.1.3.1.6 The ADS-AE consists of several elements, including the ADS-C ASE and the ADS-CF. The air/ground communication service interface is made available by the ADS-CF to the ADS-C ASE for communication with the peer ADS-C ASE.

5.1.3.1.7 The ADS-C ASE is the element in the communication system which executes the ADS-C specific protocol. In other words, it takes care of the ADS-C specific service primitive sequencing actions, message creation, timer management, error and exception handling.

5.1.3.1.8 The ADS-C ASE interfaces only with the ADS-CF. This ADS-CF is responsible for mapping service primitives received from one element (such as the ADS-C ASE and the ADS-user) to other elements which interface with it. The part of the ADS-CF which is relevant from the point of view of these specifications, i.e. the part between the ADS-user and the ADS-C ASE, will map ADS-AE service primitives to ADS-C ASE service primitives transparently.

5.1.3.1.9 The DS interface is the interface between the ADS-C ASE and part of ADS-CF underneath, the ADS-C ASE and provides the ATN dialogue service. The ADS-C ASE is designed to move on top of another communication service with no impact on the application protocol.

5.1.3.2 The ADS-C ASE Abstract Service

5.1.3.2.1 There is no requirement to implement the service in an ADS-C product; however, it is necessary to implement the ground based and air based system in such a way that it will be impossible to detect (from the peer system) whether or not an interface has been built.

5.1.3.2.2 The ADS-C ASE abstract service shall consist of a set of the following services as allowed by the subsetting rules defined in 5.8:

a) ADS-demand-contract service as defined in 5.1.3.3;

b) ADS-event-contract service as defined in 5.1.3.4;

c) ADS-periodic-contract service as defined in 5.1.3.5;

d) ADS-report service as defined In 5.1.3.6;

e) ADS-cancel service as defined in 5.1.3.7;

f) ADS-cancel-all-contracts service as defined in 5.1.3.8

g) ADS-user-abort service as defined in 5.1.3.9;

h) ADS-provider-abort service as defined in 5.1.3.10.

5.1.3.2.3 ADS-demand-contract, ADS-event-contract, ADS-periodic-contract, ADS-cancel and ADS-cancel-all-contracts are services only initiated by the ADS-ground-user.

5.1.3.2.4 ADS-report is a service only initiated by the ADS-air-user.

5.1.3.2.5 ADS-user-abort is a service initiated by an ADS-air-user or an ADS-ground-user.

5.1.3.2.6 ADS-provider-abort is a service only initiated by the ADS-C service-provider.

11946119471194811949119501195111952119531195411955119561195711958119591196011961119621196311964119651196611967119681196911970119711197211973119741197511976119771197811979119801198111982119831198411985119861198711988119891199011991119921199311994119951199611997


5.1.3.2.7 An abstract syntax is a syntactical description of a parameter which does not imply a specific implementation. Only when the ADS-C ASE maps a parameter onto an APDU field, or vice-versa, is the abstract syntax of the parameter described by using the ASN.1 of for this field.

5.1.3.2.8 For a given primitive, the presence of each parameter is described by one of the following values in the parameter tables in 5.1.3

blank not present;


C(=) conditional upon the value of the parameter to the immediate left being present, and equal to that value;

M mandatory;

M(=) mandatory, and equal to the value of the parameter to the immediate left;

U user option.

5.1.3.2.9 The following abbreviations are used in this document:

Req request; data is input by an ADS-user initiating the service to its respective ADS-C ASE;

Ind indication; data is indicated by the receiving ADS-CASE to its respective ADS-user;

Rsp response; data is input by receiving ADS-user to its respective ADS-C ASE;

Cnf confirmation; data is confirmed by the initiating ADS-CASE to its respective ADS-user.

5.1.3.2.10 An unconfirmed service allows just one message to be transmitted, in one direction.

5.1.3.2.11 A confirmed service provides end-to-end confirmation that a message sent by one user was received by its peer user.

5.1.3.3 ADS-demand-contract Service

5.1.3.3.1 General

5.1.3.3.1.1 The ADS-demand-contract service allows the ADS-ground-user to request a demand contract with the aircraft. It is a confirmed service, initiated by the ADS-ground-user.

5.1.3.3.1.2 The ADS-demand-contract service shall contain primitives and parameters as presented in Table 5-1.

11998119991200012001120021200312004120051200612007120081200912010120111201212013120141201512016120171201812019120201202112022120231202412025120261202712028120291203012031120321203312034120351203612037120381203912040120411204212043120441204512046


Table 5-1: ADS-demand-contract service parameters

Parameter Name Req Ind Rsp Cnf

Aircraft Identity M


ICAO Facility Designation C C(=)

ADS-C Message Set Version Number U C(=)

Security Required C

ADS/IC Contract Data M M(=)

Result M M(=)

ADS/IC Positive Acknowledgement C C(=)

ADS/IC Report Data C C(=)

ADS/IC Non Compliance Data C C(=)

ADS/IC Reject Data C C(=)

5.1.3.3.2 Aircraft Identity parameter

5.1.3.3.2.1 This parameter contains the 24 bit ICAO aircraft address of the aircraft or the aircraft identification with which the contract is being made.

5.1.3.3.2.2 When an aircraft address is used to identify the aircraft, the Aircraft Identity parameter value shall conform to an abstract value corresponding to a 24-bit ICAO aircraft address.

5.1.3.3.2.3 When an aircraft identification is used to identify the aircraft, the Aircraft Identity parameter value shall conform to an abstract value corresponding to a 2 to 7 character aircraft identification.

5.1.3.3.3 Class of Communication Service parameter

5.1.3.3.3.1 This parameter contains the value of the required class of communication service, if specified by the ADS-ground-user.

5.1.3.3.3.2 Where specified by the ADS-ground-user, the Class Of Communication Service parameter shall have one of the following abstract values: “A”, “B”, “C”, “D”, “E”, “F”, “G” or “H”.

5.1.3.3.3.3 If contracts are currently in place, the Class Of Communication Service parameter is not used by the ADS-C service provider.

5.1.3.3.3.4 Where not specified by the ADS-ground-user, when there are no contracts already in force, this indicates that there will be no routing preference.

1204712048

1204912050120511205212053120541205512056120571205812059120601206112062120631206412065120661206712068120691207012071120721207312074120751207612077


5.1.3.3.4 ICAO Facility Designation parameter

5.1.3.3.4.1 This parameter contains the 4 to 8 character ICAO Facility Designation of the ICAO facility which is initiating the contract. If contracts are currently in place, this parameter is not used by the ADS-service-provider.

5.1.3.3.4.2 The ICAO Facility Designation parameter value shall conform to an abstract value corresponding to a 4 to 8 character ICAO Facility Designation.

5.1.3.3.4.3 The ICAO Facility Designation parameter value shall be provided when the ADS-ground-user has no other contracts in place with the aircraft.

5.1.3.3.5 ADS-C Message Set Version Number parameter

5.1.3.3.5.1 This parameter contains the version number of the ADS-ASE and identifies the user data abstract syntax.

5.1.3.3.5.2 When provided by the ADS-user, the ADS-C Message Set Version Number parameter shall conform to an abstract integer value from 1 to 255.

5.1.3.3.6 Security Required parameter

5.1.3.3.6.1 This parameter contains the value of the required level of security, if specified by the ADS-ground-user.

5.1.3.3.6.2 If the received Security Required parameter is not as expected per the local security policy, the receiving ADS-air-ASE will abort.

5.1.3.3.6.3 Where specified by the ADS-ground-user, the Security Required parameter shall have one of the following abstract values: “no security” or “secured exchange”.

5.1.3.3.6.4 If contracts are currently in place, the Security Required parameter is not used by the ADS-C service provider.

5.1.3.3.7 ADS/IC Contract Data parameter

5.1.3.3.7.1 This parameter contains the details of the demand contract as requested by the ADS-ground-user.

5.1.3.3.7.2 This parameter contains an Application Message Integrity Check.

5.1.3.3.7.3 The ADS/IC Contract Details parameter value shall conform to the ASN.1 abstract syntax ICContractRequest.

5.1.3.3.8 Result parameter

5.1.3.3.8.1 This parameter indicates the extent to which the demand contract request can be complied with:

a) if it has the value “positive acknowledgement”, it indicates that the demand contract has been accepted but the ADS-C report will be sent later, and the ADS/IC Positive Acknowledgement parameter indicates the contract type,

12078120791208012081120821208312084120851208612087120881208912090120911209212093120941209512096120971209812099121001210112102121031210412105121061210712108121091211012111121121211312114121151211612117121181211912120121211212212123121241212512126121271212812129


b) if it has the value “accepted”, it indicates that the demand contract has been accepted and the ADS/IC Report Data parameter contains the report,

c) if it has the value “rejected”, it indicates that the demand contract has been rejected and the ADS/IC Reject Data parameter gives reasons,

d) if it has the value “non compliance notification”, it indicates that only some parts of the demand contract can be complied with and the ADS/IC Non Compliance Data parameter indicates which ones have been rejected.

5.1.3.3.8.2 If it has the value “positive acknowledgement”, this indicates that the contract has been accepted but cannot be satisfied immediately because the information is not available within the contract response time.

5.1.3.3.8.3 The Result parameter value shall conform to one of the following abstract values: “accepted”, “rejected”, “positive acknowledgement”, or “non compliance notification”.

5.1.3.3.9 ADS/IC Positive Acknowledgement parameter

5.1.3.3.9.1 This parameter contains the details of the ADS-C positive acknowledgement.


5.1.3.3.9.3 The ADS/IC positive acknowledgement parameter value shall conform to the ASN.1 abstract syntax ICPositiveAck.

5.1.3.3.9.4 The ADS/IC positive acknowledgement parameter value shall be present if and only if the Result parameter contains the abstract value “positive acknowledgement”.

5.1.3.3.10 ADS/IC Report Data parameter

5.1.3.3.10.1 This parameter contains the details of the ADS-C report.


5.1.3.3.10.3 The ADS/IC Report Data parameter value shall conform to the ASN.1 abstract syntax ICReport.

5.1.3.3.10.4 The ADS/IC Report Data parameter value shall be present if and only if the Result parameter contains the abstract value “accepted”.

5.1.3.3.11 ADS/IC Reject Data parameter

5.1.3.3.11.1 This parameter contains the reason of the contract rejection.


5.1.3.3.11.3 The ADS/IC Reject Data parameter value shall conform to the ASN.1 abstract syntax ICReject.

1213012131121321213312134121351213612137121381213912140121411214212143121441214512146121471214812149121501215112152

12154121551215612157121581215912160121611216212163121641216512166121671216812169121701217112172121731217412175121761217712178121791218012181


5.1.3.3.11.4 The ADS/IC Reject Data parameter value shall be present if and only if the Result parameter contains the abstract value “rejected”.

5.1.3.3.12 ADS/IC Non Compliance Data parameter

5.1.3.3.12.1 This parameter contains an indication of which optional information fields cannot be sent.


5.1.3.3.12.3 The ADS/IC Non Compliance Data parameter value shall conform to the ASN.1 abstract syntax ICNonCompliance.

5.1.3.3.12.4 The ADS/IC Non Compliance Data parameter value shall be present if and only if the Result parameter contains the abstract value “non compliance notification”.

5.1.3.4 ADS-event-contract Service

5.1.3.4.1 General

5.1.3.4.1.1 The ADS-event-contract service allows the ADS-ground-user to request an event contract with the aircraft. It is a confirmed service, initiated by the ADS-ground-user.

5.1.3.4.1.2 The ADS-event-contract service shall contain primitives and parameters as presented in Table 5-2.

Table 5-2: ADS-event-contract service parameters


Aircraft Identity M




Security Required C


Result M M(=)





1218212183121841218512186121871218812189121901219112192121931219412195121961219712198121991220012201122021220312204122051220612207122081220912210

1221112212


5.1.3.4.2 Aircraft Identity

5.1.3.4.2.1 This parameter contains the 24 bit ICAO address of the aircraft or the aircraft identification with which the contract is being made.



5.1.3.4.3 Class of Communication Service


5.1.3.4.3.2 Where specified by the ADS-ground-user, the Class Of Communication Service parameter shall have one of the following abstract values: “A”, “B”, “C”, “D”, “E”, “F”, “G” or “H”.



5.1.3.4.4 ICAO Facility Designation







5.1.3.4.6 Security Required


12213122141221512216122171221812219122201222112222122231222412225122261222712228122291223012231122321223312234122351223612237122381223912240122411224212243122441224512246122471224812249122501225112252122531225412255122561225712258122591226012261122621226312264





5.1.3.4.7 ADS/IC Contract Data

5.1.3.4.7.1 This parameter contains the details of the event contract as requested by the ADS-ground-user.


5.1.3.4.7.3 The ADS/IC contract data parameter value shall conform to the ASN.1 abstract syntax ICContractRequest.

5.1.3.4.8 Result

5.1.3.4.8.1 This parameter indicates the extent to which the event contract request can be complied with:

a) If it has the value “rejected”, it indicates that the event contract has been rejected and the ADS/IC Reject Data parameter gives reasons,

b) If it has the value “accepted”, it indicates that the event contract has been accepted and the ADS/IC Report Data parameter contains the report,

c) If it has the value “non compliance notification”, it indicates that only some parts of the event contract can be complied with, and the ADS/IC Non Compliance Data parameter indicates which ones have been rejected,

d) If it has the value “positive acknowledgement”, it indicates full compliance with the event contract has been accepted but the ADS-C report will be sent later, and the ADS/IC Positive Acknowledgement parameter indicates the contract type.


5.1.3.4.9 ADS/IC Positive Acknowledgement




1226512266122671226812269122701227112272122731227412275122761227712278122791228012281122821228312284122851228612287122881228912290122911229212293122941229512296122971229812299123001230112302123031230412305123061230712308123091231012311

123131231412315



5.1.3.4.10 ADS/IC Report Data



5.1.3.4.10.3 The ADS/IC report data parameter value shall conform to the ASN.1 abstract syntax ICReport.

5.1.3.4.10.4 The ADS/IC report data parameter value shall be present if and only if the Result parameter contains the abstract value “accepted”.

5.1.3.4.11 ADS/IC Reject Data



5.1.3.4.11.3 The ADS/IC reject data parameter value shall conform to the ASN.1 abstract syntax ICReject.

5.1.3.4.11.4 The ADS/IC reject data parameter value shall be present if and only if the Result parameter contains the abstract value “rejected”.

5.1.3.4.12 ADS/IC Non Compliance Data



5.1.3.4.12.3 The ADS/IC non compliance data parameter value shall conform to the ASN.1 abstract syntax ICNonCompliance.

5.1.3.4.12.4 The ADS/IC non compliance data parameter value shall be present if and only if the Result parameter contains the abstract value “non compliance notification”.

5.1.3.5 ADS-periodic-contract Service

5.1.3.5.1 General

5.1.3.5.1.1 The ADS-periodic-contract service allows the ADS-ground-user to request a periodic contract with the aircraft. It is a confirmed service, initiated by the ADS-ground-user.

5.1.3.5.1.2 The ADS-periodic-contract service shall contain primitives and parameters as presented in Table 5-3.

123161231712318123191232012321123221232312324123251232612327123281232912330123311233212333123341233512336123371233812339123401234112342123431234412345123461234712348123491235012351123521235312354123551235612357123581235912360123611236212363123641236512366


Table 5-3: ADS-periodic-contract service parameters


Aircraft Identity M




Security Required C


Result M M(=)





5.1.3.5.2 Aircraft Identity parameter

5.1.3.5.2.1 This parameter contains the 24 bit ICAO address of the aircraft or the aircraft identification with which the contract is being made.



5.1.3.5.3 Class of Communication Service parameter


5.1.3.5.3.2 Where spcified by the ADS-ground-user, the Class Of Communication Service parameter shall have one of the following abstract values: “A”, “B”, “C”, “D”, “E”, “F”, “G” or “H”.



1236712368

1236912370123711237212373123741237512376123771237812379123801238112382123831238412385123861238712388123891239012391123921239312394123951239612397


5.1.3.5.4 ICAO Facility Designation parameter







5.1.3.5.6 Security Required parameter





5.1.3.5.7 ADS/IC Contract Data parameter

5.1.3.5.7.1 This parameter contains the details of the periodic contract as requested by the ADS-ground-user.

5.1.3.5.7.2 This parameter contains the Application Message Integrity Check.

5.1.3.5.7.3 The ADS/IC Contract Data parameter value shall conform to the ASN.1 abstract syntax ICContractRequest.

5.1.3.5.8 Result parameter

5.1.3.5.8.1 This parameter indicates the extent to which the periodic contract request can be complied with:

a) If it has the value “rejected” it indicates that the periodic contract has been rejected and the ADS/IC Reject Data parameter gives reasons,

123981239912400124011240212403124041240512406124071240812409124101241112412124131241412415124161241712418124191242012421124221242312424124251242612427124281242912430124311243212433124341243512436124371243812439124401244112442124431244412445124461244712448


b) If it has the value “accepted”, it indicates that the periodic contract has been accepted and the ADS/IC Report Data parameter contains the report,

c) If it has the value “non compliance notification”, it indicates that only some parts of the contract can be complied with, and the ADS/IC Non Compliance Data parameter indicates which ones have been rejected,

[d)] If it has the value “positive acknowledgement”, it indicates that the contract has been accepted but cannot be satisfied immediately, either because there is an emergency contract in place, or because the information is not available within the contract response time, and the ADS/IC Positive Acknowledgement parameter indicates the contract type.


5.1.3.5.9 ADS/IC Positive Acknowledgement parameter








5.1.3.5.10.3 The ADS/IC report data parameter value shall conform to the ASN.1 abstract syntax ICReport.

5.1.3.5.10.4 The ADS/IC report data parameter value shall be present if and only if the Result parameter contains the abstract value “accepted”.

5.1.3.5.11 ADS/IC Reject Data parameter



5.1.3.5.11.3 The ADS/IC reject data parameter value shall conform to the ASN.1 abstract syntax ICReject.

12449124501245112452124531245412455124561245712458124591246012461124621246312464124651246612467124681246912470

12472124731247412475124761247712478124791248012481124821248312484124851248612487124881248912490124911249212493124941249512496124971249812499


5.1.3.5.11.4 The ADS/IC reject data parameter value shall be present if and only if the Result parameter contains the abstract value “rejected”.

5.1.3.5.12 ADS/IC Non Compliance Data parameter



5.1.3.5.12.3 The ADS/IC non compliance data parameter value shall conform to the ASN.1 abstract syntax ICNonCompliance.

5.1.3.5.12.4 The ADS/IC non compliance data parameter value shall be present if and only if the Result parameter contains the abstract value “non compliance notification”.

5.1.3.6 ADS-report Service

5.1.3.6.1 General

5.1.3.6.1.1 The ADS-report service allows the ADS-air-user to send an ADS-C report to the ADS-ground-user. This is an unconfirmed service, initiated by the ADS-air-user.

5.1.3.6.1.2 The ADS-report service shall contain primitives and parameters as contained in Table 5-4.

Table 5-4: ADS-report service parameters

Parameter Name Req Ind

Contract type M M(= )

ADS/IC Report Data M M(= )

5.1.3.6.2 Contract Type parameter

5.1.3.6.2.1 This parameter identifies the type of contract that this report is in response to.

5.1.3.6.2.2 The contract type parameter value shall contain a value conforming to the abstract syntax ContractType.


5.1.3.6.3.1 This parameter contains the details of the ADS-C report. 5.1.3.6.3.2 This parameter contains the Application Message Integrity Check.

5.1.3.6.3.3 The ADS/IC Report Data parameter value shall conform to the ASN.1 abstract syntax ICReport.

1250012501125021250312504125051250612507125081250912510125111251212513125141251512516125171251812519125201252112522125231252412525125261252712528

1252912530125311253212533125341253512536125371253812539125401254112542125431254412545


5.1.3.7 ADS-cancel Service

5.1.3.7.1 General

5.1.3.7.1.1 The ADS-cancel service allows the ADS-ground-user to cancel an existing ADS-C contract. It is a confirmed service, initiated by the ADS-ground-user.

5.1.3.7.1.2 The ADS-cancel service shall contain primitives and parameters as contained in Table 5-5.

Table 5-5: ADS-cancel service parameters

Parameter Name Req Ind Cnf

Contract type M M(=) M(=)

5.1.3.7.2 Contract Type parameter

5.1.3.7.2.1 This parameter identifies the type of ADS-C contract that is to be cancelled.

5.1.3.7.2.2 The Contract type parameter value shall conform to the ASN.1 abstract syntax CancelContract.

5.1.3.8 ADS-cancel-all-contracts Service

5.1.3.8.1 General

5.1.3.8.1.1 The ADS-cancel-all-contracts service allows the ADS-ground-user to cancel all ADS-C contracts with a particular aircraft. It is a confirmed service, initiated by the ADS-ground-user.

5.1.3.8.1.2 The ADS-cancel-all-contracts service shall contain primitives as contained in Table 5-6.

Table 5-6: ADS-cancel-all-contracts service parameters

Parameter Name Req Ind Cnf

None

5.1.3.9 ADS-user-abort Service

5.1.3.9.1 General

5.1.3.9.1.1 The ADS-user-abort service allows the ADS-air-user to abort all ADS-C contracts with a particular ground system or ADS-ground-user to abort all ADS-C contracts with a particular aircraft. It is an unconfirmed service, initiated by an ADS-ground-user or the ADS-air-user. Messages in transit may be lost during this operation. It can be invoked at any time that the ADS-user is aware that any ADS-C service is in operation.

5.1.3.9.1.2 If the service is invoked prior to complete establishment of the dialogue, the ADS-user-abort indication may not be provided. An ADS-provider-abort indication may result instead.

125461254712548125491255012551125521255312554125551255612557

1255812559125601256112562125631256412565125661256712568125691257012571125721257312574125751257612577

12578125791258012581125821258312584125851258612587125881258912590


5.1.3.9.1.3 The ADS-user-abort service shall contain primitives as contained in Table 5-7.

Table 5-7: ADS-user-abort service parameters

Parameter Name Req Ind

Reason U M

5.1.3.9.2 Reason parameter

5.1.3.9.2.1 This parameter is used to indicate a reason for aborting the ADS-C contracts.

5.1.3.9.2.2 If provided by the ADS-user, the parameter indicated to the peer ADS-user is that provided by the ADS-user, else it is what the ASE supplies.

5.1.3.9.2.3 The reason parameter value shall conform to the ASN.1 abstract syntax UserAbortReason.

5.1.3.9.2.4 When the reason parameter is provided by the ADS-user, the same value shall be indicated to the peer ADS-user.

5.1.3.10 ADS-provider-abort Service

5.1.3.10.1 General

5.1.3.10.1.1 The ADS-provider-abort service allows the ADS-service-provider to inform the ADS-ground-user and the ADS-air-user that it can no longer provide the ADS-C service for a particular ADS-ground-user - ADS-air-user pairing. It is initiated by the ADS-service-provider. Messages in transit may be lost during this operation.

5.1.3.10.1.2 The ADS-provider-abort service shall contain primitives and parameters as contained in Table 5-8.

Table 5-8: ADS-provider-abort service parameters

Parameter Name Ind

Reason M

5.1.3.10.2 Reason parameter

5.1.3.10.2.1 This parameter identifies the reason for the provider abort.

5.1.3.10.2.2 The reason parameter shall conform to the ASN.1 abstract syntax ProviderAbortReason.

1259112592125931259412595

1259612597125981259912600126011260212603126041260512606126071260812609126101261112612126131261412615126161261712618126191262012621

12622126231262412625126261262712628


5.1.4 Formal Definitions of Messages

5.1.4.1 Encoding/Decoding Rules

5.1.4.1.1 An ADS-air-ASE shall be capable of encoding [ADSAircraftPDUs] APDUs and decoding [ADSGroundPDUs] APDUs.

5.1.4.1.2 An ADS-ground-ASE shall be capable of encoding [ADSGroundPDUs] APDUs and decoding [ADSAircraftPDUs] APDUs.

5.1.4.2 ADS-C ASN.1 Abstract Syntax

5.1.4.2.1 The abstract syntax of the air-ground ADS-C protocol data units shall comply with the description contained in the ASN.1 module PMADSCAPDUVersion1 (conforming to ISO/IEC 8824), as defined below.

PMADSCAPDUVersion1 DEFINITIONS ::=

BEGIN

-- -------------------------------------------------------------------------------------------------------------------------- Aircraft-generated and Ground-generated Message Choice-- ------------------------------------------------------------------------------------------------------------------------ADSAircraftPDUs ::= SEQUENCE{

timestamp [0] DateTimeGroup,adsAircraftPdu [1] ADSAircraftPDU

}

ADSAircraftPDU ::= CHOICE{

aDS-report-PDU [0] Report,aDS-accepted-PDU [1] Report,aDS-rejected-PDU [2] Reject,aDS-ncn-PDU [3] NonCompliance,aDS-positive-acknowledgement-PDU [4] PositiveAcknowledgement,aDS-cancel-positive-acknowledgement-PDU [5] RequestType,aDS-cancel-negative-acknowledgement-PDU [6] CancelRejectReason,aDS-provider-abort-PDU [7] ProviderAbortReason,aDS-user-abort-PDU [8] UserAbortReason,...

}

ADSGroundPDUs ::= SEQUENCE{

timestamp [0] DateTimeGroup,adsGroundPdu [1] ADSGroundPDU

}

126291263012631126321263312634126351263612637126381263912640126411264212643

1264412645126461264712648126491265012651126521265312654126551265612657126581265912660126611266212663126641266512666126671266812669126701267112672126731267412675126761267712678


ADSGroundPDU ::= CHOICE{

aDS-cancel-all-contracts-PDU [0] NULL,aDS-cancel-contract-PDU [1] CancelContract,aDS-contract-PDU [2] ContractRequest,aDS-provider-abort-PDU [3] ProviderAbortReason,aDS-user-abort-PDU [4] UserAbortReason,...

}

-- -------------------------------------------------------------------------------------------------------------------------- Ground-generated and Aircraft-generated message components - Protocol Data Units-- ------------------------------------------------------------------------------------------------------------------------ContractRequest ::= SEQUENCE{

contract-type [0] ContractType,ic-contract-request [1] ICContractRequest

}

ICContractRequest ::= SEQUENCE{

algorithmIdentifier [0] AlgorithmIdentifier OPTIONAL,aDSMessage [1] ADSMessage,

-- PER encoded User Data ADSRequestContractintegrityCheck [2] BIT STRING,...

}

ICPositiveAck ::= SEQUENCE{

algorithmIdentifier [0] AlgorithmIdentifier OPTIONAL,aDSPositiveAck [1] ADSMessage,

-- PER encoded User Data ADSPositiveAcknowledgementintegrityCheck [2] BIT STRING,…

}

PositiveAcknowledgement ::= SEQUENCE{

contract-type [0] ContractType,ic-positive-ack [1] ICPositiveAck

}

Report ::= SEQUENCE{

contract-type [0] ContractType,ic-report [1] ICReport

}

126791268012681126821268312684126851268612687126881268912690126911269212693126941269512696126971269812699127001270112702127031270412705127061270712708127091271012711127121271312714127151271612717127181271912720127211272212723127241272512726127271272812729


ICReport ::= SEQUENCE{


-- PER encoded User Data ADSReport integrityCheck [2] BIT STRING,...

}

Reject ::= SEQUENCE{

contract-type [0] ContractType OPTIONAL,ic-reject [1] ICReject

}

ICReject ::= SEQUENCE{


-- PER encoded User Data ADSRejectintegrityCheck [2] BIT STRING,...

}

NonCompliance ::= SEQUENCE{

contract-type [0] ContractType,ic-ncn [1] ICNonCompliance

}

ICNonCompliance ::= SEQUENCE{


-- PER encoded User Data ADSNonComplianceintegrityCheck [2] BIT STRING,...

}

CancelContract ::= ENUMERATED{

event-contract (0),periodic-contract (1),...

}

AlgorithmIdentifier ::= RELATIVE-OID -- root is {icao-arc atn-algorithms(9)}

ADSMessage ::= BIT STRING

127301273112732127331273412735127361273712738127391274012741127421274312744127451274612747127481274912750127511275212753127541275512756127571275812759127601276112762127631276412765127661276712768127691277012771127721277312774127751277612777127781277912780


RequestType ::= ENUMERATED{

cancel-event-contract (0),cancel-periodic-contract (1),cancel-all-contracts (2),...

}

CancelRejectReason ::= SEQUENCE{

requestType [0] RequestType,rejectReason [1] RejectReason,…

}

RejectReason ::= ENUMERATED{

no-such-contract (0),…

}

ContractType ::= ENUMERATED{

event-contract (0),periodic-contract (1),demand-contract (2)

}

ProviderAbortReason ::= ENUMERATED{

communications-service-failure (0),unrecoverable-system-error (1),invalid-PDU (2),sequence-error (3),timer-expiry (4),cannot-establish-contact (5),undefined-error (6),dialogue-end-not-accepted (7),unexpected-PDU (8),decoding-error (9),invalid-qos-parameter (10),...

}

UserAbortReason ::= ENUMERATED{undefined (0),unknown-integrity-check (1),validation-failure (2),unable-to-decode-message (3),...}

12781127821278312784127851278612787127881278912790127911279212793127941279512796127971279812799128001280112802128031280412805128061280712808128091281012811128121281312814128151281612817128181281912820128211282212823128241282512826128271282812829128301283112832


DateTimeGroup ::= SEQUENCE{

date Date,time Time

}

Date ::= SEQUENCE{

year DateYear,month DateMonth,day DateDay

}

DateYear ::= INTEGER (1996..2095)-- unit = year-- Range = 1996 to 2095

DateMonth ::= INTEGER (1..12)-- unit = month-- Range = January to December

DateDay ::= INTEGER (1..31)-- unit = day-- Range = 1 to 31

Time ::= SEQUENCE{

timeHours [0] TimeHours,timeMinutes [1] TimeMinutes,timeSeconds [2] TimeSeconds OPTIONAL

}

TimeHours ::= INTEGER (0..23)-- Unit = hours-- Range = midnight to 23.00 (11 PM)

TimeMinutes ::= INTEGER (0..59)-- Unit = minutes-- Range = 0 minutes to 59 minutes

TimeSeconds ::= INTEGER (0..59)-- Unit = seconds-- Range = 0 seconds to 59 seconds

END

128331283412835128361283712838128391284012841128421284312844128451284612847128481284912850128511285212853128541285512856128571285812859128601286112862128631286412865128661286712868128691287012871128721287312874128751287612877128781287912880


5.1.5 Protocol Definition

5.1.5.1 Sequence Rules

5.1.5.1.1 Only the sequence of primitives illustrated in Figure 6-2 to Figure 5-24 shall be permitted.

5.1.5.1.2 The following figures define the valid sequences of primitives that are possible to be invoked during the operation of the ADS-C application over the ATN Dialogue. They show the relationship in time between the service request and the resulting indication, and if applicable, the subsequent response and the resulting confirmation.

5.1.5.1.3 Abort primitive may interrupt and terminate any of the normal message sequences outlined below.

5.1.5.1.4 Primitives are processed in the order in which they are received.

Figure 5-2: Use of demand contract (accepted or rejected) with no dialogue existing

1288112882128831288412885128861288712888128891289012891128921289312894

12895128961289712898


Figure 5-3: Use of demand contract (accepted or rejected) with dialogue existing

1289912900129011290212903


Figure 5-4: Use of demand contract (non compliance notification or positive acknowledgement) with no dialogue existing

Figure 5-5: Use of demand contract (non compliance notification or positive acknowledgement) with dialogue existing

129041290512906

1290712908129091291012911

1291212913129141291512916


Figure 5-6: Use of event contract (positive acknowledgement or non compliance notification) with no dialogue existing

Figure -7: Use of event contract (positive acknowledgement or non compliance notification) with dialogue existing

12917129181291912920

12921129221292312924


Figure 5-8: Use of event contract (accepted) with no dialogue existing

Figure 5-9: Use of event contract (accepted) with dialogue existing

129251292612927

129281292912930


Figure 5-10: Use of event contract (positive acknowledgement or non compliance notification and immediate report) with no dialogue existing

Figure 5-11: Use of event contract (rejected) with no dialogue existing

12931129321293312934

12935129361293712938


Figure 5-12: Use of event contract (rejected) with dialogue existing

Figure 5-13: Use of periodic contract (accepted) with no dialogue existing

129391294012941

129421294312944


Figure 5-14: Use of periodic contract (accepted) with a dialogue existing

Figure 5-15: Use of periodic contract (positive acknowledgement or non compliance notification) with no dialogue existing

129451294612947

12948129491295012951


Figure 5-16: Use of periodic contract (rejected) with no dialogue existing

Figure 5-17: Use of periodic contract (positive acknowledgement or non compliance notification) with dialogue existing

129521295312954

12955129561295712958


Figure 5-18: Use of periodic contract (rejected) with a dialogue existing

Figure 5-19: Use of ADS-cancel contract service

129591296012961

129621296312964


Figure 5-20: Use of ADS-cancel-contract service with only one contract

Figure 5-21: Use of ADS-cancel-all-contracts service

129651296612967

1296812969129701297112972


Figure 5-22: Air user abort service

Figure 5-23: Ground user abort service

129731297412975

129761297712978


Figure 5-24: Air ASE abort

Figure 5-25: Ground ASE abort

129791298012981

129821298312984


5.1.5.2 ADS-C Service Provider Timers

5.1.5.2.1 The ADS-C ASE shall be capable of detecting when a timer expires.

5.1.5.2.2 Table 5-9 lists the time constraints related to the ADS-C application. Each time constraint requires a timer to be set in the ADS-C protocol machine.

5.1.5.2.3 If the timer expires before the final event has occurred, the ADS-C ASE takes the appropriate action as defined in .

5.1.5.2.4 The timer values should be as indicated in Table 5-9.

Table 5-9: ADS-C Service Provider Timers

ADS-C service Timer Timer Value

Timer Start Event Timer Stop Event

ADS-demand- contract

t-DC-1 6 minutes ADS-demand-contract request ADS-demand-contract confirmation

t-DC-2 3 minutes

30 seconds

ADS-demand-contract confirmation (pos-ack, ncn)

ADS-report indication

ADS-event- contract

t-EC-1 6 minutes ADS-event-contract request ADS-event-contract confirmation

t-EC-2 6 minutes ADS-cancel request ADS-cancel-contract confirmation

ADS-periodic- contract

t-PC-1 6 minutes ADS-periodic-contract request ADS-periodic-contract confirmation

t-PC-2 123 minutes (longest reporting rate + 3 minutes)

ADS-report indication or ADS-periodic-contract confirmation

ADS-report indication

t-PC-3 6 minutes ADS-cancel request ADS-cancel-contract confirmation

General t-LI-1 6 minutes D-END request D-END confirmation

Note.— The receipt of ADS-user-abort request, D-ABORT indication or D-P-ABORT indication are also timer stop events.

1298512986129871298812989129901299112992129931299412995129961299712998

1299913000130011300213003


5.1.5.3 ADS-C ASE Protocol Description

5.1.5.3.1 Description

5.1.5.3.1.1 ADS-C ASE Functional Model

5.1.5.3.1.1.1 The ADS-ground-ASE is functionally made of 6 modules as shown in Figure 5-27 and the ADS-air-ASE is functionally made of a similar 6 modules as shown in Figure 5-26:

a) the ADS-C High Interface Module (ADS-C HI module) interfaces with the ASE-user through the abstract service interface as defined in 5.1.3.

b) the ADS-C Demand Contract Module (ADS-C DC module) manages all demand contracts with a single ground system.

c) the ADS-C Event Contract Module (ADS-C EC module) manages event contracts with a single ground system.

d) the ADS-C Periodic Contract Module (ADS-C PC module) manages periodic contracts with a single ground system.

e) the ADS-C Abort Module (ADS-C AB module) handles aborts in case of unrecoverable error.

f) the Low Interface Modules (LI modules) described in this document interfaces the ATN Dialogue Service Provider on behalf of the DC, EC and PC and AB modules.

Figure 5-26: Functional model of the ADS-air-ASE

130041300513006130071300813009130101301113012130131301413015130161301713018130191302013021130221302313024130251302613027130281302913030

13031130321303313034


Figure 5-27: Functional model of the ADS-ground-ASE

5.1.5.3.1.1.2 There is no difference between the ADS-ground-ASE and the ADS-air-ASE functional models.

5.1.5.3.1.1.3 Section 5.1.5.3 describes the actions of the individual modules in both the air and ground systems. Section 5.1.5.5 contains state tables for the individual modules.

5.1.5.3.1.1.3 The ADS-ground-user is considered an active user from the time at which it invokes the first ADS-demand-contract request, an ADS-event-contract request or an ADS-periodic-contract request until such time that:

a) the ADS-ground-user receives an ADS-cancel-all-contracts confirmation,

b) the ADS-ground-user receives an ADS-cancel confirmation, and there are no other contracts in place,

c) the ADS-ground-user receives an ADS-demand-contract confirmation, an ADS-event-contract confirmation or an ADS-periodic-contract confirmation, with the Result parameter value set to “rejected”, and there are no other contracts in place,

d) the ADS-ground-user receives an ADS-demand-contract confirmation with the Result parameter value set to “accepted” an ADS-report indication, with the Contract type parameter value set to “demand contract”, and there are no other contracts in place,

e) the ADS-ground-user receives an ADS-user-abort indication,

f) the ADS-ground-user receives an ADS-provider-abort indication, or

g) the ADS-ground-user invokes an ADS-user-abort request.

5.1.5.3.1.1.4 The ADS-air-user is considered an active user from the time at which it receives the first ADS-demand-contract indication, an ADS-event-contract indication or an ADS-periodic-contract indication until such time that:

a) the ADS-air-user receives an ADS-cancel-all-contracts indication,

b) the ADS-air-user receives an ADS-cancel indication, and there are no other contracts in place,

1303513036130371303813039130401304113042130431304413045130461304713048130491305013051130521305313054130551305613057130581305913060130611306213063130641306513066130671306813069130701307113072130731307413075


c) the ADS-air-user invokes an ADS-demand-contract response, an ADS-event-contract response or an ADS-periodic-contract response, with the Result parameter value set to “rejected”, and there are no other contracts in place,

d) the ADS-air-user invokes an ADS-demand-contract response with the Result parameter value set to “accepted” an ADS-report request, with the Contract type parameter value set to “demand contract”, and there are no other contracts in place,

e) the ADS-air-user receives an ADS-user-abort indication,

f) the ADS-air-user receives an ADS-provider-abort indication, or

g) the ADS-air-user invokes an ADS-user-abort request.

5.1.5.3.2 In section 5.1.5.3, if no actions are described for an ADS-C service primitive in a particular state, then the invocation of that service primitive shall be prohibited in that state.

5.1.5.3.3 Possible errors arising upon Receipt of an APDU or a Dialogue Service Primitive.

5.1.5.3.3.1 If an APDU is not received when one is required, or one is received in an inappropriate dialogue service primitive, then exception handling procedures as described in 5.1.5.4.3 shall apply.

5.1.5.3.3.2 Upon receipt of an APDU or dialogue service primitive, if no actions are described for their arrival when in a particular state, then exception handling procedures as described in 5.1.5.4.4 shall apply.

5.1.5.3.3.3 Upon receipt of an APDU that cannot be decoded, then exception handling procedures as described in 5.1.5.4.7 shall apply.

5.1.5.3.4 Ground ADS-C HI Module

5.1.5.3.4.1 Upon receipt of a service primitive, the ADS-C HI module shall pass it to the module as shown in Table 5-10.

Table 5-10: Request and response primitive to ground module mapping

Service Primitive ADS-ground-ASE Module

ADS-demand-contract request ADS-C DC

ADS-event-contract request ADS-C EC

ADS-periodic-contract request ADS-C PC

ADS-cancel request with contract type “event-contract” ADS-C EC

ADS-cancel request with contract type “periodic-contract”

ADS-C PC

ADS-cancel-all-contracts request ADS-C LI

ADS-user-abort request ADS-C AB

5.1.5.3.4.2 Upon receipt of a request to invoke a service primitive from one of the ground modules in the

1307613077130781307913080130811308213083130841308513086130871308813089130901309113092130931309413095130961309713098130991310013101131021310313104131051310613107131081310913110

131111311213113


ADS-ground-ASE as shown in Table 9-11, the ADS-C ground HI module shall do so.Table 9-11: Indication and confirmation primitive to ground module mapping

ADS-ground-ASE Module

Service Primitive

ADS-C DC ADS-demand-contract confirmation

ADS-C EC ADS-event-contract confirmation

ADS-C PC ADS-periodic-contract confirmation

ADS-C DC ADS-report indication with contract type “demand-contract”

ADS-C EC ADS-report indication with contract type “event-contract”

ADS-C PC ADS-report indication with contract type “periodic-contract”

ADS-C EC ADS-cancel confirmation with contract type “event-contract”

ADS-C PC ADS-cancel confirmation with contract type “periodic-contract”

ADS-C LI ADS-cancel-all-contracts confirmation

5.1.5.3.4.3 On receipt of a request to invoke ADS-provider-abort indication from the ADS-C ground AB module, the ADS-C ground HI module shall:

a) if the ADS-ground-user is not an active user, take no further action;

b) if the ADS-ground-user is an active user, invoke ADS-provider-abort indication.

5.1.5.3.4.4 On receipt of a request to invoke ADS-user-abort indication from the ADS-C ground AB module, the ADS-C ground HI module shall:

a) if the ADS-ground-user is not an active user, take no further action;

b) if the ADS-ground-user is an active user, invoke ADS-user-abort indication.

5.1.5.3.4.5 The ADS-C ground HI module shall reject requests and responses, apart from ADS-user-abort requests, when the ground LI module is in the LI-G-START state or the LI-G-END state.

5.1.5.3.5 Air ADS-C HI Module

5.1.5.3.5.1 Upon receipt of a service primitive, the air HI module shall pass it to the air module as shown in Table 5-12

131141311513116

13117131181311913120131211312213123131241312513126131271312813129131301313113132131331313413135131361313713138


Table 5 -12: Request and response primitive to air module mapping

Service Primitive ADS-air-ASE Module

ADS-demand-contract response ADS-C DC

ADS-event-contract response ADS-C EC

ADS-periodic-contract response ADS-C PC

ADS-report request with contract type “event-contract” ADS-C EC

ADS-report request with contract type “periodic-contract”

ADS-C PC

ADS-user-abort request ADS-C AB

5.1.5.3.5.2 Upon receipt of a request to invoke a service primitive from one of the air modules in the ADS-air-ASE as shown in Table 5-13, the air HI module shall do so.

Table 5-13: Indication and confirmation primitive to air module mapping

ADS-air-ASE Module Service Primitive

ADS-C DC ADS-demand-contract indication

ADS-C EC ADS-event-contract indication

ADS-C PC ADS-periodic-contract indication

ADS-C EC ADS-cancel indication with contract type “event-contract”

ADS-C PC ADS-cancel indication with contract type “periodic-contract”

ADS-C LI ADS-cancel-all-contracts indication

5.1.5.3.5.3 On receipt of a request to invoke ADS-provider-abort indication from the ADS-C air AB module, the air HI module shall:

a) if the ADS-air-user is not an active user, take no further action;

b) if the ADS-air-user is an active user, invoke ADS-provider-abort indication.

5.1.5.3.5.4 On receipt of a request to invoke ADS-user-abort indication from the ADS-C air AB module, the air HI module shall:

a) if the ADS-air-user is not an active user, take no further action;

b) if the ADS-air-user is an active user, invoke ADS-user-abort indication.

5.1.5.3.6 Ground ADS-C DC Module

5.1.5.3.6.1 The states defined for the ground ADS-C DC module are the following:

a) DC-G-IDLE

1313913140

13141131421314313144131451314613147

1314813149131501315113152131531315413155131561315713158131591316013161131621316313164131651316613167


b) DC-G-PENDING

c) DC-G-ACTIVE

5.1.5.3.6.2 On initiation, the ADS-C ground DC module shall be in the DC-G-IDLE state.

5.1.5.3.6.3 Upon receipt of an ADS-demand-contract request:

5.1.5.3.6.3.1 If in the DC-G-IDLE state, the ADS-C ground DC module shall:

a) eate an ADS-contract-PDU with “demand contract” in the contract-type PDU elements and the ADS/IC contract data parameter in the ic-contract-request PDU element,

b) pass it, together with the Aircraft Address parameter value, ICAO Facility Designation parameter value, the Class Of Communication Service parameter value, the ADS-C Message Set Version Number parameter value and the Security Required parameter to the ground LI module,

c) start timer t-DC-1, and

d) enter the DC-G-PENDING state.

5.1.5.3.6.4 Upon receipt of an ADS-accepted-PDU containing the ContractType element set to the abstract value “demand-contract”:

5.1.5.3.6.4.1 If in the DC-G-PENDING state, the ADS-C ground DC module shall:

a) stop the t-DC-1 timer,

b) request the ADS-C ground HI module to invoke ADS-demand-contract confirmation with “accepted” in the Result parameter and the ic-report element of the ADS-accepted-report-PDU in the ADS/IC Report Data parameter,

c) enter the DC-G-IDLE state.

5.1.5.3.6.5 Upon receipt of an ADS-report-PDU containing the ContractType element set to the abstract value “demand-contract”:

5.1.5.3.6.5.1 If in the DC-G-ACTIVE state, the ADS-C ground DC module shall:


b) request the ADS-C ground HI module to invoke ADS-report indication with “demand contract” in the Contract Type parameter and the ic-report element of the ADS-report-PDU in the ADS/IC Report Data parameter, and


5.1.5.3.6.6 Upon receipt of an ADS-positive-acknowledgement-PDU containing the ContractType element set to the abstract value “demand-contract”:


13168131691317013171131721317313174131751317613177131781317913180131811318213183131841318513186131871318813189131901319113192131931319413195131961319713198131991320013201132021320313204132051320613207132081320913210132111321213213132141321513216132171321813219



b) request the ADS-C ground HI module to invoke ADS-demand-contract confirmation, with “positive-acknowledgement” in the Result parameter and the ic-positive-ack element of the ADS-positive-acknowledgement-PDU in the ADS/IC Positive Acknowledgement parameter,

c) start the t-DC-2 timer,

d) enter the DC-G-ACTIVE state.

5.1.5.3.6.7 Upon receipt of an ADS-rejected-PDU containing the ContractType element set to the abstract value “demand-contract”:



b) request the ADS-C ground HI module to invoke ADS-demand-contract confirmation with “rejected” in the Result parameter and the ic-reject element of the ADS-rejected-PDU in the ADS/IC Reject Data parameter, and


5.1.5.3.6.8 Upon receipt of an ADS-ncn-PDU containing the ContractType element set to the abstract value “demand-contract”:



b) request the ADS-C ground HI module to invoke an ADS-demand-contract confirmation with “non compliance notification” in the Result parameter and the ic-ncn element of the ADS-ncn-PDU in the ADS/IC Non Compliance Data parameter,

c) start the t-DC-2 timer, and

d) enter the DC-G-ACTIVE state.

5.1.5.3.6.9 Upon expiry of the t-DC-1 timer or the t-DC-2 timer, the ADS-C ground DC module shall:

a) request the ADS-C ground AB module to abort with reason timer-expiry, and

b) enter the DC-G-IDLE state

5.1.5.3.6.10 Upon receipt of a request from the ground AB or ground LI module to stop operation, the ADS-C ground DC module shall:

a) stop any timers, and

b) enter the DC-G-IDLE state.

132201322113222132231322413225132261322713228132291323013231132321323313234132351323613237132381323913240132411324213243132441324513246132471324813249132501325113252132531325413255132561325713258132591326013261132621326313264132651326613267132681326913270


5.1.5.3.7 Air ADS-C DC Module

5.1.5.3.7.1 The states defined for the air ADS-C DC module are the following:

a) DC-A-IDLE

b) DC-A-PENDING

c) DC-A-ACTIVE

5.1.5.3.7.2 On initiation, the ADS-C air DC module shall be in the DC-A-IDLE state.

5.1.5.3.7.3 Upon receipt of an ADS-demand-contract response with the Result parameter value set to “rejected”:

5.1.5.3.7.3.1 If in the DC-A-PENDING state, the ADS-C air DC module shall:

a) create an ADS-rejected-PDU with “demand-contract” in the contract-type element and the ADS/IC Reject Data parameter value in the ic-reject element,

b) pass it to the air LI module, and

c) enter the DC-A-IDLE state.

5.1.5.3.7.4 Upon receipt of an ADS-demand-contract response with the Result parameter value set to “positive-acknowledgement”:


a) create an ADS-positive-acknowledgement-PDU with “demand-contract” in the contrat-type element and the ic-positive-ack element of the ADS-positive-acknowledgement-PDU in the ADS/IC Positive Acknowledgement parameter,


c) enter the DC-A-ACTIVE state.

5.1.5.3.7.5 Upon receipt of an ADS-demand-contract response with the Result parameter value set to “non compliance notification”:


a) create an ADS-ncn-PDU with “demand-contract” in the contract-type element and the ADS/IC Non Compliance Data parameter value in the ic-ncn element,


c) enter the DC-A-ACTIVE state.

5.1.5.3.7.6 Upon receipt of an ADS-demand-contract response with the Result parameter value set to set to “accepted”:

132711327213273132741327513276132771327813279132801328113282132831328413285132861328713288132891329013291132921329313294132951329613297132981329913300133011330213303133041330513306133071330813309133101331113312133131331413315133161331713318133191332013321



a) create an ADS-accepted-PDU with “demand-contract” in the contract-type element and the ADS/IC Report Data parameter value in the ic-report element,



5.1.5.3.7.7 Upon receipt of an ADS-report request containing the ContractType element set to the abstract value “demand-contract”:

5.1.5.3.7.7.1 If in the DC-A-ACTIVE state, the ADS-C air DC module shall:

a) create ADS-report-PDU with “demand-contract” in the contract-type element and the ADS/IC Report Data parameter value in the ic-report element,



5.1.5.3.7.8 Upon receipt of an ADS-contract-PDU containing the ContractType element set to the abstract value “demand-contract”:

5.1.5.3.7.8.1 If in the DC-A-IDLE state, the ADS-C air DC module shall:

a) request the air HI module to invoke ADS-demand-contract indication with:

1) the ic-contract-request PDU element in the ADS/IC Contract Data parameter,

[2)] the Calling peer id PDU element, if provided by the air LI module, in the ICAO Facility Designation parameter, and,

2)[3)] the DS-User Version Number, if provided by the air LI module, in the ADS-C Message Set Version Number parameter, and

b) enter the DC-A-PENDING state.

5.1.5.3.7.9 Upon receipt of a request from the air AB or air LI module to stop operation, the ADS-C air DC module shall enter the DC-A-IDLE state.

5.1.5.3.8 Ground ADS-C EC Module

5.1.5.3.8.1 The states defined for the ground ADS-C EC module are the following:

a) EC-G-IDLE

b) EC-G-START-PENDING

c) EC-G-ACTIVE

13322133231332413325133261332713328133291333013331133321333313334133351333613337133381333913340133411334213343133441334513346133471334813349133501335113352133531335413355133561335713358133591336013361133621336313364133651336613367133681336913370133711337213373


d) EC-G-PENDING

e) EC-G-CANCEL

5.1.5.3.8.2 On initiation, the ADS-C ground EC module shall be in the EC-G-IDLE state.

5.1.5.3.8.3 Upon receipt of an ADS-event-contract request:

5.1.5.3.8.3.1 If in the EC-G-IDLE state, the ADS-C ground EC module shall:

a) create an ADS-contract-PDU with elements as defined in Table 2.1.5-18,

b) pass it, together with the Aircraft Address parameter value, ICAO Facility Designation parameter value, the Class Of Communication Service parameter value, , the ADS-C Message Set Version Number parameter value and the Security Required parameter value, to the ground LI module,

c) start timer t-EC-1, and

d) enter the EC-G-START-PENDING state.

5.1.5.3.8.3.2 If in the EC-G-ACTIVE state, the ADS-C ground EC module shall:

a) create an ADS-contract-PDU with “event-contract” in the contract-type element and the ADS/IC Contract Data parameter in the ic-contract-request element,

b) pass it to the ground LI module,


d) enter the EC-G-PENDING state.

5.1.5.3.8.4 Upon receipt of an ADS-cancel request:

5.1.5.3.8.4.1 If in the EC-G-ACTIVE state, the ADS-C ground EC module shall:

a) create an ADS-cancel-contract-PDU with “event-contract” in the ADS-cancel-contract-PDU element,

b) pass it to the ground LI module,


d) enter the EC-G-CANCEL state.

5.1.5.3.8.5 Upon receipt of an ADS-accepted-PDU containing the ContractType element set to the abstract value “event-contract”:

5.1.5.3.8.5.1 If in the EC-G-PENDING or the EC-G-START-PENDING state, the ADS-C ground EC module shall:

a) stop the t-EC-1 timer,

b) request the ADS-C ground HI module to invoke ADS-demand-contract indication, with “accepted” in

13374133751337613377133781337913380133811338213383133841338513386133871338813389133901339113392133931339413395133961339713398133991340013401134021340313404134051340613407134081340913410134111341213413134141341513416134171341813419134201342113422134231342413425


the Result parameter and the ic-report element of the ADS-accepted-PDU in the ADS/IC Report Data parameter, and

c) enter the EC-G-ACTIVE state.

5.1.5.3.8.6 Upon receipt of an ADS-report-PDU containing the ContractType element set to the abstract value “event-contract”:

5.1.5.3.8.6.1 If in the EC-G-ACTIVE, EC-G-PENDING or EC-G-CANCEL state, the ADS-C ground EC module shall

a) request the ADS-C ground HI module to invoke ADS-report indication, with “event contract” in the Contract Type parameter and the ic-report PDU element of the ADS-report-PDU in the ADS/IC Report Data parameter, and

b) remain in the same state.

5.1.5.3.8.7 Upon receipt of an ADS-positive-acknowledgement-PDU containing a ContractType element set to the abstract value “event-contract”:

5.1.5.3.8.7.1 If in the EC-G-START-PENDING state or the EC-G-PENDING state, the ADS-C ground EC module shall:


b) request the ADS-C ground HI module to invoke ADS-event-contract confirmation, with “positive- acknowledgement” in the Result parameter and the ic-positive-ack element of the ADS-positive-acknowledgement-PDU in the ADS/IC Positive Acknowledgement parameter, and


5.1.5.3.8.8 Upon receipt of an ADS-cancel-positive-acknowledgement-PDU containing a RequestType element set to the abstract value “cancel-event-contract”:

5.1.5.3.8.8.1 If in the EC-G-CANCEL state, the ADS-C ground EC module shall:


b) request the ADS-C ground HI module to invoke ADS-cancel-contract confirmation, with “event-contract” in the Contract Type parameter, and

c) enter the EC-G-IDLE state.

5.1.5.3.8.9 Upon receipt of an ADS-rejected-PDU containing the ContractType element set to the abstract value “event-contract”:

5.1.5.3.8.9.1 If in the EC-G-START-PENDING state, the ADS-C ground EC module shall:


b) request the ADS-C ground HI module to invoke ADS-event-contract confirmation, with “rejected” in the Result parameter and ic-reject element of the ADS-rejected-PDU in the ADS/IC Reject Data parameter, and

13426134271342813429134301343113432134331343413435134361343713438134391344013441134421344313444134451344613447134481344913450134511345213453134541345513456134571345813459134601346113462134631346413465134661346713468134691347013471134721347313474134751347613477


c) enter the EC-G-IDLE state.

5.1.5.3.8.9.2 If in the EC-G-PENDING state, the ADS-C ground EC module shall:


b) request the ADS-C ground HI module to invoke ADS-event-contract confirmation, with “rejected” in the Result parameter and ic-reject element of the ADS-rejected-PDU in the ADS/IC Reject Data parameter, and


5.1.5.3.8.10 Upon receipt of an ADS-ncn-PDU:

5.1.5.3.8.10.1 If in the EC-G-START-PENDING state or the EC-G-PENDING, the ADS-C ground EC module shall:


b) request the ADS-C ground HI module to invoke ADS-event-contract confirmation, with “non compliance notification” in the Result parameter and the ic-ncn element of the ADS-ncn-PDU in the ADS/IC Non Compliance Data parameter, and


5.1.5.3.8.11 Upon expiry of the t-EC-1 timer or the t-EC-2 timer, the ADS-C ground EC module shall:


b) enter the EC-G-IDLE state

5.1.5.3.8.12 Upon receipt of a request from the ADS-C ground AB module or LI module to stop operation, the EC module shall:

a) stop any timers, and

b) enter the EC-G-IDLE state.

5.1.5.3.9 Air ADS-C EC Module

5.1.5.3.9.1 The states defined for the air ADS-C EC module are the following:

a) EC-A-IDLE

b) EC-A-PENDING

c) EC-A-ACTIVE

d) EC-A-ACTIVE-PENDING

5.1.5.3.9.2 On initiation, the ADS-C air EC module shall be in the EC-A-IDLE state.

13478134791348013481134821348313484134851348613487134881348913490134911349213493134941349513496134971349813499135001350113502135031350413505135061350713508135091351013511135121351313514135151351613517135181351913520135211352213523135241352513526135271352813529


5.1.5.3.9.3 Upon receipt of an ADS-event-contract response with the Result parameter value set to the abstract value “positive acknowledgement”:

5.1.5.3.9.3.1 If in the EC-A-PENDING state or in the EC-A-ACTIVE-PENDING state, the ADS-C air EC module shall:

a) create an ADS-positive-acknowledgement-PDU with “event-contract“ in the contract-type PDU element and the ic-positive-ack element of the ADS-positive-acknowledgement-PDU in the ADS/IC Positive Acknowledgement parameter,


c) enter the EC-A-ACTIVE state.

5.1.5.3.9.4 Upon receipt of an ADS-event-contract response with the Result parameter value set to the abstract value “non compliance notification”:


a) create an ADS-ncn-PDU with “event-contract” in the contract-type PDU element and the ADS/IC Non Compliance Data parameter value in the ic-ncn PDU element,



5.1.5.3.9.5 Upon receipt of an ADS-event-contract response with the Result parameter value set to the abstract value “rejected”:

5.1.5.3.9.5.1 If in the EC-A-PENDING state, the ADS-C air EC module shall:

a) create an ADS-rejected-PDU with “event-contract“ in the Contract-Type PDU element and the ADS/IC Reject Data parameter value in the ic-reject PDU element,


c) enter the EC-A-IDLE state.

5.1.5.3.9.5.2 If in the EC-A-ACTIVE-PENDING state, the ADS-C air EC module shall:

a) create an ADS-rejected-PDU with “event-contract“ in the Contract-Type PDU element and the ADS/IC Reject Data parameter value in the ic-reject PDU element,



5.1.5.3.9.6 Upon receipt of an ADS-event-contract response with the Result parameter value set to the abstract value “accepted”:


135301353113532135331353413535135361353713538135391354013541135421354313544135451354613547135481354913550135511355213553135541355513556135571355813559135601356113562135631356413565135661356713568135691357013571135721357313574135751357613577135781357913580


a) create an ADS-accepted-PDU with “event-contract“ in the request-type PDU element and the ADS/IC Report Data parameter value in the ic-report PDU element,



5.1.5.3.9.7 Upon receipt of an ADS-report request containing the ContractType element set to the abstract value “event-contract”:

5.1.5.3.9.7.1 If in the EC-A-ACTIVE state, the ADS-C air EC module shall:

a) create an ADS-report-PDU with “event-contract” in the contract-type PDU element and the ADS/IC Report Data parameter value in the ic-report PDU element,


c) remain in the EC-A-ACTIVE state.

5.1.5.3.9.8 Upon receipt of an ADS-contract-PDU containing the ContractType element set to the abstract value “event-contract”: 5.1.5.3.9.8.1 If in the EC-A-IDLE state, the ADS-C air EC module shall:

a) request the air HI module to invoke ADS-event-contract indication with:


[2)] the Calling peer id, if provided by the air LI module, in the ICAO Facility Designation parameter, and


b) enter the EC-A-PENDING state.


a) request the air HI module to invoke ADS-event-contract indication with the ic-contract-request PDU element in the ADS/IC Contract Data parameter and the Calling peer id, if provided by the air LI module, in the ICAO Facility Designation parameter, and

b) enter the EC-A-ACTIVE-PENDING state.

5.1.5.3.9.9 Upon receipt of an ADS-cancel-contract-PDU:


a) request the ADS-C HI module to invoke ADS-cancel indication with “event-contract” in the Contract Type parameter,

135811358213583135841358513586135871358813589135901359113592135931359413595135961359713598135991360013601136021360313604136051360613607136081360913610136111361213613136141361513616136171361813619136201362113622136231362413625136261362713628136291363013631


b) create an ADS-cancel-positive-acknowledgement-PDU with “cancel-event-contract” in the Request type PDU element,

c) pass it to the air LI module, and

d) enter the EC-A-IDLE state.

5.1.5.3.9.9.2 If in the EC-A-IDLE state, the ADS-C air EC module shall:

a) create an ADS-cancel-negative-acknowledgement-PDU with “cancel-event-contract” for the RequestType element and “no-such-contract” for the RejectReason element in the CancelRejectReason PDU element,


c) remain in the EC-A-IDLE state.

5.1.5.3.9.10 Upon receipt of a request from the air AB or air LI module to stop operation, the ADS-C air EC module shall enter the EC-A-IDLE state.

5.1.5.3.10 Ground ADS-C PC Module

5.1.5.3.10.1 The states defined for the ground ADS-C PC module are the following:

a) PC-G-IDLE

b) PC-G-START-PENDING

c) PC-G-ACTIVE

d) PC-G-PENDING

e) PC-G-CANCEL

5.1.5.3.10.2 On initiation, the ADS-C ground PC module shall be in the PC-G-IDLE state.

5.1.5.3.10.3 Upon receipt of an ADS-periodic-contract request:

5.1.5.3.10.3.1 If in the PC-G-IDLE state, the ADS-C ground PC module shall:

a) create an ADS- contract-PDU with “periodic-contract” in the contract-type PDU element and the ADS/IC contract data parameter value in the ic-contract-request PDU element,

b) pass it, together with the Aircraft Address parameter value, ICAO Facility Designation parameter value, the Class of Communication Service parameter value, the ADS-C Message Set Version Number parameter value and the Security Required parameter value, to the ground LI module,

c) start timer t-PC-1, and

d) enter the PC-G-START-PENDING state.

13632136331363413635136361363713638136391364013641136421364313644136451364613647136481364913650136511365213653136541365513656136571365813659136601366113662136631366413665136661366713668136691367013671136721367313674136751367613677136781367913680136811368213683


5.1.5.3.10.3.2 If in the PC-G-ACTIVE state, the ADS-C ground PC module shall:

a) stop the t-PC-2 timer,

b) create an ADS- contract-PDU with “periodic-contract” in the contract-type PDU element and the ADS/IC contract data parameter value in the ic-contract-request PDU element,

c) pass it to the ground LI module,

d) start timer t-PC-1, and

e) enter the PC-G-PENDING state.

5.1.5.3.10.4 Upon receipt of an ADS-cancel request containing the ContractType element set to the abstract value “periodic-contract”:



b) create an ADS-cancel-contract-PDU with “periodic-contract” in the ADS-cancel-contract-PDU element,

c) pass it to the ground LI module,

d) start timer t-PC-3, and

e) enter the PC-G-CANCEL state.

5.1.5.3.10.5 Upon receipt of an ADS-accepted-PDU containing the ContractType element set to the abstract value “periodic-contract”:

5.1.5.3.10.5.1 If in the PC-G-START-PENDING state, or the PC-G-PENDING state, the ADS-C ground PC module shall:


b) create the ADS/IC report data parameter of an ADS-periodic-indication,

c) request the ADS-C ground HI module to invoke ADS-periodic-contract indication with “accepted” in the Result parameter and the ic-report PDU element of the ADS-accepted-PDU in the ADS/IC Report Data parameter,

d) start the t-PC-2 timer,

e) enter the PC-G-ACTIVE state.

5.1.5.3.10.6 Upon receipt of an ADS-report-PDU:

5.1.5.3.10.6.1 If in the PC-G-PENDING state, the ADS-C ground PC module shall:

13684136851368613687136881368913690136911369213693136941369513696136971369813699137001370113702137031370413705137061370713708137091371013711137121371313714137151371613717137181371913720137211372213723137241372513726137271372813729137301373113732137331373413735


a) request the ADS-C ground HI module to invoke ADS-report indication with “periodic-contract“ in the Contract Type parameter and the ic-report PDU element of the ADS-report-PDU in the ADS/IC Report Data parameter,

b) remain in the PC-G-PENDING state.



b) request the ADS-C ground HI module to invoke ADS-report indication with “periodic-contract“ in the Contract Type parameter and the ic-report PDU element of the ADS-report-PDU in the ADS/IC Report Data parameter,

c) start the t-PC-2 timer,

d) remain in the PC-G-ACTIVE state.

5.1.5.3.10.6.3 If in the PC-G-CANCEL state, the ADS-C ground PC module shall:

a) request the ADS-C ground HI module to invoke ADS-report indication with “periodic-contract“ in the Contract Type parameter and the ic-report PDU element of the ADS-report-PDU in the ADS/IC Report Data parameter, and

b) remain in the PC-G-CANCEL state.

5.1.5.3.10.7 Upon receipt of an ADS-positive-acknowledgement-PDU containing a ContractType element set to the abstract value “periodic-contract”:



b) request the ADS-C ground HI module to invoke ADS-periodic-contract confirmation with “positive acknowledgement” in the Result parameter and the ic-positive-ack element of the ADS-positive-acknowledgement-PDU in the ADS/IC Positive Acknowledgement parameter,


d) enter the PC-G-ACTIVE state.

5.1.5.3.10.8 Upon receipt of an ADS-cancel-positive-acknowledgement-PDU containing a RequestType element set to the abstract value “cancel-periodic-contract”:

5.1.5.3.10.8.1 If in the PC-G-CANCEL state, the ADS-C ground PC module shall:


b) request the ADS-C ground HI module to invoke ADS-cancel-contract confirmation with “periodic-contract“ in the Contract Type parameter, and

13736137371373813739137401374113742137431374413745137461374713748137491375013751137521375313754137551375613757137581375913760137611376213763137641376513766137671376813769137701377113772137731377413775137761377713778137791378013781137821378313784137851378613787


c) enter the PC-G-IDLE state.

5.1.5.3.10.9 Upon receipt of an ADS-rejected-PDU containing the ContractType element set to the abstract value “periodic-contract”:

5.1.5.3.10.9.1 If in the PC-G-START-PENDING state, the ADS-C ground PC module shall:


b) request the ADS-C ground HI module to invoke ADS-periodic-contract confirmation with parameter values derived as in Table 2.1.5-40, and

c) enter the PC-G-IDLE state.

5.1.5.3.10.9.2 If in the PC-G-PENDING state, the ADS-C ground PC module shall:


b) request the ADS-C ground HI module to invoke ADS-periodic-contract confirmation with “rejected” in the Result parameter and the ic-reject element of the ADS-rejected-PDU in the ADS/IR Reject Data parameter,



5.1.5.3.10.10 Upon receipt of an ADS-ncn-PDU containing the ContractType element set to the abstract value “periodic-contract”:



b) request the ADS-C ground HI module to invoke ADS-periodic-contract confirmation with “non compliance notification” in the Result parameter and the ic-ncn element of the ADS-ncn-PDU in the ADS/IC Non Compliance Data parameter,

c) start the t-PC-2 timer, and


5.1.5.3.10.11 Upon receipt of a request from the ground AB or ground LI module to stop operation, the ADS-C ground PC module shall:

a) stop any timers,

b) enter the PC-G-IDLE state.

5.1.5.3.10.12 Upon expiry of the t-PC-1 timer, t-PC-2 timer, or t-PC-3 timer, the ADS-C ground PC module shall:

137881378913790137911379213793137941379513796137971379813799138001380113802138031380413805138061380713808138091381013811138121381313814138151381613817138181381913820138211382213823138241382513826138271382813829138301383113832138331383413835138361383713838



b) enter the PC-G-IDLE state.

5.1.5.3.11 Air ADS-C PC Module

5.1.5.3.11.1 The states defined for the air ADS-C PC module are the following:

a) PC-A-IDLE

b) PC-A-PENDING

c) PC-A-ACTIVE

d) PC-A-ACTIVE-PENDING

5.1.5.3.11.2 On initiation, the ADS-C air PC module shall be in the PC-A-IDLE state.

5.1.5.3.11.3 Upon receipt of an ADS-periodic-contract response with the Result parameter value set to the abstract value “positive acknowledgement”, then:

5.1.5.3.11.3.1 If in the PC-A-PENDING state or PC-A-ACTIVE-PENDING state, the ADS-C air PC module shall:

a) If the Result parameter value contains the abstract value “positive acknowledgement”, create an ADS-positive-acknowledgement-PDU with “periodic-contract“ in the contract-type PDU element and the ic-positive-ack element of the ADS-positive-acknowledgement-PDU in the ADS/IC Positive Acknowledgement parameter,


c) enter the PC-A-ACTIVE state.

5.1.5.3.11.4 Upon receipt of an ADS-periodic-contract response with the Result parameter value set to the abstract value “non compliance notification”, then:

5.1.5.3.11.4.1 If in the PC-A-PENDING state or PC-A-ACTIVE-PENDING state, the ADS-C air PC module shall:

a) If the Result parameter value contains the abstract value “non compliance notification”, create an ADS-ncn-PDU with “periodic-contract” in the contract-type PDU element and the ADS/IC Non Compliance Data parameter value in the ic-ncn PDU element,



5.1.5.3.11.5 Upon receipt of an ADS-periodic-contract response with the Result parameter value set to the abstract value “rejected”, then:

5.1.5.3.11.5.1 If in the PC-A-PENDING state, the ADS-C air PC module shall:

138391384013841138421384313844138451384613847138481384913850138511385213853138541385513856138571385813859138601386113862138631386413865138661386713868138691387013871138721387313874138751387613877138781387913880138811388213883138841388513886138871388813889


a) create an ADS-rejected-PDU with “periodic-contract “ in the contract-type PDU element and the ADS/IC Reject Data parameter value in the ic-ncn PDU element,


c) enter the PC-A-IDLE state.

5.1.5.3.11.5.2 If in the PC-A-ACTIVE-PENDING state, the ADS-C air PC module shall:

a) create an ADS-rejected-PDU with “periodic-contract “ in the contract-type PDU element and the ADS/IC Reject Data parameter value in the ic-ncn PDU element,



5.1.5.3.11.6 Upon receipt of an ADS-periodic-contract response with the Result parameter value set to the abstract value “accepted”, then:

5.1.5.3.11.6.1 If in the PC-A-PENDING state or PC-A-ACTIVE-PENDING, the ADS-C air PC module shall:

a) create ADS- -accepted-PDU with “periodic-contract “ in the contract-type PDU element and the ADS/IC Report Data parameter value in the ic-report PDU element,



5.1.5.3.11.7 Upon receipt of an ADS-report request containing the ContractType element set to the abstract value “periodic-contract”:

5.1.5.3.11.7.1 If in the PC-A-ACTIVE state, the ADS-C air PC module shall:

a) create ADS-report-PDU with “periodic-contract” in the contract-type PDU element and the ADS/IC Report Data parameter value in the ic-report PDU element,


c) remain in the PC-A-ACTIVE state.

5.1.5.3.11.8 Upon receipt of an ADS-contract-PDU containing the ContractType element set to the abstract value “periodic-contract”:

5.1.5.3.11.8.1 If in the PC-A-IDLE state, the ADS-C air PC module shall:

a) request the air HI module to invoke ADS-periodic-contract indication with:


[2)] the Calling peer id, if provided by the air LI module, in the ICAO Facility Designation parameter, and

13890138911389213893138941389513896138971389813899139001390113902139031390413905139061390713908139091391013911139121391313914139151391613917139181391913920139211392213923139241392513926139271392813929139301393113932139331393413935139361393713938139391394013941



b) enter the PC-A-PENDING state.


a) request the air HI module to invoke ADS-periodic-contract indication with the ic-contract-request PDU element in the ADS/IC Contract Data parameter and the Calling peer id, if provided by the air LI module, in the ICAO Facility Designation parameter, and

b) enter the PC-A-ACTIVE-PENDING state.

5.1.5.3.11.9 Upon receipt of an ADS-cancel-contract-PDU containing the ContractType element set to the abstract value “periodic-contract”, then:


a) request the air HI module to invoke ADS-cancel indication with “periodic-contract” in the Contract Type parameter,

b) create an ADS-cancel-positive-acknowledgement-PDU with “cancel-periodic-contract” in the RequestType PDU element,

c) pass it to the air LI module, and

d) enter the PC-A-IDLE state.

5.1.5.3.11.9.2 If in the PC-A-IDLE state, the ADS-C air PC module shall:

a) create an ADS-cancel-negative-acknowledgement-PDU with “cancel-periodic-contract” in the RequestType element and “no-such-contract” in the RejectReason element of the CancelRejectReason PDU element,


c) remain in the PC-A-IDLE state.

5.1.5.3.11.10 Upon receipt of a request from the air AB or air LI module to stop operation, the ADS-C air PC module shall enter the PC-A-IDLE state.

5.1.5.3.12 Ground and Air ADS-C AB Modules

5.1.5.3.12.1 All statements in 5.3.14 apply to both the ADS-C ground AB module and the ADS-C air AB module.

5.1.5.3.12.2 Upon receipt of an ADS-user-abort request, the ADS-C AB module shall:

a) request the DC, EC and PC modules to stop operation,

139421394313944139451394613947139481394913950139511395213953139541395513956139571395813959139601396113962139631396413965139661396713968139691397013971139721397313974139751397613977139781397913980139811398213983139841398513986139871398813989139901399113992


b) create an ADS-user-abort-PDU with the UserAbortReason PDU element derived from the reason parameter, and

c) request the LI module to invoke D-ABORT request with “user” in the originator parameter and the the ADS-user-abort-PDU in the User Data parameter.

5.1.5.3.12.3 Upon receipt of a request to abort, the ADS-C AB module shall:

a) request the DC, EC and PC modules to stop operation,

b) create an ADS-provider-abort-PDU with the value provided by DC, EC or PC module in the AbortReason PDU element,

c) request the LI module to invoke D-ABORT request with “provider” in the Originator parameter and the ADS-provider-abort-PDU in the User Data parameter, and

d) request the ADS-C HI module to invoke ADS-provider-abort indication with the value provided by DC, EC or PC module in the Reason parameter.

5.1.5.3.12.4 Upon receipt of a D-P-ABORT indication, the ADS-C AB module shall:

a) request the DC, EC and PC modules to stop operation, and

b) request the ADS-C HI module to invoke ADS-provider-abort indication with “communications-service-failure” in the Reason parameter.

5.1.5.3.12.5 Upon receipt of a D-ABORT indication with the Originator parameter value set to the abstract value “user” and with an ADS-user-data-PDU in the User Data parameter, the ADS-C AB module shall:


b) request the ADS-C HI module to invoke ADS-user-abort indication with the value of the User Data parameter in the Reason parameter.

5.1.5.3.12.6 Upon receipt of a D-ABORT indication with the Originator parameter value set to the abstract value “provider” and with data in the User Data parameter, the ADS-C AB module shall:


b) request the ADS-C HI module to invoke ADS-provider-abort indication with the value of the User Data parameter in the Reason parameter.

5.1.5.3.13 Ground ADS-C LI Module

5.1.5.3.13.1 The states defined for the ground ADS-C ATN LI module are the following:

a) LI-G-IDLE

b) LI-G-START

c) LI-G-ACTIVE

13993139941399513996139971399813999140001400114002140031400414005140061400714008140091401014011140121401314014140151401614017140181401914020140211402214023140241402514026140271402814029140301403114032140331403414035140361403714038140391404014041140421404314044


d) LI-G-END

5.1.5.3.13.2 On initiation, the ground LI module shall be in the LI-G-IDLE state.

5.1.5.3.13.3 Upon receipt of an ADS-contract-PDU from the ground DC, EC or PC modules:

5.1.5.3.13.3.1 If in the LI-G-IDLE state, the ground LI module shall:

a) Invoke D-START request using parameter values as shown in Table 5-14, and

b) enter the LI-G-START state.

Table 5-14: D-START request parameter values

D-START parameter Source

Called peer Id Aircraft address parameter value from contract request

Calling peer Id ICAO Facility Designation parameter value from contract request

DS-user version number Not usedADS-C Message Set Version Number parameter value from contract request

Security requirements Security Required parameter value from contract request

Quality of service Routing class: ATSC, with value from Class of Communication Service parameter value from contract request

Priority: High priority flight safety messages

RER: Low

User data The contract PDU passed to LI

5.1.5.3.13.3.2 If in the LI-G-ACTIVE state, the ground LI module shall:

a) Invoke D-DATA request with the PDU as the User Data parameter value, and

b) remain in the LI-G-ACTIVE state.

5.1.5.3.13.4 Upon receipt of an ADS-cancel-all-contracts request:


a) Invoke D-END req with ADS-cancel-all-contracts-PDU in the user data,

b) start the t-LI-1 timer, and

c) enter the LI-G-END state.

5.1.5.3.13.5 Upon receipt of an ADS-cancel-contract-PDU from the ground EC or PC modules:


a) invoke D-DATA req with the PDU in the user data,

140451404614047140481404914050140511405214053140541405514056

14057

14058140591406014061140621406314064140651406614067140681406914070140711407214073140741407514076140771407814079


b) if the DC module is in the DC-G-IDLE state, and the EC module is in the EC-G-IDLE state, and the PC module is in the PC-G-IDLE state, then:

1) invoke D-END req with no user data,

2) start the t-LI-1 timer, and

3) enter the LI-G-END state; or

c) otherwise, remain in the LI-G-ACTIVE state.

5.1.5.3.13.6 Upon receipt of request to invoke D-ABORT from the ADS-C ground AB module: 5.1.5.3.13.6.1 If in the LI-G-START state, the LI-G-ACTIVE state or the LI-G-END state, the ground LI module shall:

a) invoke D-ABORT request with the parameter values supplied, and

b) enter the LI-G-IDLE state.

5.1.5.3.13.6.2 If in the LI-G-IDLE state, the ground LI module shall ignore the request.

5.1.5.3.13.7 Upon receipt of a D-START confirmation with the Result parameter value containing the abstract value “accepted” and the Security Requirements parameter value containing an abstract value equal to the abstract value set in the D-START request Security Requirements parameter:

Note.— If a secure D-START request was issued (i.e. the Security Requirements parameter was set to “secured exchange”) then the D-START confirmation Security Requirements parameter must be equal to that value. If an unsecure D-START request was issued (i.e. the Security Requirements parameter was set to “no security”) then the D-START confirmation Security Requirements parameter will be equal to that value.

5.1.5.3.13.7.1 If in the LI-G-START state, the ground LI module shall:

a) pass the user data to the module as defined in Table 5-15,

b) if, after processing the PDU (i.e. the ADS-C ground HI module has issued the appropriate indication or confirmation), the ADS-C ground DC module is in the DC-G-IDLE state, and the ADS-C ground EC module is in the EC-G-IDLE state, and the ADS-C ground PC module is in the PC-G-IDLE state, then:

1) invoke D-END req with no user data, and

2) start the t-LI-1 timer, and


c) if, after processing the PDU, the ADS-C ground DC module is not in the DC-G-IDLE state, or the ADS-C ground EC module is not in the EC-G-IDLE state, or the ADS-C ground PC module is not in the PC-G-IDLE state, then:

140801408114082140831408414085140861408714088140891409014091140921409314094140951409614097140981409914100141011410214103141041410514106141071410814109141101411114112141131411414115141161411714118141191412014121141221412314124141251412614127141281412914130


1) enter the LI-G-ACTIVE state.

5.1.5.3.13.8 Upon receipt of a D-DATA indication:


a) pass the user data to the module as defined in Table 5-15,

b) if, after processing the PDU (i.e. the ADS-C ground HI module has issued the appropriate indication or confirmation), the ADS-C ground DC module is in the DC-G-IDLE state, and the ADS-C ground EC module is in the EC-G-IDLE state, and the ADS-C ground PC module is in the PC-G-IDLE state, then:

1) invoke D-END req with no user data, and

2) start the T-LI-1 timer, and


c) otherwise, remain in the LI-G-ACTIVE state.

5.1.5.3.13.8.2 If in the LI-G-END state, the ground LI module shall:

a) pass the user data to the module as defined in Table 5-15, and

b) remain in the LI-G-END state.

141311413214133141341413514136141371413814139141401414114142141431414414145141461414714148141491415014151141521415314154141551415614157


Table 5-15: PDU to ground module mapping

PDU Subfield Ground Module

ADS-report-PDU

contract-type

“demand-contract” DC

“event-contract” EC

“periodic-contract” PC

ADS-accepted-PDU,

ADS-rejected-PDU,

ADS-ncn-PDU

contract-type




ADS-cancel-positive-acknowledgement-PDU

RequestType

“cancel-event-contract” EC

“cancel-periodic-contract” PC

ADS-positive-acknowledgement-PDU

ContractType



ADS-cancel-negative-acknowledgement-PDU AB

5.1.5.3.13.9 Upon receipt of a D-END confirmation with the Result parameter value containing the abstract value “accepted”:

5.1.5.3.13.9.1 If in the LI-G-END state, the ground LI module shall:

a) stop the t-LI-1 timer,

b) if the User Data parameter value contains an ADS-cancel-positive-acknowledgement-PDU (cancel-all-contracts), then request the ADS-C ground HI module to invoke ADS-cancel-all-contracts confirmation,

c) request the DC, EC and PC modules to stop operation, and

14158

1415914160141611416214163141641416514166141671416814169141701417114172


d) enter the LI-G-IDLE state.

5.1.5.3.13.10 Upon receipt of a D-ABORT indication, the ground LI module shall:

a) pass the D-ABORT indication to the ADS-C ground AB module, and


5.1.5.3.13.11 Upon receipt of a D-P-ABORT indication, the ground LI module shall:

a) pass the D-P-ABORT indication to the ADS-C ground AB module, and


5.1.5.3.13.12 Upon expiry of the t-LI-1 timer, the ground LI module shall:

a) request the ADS-C air AB module to abort with reason timer-expiry, and

b) remain in the same state.

5.1.5.3.14 Air ADS-C LI Module

5.1.5.3.14.1 The states defined for the air ADS-C ATN LI module are the following:

a) LI-A-IDLE

b) LI-A-START

c) LI-A-ACTIVE

5.1.5.3.14.2 On initiation, the air LI module shall be in the LI-A-IDLE state.

5.1.5.3.14.3 Upon receipt of an ADS-positive-acknowledgement-PDU, an ADS-accepted-PDU, ADS-rejected-PDU, or an ADS-ncn-PDU from the air DC, EC or PC modules:

5.1.5.3.14.3.1 If in the LI-A-START state, the air LI module shall:

a) Invoke D-START response using parameter values as shown in Table 5-16, and

b) enter the LI-A-ACTIVE state.

Table 5-16: D-START response parameter values

1417314174141751417614177141781417914180141811418214183141841418514186141871418814189141901419114192141931419414195141961419714198141991420014201142021420314204142051420614207142081420914210142111421214213

14214


D-START parameter Source

DS-user version number Not used

Security requirements the Security Requirements parameter received in the D-START indication

Quality of service Not used

Result “Accepted”

User data The PDU passed to the air LI module

5.1.5.3.14.4 Upon receipt of an ADS-report-PDU, an ADS-positive-acknowledgement-PDU, an ADS-accepted-PDU, ADS-rejected-PDU, or an ADS-ncn-PDU from the air DC, EC or PC modules:

5.1.5.3.14.4.1 If in the LI-A-ACTIVE state, the air LI module shall:

a) Invoke D-DATA request using the PDU as the User Data parameter value, and

b) remain in the LI-A-ACTIVE state.

5.1.5.3.14.5 Upon receipt of a request to invoke D-ABORT from the ADS-C air AB module:

5.1.5.3.14.5.1 The air LI module shall:

a) If a dialogue exists, invoke D-ABORT request with the APDU as User Data parameter value and the value supplied by the ADS-C AB module as Originator parameter, and

b) enter the LI-A-IDLE state.

5.1.5.3.14.6 Upon receipt of a D-START indication:

5.1.5.3.14.6.1 If in the LI-A-IDLE state, and the application service priority parameter value is “high priority flight safety messages”, the RER quality of service parameter is the abstract value “low”, the Routing Class parameter identifies the traffic category “Air Traffic Service Communications (ATSC)”, the Calling Peer ID parameter is a valid four to eight character facility designation and the Security Requirements parameter is consistent with the local security policy, the air LI module shall:

[a)] pass the user data, and the calling peer id and the DS-User Version Number parameter values to the module as defined in Table 5-17, and

a)[b)] enter LI-A-START state.

5.1.5.3.14.7 Upon receipt of a D-DATA indication:

5.1.5.3.14.7.1 If in the LI-A-ACTIVE state, the air LI module shall:

a) pass the user data to the module as defined in Table 5-17, and

b) remain in the LI-A-ACTIVE state.

14215142161421714218142191422014221142221422314224142251422614227142281422914230142311423214233142341423514236142371423814239142401424114242142431424414245142461424714248142491425014251142521425314254


Table 5-17: PDU to air module mapping

PDU type Sub-element Air Module

ADS-contract-PDU

contract-type




ADS-cancel-all-contracts-PDU HI

ADS-cancel-contract-PDU

CancelContract



5.1.5.3.14.8 Upon receipt of a D-END indication:

5.1.5.3.14.8.1 If in the LI-A-ACTIVE state:

5.1.5.3.14.8.2 If the User Data parameter value contains an ADS-cancel-all-contracts-PDU, the air LI module shall:

a) pass it to the air HI module,

b) invoke D-END response with the Result parameter value set to “accepted” and aDS-cancel-positive-acknowledgement-PDU (“cancel-all-contracts”) in the user data,

c) request the DC, EC and PC modules to stop operation, and

d) enter LI-A-IDLE state.

5.1.5.3.14.8.3 If there is no user data, the air LI module shall:

a) invoke D-END response with the Result parameter value set to “accepted” and no user data, and

b) enter LI-A-IDLE state.

5.1.5.3.14.9 Upon receipt of a D-ABORT indication, the air LI module shall:

a) pass the D-ABORT indication to the ADS-C air AB module, and


5.1.5.3.14.10 Upon receipt of a D-P-ABORT indication, the air LI module shall:

a) pass the D-P-ABORT indication to the ADS-C air AB module, and


14255

14256142571425814259142601426114262142631426414265142661426714268142691427014271142721427314274142751427614277142781427914280142811428214283142841428514286142871428814289


5.1.5.4 Exception Handling

5.1.5.4.1 Timer Expires

When any of the timers in any of the modules stated in 5.1.5.2 reaches its maximum time, the module shall request the air or ground AB module to abort with reason timer-expiry.

5.1.5.4.2 Unrecoverable System Error

When any module has an unrecoverable system error, the module should request the air or ground AB module to abort with reason unrecoverable-system-error.

5.1.5.4.3 Invalid PDU

5.1.5.4.3.1 When the user data parameter value of a D-START indication is a valid APDU and is not an ADS-contract-PDU, the air LI module shall request the ADS-C AB module to abort with reason invalid-PDU.

5.1.5.4.3.2 When the user data parameter value of a D-START confirmation is a valid APDU and is not an ADS-accepted-PDU, an ADS-positive-acknowledgement-PDU, an ADS-rejected-PDU or an ADS-ncn-PDU the ground LI module shall request the ADS-C AB module to abort with reason invalid-PDU.

5.1.5.4.3.3 When the user data parameter value of a D-DATA indication is a valid APDU and is not an ADS-contract-PDU or an ADS-cancel-contract-PDU, the air LI module shall request the ADS-C AB module to abort with reason invalid-PDU.

5.1.5.4.3.4 When the user data parameter value of a D-DATA indication is a valid APDU and is not an ADS-report-PDU, an ADS-accepted-PDU, an ADS-positive-acknowledgement-PDU, and ADS-rejected-PDU, or an ADS-ncn-PDU, the ground LI module shall request the ADS-C AB module to abort with reason invalid-PDU.

5.1.5.4.3.5 When the user data parameter value of a D-END indication is present, but does not contain an ADS-cancel-all-contracts-PDU, the air LI module shall request the ADS-C AB module to abort with reason invalid-PDU.

5.1.5.4.3.6 When the user data parameter value of a D-ABORT indication is a valid APDU and is not an ADS-provider-abort-PDU or an ADS-user-abort-PDU, the air LI module or the ground LI module shall request the ADS-C AB module to abort with reason invalid-PDU.

5.1.5.4.3.7 When the user data parameter value of a D-END confirmation is present, but does not contain an ADS-positive-acknowledgement-PDU (cancel-all-contracts), the ground LI module shall request the ADS-C AB module to abort with reason invalid-PDU.

5.1.5.4.4 Sequence Error

5.1.5.4.4.1 When a PDU is passed to a module for which there are no instructions in 5.1.5.3 (i.e. the PDU has arrived out of sequence), the air or ground AB module shall be requested to abort with reason sequence-error.

5.1.5.4.4.1 Upon receipt of a Dialogue service primitive for which there are no instruction in 5.1.5.3 (i.e. the primitive was not expected or was expected under other conditions or with other parameter values), the air or ground AB module shall be requested to abort with reason sequence-error.

14290142911429214293142941429514296142971429814299143001430114302143031430414305143061430714308143091431014311143121431314314143151431614317143181431914320143211432214323143241432514326143271432814329143301433114332143331433414335143361433714338143391434014341


5.1.5.4.5 D-START Rejection

5.1.5.4.5.1 Upon receipt of a D-START confirmation with a negative Result parameter value (i.e. containing the abstract value “rejected (transient)” or “rejected (permanent)”), and the reject source parameter value containing the abstract value “DS user”, the ground LI module shall:

a) request the ADS-C ground AB module to abort with reason sequence-error; and


5.1.5.4.5.2 Upon receipt of a D-START confirmation with a negative Result parameter value (i.e. containing the abstract value “rejected (transient)” or “rejected (permanent)”), and the reject source parameter value containing the abstract value “DS provider”, the ground LI module shall:

a) request the ADS-C ground AB module to abort with reason “cannot-establish-contact”; and


5.1.5.4.6 D-END Rejection

Upon receipt of a D-END confirmation with the Result parameter value containing the abstract value rejected, the ADS-C ground AB module shall be requested to abort with reason “dialogue-end-not-accepted”.

5.1.5.4.7 Decoding Error

5.1.5.4.7.1 When the air LI module or the ground LI module fails to decode an APDU, the LI module shall request the ADS-C AB module to abort with reason “decoding-error”.

5.1.5.4.7.2 Upon receipt of a D-START indication, a D-START confirmation or a D-DATA indication with no user data, the air or ground AB module shall be requested to abort with reason “decoding-error”.

5.1.5.4.8 Invalid QOS

Upon receipt of a D-START indication with the application service priority parameter set to a value other than the abstract value “high priority flight safety messages”, or the RER quality of service parameter set to a value other than the abstract value “low” or the Routing Class quality of service parameter set to a value other than one identifying the traffic category “Air Traffic Service Communications (ATSC)”, the air LI module shall request the ADS-C air AB module to abort with reason “invalid-qos-parameter”.

5.1.5.4.9 Invalid Security Parameter

5.1.5.4.9.1 Upon receipt of a D-START indication with the Security Requirements parameter not consistent with the local security policy, the air LI module shall:

a) request the ADS-C air AB module to abort with reason “communications-service-failure”; and


143421434314344143451434614347143481434914350143511435214353143541435514356143571435814359143601436114362143631436414365143661436714368143691437014371143721437314374143751437614377143781437914380143811438214383143841438514386143871438814389143901439114392


5.1.5.4.9.2 Upon receipt of a positive D-START confirmation with the Security Requirements parameter value containing an abstract value no equal to the abstract value set in the D-START request Security Requirements parameter, the ground LI module shall:

a) request the ADS-C ground AB module to abort with reason “communications-service-failure”; and


5.1.5.5 ADS-C ASE State Tables

5.1.5.5.1 Priority

5.1.5.5.1.1 If the state tables for the ADS-air-ASE and the ADS-ground-ASE shown below conflict with textual statements made elsewhere in this document, the textual statements shall take precedence.

5.1.5.5.1.2 In the following state tables, the statement “cannot occur” means that if the implementation conforms to this Specification, it is impossible for this event to occur. If the event does occur, this implies that there is an error in the implementation. If such a situation is detected, it is suggested that the ASE aborts with the error “unrecoverable error”.

5.1.5.5.1.3 In the following state tables, the statement “not permitted” means that the implementation must prevent this event from occurring through some local means. If the event does occur this implies that there is an error in the implementation. If such a situation is detected, it is suggested that the ASE performs a local rejection of the request rather than aborting the dialogue.

1439314394143951439614397143981439914400144011440214403144041440514406144071440814409144101441114412144131441414415144161441714418144191442014421


Table 5-18: ADS-C ground DC module state table

State DC-G-IDLE(Initial State)

DC-G-PENDING DC-G-ACTIVE

Event

Primitive Requests and Responses

ADS-demand-contract req Send ADS-contract-PDU (demand-contract)Start t-DC-1DC-G-PENDING

Not permitted Not permitted

ADS-C downlink PDUs

ADS-accepted-PDU (demand-contract) request AB to abort Stop t-DC-1ADS-demand-contract cnf (accepted)DC-G-IDLE

request AB to abort

ADS-report-PDU (demand-contract) request AB to abort request AB to abort stop t-DC-2ADS-report ind (demand-contract)DC-G-IDLE

ADS-rejected-PDU (demand-contract) request AB to abort stop t-DC-1ADS-demand-contract cnf (rejected)DC-G-IDLE

request AB to abort

ADS-positive-acknowledgement-PDU (demand-contract) request AB to abort stop t-DC-1 ADS-demand-contract cnf (pos ack)start t-DC-2 DC-G-ACTIVE

request AB to abort

ADS-ncn-PDU (demand-contract) request AB to abort stop t-DC-1ADS-demand-contract cnf (ncn)start t-DC-2DC-G-ACTIVE

request AB to abort

Requests from other modules


Request to stop operation DC-G-IDLE stop t-DC-1DC-G-IDLE

stop t-DC-2DC-G-IDLE

Timer expiry

t-DC-1 cannot occur request AB to abort cannot occurt-DC-2 cannot occur cannot occur request AB to abort

Table Erreur ! Il n'y a pas de texte répondant à ce style dans ce document.5-19: ADS-C air DC module state table

State DC-A-IDLE(Initial State)

DC-A-PENDING DC-A-ACTIVE

Event


ADS-demand-contract rsp (rejected) Not permitted Send ADS-rejected-PDU (demand-contract)DC-A-IDLE

Not permitted

ADS-demand-contract rsp (non compliance notification) Not permitted Send ADS-ncn-PDU (demand-contract)DC-A-ACTIVE

Not permitted

ADS-demand-contract rsp (accepted) Not permitted Send ADS-accepted-PDU (demand-contract) DC-A-IDLE

Not permitted

ADS-demand-contract rsp (positive acknowledgement) Not permitted Send ADS-positive-acknowledement-PDU (demand contract)DC-A-ACTIVE

Not permitted

ADS-report req (demand-contract) Not permitted Not permitted Send ADS-report-PDU (demand-contract)DC-A-IDLE


Requests to stop operation DC-A-IDLE DC-A-IDLE DC-A-IDLE

ADS-C uplink PDUs

ADS-contract-PDU (demand-contract) ADS-demand-contract indDC-A-PENDING

request AB to abort request AB to abort

14422

14423

14424


14425


Table Erreur ! Il n'y a pas de texte répondant à ce style dans ce document.5-20: ADS-C ground EC module state table

State EC-G-IDLE(Initial State)

EC-G-START-PENDING

EC-G-ACTIVE EC-G-PENDING EC-G-CANCEL

Event


ADS-event-contract req

Send ADS-contract-PDU (event)Start t-EC-1EC-G-START-PENDING

Not permitted Send ADS-contract–PDUStart t-EC-1EC-G-PENDING


ADS-cancel req(event)

Not permitted Not permitted Send ADS-cancel-PDUStart t-EC-2EC-G-CANCEL


ADS-C Aircraft PDUs

ADS-positive-acknowledgementPDU(event)

request AB to abort Stop t-EC-1ADS-event-contract cnfEC-G-ACTIVE

request AB to abort Stop t-EC-1ADS-event-contract cnfEC-G-ACTIVE

request AB to abort

ADS-report-PDU (event)

request AB to abort request AB to abort ADS-report indEC-G-ACTIVE

ADS-report indEC-G-PENDING

ADS-report indEC-G-CANCEL

ADS-accept-PDU (event)

request AB to abort stop t-EC-1ADS-event-contract cnfEC-G-ACTIVE


request AB to abort

ADS-positive-acknowledgement-PDU (cancel-contract-event)

request AB to abort request AB to abort request AB to abort request AB to abort Stop t-EC-2ADS-cancel-contract cnfEC-G-IDLE

ADS-cancel-negative-acknowledgement-PDU (no-such-contract)

request AB to abort request AB to abort request AB to abort request AB to abort Stop t-EC-2ADS-cancel-contract cnfEC-G-IDLE

ADS-rejected-PDU (event)

request AB to abort stop t-EC-1ADS-event-contract cnfEC-G-IDLE


request AB to abort

ADS-ncn-PDU(event)



request AB to abort

14426

14427



Requests to stop operation

EC-G-IDLE stop t-EC-1EC-G-IDLE

EC-G-IDLE stop t-EC-1EC-G-IDLE

stop t-EC-2EC-G-IDLE

Timer expiry

t-EC-1 cannot occur request AB to abort cannot occur request AB to abort cannot occurt-EC-2 cannot occur cannot occur cannot occur cannot occur request AB to abort

1442814429


Table Erreur ! Il n'y a pas de texte répondant à ce style dans ce document.5-21: ADS-C air EC module state table

State EC-A-IDLE(Initial State)

EC-A-PENDING EC-A-ACTIVE EC-A-ACTIVE-PENDING

Event


ADS-event-contract rsp (positive acknowledgement)

Not permitted Send ADS-positive-acknowledgement-PDUEC-A-ACTIVE

Not permitted Send ADS- positive-acknowledgementPDUEC-A-ACTIVE

ADS-event-contract rsp (non compliance notification)

Not permitted Send ADS-ncn-PDUEC-A-ACTIVE

Not permitted Send ADS-ncn-PDUEC-A-ACTIVE

ADS-event-contract rsp (rejected)

Not permitted Send ADS-rejected-PDUEC-A-IDLE

Not permitted Send ADS-rejected-PDUEC-A-ACTIVE

ADS-event-contract rsp (accepted)

Not permitted Send ADS-accepted-PDUEC-A-ACTIVE

Not permitted Send ADS-accepted-PDUEC-A-ACTIVE

ADS-report req(event)

Not permitted Not permitted Send ADS-report-PDUEC-A-ACTIVE

Not permitted


Requests to stop operation EC-A-IDLE EC-A-IDLE EC-A-IDLE EC-A-IDLE

ADS-C Ground PDUs

ADS-contract-PDU(event) ADS-event-contract indEC-A-PENDING

request AB to abort ADS-event-contract indEC-A-ACTIVE-PENDING

request AB to abort

ADS-cancel-PDU(event)

Send ADS-cancel-negative-acknowledgementEC-A-IDLE

request AB to abort ADS-cancel indSend ADS-cancel-positive-acknowledgementEC-A-IDLE

request AB to abort

14430

14431

1443214433


Table Erreur ! Il n'y a pas de texte répondant à ce style dans ce document.5-22: ADS-C ground periodic-contract state table

State PC-G-IDLE

(Initial State)PC-G-START-PENDING

PC-G-ACTIVE PC-G-PENDING PC-G-CANCEL

Event


ADS-periodic-contract req

Send ADS-contract-PDUStart t-PC-1PC-G-START-PENDING

Not permitted Stop t-PC-2Send ADS-contract-PDUStart t-PC-1PC-G-PENDING


ADS-cancel req (periodic)

Not permitted Not permitted Stop t-PC-2Send ADS-cancel-PDUStart t-PC-3PC-G-CANCEL


ADS-C Aircraft PDUs

ADS-accepted-PDU(periodic)

request AB to abort Stop t-PC-1ADS-periodic-cnfStart t-PC-2PC-G-ACTIVE

request AB to abort Stop t-PC-1ADS-periodic-cnfStart t-PC-2PC-G-ACTIVE

request AB to abort

ADS-report-PDU(periodic)

request AB to abort request AB to abort Stop t-PC-2ADS-report indStart t-PC-2PC-G-ACTIVE

ADS-report indPC-G-PENDING

ADS-report indPC-G-CANCEL

ADS-positive-acknowledgement-PDU (periodic-contract)

request AB to abort stop t-PC-1ADS-periodic-contract cnfStart t-PC-2PC-G-ACTIVE


request AB to abort

ADS-positive-acknowledgement-PDU (cancel-periodic-contract)

request AB to abort request AB to abort request AB to abort request AB to abort

Stop t-PC-3ADS-cancel-contract cnfPC-G-IDLE

ADS-cancel-negative-acknowledgement-PDU (no-such-contract)

Request AB to abort Request AB to abort Request AB to abort Request AB to abort

Stop t-PC-3ADS-cancel-contract cnfPC-G-IDLE

14434

14435


ADS-rejected-PDU (periodic)

request AB to abort stop t-PC-1ADS-periodic-contract cnfPC-G-IDLE


request AB to abort

ADS-ncn-PDU (periodic)



request AB to abort


Request to stop operation

PC-G-IDLE stop t-PC-1PC-G-IDLE

Stop t-PC-2PC-G-IDLE

stop t-PC-1PC-G-IDLE

stop t-PC-3PC-G-IDLE

Request to suspend periodic contract

stop t-PC-2

Request to reinstate periodic contract

start t-PC-2

Timer expiry

t-PC-1 cannot occur request AB to abort cannot occur request AB to abort

cannot occur

t-PC-2 cannot occur cannot occur request AB to abort cannot occur cannot occurt-PC-3 cannot occur cannot occur cannot occur cannot occur request AB to abort

14436


Table Erreur ! Il n'y a pas de texte répondant à ce style dans ce document.5-23: ADS-C air PC module state table

State PC-A-IDLE(Initial State)

PC-A-PENDING PC-A-ACTIVE PC-A-ACTIVE-PENDING

Event


ADS-periodic-contract rsp (positive acknowledgement)

Not permitted Send ADS-positive-acknowledgement-PDUPC-A-ACTIVE

Not permitted Send ADS-positive-acknowledgement-PDUPC-A-ACTIVE

ADS-periodic-contract rsp (non compliance notification)

Not permitted Send ADS-ncn-PDUPC-A-ACTIVE

Not permitted Send ADS-ncPDUPC-A-ACTIVE

ADS-periodic-contract rsp (reject)

Not permitted Send ADS-rejected-PDUPC-A-IDLE

Not permitted Send ADS-rejected-PDUPC-A-ACTIVE

ADS-periodic-contract rsp (accepted)

Not permitted Send ADS-accepted-PDUPC-A-ACTIVE

Not permitted Send ADS-accepted-PDUPC-A-ACTIVE

ADS-report req(periodic)

Not permitted Not permitted Send ADS-report-PDUPC-A-ACTIVE

Not permitted


Requests to stop operation PC-A-IDLE PC-A-IDLE PC-A-IDLE PC-A-IDLEADS-C uplink PDUs

ADS-contract-PDU (periodic)

ADS-periodic-contract indPC-A-PENDING

request AB to abort ADS-periodic-contract indPC-A-ACTIVE-PENDING

request AB to abort

ADS-cancel-contract-PDU(periodic)

Send ADS-cancel-negative-acknowledgementPC-A-IDLE

request AB to abort ADS-cancel indSend ADS-positive-acknowledgementPC-A-IDLE

request AB to abort

14437

14438

144391444014441


Table Erreur ! Il n'y a pas de texte répondant à ce style dans ce document.5-24: Ground ADS-C LI module state table

State LI-G-IDLE(Initial State)

LI-G-START LI-G-ACTIVE LI-G-END

Event

Data and requests passed from other modulesADS-contract-PDU D-START req

LI-G-STARTNot permitted D-DATA req

LI-G-ACTIVENot permitted

ADS-cancel-all-contracts req Not permitted Not permitted start t-LI-1D-END reqLI-G-END

Not permitted

ADS-cancel-contract-PDU Not permitted Not permitted D-DATA req[1]

LI-G-END

ADS-provider-abort-PDU, ADS-user-abort-PDU

LI-G-IDLE D-ABORT reqLI-G-IDLE

D-ABORT reqLI-G-IDLE

D-ABORT reqLI-G-IDLE

ADS-forward-contract-response-PDU Not permitted Not permitted Not permitted Not permittedPrimitive Indications and Confirmations

D-START ind pass user data to appropriate moduleLI-G-START-R


D-START cnf cannot occur pass user data to appropriate module[1]


D-DATA ind cannot occur cannot occur pass user data to appropriate module[1]

pass user data to appropriate moduleLI-G-END

D-END-ind cannot occur cannot occur if ADS-end-forward-service-PDU, pass to HI moduleD-END rspLI-G-IDLE

cannot occur

D-END cnf cannot occur cannot occur cannot occur stop t-LI-1ADS-cancel-all-contracts cnfLI-G-IDLE

D-ABORT ind or D-P-ABORT ind cannot occur pass to AB moduleLI-G-IDLE

pass to AB moduleLI-G-IDLE

pass to AB moduleLI-G-IDLE

Timer expiry


t-LI-1 cannot occur cannot occur cannot occur request AB to abort

[1] If DC, EC and PC modules are all in their idle state then Invoke D-END req with no user data LI-G-END Else LI-G-ACTIVE

Table Erreur ! Il n'y a pas de texte répondant à ce style dans ce document.5-25: Air ADS-C LI module state table

State LI-A-IDLE(Initial State)

LI-A-START LI-A-ACTIVE

Event

Data and requests passed from other modules

ADS-accepted-PDU, ADS-rejected-PDU, ADS-ncn-PDU, ADS-positive-acknowledgement-PDU

Not permitted D-START rspLI-A-ACTIVE

D-DATA reqLI-A-ACTIVE

ADS-report-PDU, ADS-negative-acknowledgement-PDU

Not permitted Not permitted D-DATA reqLI-A-ACTIVE

Primitive Indications and Confirmations

D-START ind pass to appropriate moduleLI-A-START


D-DATA ind cannot occur cannot occur pass user data to appropriate moduleLI-A-ACTIVE

D-END ind cannot occur cannot occur if ADS-cancel-all-contracts-PDU, pass to HI moduleD-END rspLI-A-IDLE

D-ABORT ind or D-P-ABORT ind cannot occur pass to AB moduleLI-A-IDLE

pass to AB moduleLI-A-IDLE

1444214443

14444

14445

14446

5.1.6 Communication Requirements

5.1.6.1 Encoding Rules

5.1.6.1.1 The ADS-C application shall use PER as defined in ISO/IEC 8825-2, using the Basic Unaligned variant to encode/decode the ASN.1 message structure and content specified in 4.

5.1.6.1.2 When encoded ADS-C APDUs are treated as bit-oriented values that are not padded to an integral number of octets, the length determinant includes only the significant bits of the encoding, corresponding to the ASN.1 type.

5.1.6.2 Dialogue Service Requirements

5.1.6.2.1 Primitive Requirements

5.1.6.2.1.1 Where dialogue service primitives, that is D-START, D-END, D-ABORT, D-P-ABORT and D-DATA are described as being invoked in 5.1.5, the ADS-ground-ASE and the ADS-air-ASE shall exhibit external behaviour consistent with the dialogue service, as described in 5.14.2, having been implemented and its primitives invoked.

5.1.6.2.2 Quality of Service Requirements

5.1.6.2.2.1 The application service priority for ADS-C shall have the abstract value of “high priority flight safety messages”.

5.1.6.2.2.2 The RER quality of service parameter of the D-START request shall be set to the abstract value of “low”.

5.1.6.2.2.3 The ADS-C ASE shall map the class of communication service abstract values to the ATSC routing class abstract value part of the D-START QOS parameter as presented in Table 5-26.

Table 5-26: Mapping between class of communication and routing class abstract values

Class of Communication Abstract Value Routing Class Abstract Value









5.1.6.2.2.4 ATSC values are defined in 1.3.

5.1.6.2.2.5 ATN Security Requirements

5-1

1144471444814449144501445114452144531445414455144561445714458144591446014461144621446314464144651446614467144681446914470144711447214473144741447514476

1447714478144791448014481

2


5.1.6.2.2.5.1 The Security Requirements parameter of the D-START request shall be set to the abstract value of either “secured exchange” or “no security” for the ADS-demand-contract, ADS-event-contract and ADS-periodic-contract services.

5.1.7 ADS-user Requirements

5.1.7.1 General

5.1.7.1.1 General Requirements

The ADS-ground-user shall only establish a demand contract, an event contract or a periodic contract with an ADS-air-user.

5.1.7.1.2 General Parameter Requirements

5.1.7.1.2.1 When an ADS-ground-user invokes ADS-demand-contract request, ADS-event-contract request, ADS-periodic-contract request or ADS-forward-contract request and requires a particular class of communication service, it provides the Class of Communication Service parameter.

5.1.7.1.2.2 When an ADS-ground-user invokes ADS-demand-contract request, ADS-event-contract request, ADS-periodic-contract request or ADS-forward-contract request, and does not provide the Class of Communications Service parameter, this indicates no routing preference.

5.1.7.1.2.3 When an ADS-ground-user specifies the Class of Communications Service parameter and there is an ADS-C contract in place, the parameter is ignored.

5.1.7.1.2.4 When a ADS-ground-user requires to establish a secure or unsecure air-ground ADS-C contracts, it sets the Security Required parameter as appropriate.

5.1.7.1.3 Timing Requirements

5.1.7.1.3.1 When a ADS-ground-user requires to establish a secure or unsecure air-ground ADS-C contracts, it sets the Security Required parameter as appropriate.

5.1.7.1.3.2 When an ADS-air-user or ADS-ground-user receives an indication that requires a response, it should invoke the response within the contract response time.

5.1.7.1.3.3 When a periodic contract is in place, the ADS-air-user should invoke ADS-report request (as described below) within the report generation time of the reporting interval as measured from the sending of the previous report.

5.1.7.1.4 Error Handling Requirements

5.1.7.1.4.1 If the ADS-air-user or ADS-ground-user has an unrecoverable system error, then it should invoke ADS-user-abort request for each affected peer system.

5.1.7.1.4.2 If the ADS-user receives an ADS-user-abort indication or an ADS-provider-abort indication, then it shall cease operation of all ADS-C contracts with the peer system to which the indication is related.

314482144831448414485144861448714488144891449014491144921449314494144951449614497144981449914500145011450214503145041450514506145071450814509145101451114512145131451414515145161451714518145191452014521145221452314524145251452614527145281452914530145311453214533

4

Part I. Air-Ground ApplicationsChapter 5. Automatic dependent surveillance — contact (ADS-C) 5-3

5.1.7.1.5 Miscellaneous Air User Requirements

With the permissible exception of ADS-user-abort and ADS-provider-abort, the ADS-air-user shall respond to indications and confirmations in the order in which they are received.

5.1.7.1.6 Miscellaneous Ground User Requirements

With the permissible exception of ADS-user-abort and ADS-provider-abort, the ADS-ground-user shall respond to indications and confirmations in the order in which they are received.

514534145351453614537145381453914540145411454214543145441454514546

6


5.1.8 Subsetting Rules

5.1.8.1 This section specifies conformance requirements which all implementations of the ADS-C protocol obey.

5.1.8.2 An implementation of either the ADS-C ground based service or the ADS-C air based service claiming conformance to 5.1 shall support the ADS-C protocol features as shown in the tables below.

5.1.8.3 The ‘status’ column indicates the level of support required for conformance to the ADS-C ASE protocol described in the tables are as follows:

a) ‘M’ mandatory support is required;

b) ‘O’ optional support is permitted for conformance to the ADS-C protocol;

c) ‘N/A’ the item is not applicable; and

d) ‘C.n’ the item is conditional where n is the number which identifies the condition which is applicable.

Table 5-27: ADS-C Protocol Versions Implemented

Status Associated Predicate

Version 1 C V1

C: a conformant implementation shall support one and only one of these two options

714547145481454914550145511455214553145541455514556145571455814559145601456114562145631456414565145661456714568

1456914570

8


Table 5-28: ADS-C Protocol Functional Units

Status Associated Predicate

The ADS-C system acts as an airborne system

C.1 ADS/air

The ADS-C system acts as a ground system

C.1 ADS/ground

The ADS-C ground system can establish demand contract

If (ADS/ground) C.2 else N/A G-DC-FU

The ADS-C ground system can establish event contracts

If (ADS/ground) C.2 else N/A G-EC-FU

The ADS-C ground system can establish periodic contracts

If (ADS/ground) C.2 else N/A G-PC-FU

The ADS-C air system can process demand contracts

If (ADS/air) C.3 else N/A A-DC-FU

The ADS-C air system can process event contracts

If (ADS/air) C.3 else N/A A-EC-FU

The ADS-C air system can process periodic contracts

If (ADS/air) C.3 else N/A A-PC-FU

C.1: a conformant implementation shall support one and only one of these two options.C.2: a conformant ground implementation shall support at least one of the three options.C.3: a conformant air implementation shall support at least one of the three options.

914571145721457314574

14575145761457714578

10


Table 5-29: ADS-ground-ASE Conformant Configurations

List of Predicates Functionality Description

I G-DC-FU + ADS/ground ADS-ground-ASE supporting demand contract only

Demand contract only can be established with the aircraft

II G-EC-FU + ADS/ground ADS-ground-ASE supporting event contracts

Event contracts can be established with the aircraft

III G-PC-FU + ADS/ground ADS-ground-ASE supporting periodic contracts

Periodic contracts can be established with the aircraft

IV G-DC-FU + G-EC-FU + ADS/ground ADS-ground-ASE supporting demand and event contracts

Demand and Event contracts can be established with the aircraft

V G-DC-FU + G-PC-FU + ADS/ground ADS-ground-ASE supporting demand and periodic contracts

Demand and Periodic contracts can be established with the aircraft

VI G-EC-FU + G-PC-FU + ADS/ground Event and Periodic contracts can be established with the aircraft

VII G-DC-FU + G-EC-FU + G-PC-FU + ADS/ground Demand, Event and Periodic contracts can be established with the aircraft

111457914580

14581

12


Table 5-30: ADS-air-ASE Conformant Configurations

List of Predicates Functionality Description

I ADS/air + A-DC-FU Demand contracts only can be established with the ground system. A Reject Contract with reason “ADS-service unavailable” is sent when Event or Periodic contracts are requested.

II ADS/air + A-EC-FU Event contracts only can be established with the ground system. A Reject Contract with reason “ADS-service unavailable” is sent when contracts are requested.

III ADS/air + A-PC-FU Periodic contracts only can be established with the ground system. A Reject Contract with reason “ADS-service unavailable” is sent when Demand or Event contracts are requested.

IV ADS/air + A-DC-FU + A-EC-FU Demand and Event contracts can be established with the ground system. A Reject Contract with reason “ADS-service unavailable” is sent when Periodic contracts are requested.

V ADS/air + A-DC-FU + A-PC-FU Demand and Periodic contracts can be established with the ground system. A Reject Contract with reason “ADS-service unavailable” is sent when Event contracts are requested.

VI ADS/air + A-EC-FU + A-PC-FU Event and Periodic contracts can be established with the ground system. A Reject Contract with reason “ADS-service unavailable” is sent when Demand contracts are requested.

VII ADS/air + A-DC-FU + A-EC-FU +A-PC-FU Demand, Event and Periodic contracts can be established with the ground system.

5.2 ADS REPORT FORWARDING APPLICATION

(To be developed.)

______________________

131458214583

1458414585145861458714588145891459014591145921459314594

14

Chapter 6

ATN MESSAGE INTEGRITY CHECK ALGORITHM

6.1 USE OF THE INTEGRITY CHECK FUNCTION

6.1.1 The integrity check algorithm specified in this chapter may optionally be invoked by the ATN application-user specification to provide a proof of message integrity. If other information (e.g. sender and/or receiver identity) is also bound to the message when the integrity sequence is computed and verified, then it can also provide additional proof (e.g. a proof of delivery to an intended recipient).

6.1.2 By default, an application integrity check shall be computed using the default ATN message checksum algorithm specified in this chapter.

6.1.3 Other integrity check algorithms may be used and their use identified by including, in the application message, a relative OID that identifies the algorithm alongside the computed integrity check. However, the use of an alternative integrity check algorithm must be agreed in advance by both air and ground users using a procedure outside of the scope of this specification.

6.2 DEFAULT ATN MESSAGE CHECKSUM ALGORITHM

6.2.1 General

6.2.1.1 The default ATN message checksum algorithm generates a 32-bit (4-octet) checksum.

6.2.1.2 The default ATN message checksum algorithm is a 32-bit version of the Fletcher algorithm. This has been chosen in order to satisfy requirements for high data integrity with good performance characteristics.

6.2.1.3 The object identifier “atn-default-checksum”, as defined below, identifies the default ATN message checksum algorithm:

atn-default-checksum ::= OBJECT IDENTIFIER {iso(1) identified organization(3) icao(27) atn-algorithms(9) atc-chk32(0)}

6.2.2 Symbols

6.2.2.1 The symbols used in the ATN application-user specification are as follows:

C0, C1, C2, C3 are variables used by the algorithm.

i is the number (i.e. position) of an octet within the message to be protected.

L is the length of the message to be protected, in octets.

6-1

14595

14596

1459714598145991460014601146021460314604146051460614607146081460914610146111461214613146141461514616146171461814619146201462114622146231462414625146261462714628146291463014631146321463314634146351463614637146381463914640146411464214643


Xj is the value of the j'th octet of the checksum BIT STRING, where X0 is the first octet in the BIT STRING; X1 is the second octet; X2 is the third octet; and X3 is the fourth octet.

6.2.2.2 The data to be protected is a bit string provided by the user of this algorithm.

6.2.3 Arithmetic conventions

6.2.3.1 Addition shall be performed in one of the two following modes:

a) modulo 255; or

b) ones complement arithmetic.

6.2.3.2 In the ones complement mode, if any of the variables has the value minus zero (i.e. 0xFFFF), it shall be regarded as though it were plus zero (i.e. 0).

6.2.4 Algorithm for checksum generation

6.2.4.1 If the data to be protected is not an integral number of octets, it shall be right padded to the next octet boundary by appending bits with value “zero” (0).

6.2.4.2 The ATN message checksum shall be generated by the following algorithm:

a) Initialize C0, C1, C2 and C3 to zero.

b) Process each octet in the message sequentially from i = 1 to L by:

1) adding the value of the octet to C0; and

2) then adding the value of C0 to C1, C1 to C2, and C2 to C3.

c) Set the octets of the checksum as follows:

1) X0 = - (C0 + C1 + C2 + C3);

2) X1 = C1 + 2*C2 + 3*C3;

3) X2 = - (C2 + 3*C3); and

4) X3 = C3.

6.2.5 Algorithm for checksum verification

When the integrity of a message is to be verified using this algorithm, the verification function shall:

a) append to the message the octets of the checksum field in the same order in which they appear in the checksum BIT STRING;

b) initialize C0, C1, C2 and C3 to zero;

14644146451464614647146481464914650146511465214653146541465514656146571465814659146601466114662146631466414665146661466714668146691467014671146721467314674146751467614677146781467914680146811468214683146841468514686146871468814689146901469114692146931469414695

Part I. Air-Ground ApplicationsChapter 6. ATN Message Integrity Check Algorithm 6-3

c) process each octet in the message, including the appended checksum octets, sequentially from i = 1 to L by:

1) adding the value of the octet to C0; and

2) then adding the value of C0 to C1, C1 to C2, and C2 to C3;

d) discard the appended checksum octets; and

e) if, when all the octets have been processed, all of the variables C0, C1, C2 and C3 have the value zero, then a “success” indication is given to the algorithm user. Otherwise, a “verification failure” indication is given to the algorithm user.

— END —

1469614697146981469914700147011470214703147041470514706147071470814709147101471114712

international civil aviation organization … · web viewpart i. air-ground applications. chapter...

Documents