ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79

International Civil Aviation Organization

WORKING PAPER

AERONAUTICAL COMMUNICATIONS PANEL (ACP)

WORKING GROUP N (Networking) ------------------------------------------------------------------------------------------------------

ANNEX 10, Volume III, CHAPTER 3 AERONAUTICAL TELECOMMUNICATION NETWORK

VERSION 3.2-3 (28 January 2007)

(including changes as reviewed by the Air Navigation Commission

in November 2005)Proposed amendments to:a. incorporate IPSb. update existing SARPs in accordance with ANC

guidelines

Explanatory notes.

This paper contains proposed revisions to Annex 10, Volume III, Chapter 3 with the view to bring the SARPs for the Aeronautical Telecommunications Network in line with the “Guidelines to ANC panels for the development of SARPs material for complex systems” (see WGN6 / IP 19).

The material below has been reviewed by ACP WGN/6 with the following conclusions:1. Proposals as noted “no comments” in the comments boxes are in principle

agreed. Participants in WG N and its sub-groups are invited to provide additional comments, as required, prior to the next meeting on WG N.

2. Proposals as noted “agreed” in the comments boxes are agreed. However, participants in WG N and its sub-groups are invited to provide comments, as required, prior to the next meeting of WG N.

This material will be further reviewed by SWG N1 and a final proposal for revision will be developed at WGN/7 which will also include proposals to incorporate IPS (TCP/IP) in the SARPs for the ATN.

Proposals for further changes for updating and enhancing this material are to be submitted through a relevant working paper, to be submitted to either SWGN1, proving the rationale for the change.

Doc. XXX referenced in this paper refers to the manual on detailed technical specifications for an IPS based ATN

Further revisions were considered at SWGN1-11. The results of the discussions of these

1(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 comments and proposals are incorporated in this document.

Comments on all issues raised in this paper are invited, for review by SWGN1 at its next meeting (November 2006). Completion of this activity is scheduled at SWGN-11 (January/February 2007) and ACP/1 (May 2007) This version 3.3. incorporates all changes agreed up to and including WGN7 (January 2007)

Note: Detailed technical specifications for the ATN are contained in Docs 9705/Doc. 9880 and Doc.XXX respectively. These documents also contain a detailed description of the ATN, including details on the Standards and Recommended Practices below.

3.1 DEFINITIONS

Note 1.— The following definitions were taken from ISO/IEC 7498-1, Information technology — Open SystemsInterconnection — Basic Reference Model (Reference: ITU-T Rec. X.200 (1994)) and from ICAO Doc 9705 — Manual of Technical Provisions for the Aeronautical Telecommunication Network (ATN).

Note 2.— ICAO Doc 9705 has evolved through multiple editions. Each sub-volume of that document indicates the evolution of the provisions between successive editions.

Note 3.— Sub-volume I of ICAO Doc 9705 provides a cross-reference chart between versions (i.e. embedded software capabilities) and editions (i.e. technical provisions).

Note: Detailed technical specifications for the ATN are contained in Docs 9705 and XXX respectively. These documents also contain a detailed description of the ATN, including details on the Standards and Recommended Practices below.

Comment: the notes above are no longer relevant because of the introduction of material in the SARPs for an ATN that is based upon the Internet Protocol Suite (IPS). The added note refers to the detailed technical specifications for the ATN, for ATN/OSI in Doc. 9705 and for ATN/IPS in Doc. XXX respectively. See also the proposal to remove paragraph 3.2 from Annex 10 WGN06: in principle agreed; SWGN1-10 deletion agreed; note on reference to Manuals to move as shown.

Application integrity check. A small amount of additional information transferred with an application message and used to provide proof to a recipient of message content integrity. When the Integrity Check is computed, it maybe computed over more than just the message itself e.g. sender and receiver identifiers (and hence used to provide additional proofs (e.g. delivery to the intended recipient and/or authorization of the sender). The type of proof offered depends on the algorithm used to generate/verify the Application Integrity Check. A cryptographic checksum and/or use of a shared secret may be required to provide proof of origin (authentication of the sender).(ADD-ACP-WGW-01)

Comment: The definition above is rather explanatory material than a definition. In addition, the terms application integrity check or application integrity are NOT used in the SARPs. Deletion is proposed. WGN06: in principle agreed (this material is already contained in Doc. 9705, SV1) SWGN1-10 deletion agreed

Accounting management. An ATN systems management facility to monitor users for use of network resources. and to limit the use of those resources.

Comment: The definition above is rather confusing since the accounting management is

2(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 not a mechanism to limit the use of the ATN network resources. Deletion is proposed. (See also proposal for paragraph 3.8) WGN06: deletion in principle agreed SWGN1-10 deletion agreed

ADS application. An ATN application that provides ADS data from the aircraft to the ATS unit(s) for surveillance purposes.

Comment: The definition above is self explanatory. It is obvious that an ADS application is providing ADS (data). The definition for Automatic Dependent Surveillance below is sufficient. Deletion is proposed. WGN06: in principle agreed; SWGN1-10 deletion agreed

Aeronautical administrative communication (AAC). Communication used by aeronautical operating agencies relatinged to the non-safety communications for the business aspects of operating their flights and transport services. This communication is used for a variety of purposes, such as flight and ground transportation, bookings, deployment of crew and aircraft or any other logistical purposes that maintain or enhance the efficiency of over-all flight operation.

Comment: The first part of the definition is sufficient. The second part is not necessary since it is adding examples of AAC. Where necessary, these examples should be included in the relevant guidance material. WGN06: in principle agreed ; SWGN1-10 agreed to amend this definition as follows:Aeronautical administrative communications (AAC). Communications necessary for the exchange of aeronautical administrative messages (Re. Annex 10, Vol. II, paragraph 4.4.1.1.7).This definition needs to move to Annex 10, Volume III, Part I Chapter 3.1 (Definitions).

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.

Comment: This definition is identical to the definition for Operational Control in Annex 6 and for Operational Control communications in Annex 10 Volume II. . WGN06: retaining this definition in principle agreed; SWGN1-10 agreed to amend this definition into: Aeronautical operational control (AOC). Communication required for the exchange of aeronautical administrative messages (Re Annex 10, Volume II, paragraph 4.4.1.6).This definition needs to move to Annex 10, Volume III, Part I Chapter 3.1 (Definitions).

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

Comments: This definition above needs to be deleted. APC is not part of ANY aeronautical communication application contained in the ICAO Annexes. WGN06: in principle agreed; SWGN1-10 deletion agreed

AIDC application. An ATN application dedicated to exchanges between ATS units (ATSUs) of air traffic control (ATC) information in support of flight notification, flight coordination, transfer of control, transfer of communication, transfer of surveillance data and transfer of general data.

Comment: The definition above seems to rather re-define the definition for AIDC below than to explain that an AIDC application is an application that supports AIDC. However, this definition (for AIDC application) is not necessary since it is clear that an AIDC

3(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 application is an application supporting AIDC. The definition for AIDC below is sufficient. Deletion is proposed. WGN06: deletion agreed; ; SWGN1-10 deletion agreed

Air traffic service. 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).

Comment: This definition is identical to the definition in Annexes 11. A reference to these (this) definition is proposed. The definition above is self explanatory. WGN06: retention of definition and inclusion of a reference agreed; SWGN1-10 retention agreed; insert reference to Annex 11, Chapter 1, DefinitionsThis definition needs to move to Annex 10, Volume III, Part I, Chapter 3.1 (Definitions).

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

Comment: This definition is not necessary since the meaning of application is well understood. Deletion is proposed. WGN06: deletion in principle agreed; SWGN1-10 deletion agreed

Application entity (AE). Part of an application process that is concerned with communication within the ATN 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.

Comment: This definition is may not apply only to the OSI environment since it is also used at instances that are not specific to the ATN/OSI. Changes to the definition are proposed. However, the remaining definition is still not clear and may need updating. It is not clear why an application should be concerned with communication. This is taking place at lower layers (both in the OSI and the IPS environment) and should not be4 mixed with the application itself.WGN06: bring this definition in line with OSI material (OSI – 9545)(Reference to OSI standard). Requires further consideration. SWGN1-10: further consideration requiredSWGN1-11 – Bring definition in line with OSI 9545; the AE refers only to the OSI environment. Reword to read: An AE represents a set of OSI communication capabilities of a particular application process. (Re. ISO Doc. 9545 for further details)

Application information. Refers to the application names (e.g. AE qualifiers such as ADS and CPC), version numbers, and addresses (the long or short TSAP, as required) of each application.

Comment: With a clear definition for application entity, a definition for application information is not necessary, since the words are self-explanatory. Application information is information relating to the application and the name of it is just one element of the application. Deletion is proposed. WGN06: deletion in principle agreed; SWGN1-10 deletion agreed

ATIS application. A FIS application that supports the D-ATIS.

Comment: This definition is not necessary since the meaning of application as well as of D-ATIS is well understood. Deletion is proposed. WGN06: deletion in principle agreed Action Secretary: take up with ATM); SWGN1-10 deletion of definition for ATIS application agreed; keep definition for ATIS(see below)

4(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79

ATN directory services (DIR). Services provided by the Directory, through an access point, to its users by means of a number of Directory operations. (Re. ITU-T X.511)A service which provides the capability for an application entity or user in the ATN community to query a distributed directory data base and retrieve addressing, security and technical capabilities information relating to other users or entities within the ATN community.

Comment: Check whether a generic definition for directory service is available. If so, there may not be a need to define an ATN directory service, in which case deletion is proposed. WGN06: No generic definition for (ATN) directory services seems to be available; keep the current definition . SWGN1-10: further consideration requiredSWGN1.12 AC to check if definition is ATN specific or Directory general. Amended in line with the description for directory services in X.511

ATN security services. A set of information security provisions allowing the receiving end system orintermediate system to unambiguously identify (i.e. authenticate) the source of the received information and to verify the integrity of that information.

Comment: It is questionable whether the definition of ATN security service is necessary, since the term is self explanatory. Check with generic definitions. There is nothing specific in “ATN” security services compared to security services. Is the list complete? WGN06: to be further reviewed b y SWGN4. SWGN1-10: further consideration inSGN4 ongoing SWGN1-12: all to consider the need for this definition

ATN systems management (SM). A collection of facilities to control, coordinate and monitor the resources which allow communications to take place in the ATN environment. These facilities include fault management, accounting management, configuration management, performance management and security management.

Comment: This definition should be deleted. It is proposed to move all material on system management in the SARPs to guidance material for information purposes since there is no need to regulate SM on a global basis. There are other option to perform system management compared to those in the SARPs/Guidance material. At best, the SARPs could specify that a form of system management is required (in which case the definition needs to be retained.) WGN06: deletion in principle agreed SWGN1-10 deletion agreed

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.

Comment: This definition is not clear (see definition for transit delay below). A new definition for end-to-end delay may be necessary. Also check with OPLINKP document on RCP WGN06: (no comments). SWGN1-10: further consideration required. SGN1-11: can be deleted; Insert definition for DLIC; amend 3.4.7 to refer to RCP manual and remove Table 3-1. ATSC classes are OSI specific and are to be retained in Doc. 9705/Doc. 9880.

ATS communications (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.

5(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79

Required communication performance (RCP) A statement of the performance requirements for operational communication in support of specific ATM functions. Re. Manual on Required Communication Performance (RCP) (Doc 9869)

Comment: This definition is not necessary since the meaning of ATS communications is well understood in the light of the definition of ATS. Deletion is proposed. WGN06: deletion in principle agreed; SWGN1-10 deletion agreed

ATS interfacility data communication (AIDC). Automated data exchange between air traffic services units, particularly in regard to co-ordination and transfer of flights in support of flight notification, flight coordination, transfer of control, and transfer of communication. ….. etc…..

Comment: The amendment proposed is necessary since AIDC is (may?) not be restricted to coordination of transfer of flight. It is obvious that data exchange serves the purpose of coordination in general. WGN06: agreed as amended SWGN1-10 agreed. SWN1-11 agreed.

ATS message handling service (ATSMHS). An application consisting of procedures used to exchange ATS messages in store-and-forward mode over the ATN such that the conveyance of an ATS message is in general not correlated with the conveyance of another ATS message by the service provider. (MOD-ACP-WGW-01)

ATS message handling system(AMHS). The set of computing and communication resources implemented by ATS organizations to provide the ATS message handling service. (ADD-ACP-WGW-01)

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

Comment: The fact that an ATS unit provides air traffic services (or FIS or is the ATS reporting office) is well understood. Deletion is proposed. WGN06: deletion agreed (spell ATSU in Annex 10 wherever necessary); SWGN1-10 deletion agreed

Authentication. A process used to ensure the identity of a person/user/network entity.

Comment: This definition is not necessary since the meaning of application is well understood. Deletion is proposed. The word is only used in the definition for security management and, if necessary, could be clarified in that definition. Deletion here is proposed. WGN06: deletion agreed; SWGN1-10 deletion agreed

Authorized path. A communication path that the administrator (s) of the routing domain(s) has pre-defined as suitable for a given traffic type and category.

Automatic dependent surveillance Contract (ADS-C). 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 over the ATN.

Comment: WGN06: change agreed. SWGN1-10 agreed to amend this definition further to bring it in line with the definition for ADS-C as developed by OPLINKP/1 as follows:

6(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 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 report.This definition needs to move to Annex 10, Volume III, Part I, Chapter 3.1 (Definitions).

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.

Comment: SWGN1-10: This definition needs to move to Annex 10, Volume III, Part I, Chapter 3.1 (Definitions).

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

Comment: As per SWGN1-11 WP-1117 deleted.

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

Comment: Digital voice? Different from D-ATIS?) In any case, the term is not used in the SARPs and can be deleted. WGN06: deletion agreed; SWGN1-10: This definition should be maintained and to move to Annex 10, Volume III, Part I, Chapter 3.1 (Definitions).

Configuration management. An ATN systems management facility for managers to change the configuration of remote elements.

Comment: Is the configuration management restricted to remote elements (of the ATN)? It is used only in the section addressing systems management, which is proposed to be deleted. This definition can also be deleted. WGN06: deletion in principle agreed; SWGN1-10 deletion agreed

Context management (CM) application. An ATN application that provides a log-on 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 havenothing in common.

WGN06: Further study; consider to replace CM definitions (application, server) with a CM definition for ATN; SWGN1-10: further consideration requiredSWGN1-11: Amended as shown SWGN1-12 Definition is OSI specific. Replace with definition for DLIC; keep CM in Doc. 9705/Doc. 9880. Amend 3.5.1.1 accordingly

Context management (CM) server. An ATS facility that is capable of providing application information relating to other ATS units, Us to requesting aircraft or ATS units Us.

Comment: This is confusing. The CM application is an ATN application providing a log-on

7(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 service. It also provides a directory of all data link applications on the aircraft. It also includes functionality (?)to forward addresses. But the CM server is an ATS facility capable of providing application information to other ATSU’s to requesting aircraft or ATSU’s. A CM server is a server enabling CM applications. Revision/clarification is needed. WGN06: The note above can be deleted. Secretary: further consideration required SWGN1-12 Remove reference to CM and replace with DLIC; keep CM in Doc. 9705/Doc.9880. Amend 3.5.1.1 accordingly

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. (Re. Doc. 4444)

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

Comment: A minor change to the definition is proposed. WGN06: change in principle agreed; SWGN1-10: amend definition (again) as follows:Controller pilot data link communication (CPDLC). A means of communications between controller and pilot, using data link for ATC communications.This definition needs to move to Annex 10, Volume III, Part I, Chapter 3.1 (Definitions).

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.

Comment: This definition is not necessary since it is clear that a CPDLC application is an application providing CPDLC. WGN06: deletion in principle agreed; ; SWGN1-10 deletion agreed

Data integrity. The probability that data has not been altered or destroyed.

Comment: This definition is not necessary. WGN06: deletion in principle agreed; ; SWGN1-10 deletion agreed

D-METAR. The symbol used to designate data link aviation weather report service.

Comment: this definition is only used in the definition for METAR and not further in the SARPs. Deletion is proposed WGN06: deletion in principle agreed; ; SWGN1-10 deletion agreed

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

Comment: In IPS systems, the end system is called a host and contains only the four IPS layers. A definition for hast could be considered and if agreed, in the definition of end system the definition for host should be referenced. To be removedWGN06: deletion in principle agreed; ; SWGN1-10 deletion agreed

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.

8(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79

Comment: This definition can be deleted since there is a general understanding of what end-to-end means. It is not specific to ATN SARPs. Can be deleted WGN06: deletion agreed; ; SWGN1-10 deletion agreed

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

Comment: This definition can be deleted since it is only used in the SARPs in relation to application entity. There is already a definition for application entity. WGN06: deletion agreed; ; SWGN1-10 deletion agreed

Fault management. An ATN systems management facility to detect, isolate and correct problems.

Comment: In consideration of the proposal to remove section 3.8 on system management from the SARPs, this definition can be deleted. WGN06: deletion agreed; SWGN1-10 deletion agreed

FIS application. An ATN application that provides to aircraft information and advice useful for the safe and efficient conduct of flights.

Comment: A FIS application is an application within the flight information service. This definition is not necessary in the light of the definition for FIS below. WGN06: deletion in principle agreed; SWGN1-10 deletion agreed

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

Comment: This definition is identical to those used in Annexes 2 and 11. It should also be noted that the ATN only provides D-FIS (data-link FIS) and the definition should rather refer to D-FIS WGN06: adjustment of definition in principle agreed; SWGN1-10 agreed; the definition to FIS should include a reference to Annex 11; a definition for D-FIS needs to be added as follows:Data-link flight information service – (D-FIS) The provision of FIS via data linkThese definitions need to move to Annex 10, Volume III, Part I, Chapter 3.1 (Definitions).

Inter-centre communications (ICC). ICC is data communication between ATS units to support ATS, such as notification, coordination, transfer of control, flight planning, airspace management and air traffic flow management. ICC is a functional superset of AIDC

Comment: this definition needs to be considered together with the definition of AIDC. Since the definitions look similar, the difference between AIDC and ICC needs to be clarified. WGN06: Keep as amended; SWGN1-10 agreed

Intermediate system (IS). A system which performs relaying and routing functions and comprises the lowest three layers of the OSI reference model.

Comment: In IPS this is called a router. We may need to include a definition for router and refer to it in this definition. However, this definition may also be deleted (together with the definition for end-system) WGN06: deletion agreed; SWGN1-10 deletion agreed

9(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 Internet communications service. 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.

Comment: This definition also refers to and IPS based internet communication service and requires amendments as proposed. However, the definition is only used in the title of paragraph 3.6.2 and under the chapter title ATN communication service requirements. WGN06: deletion agreed SWGN1-10 deletion agreed

METAR application. A FIS application that supports the D-METAR.

Comment: This definition needs to be checked against definitions for METAR in other Annexes. WGN06: (deletion agreed) SWGN1-10 deletion agreed

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.Note: not

Comment: see addition. WGN06: deletion agreed SWGN1-10 deletion agreed

Performance management. An ATN systems management facility to monitor and evaluate the performance of the systems.

Comment: This definition may be removed from Annex 10 if material on systems management is moved to the relevant manual(s) WGN06: deletion agreed SWGN1-10 deletion agreed

Security management. An ATN systems management facility for access control, authentication and data integrity.

Comment: This definition may be removed from Annex 10 if material on systems management is moved to the relevant manual(s) WGN06: deletion agreed SWGN1-10 deletion agreed

Subnetwork. An actual implementation of a data network that employs a homogeneous protocol and addressing plan and is under control of a single authority.

Comment: This definition is confusing. Is the single authority an Administrative authority (which is implied by referencing “authority” in Annex 10 or is it a telecommunication operator authority. In particular with mobile sub-networks there may be different authorities. Revision/clarification of this definition is suggested. WGN06: deletion agreed SWGN1-10 deletion agreed

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.

Comment: The expression system level requirement is only used in paragraph 3.4. Introduction of system level implies that other requirement levels are used, but this is not the case. Deletion is proposed together with renaming paragraph 3.5 into “General

10(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 requirements” WGN06: deletion agreed SWGN1-10 deletion agreed

Transit delay. In packet data systems, the elapsed time between a request to transmit an assembled data packet and an indication at the receiving end that the corresponding packet has been received and is ready to be used orforwarded.

Comment: not to be confused with end-to-end delay; maybe a definition for end-to-end delay would be necessary WGN06: delete definition; insert clarification in figure on ATS Classes SWGN1-10: further consideration required With the removal of transit delay (ATSC-classes) from Annex 10, this definition is not further required. Transit delays are addressed in the manuals

Upper layers (UL) communications service. A term pertaining to the session, presentation and application layers of the OSI reference model. l

Comment: the addition is clarifying the difference between the OSI and the IPS-based models. However, the definition may not really be necessary WGN06: delete the proposed note; delete also the definition SWGN1-10 deletion agreed

Comment: Add definitions forATNATN/OSI see 3.2.1ATN/IPS

Suggested definition for ATN/OSIATN based on OSI Standards The aeronautical telecommunication network (ATN) based on Open Systems Interconnection (OSI) Standards from the International Standards Organization (ISO) is a network that includes application entities and communication services which allow ground, air-to-ground and avionics data subnetworks to interoperate by adopting common interface services and protocols based on the International Organization for Standardization (ISO) open systems interconnection (OSI) reference model. The conceptual model of the ATN is shown in Figure 3-1.*

ATN based on IPS Standards The aeronautical telecommunication network (ATN) based on the Standards forming the Internet Protocol Suite (IPS) from the Internet Society (ISOC) is a network that provides for communications between ground based ATN systems as well as with air-ground sub-networks.

SWGN1-10 agreed; the above definitions for ATN/IPS and ATN/OSI are not necessary; the following definition for ATN inAnnex 10, Volume III, Part I Chapter 3.1 to be amended as follows:Aeronautical telecommunication network – (ATN) A global internetwork architecture that allows ground, air-ground and avionic data sub-networks to exchange messages digital data primarily for the safety of air navigation and for the regular, efficient and economic operation of air traffic services

3.2 INTRODUCTION

Comment: All of paragraph 3.2 is descriptive material intended to introduce the material that follows in paragraphs 3.3 – 3.9 and do not contain specific SARPs. Removal of the

11(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 whole paragraph is proposed. Renumbering of the other paragraphs is not introduced in this paper. WGN06: Deletion in principle agreed; however, consider keeping 3.2.2a minus 3.2.2a)4). Check with Volume II

Proposal:3.2 The ATN and the associated application processes have been designed in support of the communications,navigation, surveillance and air traffic management (CNS/ATM) systems. The ATN is specifically and exclusively intended to provide data communications services to air traffic service provider organizations and aircraft operating agencies supporting the following types of communications traffic:

1) air traffic services communication (ATSC);2) aeronautical operational control (AOC);3) aeronautical administrative communication (AAC)

SWGN1-10 deletion agreed; keep paragraph 3.2 as follows:3.2 Introduction

3.2.2 The ATN and the associated application processes have been designed in support of the communications,navigation, surveillance and air traffic management (CNS/ATM) systems. The ATN is specifically and exclusively intended to provide digital data communications services to air traffic service provider organizations and aircraft operating agencies in support of supporting the following types of communications traffic:

1) air traffic services communication (ATSC)with aircraft;; 2) air traffic services communications between ATS uits;

2) aeronautical operational control communications (AO C);3) aeronautical administrative communication (AAC)

SWGN1-11 Change is editorial; see also deletion of 3.3 and 3,3,1 below

3.2.1 The aeronautical telecommunication network (ATN) comprises application entities and communication services which allow ground, air-to-ground and avionics data subnetworks to interoperate by adopting common interface services and protocols based on the International Organization for Standardization (ISO) open systems interconnection (OSI) reference model. The conceptual model of the ATN is shown in Figure 3-1.*

3.2.2 The ATN and the associated application processes have been designed in support of the communications,navigation, surveillance and air traffic management (CNS/ATM) systems. The ATN:

a) is specifically and exclusively intended to provide data communications services to air traffic service provider organizations and aircraft operating agencies supporting the following types of communications traffic: 1) air traffic services communication (ATSC); 2) aeronautical operational control (AOC); 3) aeronautical administrative communication (AAC); and 4) aeronautical passenger communication (APC);

b) provides, in a manner transparent to the user, a reliable end-to-end communications service essential to support the provision of safe and efficient air traffic services, between:

12(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 1) airborne systems and ground systems; and 2) multiple ground systems;

c) provides a data communication service which is capable of meeting the security and safety requirements of the users; d) is based on internationally recognized data communications standards which will facilitate the development of compliant systems and encourage the competitive provision of network services;

e) accommodates differing types/categories/classes of service (including preferred/selected air-ground subnetwork) required by the various applications;

f) defines an architecture that enables the integration of public and private subnetworks, both air-ground and ground-ground. This allows the use of existing/planned infrastructure and network technologies, as well asgiving implementors the freedom to scale the network to meet the increasing needs of the users; and

g) efficiently uses the bandwidth limited air-ground subnetworks and consequently reduces the associated costs.

3.2.3 The ATN applications presently defined have been developed to provide aeronautical communication, surveillance, and information services. These applications are intended to support the following air traffic management services.

a) air traffic services (ATS); 1) air traffic control service; 2) flight information service (FIS); and 3) alerting service. b) air traffic flow management (ATFM); and c) airspace management.

3.2.4 This chapter contains broad and general provisions for the ATN. The detailed technical provisions are found in Doc 9705. The remainder of this chapter is organized to address the following requirements and functions:

a) general; b) system level requirements; c) ATN applications requirements; d) ATN communications service requirements; e) ATN naming and addressing; f) ATN systems management requirements; and g) ATN security requirements.

3.3 GENERAL

Note: the following Standards and Recommended Practices define the minimum required protocols and services that will enable the global implementation of the ICAO Aeronautical Telecommunications Network (ATN).

3.3.1 The aeronautical telecommunication network (ATN) shall provide data communication services and application entities in support of:

a) the delivery of air traffic services (ATS) to aircraft; b) the exchange of ATS information between ATS units; and

13(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 c) other applications such as aeronautical operational control (AOC) and aeronautical administrative communication (AAC).

Comment: Although the ATN as currently defined only provides data communication services, in the future other services (voice through data) may be implemented. WGN06: amendment in principle agreed; SWGN1-10modified this paragraph further as follows: 3.3.1 The aeronautical telecommunication network (ATN) shall provide data communication services and application entities in support of:

a) the delivery of air traffic services (ATS) to aircraft;b) the exchange of ATS information between ATS units; andc) other applications such as aeronautical operational control communications

(AOC); and d) and aeronautical administrative communication (AAC).

SWGN1-11; editorial change; agreed to merge 3.3.1 into 3.2.2

Note 1.— Provisions have been made to accommodate the exchange of information such as weather, flight plans, notices to airmen and dynamic real time air traffic flow management between aircraft operating agencies’ ground-based systems and ATS units.

Comment: Note 1 is not necessary. WGN06: deletion in principle agreed; SWGN1-10 deletion agreed

Note 2.— Provisions have also been made to accommodate aeronautical passenger communication (APC).

Comment: APC is not to be part of the ICAO SARPs. However, some aspects of these may be addressed in the manual(s). WGN06: deletion agreed; SWGN1-10 deletion agreed

3.3.2 When the ATN is used in support of air traffic services, it shall conform with the provisions of this chapter.

Comment: The provisions of this chapter also apply to AOC and, as necessary, to AAC and other communications. Limiting these provisions to ATS applications opens the ATN to other applications not using the provisions in Annex 10. 3.3.2 can be deleted, since the provisions in Annex 10 apply to the whole ATN. See also the new note at the beginning of this paragraph. WGN06: deletion agreed; SWGN1-10 deletion agreed

3.3.1 ATN communication services shall support ATN applications.Note 1.- Detailed technical specifications for ATN/OSI applications are contained in the “Manual of Detailed Technical Specifications for the ATN using ISO/OSI standards and protocols” (Doc 9880).Note 2.- Detailed technical specifications for ATN/IPS applications are contained in the “Manual of Detailed Technical Specifications for the ATN using IPS standards and protocols” (Doc xxxx). [Insert correct title]

Comment: WG N7 – paragraph 3.3.1 re-inserted as shown. See WGN7 IP 9 WGN06: change in principle agreed; SWGN1-10 change agreed; add the following sentence to this paragraph:This agreement shall specify the area in which the provisions of paragraph 3.4.1 or 3.4.1 bis are applicable

3.3.3 Requirements for implementation use of the ATN shall be made on the basis of a regional air navigation agreements.

14(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 Comment: editorialWGN06: change in principle agreed; SWGN1-10 change agreed; add the following sentence to this paragraph:This agreement shall specify the area in which the provisions of paragraph 3.4.1 or 3.4.1 bis are applicable

3.3.4 Recommendation.— Civil aviation authorities should co-ordinate, with national authorities and aeronautical industry, those implementation aspects of the ATN which will permit its world-wide safety, interoperability and efficient use, as appropriate.

Comment: The aspects mentioned in this note are part of the regional air navigation agreement.WGN06: deletion in principle agreed; SWGN1-10 deletion agreed

3.4 SYSTEM LEVEL GENERAL REQUIREMENTS

Note.— The system level requirements are high-level technical requirements that have been derived from operational requirements, technological constraints and regulatory constraints (administrative and institutional). These system level requirements are the basis for the functional requirements and lower-level requirements.

Comment: In the light of the change to the title, note 1 is no longer necessaryWGN06: deletion in principle agreed; SWGN1-10 deletion agreed

3.4.1 The ATN shall either use International Organization for Standardization (ISO) communication standards for open systems interconnection (OSI). 3.4.1.bis The ATN shall use or Internet Society (ISOC) communication standards for the Internet Protocol Suite (IPS)

Note: Interoperability between interconnecting OSI/IPS networks shall be arranged prior to implementation.

Comment: this paragraph more or less also “legalizes” the use of IPv4 in some States or Regions. Standards for IPv6 are included below. WGN06: addition agreed SWGN1-10 addition agreed; . SWGN1-12 agreed to merge into one standard and add a note on OSI/IPS interoperability

Comment: SWGN1-10 noted through WP 1010 and WP1016 that paragraphs 3.4.1 and 3.4.1 bis require clarification; a note needs to be developed. SWGN1-12 agreed to add a note shown above

3.4.2 The ATN shall provide a means to facilitate migration to future versions of application entities and/or the communication services.

Note.— It is an objective that the evolution towards future versions facilitates the backward compatibility with previous versions.

Comment: This provision is rather an objective than a solution. It is obvious that the ATN needs to be flexible enough to accommodate future applications This provision can be deleted. In addition, the ATN would not need to “migrate” to future applications or version of applications; the applications need to be programmed in such a way that they can be accommodated over the ATN. WGN06: deletion agreed; SWGN1-10 deletion agreed

15(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 3.4.3 The ATN shall enable the transition of existing AFTN/CIDIN users and systems into the ATN architecture.

Comment: This is rather an objective than a standard. This paragraph should be deleted. WGN06: reword into a standard; SWGN1-10 agreed to the following standard:3.4.3. The AFTN/AMHS and CIDIN/AMHS gateways shall ensure the interoperability of AFTN andor CIDN stations and--or networks with the ATN (Agreed at SWGN1-11)WGN 7 amended 3.4.3 as follows 3.4.3. The AFTN/AMHS gateway shall ensure the interoperability of AFTN and CIDN stations and--or networks with the ATN (Agreed at SWGN1-11)

Note.— The transition from the AFTN or from the CIDIN to the ATN is handled by AFTN/AMHS and CIDIN/AMHS gateways respectively, which are defined in Doc 9705, Sub-volume III.

Comment: In Europe, CIDIN is being phased out. If this is also the case in the Middle East (there are no other CIDIN implementations), this paragraph an relevant note can be deleted. WGN06: reword into a Standard; SWGN1-10 agreed to delete the note in the light of the new text for paragraph 3.4.3 WG N7 amended the note as shown; See WGN7-IP8

3.4.4 The ATN shall make provisions whereby only the controlling ATS unit may provide ATC instructions to aircraft operating in its airspace.

Note.— This is achieved through the current and next data authority aspects of the controller-pilot data link communications (CPDLC) application entity.

Comment: First, this provision is part of the CPDLC application, as indicated in the note and belongs to paragraph 3.5. Second, as a security issue, it should belong to paragraph 3.9. But not here. Further discussion on this matter is necessary WGN06: agreed; FAA will provide additional input; SWGN1-10: further input from FAA expected requiredSWGN1!-11 Move to Section 3.9

3.4.5 The ATN shall accommodate routing based on a pre-defined routing policy.

3.4.5 bis The ATN shall transmit, relay and (or) deliver messages in accordance with the priority classification and without discrimination or undue delay.

Comment: SWGN1-12: added to arrange for the obligation to transfer and deliver messages.

3.4.6 The ATN shall provide means to define data communications that can be carried only over authorized pathsfor the traffic type and category specified by the user.

Comment: The routing of messages (or packages) in ATN/IPS is not necessarily through a predefine routing. TCP/IP ensures delivery of the message at the required receiving station(s) . These provisions can be deleted WGN06: further consideration required; SWGN1-10 agreed to keep paragraphs 3.4.5 and 3.4.6

3.4.7 The ATN shall provide offer communication in accordance with the prescribed required communication performance (RCP) (Re. Manual on Required Communication Performance (Doc. 9869) ATSC classes in accordance with the criteria in Table 3-1.*

Comment: The current ATSC classes need to be considered in the light of the OPLINKP

16(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 report on RCP WGN06: this is not necessary; keep; SWGN1-10 agreed SGN1-12 Agreed to replace reference to ATSC classes with reference to RCP and removing the Table 3-1

Note 1.— When an ATSC class is specified by an ATN application, packets will be forwarded in the ATN internetcommunications service on a best effort basis. Best effort basis means that when a route is available of the requested ATSC class, the packet is forwarded on that route. When no such route is available, the packet will be forwarded on the first known route of the ATSC class higher than that requested, or if there is no such route, first known route of the ATSC class lower than that requested.

Note 2.— The ATN communications service will not inform application entities if the requested ATSC class was not achieved. It is the responsibility of the application entity to determine the actual transit delay achieved by local means such as time stamping.

Comment: The notes, which are of an explanatory nature, should be deleted. If necessary, relevant information should be inserted in the ATN Manuals.WGN06: deletion in principle agreed; SWGN1-10 agreed to delete these notes. They need however to be re-inserted as explanatory notes to Table 3-1

3.4.8 The ATN shall operate in accordance with the communication priorities defined in Table 3-2 and Table 3-3.

3.4.9 The ATN shall enable exchange of application information when one or more authorized paths exist.

Comment: What if only un-authorized paths exist? Maybe we could review this definitionWGN06: no change; SWGN1-10 agreed

3.4.10 The ATN shall notify the appropriate application processes when no authorized path exists.

Comment: see comments above WGN06: no change; SWGN1-10 agreed

3.4.11 The ATN shall provide means to unambiguously address all ATN end systems (hosts) and intermediate systems (routers).

Comment: editorial WGN06: change in “hosts (end systems)”, delete “intermediate systems” and keep, without brackets, “routers”. SWGN1-10 agreed to keep 3.4.11 as amended above. Move to section 3.7

3.4.12 The ATN shall enable the recipient of a message to identify the originator of that message.

Comment: This is already part of the TCP protocol and does not need to be specified here. Furthermore, this provision is mixing communications with applications. If there is a need for the application to identify the originator to the recipient, this needs to be part of the application SARPs WGN06: keep, no change; SWGN1-10 agreed. Move to section 3.7; SWGN1-11: Move to section 3.9

17(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 3.4.13 The ATN addressing and naming plans shall allow States and organizations to assign addresses and names within their own administrative domains.

Comment: WGN06: keep, no change; SWGN1-10 agreed. Move to section 3.7

3.4.14 The ATN shall support data communications to fixed and mobile systems.

3.4.15 The ATN shall accommodate ATN mobile subnetworks as defined in this Annex.

3.4.16 The ATN shall make provisions for the efficient use of limited bandwidth subnetworks.

3.4.17 Recommendation. The ATN should shall enable an aircraft intermediate system (router) to be connected to a ground intermediate system (router) via different subnetworks.concurrent mobile subnetworks.

3.4.18 Recommendation: The ATN should shall enable an aircraft intermediate system (router) to be connected to different multiple ground intermediate systems (routers).

Comment: Work on this issue has demonstrated that the two provisions above are not requirements. Should the aircraft system not always be an end-system (host)? WGN06: amendments agreed, comments are invited; SWGN1-10 agreed

3.4.19 The ATN shall enable the exchange of address information between applications entities.

Comment: See 2.4.12. Is this a requirement of the communication system (ATN) or of the application. If this relates to the application, this provision should move to paragraph 3.5WGN06: keep this provision here; SWGN1-10 agreed to move this paragraph to section 3.7

3.4.20 The ATN shall support the context management (CM) application when any of the other air-ground applications are supported.

Comment: This application is already addressed in paragraph 3.5 and can be removed from this paragraph (and if necessary, moved to paragraph 3.5) WGN06: keep this provision; SWGN1-10 agreed to move3.5.1.1

3.4.21 The ATN shall be capable of establishing, maintaining, releasing and aborting peer-to-peer applicationassociations for the context management (CM) application.

Comment: This application is already addressed in paragraph 3.5 and can be removed from this paragraph (and, if necessary, moved to paragraph 3.5) WGN06: in principle agreed redundant in light of 3.5; delete); SWGN1-10 agreed to delete

3.4.22 The ATN shall be capable of establishing, maintaining, releasing and aborting peer-to-peer applicationassociations for the automatic dependent surveillance (ADS) application.

3.4.23 The ATN shall be capable of establishing, maintaining, releasing and aborting peer-to-peer application associations for the controller-pilot data link communications (CPDLC) application.

18(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 3.4.24 The ATN shall be capable of establishing, maintaining, releasing and aborting peer-to-peer applicationassociations for the automatic terminal information service (ATIS) application.

Comment: these paragraphs specify certain application requirements to be accommodated through the ATN and belong to paragraph 3.5. They should be deleted from this paragraph or move to paragraph 3.5WGN06: deletion agreed; SWGN1-10 agreed to delete

3.4.25 The ATN shall be capable of establishing, maintaining, releasing and aborting application associations for the ATS message handling service (ATSMHS) application.

3.4.26 The ATN shall be capable of establishing, maintaining, releasing and aborting peer-to-peer application associations for the ATS interfacility data communication (AIDC) application.

Comment: these paragraphs specify certain application requirements to be accommodated through the ATN and belong to paragraph 3.5. They should be deleted from this paragraph or move to paragraph 3.5WGN06: deletion agreed; SWGN1-10 agreed to delete

3.4.27 Where the absolute time of day is used within the ATN, it shall be accurate to within 1 second of coordinated universal time (UTC).

Note.— The A time accuracy of one second value may results in synchronization errors of up to twoseconds. times the stated accuracyvalue.

Comment: There are already provisions for aeronautical station to keep UTC. Shall this not be a requirement in the ATN, rather than an option? Editorial changes to the note are proposed.WGN06: change in principle agreed; SWGN1-10 agreed to delete

3.4.28 The end system shall make provisions to ensure that the probability of not detecting a message packet 255-octet message being mis-delivered, non-delivered or corrupted ATN by the internet communication service is less than or equal to 10–8 per message.

Note.— It is assumed that ATN subnetworks will ensure data integrity consistent with this system level requirement.

Comment: The note is bringing the status of the Standard in 3.4.28 to an option and is proposed to be deleted. Where 255 octet messages may be used in ATN/OSI, this may not be the case when using IPS. In addition, is the ICS not in reality the ATN? Editorial amendments to remove this ambiguity from the Standard and deletion of the note are proposed. WGN06: note can be deleted further work on 3.4.28 necessary; ; SWGN1-10: further consideration requiredSWGN1-11: Move to section 3.9 - SWGN1-12: deleted

3.4.29 ATN end systems supporting ATN security services shall be capable of authenticating the identity of peerend systems, authenticating the source of application messages and ensuring the data integrity of the application messages.

Note.— Application messages in this context include messages related to ATS, systems management and directory services

Comment: Are there ATN end systems NOT supporting ATN security services? Yes. See

19(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 also 3.4.12 and 3.4.19. Probably this provision belongs to paragraph 3.9 WGN06: no change; SWGN1-10 agreed Move paragraphs 3.4.29 and 3.4.30 to section 3.9 (security). SWGN1-11 agreed to move to section 3.9; SWGN1-12 introduced some changes (deletion of "application and consequential deletion of note) See 3.9

3.4.30 ATN ground and air-ground boundary intermediate systems supporting ATN security services shall be capable of authenticating the identity of peer boundary intermediate systems, authenticating the source of routing information and ensuring the data integrity of routing information.

Comment: see 3.4.29WGN06: keep; study further where this paragraph should go to; SWGN1-10 agreed; keep paragraph SWGN1-11 agreed to move to section 3.9 SWGN1-12 Deleted

3.4.31 The ATN shall be capable of establishing, maintaining, releasing and aborting peer-to-peer application associations for the exchange of directory information.

Comment: If this only refers to the exchange of directory information, this provision belongs to paragraph 3.5. If other application should be subject to the same provisions, this provisions should be generalized.WGN06: delete; SWGN1-10 agreed to delete

3.4.32 ATN systems supporting ATN systems management shall facilitate enhanced continuity of ATNoperations, including the monitoring and maintenance of the quality of the communications service.

Comment: Apart from the fact that this provision belongs to paragraph 3.8 (systems management), what are the enhanced continuity requirements and where are they established? In addition, paragraph 3.8 is proposed to be removed from Annex 10. WGN06: deletion agreed, further work necessary; SWGN1-10 agreed to delete

3.4.33 The ATN shall be capable of establishing, maintaining, releasing and aborting peer-to-peer application associations for the systems management (SM) application.

Comment: See 3.4.3.2WGN06: deletion agreed, further work necessary; SWGN1-10 agreed to delete

3.4.34 The ATN shall be capable of establishing, maintaining, releasing and aborting peer-to-peer applicationassociations for the aviation routine weather report service (METAR) application.

Comment: As material relating to an application, this paragraph should move to 3.5. Check if the explanation for METAR complies with the ICAO definition.WGN06: deletion agreed; SWGN1-10 agreed to delete

3.5 ATN APPLICATIONS REQUIREMENTS

Note 1.— Implementation of ATN application(s) within a State or region does not imply implementation of all of the ATN applications defined below.

Note 2.— The implementation of pre-defined subsets of the ATN application technical provisions are allowed as detailed in Doc 9705.

Comment: These notes are not necessary; reference to the Manuals is already provided

20(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 at the beginning of this Chapter. WGN06: deletion agreed; move content of notes to manual; SWGN1-10 agreed to delete

3.5.1 System applications

Note.— System applications provide services that are necessary for operation of the ATN air-ground applications, ground-ground applications and/or ATN communication services.

Comment: It is understood that specific system applications are necessary for the functioning of the ATN (as a transport mechanism for data messages (=applications))WGN06: change agreed; SWGN1-10 agreed to change

3.5.1.1.xx The ATN shall be capable of supporting the following DLIC CM applications as contained in Doc. 9694 (Manual on Data link applications when air-ground data links are implemented

Note: Detailed technical specifications for DLIC application for the ATN[OSI (Context Management (CM)) are contained in Doc. 9880, Part 1. For ATN/IPS detailed technical specifications for DLIC capabilities are contained in Doc. Xxxx)

Comment: SWGN1-10: moved from 3.5.1.1.1.paragraph 1-10 moved from 3.4.2; agreed SWGN1-12 Amended as shown. Log-on material for ATN/IPS to be added.WGN7 amended 3.5.1.1.xx and note as shown; See WGN7 IP 8

3.5.1.1 CONTEXT MANAGEMENT (CM) APPLICATION

3.5.1.1.1 The ATN shall be capable of supporting the context management (CM) applications to provide data link initiation capability as described in Doc. 9694. when any of the other air-ground applications are supported.

Comment: SWGN1-10, 11: amended as shown. SWGN1-12 can be deleted (see 3.5.1.1.xx above)

Note.— The CM application provides the capability for an aircraft to log on with an ATS ground system; in someinstances the ground system will request the aircraft to contact a specific ground system. Once an appropriate connection is established, CM provides for the exchange of information on each supported ATN application including the network address of each, as appropriate. For ATN systems supporting security services, CM also obtains and exchanges key and key usage information. CM also provides the capability to update log-oninformation and the capability for an ATS ground system to forward log-on information to another ATS ground system. The registration function of the CM allows the sharing of information with other applications on the ground or on the aircraft.

Comment: If necessary, an explanation of the CM applications can be given in the relevant manual WGN06: deletion agreed; SWGN1-10: further consideration requiredSWGN1-11: amendment agreed

3.5.1.1.1 The ATN shall be capable of supporting the following DL CM applications as contained in Doc. 9694 (Manual on Data link applications Part II functions:

21(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 a) log-on; b) contact; c) update; d) CM server query; e) CM server update; f) ground forwarding; and g) registration.

Note.— The technical provisions for the CM applicationare defined in Doc 9705, Sub-volume II.

Comment: As per the definition for CM, it provides a log-on service for aircraft and a directory of the data links applications on the aircraft. CM management also provides functionality to forward [aircraft?] addresses between ATS units. The list of CM function should likely be limited to these.WGN06: change agreed; SWGN1-10: move to 3.5.1; see further 5.5.1.1.1.xx above

3.5.1.2 ATN DIRECTORY SERVICES (DIR)

3.5.1.2.1 The ATN segments deploying ISO lower layers shall be capable of supporting the following following DIR applications as contained in Doc. 9705 functions when AMHS and/or security protocols are implemented:

a) directory bind;b) directory information retrieval; andc) directory information modification change.

Comment: Directory bind may need a definition rather than a note. WGN06: Not ok remove directory bind; further clarification may be required with regard to keep the details b) and c) or to refer only to Doc. 9705 in 3.5.1.2.1. SWGN1-10 agreed to change 3.5.1.2.1 to read:3.5.1.2.1 The ATN shall be capable of supporting following DIR applications:

a) directory bindb) directory information retrieval; andc) directory information modification .

SWGN1-11 agreed to delete 3.5.1.2 and to restructuring this section as indicated above; delete directory bindWG N7: amended as per WG N7 IP8

Note 1.— The ATN Directory Service provides a capability for an application or user to query a distributed directory data base and to retrieve addressing, security and technical capabilities information. Directory Service provides a capability to special, authorized users to add, delete and modify parts of the directory data base for which they are responsible. The Directory Service is offered over the ATN to all applications and users complying with the technical provisions of Doc 9705, Sub-volume VII .

Note 2.— Directory bind is the function of establishing an association between two directory components that support other directory functions. Directory bind sets up the application contexts and underlying communications connections for use in other directory functions.

3.5.1.3 OTHER SYSTEM APPLICATIONS(to be developed)

3.5.2 Air-ground applications

22(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 Note.— The ground components of air-ground applications include functionality to support the forwarding of the contents of air-to-ground messages along ground-ground communications paths.

Comment: Since the air-ground subnetwork is part of the ATN, it is obvious that air-ground messages or applications need to have the capability to travel along the ground portion of the ATN until their destination. WGN06: deletion agreed SWGN1-10 agreed to delete

3.5.2.1 AUTOMATIC DEPENDENT SURVEILLANCE (ADS)-C APPLICATION-

Note.— The ADS application comprises an airborne and ground component. The airborne ADS application component is capable of automatically providing, via the ATN communications service, to the ground component data derived from on-board navigation systems (e.g. aircraft identification, four-dimensional position, intent, and additional data as appropriate). The ADS application provides service based on contracts established between its air and ground components (i.e. demand contract, periodic contract, event contract and emergency contract) and between two ADS ground components (i.e. forward contract).

3.5.2.1.1 The ATN shall be capable of supporting the following ADS-C applications functions as contained in (include reference to the manual on data link applications from OPLINKP:

a) demand contracts; b) periodic contracts; c) event contracts; d) emergency contracts; and e) forward contracts.

Note.— The technical provisions for the ADS application are defined in Doc 9705, Sub-volume II.

Comment: Rather than repeating (?) here what is already in an operational document, a reference to that document is sufficient. WGN06: change agreed ; but keep reference to forwarding contracts; secretary to develop text; SWGN1-10 agreed to amend into:3.5.2.1. The ATN shall be capable of supporting the ADS-C applications as

contained in Doc. 9694 SWGN1-11 agreed to remove 3.5.2.1WGN7 editorial cange as per WG N7 IP8

3.5.2.2 CONTROLLER-PILOT DATA LINK COMMUNICATIONS (CPDLC) APPLICATION

Note (1).— The CPDLC application, comprising an airborne and ground component, provides capability for data link communications between ATS units and aircraft under their control and/or aircraft about to come under their control. The CPDLC application has the capability to establish, manage, and terminate CPDLC dialogues for controller-pilot message exchange and for ground message forwarding.

Note (2). – The CPDLC application can also be supported, in addition to the standard CPDLC functions, by a protected mode for the user to verify the integrity and the correct delivery of each individual CPDLC message. (ADD-ACP-WGW-01)

3.5.2.2.1 The ATN shall be capable of supporting the following CPDLC applications functions as contained in (include reference to the manual on data link applications from OPLINKP):

23(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 a) controller-pilot message exchange; b) transfer of data authority; c) downstream clearance; and d) ground forward.

Note.— The technical provisions for the CPDLC application, including the protected mode, are defined in Doc 9705 – Manual of Technical Provisions for the Aeronautical Telecommunication Network (ATN), Sub-volume II. (MOD-ACP-WGW-01)

Comment: Rather than repeating (?) here what is already in an operational document, a reference to that document is sufficient. WGN06: change agreed; check ground forwarding as in notes ADS-C; SWGN1-10 agreed to amend into:3.5.2.1. The ATN shall be capable of supporting the CPDLC applications as contained in Doc. 9694SWGN!-11 agreed to remove 2.5.2.2

3.5.2.3 FLIGHT INFORMATION SERVICE (FIS) APPLICATIONS

Note.— FIS applications provide flight information services to airspace users from ground FIS systems.

3.5.2.3.1 AUTOMATIC TERMINAL INFORMATION SERVICE (ATIS) APPLICATION

3.5.2.3.1.1 The ATN shall be capable of supporting the following ATIS applications as contaeind in Doc. … functions:

a) aircraft-initiated FIS demand contracts; b) aircraft-initiated FIS update contracts; and c) both an aircraft- and ground-initiated FIS cancellation of contracts.

Note.— The technical provisions for the ATIS application are defined in Doc 9705, Sub-volume II.

Comment: See comments aboveWGN06: change agreed; SWGN1-10 agreed to amend into:3.5.2.1. The ATN shall be capable of supporting the ATIS applications as contained in Doc. 9694SWGN1!-11 agreed to delete 3.5.2.3 and 3.5.2.3.1

3.5.2.3.2 AVIATION ROUTINE WEATHER REPORT SERVICE (METAR) APPLICATION

3.5.2.3.2.1 The ATN shall be capable of supporting the METAR applications function for aircraft-initiated FIS demand contracts.

Note.— The technical provisions for the METAR application are defined in Doc 9705, Sub-volume II.

3.5.2.3.3 OTHER FIS APPLICATIONS(to be developed)

3.5.2.4 OTHER AIR-GROUND APPLICATIONS(to be developed)

Comment: Editorial; definition/abbreviation for METAR needs to be checked. WGN06: same as for ADS-C; SWGN1-10 agreed to amend into:3.5.2.3.2 VOLMET (meteorological information for aircraft in flight)

24(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 3.5.2.3.2.1. The ATN shall be capable of supporting data-link VOLMET (D-VOLMET) applications for aircraft initiated contracts (Re. Annex 3)Note Secretary: Alternatively, section 3.5.2 could read:3.5.2 Air-ground applications3.5.2.1 The ATN shall be capable of supporting

- ADS-C applications as contained in Doc 9694- CPDLC applications as contained in Doc. 9694- ATIS applications as contained in Doc. 9694- VOLMET applications through data-link VOLMET (Re. Annex 3)

SWGN1-11 agreed with the deletion of 3.5.2.3.2 and restructure 3.5.2 as above.

3.5.3 Ground-ground applications

Note.— Ground-ground applications are defined as those ATN applications resident in ground-based systems which solely exchange information with peer applications also resident in ground-based systems.

Comment: The note is not necessaryWGN06: deletion agreed; SWGN1-10 agreed to delete

3.5.3.1 INTER-CENTRE COMMUNICATIONS (ICC)-

Note.— The inter-centre communications applications set enables the exchange of information between air traffic service units.

Comment: Is the paragraph inter-centre communications necessary? There are only two sub-sets under ICC, i.e. AIDC and AMHS. WGN06: deletion of note agreed; SWGN1-10 agreed to deleteSWG N1-11 agreed to delete 3.5.3.1

3.5.3.1.1 ATS INTERFACILITY DATA COMMUNICATION (AIDC)

Note.— AIDC is an ATN application that is used by two air traffic service units to enable the exchange of ATS information for active flights related to flight notification, flight coordination, transfer of control, surveillance data and free (i.e. unstructured) text data.

3.5.3.1.1.1 The ATN shall be capable of supporting the following AIDC applications functions as contained in Doc. [9694xxx] :

a) flight notification; b) flight coordination; c) transfer of control; d) transfer of communications; e) transfer of surveillance data; and f) transfer of general data.

Note.— The technical provisions for the AIDC application are defined in Doc 9705, Sub-volume III.

Comment: See 3.4.42WGN06: change agreed; see Doc. 9694; SWGN1-10 agreed to change into3.5.3.1.1.1. The ATN shall be capable of supporting AIDC applications as contained in Doc. 9694

3.5.3.2 ATS MESSAGE HANDLING SERVICES (ATSMHS) APPLICATION

25(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 Note.— The ATS message handling service (ATSMHS) application enables ATS messages to be exchanged between service users through the provision of generic message services. The ATSMHS application includes the definition of AFTN/ATN and CIDIN/ATN gateways. (MOD-ACP-WGW-01)

3.5.3.2.1 The ATN shall be capable of supporting the ATS message handling service application (ATSMHS). (MOD-ACP-WGW-01)

Note.— The technical provisions for the ATSMHS application are defined in Doc 9705, Sub-volume III.

3.5.3.3 OTHER GROUND-GROUND APPLICATIONS(to be developed)

WGN06: Proposed changes agreed; SWGN1-10 agreed

Alternatively, this section could read:3.5.3. Ground-ground applications3.5.3.1 AIDC applications as contained in Doc. 9694

ATSMHSSWGN1-11 agreed with the deletion of 3.5.3.2 and restructuring of 3.5.3 as above

3.6 ATN COMMUNICATION SERVICE REQUIREMENTS

Note 1.— The ATN communication service requirements define the requirements for layers 3 through 6, as well as part of layer 7, of the OSI reference model. These services take information produced by one of the individual ATN applications and perform the end-to-end communication service using standard protocols. These communication service requirements are divided into two parts. The upper layer communications service defines the standards for layers 5 through 7. The Internet communications service defines standards for layers 3 and 4. The requirements for layers 1 and 2 are outside the scope of ATN SARPs.

Note 2.— There are two environments in ATN applications may operate. ATN applications may operate over the Internet Protocol Suite as a direct (i.e., native) application or through a convergence function. ATN applications may also make use of the OSI ULCS which is based on the OSI upper layer communications model.

Comment: Inserted at WGN-06; SWGN1-10 agreed to delete Note 1 and keep note 2 SWGN1-11 modicifation note 2 agreed WG N7 0 Note 2 deleted; see WGN7 IP 9

3.6.1 Upper layer communications service

3.6.1.1 The upper layer communications service shall include the:

a) session layer; b) presentation layer; c) application entity structure; d) association control service element (ACSE); e) security application service object (ASO), for ATN systems supporting security services; and f) control function (CF).

26(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 Note 1.— The technical provisions for the upper layer communications service for all ATN applications, except the ATS message service function of the ATSMHS application, are defined in Doc 9705, Sub-volume IV.

Note 2.— The technical provisions for the upper layer communications service for the ATS message service function of the ATSMHS application are defined in Doc 9705, Sub-volume III.

Comment: There are no standards involved in this paragraph. Also, this paragraph is [most likely] not compatible with the development of IPS SARPs and guidance materialWGN 06: deletion agreed; SWGN1-10: no specific comments (this paragraph was inadvertently inserted in the proposals for SWGN1-10)

3.6.1 ATN IPS Upper layer communications service

3.6.1.1 An ATN host shall be capable of supporting tThe ATN IPS upper layers including communications service shall have a null session, presentation, and application layer.

Comment: Inserted at WGN-6 to replace the original paragraph 3.6.1; SWGN1-10: no change; agreed further consideration required

3.6.2 ATN OSI Upper Layer Communications Service

3.6.2.1 An ATN/OSI end system (ES) shall be capable of supporting the OSI upper layer communications service (ULCS) including session, presentation and application layers.

Note: the detailed technical specifications for OSI ULCS are defined in Doc 9705.

Comment: Inserted at WGN-7- See WG N7 – IP9/

3.6.23 ATN IPS Internet Communications Service

Note.— The ATN IPS Internet communications service requirements are applicable to the Hosts andRouters, which together provide an IPS-based internet communications service. The ATN IPS Internet communications service is provided to its user (i.e. the application) directly via the transport layer service interface or via a convergence function.

3.6.23.1 An ATN Host shall be capable of supporting the ATN IPS Internet including the:

a) transport layer in accordance with RFC 793 (TCP) and RFC 768 (UDP); andb) network layer in accordance with RFC 2460 (IPv6).

3.6.23.2 An ATN IPS Router shall support the ATN network layer in accordance with RFC 2460 (IPv6) and RFC 2545 (BGP)

Comment: Inserted at WGN-6; SWGN1-10: note deleted; renumbered from 3.6.3 to 3.6.2 further consideration required with regard to the requirement (as stated) or the need to require only “ the capabilityto support” SSWGN1-11: capability to support ok.

3.6.23 ATN OSI Internet communications service

27(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 Note.— The ATN Internet communications service requirements are applicable to the end system andintermediate system functional entities which together provide the ATN Internet communications service. The ATN Internet communications service is provided to its user (i.e. the upper layers) via the transport layer service interface.

3.6.2.1 An ATN end system (ES) shall be capable of supporting the ATN Internet including the:

a) transport layer in accordance with ISO/IEC 8073 (TP4) and ISO/IEC xxxc (CTLP); and

b) network layer in accordance with ISO/IEC 8473 (CLNP).

3.6.2.2 An ATN intermediate system (IS) shall support the ATN network layer in accordance with ISO/IEC 8473 (CLNP) and ISO/IEC 10747 (IDRP). provisions as appropriate to the class of ATN IS under consideration.

Note.— A number of different classes of ATN intermediate systems for which network layer profiles are defined are contained in Doc 9705, Sub-volume V.

Comment: Inserted at WGN-6; SWGN1-10: note deleted; further consideration required with regard to the requirement (as stated) or the need to require only “ the capabilityto support” SWGN1-11 Capability to support ok.

3.7 ATN NAMING AND ADDRESSING REQUIREMENTS

Note.— The ATN naming and addressing scheme supports the principles of unambiguous identification of intermediate systems [routers] and end systems [hosts] information objects and provides global address standardization.

3.4.11 The ATN shall provide means to unambiguously address all ATN end systems (hosts) and intermediate systems (routers).

3.4.13 The ATN addressing and naming plans shall allow States and organizations to assign addresses and names within their own administrative domains.

3.7.1 The ATN shall provide provisions for unambiguous application identification entity naming.

3.7.2 The ATN shall provide provisions for unambiguous network and transport addressing.

Note.— The technical provisions for ATN application entity naming are defined in Doc 9705, Sub-volume IV, the provisions for network and transport addressing are defined in Sub-volume V, and the provisions for registration services are defined in Sub-volume IX of the same document.

Comment: To provide for clear language on the naming and addressing requirementsWGN06: changes agreed

3.8 ATN SYSTEMS MANAGEMENT REQUIREMENTS.

28(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 Note 1.— The ATN systems management (SM) application provides the capability

for an SM manager to exchange information with an SM agent and/or another SM manager.

Note 2.— Support for the ATN SM services technical provisions may be required on a State or regional basis.

3.8.1 The ATN shall be capable of supporting the following systems management application functions:

a) fault management; b) configuration management; c) accounting management; d) performance management; and e) security management.

Note.— The technical provisions for ATN Systems Management are defined in Doc 9705, Sub-volume VI.

3.8.1.1 ATN end systems and intermediate systems that support the ATN systems management application and SM managers shall support access to managed objects.

Note.— The SM application managed object definitions and access provisions are defined in Doc 9705, Sub-volume VI.

Comment: systems management is not a requirement requiring international standards. WGN06: consider inclusion of a recommendation on systems management SWGN1-10: make use of 3.4.33 in order to develop a Recommendation further consideration required

3.9 ATN SECURITY REQUIREMENTS further consideration required

3.4.4 The ATN shall make provisions whereby only the controlling ATS unit may provide ATC instructions to aircraft operating in its airspace.

Note.— This is achieved through the current and next data authority aspects of the controller-pilot data link communications (CPDLC) application entity.

3.4.12 The ATN shall enable the recipient of a message to identify the originator of that message.

3.4.29 ATN end systems supporting ATN security services shall be capable of authenticating the identity of peerend systems, authenticating the source of messages and ensuring the data integrity of the messages.

3.9.1 The security of the ATN shall be achieved based on a combination of technical provisions, local physical security measures, and procedural security measures.

29(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 Note 1.— The technical provisions for ATN security are defined in Doc 9705, and the physical and procedural security measures are defined in Annex 17 and the Security Manual.

Note 2.— Support for the ATN security services technical provisions may be required on a State or regional basis.

Comment: 3.9.1 is not a standard, since it provides no specification. Note 2 is not to be applied.WGN06: agreed; further incorporation of security material in annex 10 needs to be reviewed by SWGN4 and SWGN1, maybe keep note 1. SWGN1-10 and SWGN4-9: no action

3.9.1.1 Recommendation.— The following physical and procedural techniques should be used to provide security for ATN end systems, intermediate systems, network managers, directory servers and subnetworks: a) restricted physical access to ATN end systems, intermediate systems, SM workstations, directoryservers and subnetwork switches, network managers, and other essential network sub-systems; b) restricted user access to ATN end systems, intermediate systems, directory servers and SM workstations to only authorized personnel; and c) non-use, or restricted use, of remote access to ATN ground end system, intermediate systems and SMworkstations.

Comment: Are there no specific standards available for ATN/OSI security provisions (as there are for ATN/IPS)?WGN06: delete 3.9.1.1 SWGN1-10 and SWGN4-9: no action

3.9.2 ATN security policy

Note.— Communication monitoring and third party traffic analysis do not constitute safety hazards and are notconsidered security threats for the ATSC. However, some ATS and/or non-ATS users and applications may have local, or organizational, policies wherein communication monitoring and third party traffic analysis would be considered security threats based on other concerns, such as economic considerations.

Comment: At least a functional security policy should be specified hereWGN06: deletion of note agreed SWGN1-10 and SWGN4-9: no action

3.9.2.1 ATS messages shall be protected from masquerade, modification and replay.

Note 1. — This means that for data messages exchanged among ATN entities there will be a high level of assurance that a message comes from where it claims, has not been tampered with, and is not a repeat of an obsolete message.

Note 2. — The level of protection may vary by the type of security threat and by the level of ATN security serviceselected by the user or application process.

Comment: WGN06: delete 3.9.2.1; SWGN1-10 and SWGN4-9: no action SWGN1-12 deleted

3.9.2.2 A request for protection of ATS messages shall be honoured.

30(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79 Comment: Should all ATN messages not be protected? WGN06: delete 3.9.2.2; SWGN1-10 and SWGN4-9: no action SWGN1-12 The reason and scope of thie requirement is not clear

Note.— A request for non-use of protection may be honoured. This means that the use of security is the defaultand negotiation to non-use is based on local policy.

Comment: This provision should be a recommendation or be removed. Removal is proposed, since the provision is confusing. WGN06: deletion agreed; SWGN1-10 and SWGN4-9: no action

3.9.2.3 The ATN services that support messages to and from the aircraft shall be protected against denial of service attacks to a level of probability consistent with the required application service requirements. availability as determined by local or regional policies.

Note 1.— The term “denial of service” describes a condition where legitimate access to information or other ATN resources is deliberately impeded.dseeeeeeeeeeeeee`

Note 2.— This may mean having alternative communications paths available in case one path is subject to denial of service.

Comment: Further review of this Chapter on security , in particular relating to the need to incorporate more ATN/IPS material, as is currently being developed by SWGN1, will take place at the next meeting of SWGN1 and SWGN4 SWGN1-12 Amended as shown

31(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79

32(35)

Note 1.— When an ATSC class is specified by an ATN application, packets will be forwarded in the ATN internetcommunications service on a best effort basis. Best effort basis means that when a route is available of the requested ATSC class, the packet is forwarded on that route. When no such route is available, the packet will be forwarded on the first known route of the ATSC class higher than that requested, or if there is no such route, first known route of the ATSC class lower than that requested.

Note 2.— The ATN communications service will not inform application entities if the requested ATSC class was not achieved. It is the responsibility of the application entity to determine the actual transit delay achieved by local means such as time stamping.DELETE TABLE

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79

further consideration required

33(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79

further consideration required

34(35)

ATN-SARPS V3. 3 2 doc WGN-7 WP1822 January 2007

ANNEX 10, VOLUME III, PART 1 AMDT 79

35(35)

SWGN 1-10: Figure to be revised to cover both IPS and OSI. Proposals are invited. In principle, the figure can be deleted