32000R2082

COMMISSION REGULATION (EC) No 2082/2000

of 6 September 2000

adopting Eurocontrol standards and amending Directive 97/15/EC, adopting Eurocontrol standards and amending Council Directive 93/65/EEC

THE COMMISSION OF THE EUROPEAN COMMUNITIES,

Having regard to the Treaty establishing the European Community,

Having regard to Council Directive 93/65/EEC of 19 July 1993 on the definition and use of compatible technical specifications for the procurement of air traffic management equipment and systems(1) and in particular Article 3 thereof,

Having regard to Commission Directive 97/15/EC of 25 March 1997 adopting Eurocontrol standards and amending Council directive 93/65/EEC on the definition and use of compatible technical specifications for the procurement of air traffic management equipment and systems(2),

Whereas:

(1) Directive 97/15/EC adopted the Eurocontrol standard for On-Line Data Interchange (OLDI), edition 1.0 and the Eurocontrol standard for Air Traffic Services Data Exchange Presentation (ADEXP), edition 1.0.

(2) Eurocontrol adopted more recent versions of the two standards mentioned above, i.e. OLDI edition 2.2 and ADEXP edition 2.0 and also a new Eurocontrol standard named Flight Data Exchange - Interface Control Document (FDE-ICD).

(3) These Eurocontrol standards fall within the scope of Directive 93/65/EEC and contribute to the harmonisation of Member States' air traffic management national systems, particularly concerning the transfer of flights between air traffic control centres (OLDI), the air traffic flow management (ADEXP) and the communications between national systems (FDE-ICD).

(4) Editions 2.2 of OLDI and 2.0 of ADEXP supersede previous editions presently in force according to the provisions of Article I of Directive 97/15/EC and therefore that Article has to be repealed.

(5) The provisions of this Regulation are in accordance with the opinion of the Committee established in accordance with Directive 93/65/EEC,

HAS ADOPTED THIS REGULATION:

Article 1

In as much as they are necessary for the implementation of an integrated European air traffic management system, the mandatory elements of Eurocontrol specifications included in the following Eurocontrol standards documents are adopted in the framework of Directive 93/65/EEC:

- the Eurocontrol standard for On-Line Data Interchange (OLDI), edition 2.2 (Eurocontrol document reference DPS.ET1.ST06-STD), the text of which is included in Annex I to the present Regulation,

- the Eurocontrol standard for Air Traffic Services Data Exchange Presentation (ADEXP), edition 2.0 (Eurocontrol document reference DPS.ET1.ST09-STD), the text of which is included in Annex II to the present Regulation,

- the Eurocontrol standard for Flight Data Exchange - Interface Control Document (FDE-ICD), edition 1.0 (Eurocontrol document reference COM.ET1.ST12-STD), the text of which is included in Annex III to the present Regulation.

Article 2

Article I of Directive 97/15/EC is hereby repealed.

Article 3

The present Regulation shall enter into force on the third day following its publication in the Official Journal of the European Communities.

The present Regulation shall be binding in its entirety and directly applicable in all Member States.

Done at Brussels, 6 September 2000.

For the Commission

Loyola De Palacio

Vice-President

(1) OJ L 187, 29.7.1993, p. 52.

(2) OJ L 95, 10.4.1997, p. 16.

ANNEX I

ON-LINE DATA INTERCHANGE (OLDI) EDITION 2.2

(Eurocontrol document reference DPS.ET1.ST06-STD)

TABLE OF CONTENTS

>TABLE>

COPYRIGHT NOTICE

This document has been produced by the Eurocontrol Agency.

Copyright is vested with the Eurocontrol Agency.

The content or any part thereof is thus freely available to Member States' representatives, but copy or disclosure to any other party is subject to prior consent in writing by the Eurocontrol Agency.

FOREWORD

1. Responsible Body

The Eurocontrol Standard for On-Line Data Interchange (OLDI), Edition 2.2 has been prepared by the Directorate of European ATC Harmonisation and Integration Programme (EATCHIP) Development (DED), Eurocontrol, which is also responsible for the updating of the document. All comments or enquiries should be addressed to Director General, Eurocontrol, Rue de la Fusée, 96, B-1130 Bruxelles, for the attention of Division DED-2.

2. Relation to the EATCHIP Work Programme Document

This Standard constitutes a deliverable under Specialist Task DPS.ET1.ST06 of the ATM Data Processing Systems (DPS) domain of EATCHIP as specified in EATCHIP Work Programme Document (EWPD) Edition 2.0, dated 30/09/94.

3. Approval and Amendments

This Standard has been subject to the following approval procedure as detailed in the Directives for Eurocontrol Standardisation:

- Approval by the EATCHIP Operational Requirement and ATM Data Processing Team (ODT) by correspondence procedure;

- Consultation of all ECAC States through their representatives in the Committee of Management or EATCHIP Project Board;

- Approval by the EATCHIP Project Board and the Committee of Management;

- Adoption by the Permanent Commission.

The provisions of this Standard are effective following adoption by the Permanent Commission.

In order to meet the requirements of the evolution of Air Traffic Control (ATC) procedures, amendments and additions may be proposed through the ODT for discussion and possible approval. The requirements will be incorporated either as an amendment or as a further edition of the document for endorsement and approval in accordance with specified procedures.

4. Editorial Practices

The following practice has been adhered to in order to indicate the status of each statement: Normative Elements have been printed in light face text; Recommended Elements have been printed in light face italics, the status being indicated by the prefix Recommendation.

The following editorial practice has been followed in the writing of the specifications: for Normative Elements the operative verb "shall" is used, and for Recommended Elements the operative verb "should" is used.

Notes are printed in light face italics preceded by the prefix "NOTE".

5. Relationship to Edition 1 of the Eurocontrol Standard for On Line Data Interchange

This document supersedes Parts 1 and 2 of Edition 1 of the Eurocontrol Standard for On Line Data Interchange. Part 3, which describes the technical protocols to be used is superseded by the Eurocontrol Standard for Flight Data Exchange - Interface Control Document Part 1.

6. Significant Changes from Edition 1

The following are the most significant changes and additions from Edition 1:

1. Incorporation of the following complementary (non-mandatory) messages in respect of the basic procedure:

- Message for the Abrogation of Co-ordination (MAC);

- Secondary Surveillance Radar (SSR) Code Assignment (COD) Message;

- Information (INF) Message.

2. Definition of message content and format to support the crossing of a boundary by a flight on a track which is not a defined Air Traffic Services (ATS) route, but which is defined by the begin and end points of the route segment.

3. Incorporation of a dialogue procedure which allows:

- the identification and negotiation of non-standard transfer conditions by controllers performing the planning function;

- the provision of the capability for the accepting unit to counter-propose transfer conditions;

- the provision of transfer of communication facilities as part of the transfer of control procedure.

4. The use of the format described in Edition 2 of the Eurocontrol Standard Document for ATS Data Exchange Presentation (ADEXP) is introduced. All messages specified under the basic procedure and those used during the co-ordination phase of the dialogue procedure are described using both International Civil Aviation Organisation (ICAO) and ADEXP formats. Transfer of Communication messages described under the dialogue procedure are described utilising ADEXP format only.

5. Deletion of the following Annexes to Edition 1:

A: ATC Unit Identification.

B: OLDI Message Structure

(all messages in Edition 3 include examples).

D: Historical Overview.

E: Implementation Plan.

F: Compliance by States.

G: Guidelines for Implementation.

H: Guidelines for Evaluation of OLDI.

6. Separation of Part 3 - Technical Requirements - from the applications specification.

7. Relationship to Other Documents

This document makes reference to the use of two types of field format in the compilation of messages; these are ICAO and ADEXP.

ICAO field formats are described in Reference 1. In the event that Reference 1 is superseded by another document, the definition of ICAO field types shall be as described in that document.

Formats for ADEXP fields are described in Reference 2.

NOTE

Referenced documents are listed at Section 2.

8. Language

The English language has been used in preparing the original of this document.

1. INTRODUCTION

1.1. Purpose

1.1.1. Flights which are being provided with an ATC service are transferred from one ATC unit to the next in a manner designed to ensure complete safety. In order to accomplish this objective, it is a standard procedure that the passage of each flight across the boundary of the areas of responsibility of the two units is co-ordinated between them beforehand and that the control of the flight is transferred when it is at, or adjacent to, the said boundary.

1.1.2. Where it is carried out by telephone, the passing of data on individual flights as part of the co-ordination process is a major support task at ATC units, particularly at Area Control Centres (ACC)s. The operational use of connections between Flight Data Processing Systems (FDPS)s at ACCs for the purpose of replacing such verbal "estimates", referred to as On-Line Data Interchange (OLDI), began within Europe in the early nineteen eighties.

1.1.3. In order to facilitate implementation, common rules and message formats were elaborated and agreed by the agencies concerned and incorporated in Edition 1 of the Eurocontrol Standard for On-Line Data Interchange; this document, Edition, has been produced to support the continuing development of such facilities in compliance with the requirements of EATCHIP.

1.2. Scope

1.2.1. This document specifies the facilities and messages to be provided between FDPSs serving ATC units for the purpose of achieving:

- the co-ordination required prior to the transfer of flights from one unit to the next;

- the transfer of communication of such flights.

1.2.2. This document:

- defines the message formats and rules for the content;

- describes the facilities required at such units which are prerequisite to the use of data interchange for this purpose.

1.2.3. This Standard is applicable between the Member States of Eurocontrol to international OLDI facilities between units providing an area ATC service.

1.2.4. Recommendation

It is recommended that European Civil Aviation Conference (ECAC) States should apply this Standard to:

- international OLDI facilities between units providing an area ATC service within the ECAC area;

- OLDI facilities between units providing an area ATC service which are internal to the State concerned.

2. REFERENCES

2.1. The following Documents contain provisions which, through reference in this text, constitute provisions of this Eurocontrol Standard Document.

At the time of publication of this Eurocontrol Standard Document, the editions indicated for the referenced documents were valid.

Any revision of the referenced ICAO Documents shall be immediately taken into account to revise this Eurocontrol Standard Document.

Revisions of the other referenced documents shall not form part of the provisions of this Eurocontrol Standard Document until they are formally reviewed and incorporated into this Eurocontrol Standard Document.

In the case of conflict between the requirements of this Eurocontrol Standard Document and the contents of these other referenced documents, this Eurocontrol Standard Document shall take precedence.

2.2. The following documents are referenced in this Standard Document:

1. Procedures for Air Navigation Services - Rules of the Air & Air Traffic Services, ICAO Document 4444, Thirteenth Edition dated 7 Nov. 1996, as amended.

2. Edition 2.0 of the Eurocontrol Standard Document for ATS Data Exchange Presentation (ADEXP), reference DPS-ET1-ST09-STD-01-00, dated June 1998.

3. DEFINITIONS, SYMBOLS AND ABBREVIATIONS

3.1. Definitions

For the purposes of this Eurocontrol Standard, the following definitions shall apply.

3.1.1. Accepting Unit: The unit providing an ATC service that is to take control or has taken control of a flight when the transfer from one unit to the next is to or has taken place.

3.1.2. Acknowledgement: Notification that a message has been received and found to be correctly processable.

3.1.3. Activation: The process in a receiving ATC unit whereby the flight plan for the referent flight is upgraded to include the data provided by the transferring unit as part of the co-ordination process between the two units and which results in the provision of the data to controllers.

3.1.4. Altitude: The vertical distance of a level, a point or an object considered as a point, measured from mean sea level.

3.1.5. Application: That part of an ATS sub-system that conforms to this standard and interfaces with such entities in other ATS systems.

3.1.6. Area of Responsibility: An airspace of defined dimensions within which an ATC unit provides air traffic services.

3.1.7. Association: A procedure in which a system connects a received OLDI message with a flight plan entry in the database.

3.1.8. ATC Unit: A unit providing an air traffic control service.

3.1.9. Availability: A probability that a facility will be accessible by a user at a time.

3.1.10. Boundary: The planes (lateral and vertical) delineating the area of responsibility of an ATC unit.

3.1.11. Cleared Flight Level: The flight level to or at which a flight has currently been cleared by ATC.

3.1.12. Co-ordination, ATC: The process, executed between ATC units with adjoining areas of responsibility, of formally advising each other of the planned passage of flights across the boundary, in order to ensure flight safety through consistency of intended actions.

3.1.13. Co-ordination Message: A generic term referring to a message used for accomplishing ATC co-ordination. These include the CDN which is a specific message described in paragraph 8.8.

3.1.14. Co-ordination Phase: In respect of a given flight, the phase during which the transferring and receiving ATC units agree the conditions (e.g. flight level, boundary point) under which a flight will pass from the control of one to the other.

3.1.15. Co-ordination Point: A point on or adjacent to the boundary known by the ATC units in a co-ordination sequence and referred to in co-ordination messages.

3.1.16. Correlation: The process based on defined criteria of linking flight plan data and the radar track of the same flight, normally for presentation on a controller display.

3.1.17. Eurocontrol Standard: Any specifications for physical characteristics, configuration, material, performance, personnel or procedure, the uniform application of which has been approved as essential for implementation in ATS systems within Eurocontrol Member States. A Eurocontrol Standard must not be in conflict with ICAO Standards, but, where appropriate, should complement the latter.

3.1.18. Executive Controller: A controller who provides instructions directly to flights under his/her control. Such controllers include those providing area radar control service.

3.1.19. Exit Level: The level at which a flight has been co-ordinated to cross a transfer of control point. An exit level may include supplementary crossing conditions which define the level band within which a climbing/descending flight will be.

3.1.20. Flight Plan: Specified information provided to air traffic service units, relative to an intended flight or portion of flight of an aircraft. In addition, information derived from the flight plan of a specific flight held within an FDPS.

3.1.21. Generate: A process in an ATC system where relevant data are extracted from the data base(s) and a message is created for transmission to a receiving ATC unit.

3.1.22. ICAO Format: The format utilised for the ground - ground transmission of ATS messages and which uses the field types and separators described in Reference 1.

3.1.23. Level: A generic term relating to vertical position of an aircraft in flight; within this Standard the term level or flight level includes altitude in those cases where it is used.

3.1.24. Notification: The process whereby the transferring unit transmits data to update the system at the receiving unit in preparation for the co-ordination phase.

3.1.25. Receiving Unit: The ATC unit to which a message is sent.

3.1.26. Reliability: The percentage of the scheduled availability during which the service is to be operable.

3.1.27. Requested Flight Level: A flight level requested by the flight in the flight plan.

3.1.28. Revision: An amendment to data sent previously by the transferring ATC unit to the receiving ATC unit.

3.1.29. Supplementary Crossing Level: A level, at or above which, or at or below which a flight has been co-ordinated to cross the transfer of control point. The supplementary level, if present, is an element of the exit level.

3.1.30. System Flight Plan: Information derived from the flight plan of a specific flight held within an FDPS.

3.1.31. Transaction Time: A time interval following the initiation of a message during which transmission, initial processing in the receiving system, generation and transmission of an acknowledgement message, and its identification in the transferring system are performed.

3.1.32. Transfer of Control Point: A defined point, located along a flight path of an aircraft, at which the responsibility for providing ATS to the aircraft is transferred from one ATC unit or control position to the next. It is not necessarily coincident with the co-ordination point.

3.1.33. Transfer Phase: A phase of flight following the co-ordination phase, during which the transfer of communication is executed.

3.1.34. Transferring Unit: In a co-ordination sequence, the ATC unit responsible for providing a service to a flight before the boundary and which initiates the co-ordination phase with the next unit.

3.1.35. Transmit: Communicate a message from one system to another.

3.1.36. Unit: Air traffic service unit

3.1.37. Warning: A message displayed at a working position when the automated co-ordination process has failed.

3.2. Symbols and Abbreviations

For the purposes of this Eurocontrol Standard, the following symbols and abbreviations shall apply.

ABI Advance Boundary Information Message

ACC Area Control Centre

ACP Accept Message

ACT Activate Message

ADEXP ATS Data Exchange Presentation

ATC Air Traffic Control

ATM Air Traffic Management

ATS Air Traffic Service

CDN Co-ordination Message

CNL Flight Plan Cancellation

COD SSR Code Assignment Message

COF Change of Frequency Message

COP Co-ordination Point

DED Directorate of EATCHIP Development, Eurocontrol

EATCHIP European ATC Harmonisation and Integration Programme

ECAC European Civil Aviation Conference

ETO Estimated Time Over

ETOT Estimated Take-Off Time

EWPD EATCHIP Work Programme Document

FDPS Flight Data Processing System

FRF Further Route of Flight

HMI Human-Machine Interface

HOP Handover Proposal Message

ICAO International Civil Aviation Organisation

INF Information Message

LAM Logical Acknowledgement Message

LoA Letter of Agreement

MAC Message for the Abrogation of Co-ordination

MAS Manual Assumption of Communications

NM Nautical Mile

OLDI On-Line Data Interchange

ORCAM Originating Region Code Assignment Method

PAC Preliminary Activate Message

RAP Referred Activate Proposal Message

REV Revision Message

RJC Reject Co-ordination Message

ROF Request on Frequency Message

RRV Referred Revision Message

SBY Stand-by Message

SDM Supplementary Data Message

SSR Secondary Surveillance Radar

SYSCO System Supported Co-ordination

TI Transfer Initiation

TIM Transfer Initiation Message

TWR/APP Tower (aerodrome control) and Approach Control

4. GENERAL REQUIREMENTS

4.1. Introduction

This section describes the general operational requirements necessary for the implementation of an OLDI facility between ATC units and the classification and performance requirements of the different types of message used.

4.2. Flight Data Processing System Requirements

4.2.1. Flight Data Base

Units which utilise a facility described in this document shall be provided with data from an FDPS which contains all the information required for the display, processing and compilation of the messages as specified. The primary source of data for each flight is the flight plan as filed by, or on behalf of, the pilot in command. Further items of data are obtained by the processing of flight plans with reference to the environment of the unit concerned.

4.2.2. Operation in Real Time

The OLDI procedure includes events in the transferring ATC unit to initiate functions necessary for the timely presentation of data to the transferring controller and the transmission of co-ordination data to the accepting unit. For this purpose the FDPS shall be able to initiate functions by the comparison of Co-ordinated Universal Time and applicable time parameters with times at specified positions on the route of flight as determined from the flight database.

4.2.3. Data Communications Capability

4.2.3.1. The FDPS shall be able to receive and transmit flight data in the format applicable to the message as specified in this document via a data communication medium which supports the OLDI function.

4.2.3.2. Recommendation

The FDPS should have the development potential to allow the addition of new messages that may be included in future editions of this standard.

4.2.3.3. Within the performance requirements specified in this document, the data communication medium shall provide a rapid and reliable application-to-application data exchange by:

- assuring the integrity of OLDI message transmission;

and

- monitoring either point-to-point connections or the status of the communications network, as applicable.

4.2.3.4. The FDPS shall warn the working positions when anomalies are detected by the data communications system.

4.2.4. Application Functions

4.2.4.1. The systems used for the provision of OLDI facilities shall be able to automatically receive, store, process, extract and deliver for display, and transmit OLDI related data in real-time.

4.2.4.2. The FDPS shall:

- reflect current operational data relevant to the OLDI function as required by this Standard, updated either automatically, through manual input, or by a combination of both;

- be able to extract such elements from the flight plan database;

- identify the next ATC unit on the route of flight.

4.2.4.3. The following shall be agreed bilaterally:

- Co-ordination Points (COPs);

- Reference points used for bearing and distance notations in identifying the COP on direct, off-ATS route segments, where used.

NOTE

The COPs may not always be identical to the transfer of control points.

4.2.5. Human-Machine Interface (HMI)

4.2.5.1. The HMI shall be able to:

- display the operational contents of OLDI messages and relevant warnings related to received messages for immediate attention;

- route co-ordination and transfer message warnings to the operational positions responsible for the co-ordination of the flights concerned.

4.2.5.2. ATC staff shall be provided with a means to modify the data from which the operational contents of the messages are derived as required in this document.

4.2.5.3. The HMI shall indicate that the transmission of the message is in progress or has been successfully transmitted as appropriate.

4.2.5.4. A warning or notification to the appropriate ATC or technical position(s) shall be generated automatically if no acknowledgement has been received within the parameter time following a transmission of a co-ordination or transfer message.

4.2.5.5. Such a warning or notification shall be in a form that immediately attracts the attention of the appropriate working position.

4.2.5.6. Recommendation

The HMI at ATC positions using OLDI should provide a warning if the OLDI facility is not available.

4.2.6. Initiation of Messages

4.2.6.1. Each system shall contain a set of system parameters in order to ensure timely, automatic initiation of OLDI messages.

4.2.6.2. Recommendation

The capability to manually initiate the transmission of a co-ordination message prior to the calculated transmission time should be provided.

4.2.6.3. The automatic event shall always be assured, if manual initiation is not executed.

4.2.6.4. The system shall utilise time parameters to define the following:

- lead time, prior to transmission, when the operational contents of the messages within the transferring unit are displayed;

- lead time, global or per COP, to transmit the message, where applicable;

- time after transmission of a message within which an application level acknowledgement is to be received (time-out).

4.2.6.5. A message shall be transmitted without delay when the required information becomes available at a time later than that at which it would otherwise have been transmitted.

Example:

A flight commences a GAT IFR segment at a point close to the boundary which it is then to cross; the ETO at the point is communicated eight minutes before the COP at which time transmission of the ACT message is already late based on the applicable time parameter(s); the message is sent without delay.

4.2.7. Reception of Messages

4.2.7.1. The ATC system shall be able to:

- receive OLDI messages;

- process them automatically in accordance with this Standard;

- output flight data in accordance with the message received, and display required warnings in case of inconsistency in the data received;

- generate and transmit acknowledgement messages automatically at the application level.

4.2.7.2. An acknowledgement message (Logical Acknowledgement (LAM), Accept (ACP) or Stand-by (SBY) Message) shall be generated and transmitted when the corresponding message has been processed and the presentation of the results of the processing to the appropriate position(s), as necessary, is assured.NOTE

The detailed conditions for the generation of an acknowledgement are specified individually for each message.

4.3. Updating from Surveillance Data

Recommendation

In order to ensure the accuracy of time estimate data, information derived from the tracking of flights by radar or other surveillance means should be used to update the flight plan database.

4.4. Recording of OLDI Data

4.4.1. Content

The contents of all OLDI messages and the time of reception shall be recorded.

4.4.2. Facilities

Facilities shall be available for the retrieval and display of the recorded data.

4.5. Availability, Reliability, Data Security and Data Integrity

4.5.1. Availability

4.5.1.1. The OLDI facility shall be available during the hours of normal and peak traffic flows between the two units concerned.

4.5.1.2. Recommendation

The OLDI facility should be available 24 hours every day.

4.5.1.3. Any scheduled down-time periods (and thus the planned availability time) shall be bilaterally agreed between the two units concerned.

4.5.2. Reliability

4.5.2.1. Reliability on every OLDI link shall be at least 99,86 % (equivalent to a down-time of not more than 12 hours per year based on 24-hour availability).

4.5.2.2. Recommendation

Where operationally justified, a reliability of at least 99,99 % (equivalent to a down-time of not more than 52 minutes per year, based on 24 Hour availability) should be provided.

4.5.3. Data Security

Recommendation

Data security methods (e.g. access rights, source verification) and, where applicable, network management should be applied to OLDI facilities.

4.5.4. Data Integrity

The failure rate at application level shall not exceed one transmission error per 2000 messages.

4.6. Operational Evaluation

4.6.1. Evaluation Period

Each new OLDI facility, including a new facility on an existing link, shall be subject to an evaluation period to verify the data integrity, accuracy, performance, compatibility with ATC procedures and overall safety prior to its operational implementation.

NOTE

A procedure to assist in the evaluation of a new OLDI facility is available from the OLDI Secretariat, Eurocontrol.

4.6.2. Operational Introduction Date

The date of the operational introduction, implying completion of the evaluation period, shall be formally agreed between the two units.

5. MESSAGE CATEGORIES

5.1. General

5.1.1. Purpose

This Section of the document:

- defines the categories of messages;

- states transaction time requirements for the categories;

- states which messages are mandatory and which are complementary;

- assigns message types to categories.

5.1.2. Message Categories

OLDI messages have been assigned to the following categories:

- Category 1: Transfer of Communication;

- Category 2: Co-ordination;

- Category 3: Notification.

5.2. Transaction Times

5.2.1. Transaction Time Conditions

5.2.1.1. The transaction times specified include transmission, initial processing at the receiving unit, creation of the acknowledgement message, its transmission and reception at the transferring unit. The automatic acknowledgement messages LAM and SBY have therefore, not been assigned to a message category.

5.2.1.2. The maximum transaction times for the different categories of messages shall be as specified in Table 5-1.

Table 5-1

Maximum Transaction Times

>TABLE>

5.2.1.3. A time-out value shall be defined per message category or type.

5.2.1.4. If no acknowledgement has been received within the specified time after transmission, a message shall be considered to have been unsuccessfully transmitted or processed and a warning output as specified in the pertinent section in this document.

5.2.1.5. Recommendation

The time-out values for the three categories should not exceed 12 seconds, 30 seconds and 60 seconds respectively.

5.3. Message Classification and Categorisation

5.3.1. Message Classification - Mandatory and Complementary

5.3.1.1. Messages described in this document are classified as either mandatory or complementary.

5.3.1.2. Where a message is described as mandatory (M) for transmission (TX), processing shall be included to be able to send such messages.

5.3.1.3. Where a message is described as mandatory for reception (REC), processing shall be included to be able to process received messages.NOTE

In exceptional cases, where the traffic flow between two units is unidirectional, the mandatory messages may be applicable in only one direction.

5.3.1.4. Where a message is described as complementary (C) for transmission, processing shall be included to be able to send such messages if required by the sending unit and bilaterally agreed with the receiving unit.NOTE

Complementary messages may be used in one direction only as determined by operational requirements.

5.3.1.5. Where a message is described as complementary for reception, processing shall be included to be able to process received messages where such use has been bilaterally agreed.

5.3.1.6. Requirements described in Tables 5-3 and 5-4 are applicable only where the use of the Dialogue procedure for Co-ordination and/or Transfer of Communication respectively have been agreed bilaterally between ATC units.

5.3.2. Categorisation of Messages

5.3.2.1. The categorisation of messages for the basic procedure is specified in Table 5-2.

5.3.2.2. The categorisation of the additional co-ordination messages for the dialogue procedure is specified in Table 5-3.

5.3.2.3. The categorisation of transfer of communication messages for the dialogue procedure is specified in Table 5-4.

Table 5-2

Basic Procedure Messages

>TABLE>

Table 5-3

Dialogue Procedure - Co-ordination Phase Messages

(Additional to Table 5-2)

>TABLE>

Table 5-4

Dialogue Procedure - Transfer Phase Messages

>TABLE>

6. BASIC PROCEDURE - MANDATORY MESSAGES

6.1. General

6.1.1. Description of Requirement

This section describes the minimum requirement at the application level for the implementation of OLDI facilities.

6.1.2. Implementation

Units using OLDI for the co-ordination of flights shall implement the ABI, ACT, and LAM as described in this section, except where it has been bilaterally agreed to use the co-ordination dialogue procedure as described in Section 8 of this document, in which case the conditions for the use of ACT and LAM messages are as defined in that section.

6.2. Advance Boundary Information Message (ABI)

6.2.1. Purpose of the ABI Message

The ABI satisfies the following operational requirements:

- provide for acquisition of missing flight plan data;

- provide advance boundary information and revisions thereto for the next ATC unit;

- update the basic flight plan data;

- facilitate early correlation of radar tracks;

- facilitate accurate short-term sector load assessment.

The ABI is a notification message.

6.2.2. Message Contents

The ABI message shall contain the following items of data:

- Message Type;

- Message Number;

- Aircraft Identification;

- SSR Mode and Code (if available);

- Departure Aerodrome;

- Estimate Data;

- Destination Aerodrome;

- Aircraft number and type;

- Route (optional);

- Other Flight Plan Data (optional).

NOTE

Data insertion rules, formats and field contents are specified at Annex A.

6.2.3. Rules of Application

6.2.3.1. General

6.2.3.1.1. Except as provided for in 6.2.3.1.3 and 6.2.3.1.4 below, one or more ABI messages shall be sent for each flight planned to cross the boundary of areas of responsibility subject to OLDI procedures.

6.2.3.1.2. When sent, the ABI message shall precede the Activate (ACT) or Referred Activate Proposal (RAP) message.

6.2.3.1.3. An ABI message shall not be generated if a Preliminary Activate (PAC) message is to be sent.

6.2.3.1.4. Recommendation

ABI transmission should be inhibited if the ACT or RAP message is due for transmission immediately or within a bilaterally agreed time interval.NOTE

The purpose of this recommendation is to avoid the attempted simultaneous resolution of anomalies at different positions at the receiving unit in respect of ABI and ACT messages for the same flight.

6.2.3.1.5. A revised ABI message shall be sent if the subsequent ACT message has not been generated and:

- the route of flight has been modified such that the COP in the previous ABI message is no longer accurate;

- the aerodrome of destination has been changed;

or

- the type of aircraft has been changed.

6.2.3.1.6. Recommendation

A revised ABI message should be sent if the subsequent ACT message has not been generated and one of the following items is subject to change:

- The expected boundary crossing level;

- The expected SSR code at the transfer of control point;

- When the estimated time over (ETO) at the COP differs from the previous ABI message more than the time specified in the Letter of Agreement (LoA);

- Any other data as bilaterally agreed.

6.2.3.2. Processing in the Receiving Unit

6.2.3.2.1. The ATC system receiving an ABI message shall attempt association with the corresponding flight plan data.

6.2.3.2.2. If the flight plan association is unsuccessful, a flight plan shall be created automatically or manually in the receiving system.

6.2.3.2.3. If the flight plan association is successful but a discrepancy is identified between the data in the message and corresponding data in the receiving system that would result in the need for corrective action on receipt of the following ACT message, the discrepancy shall be referred to an appropriate position for resolution.

6.2.3.3. Time Parameters for Transmission

6.2.3.3.1. The message shall be transmitted a parameter number of minutes before the estimated time at the COP.

6.2.3.3.2. The ABI generation parameter(s) shall be included in the LoA between the ATC units concerned.

6.2.3.3.3. Recommendation

The ABI generation parameter(s) should be:

- variable, based on the provisions of the LoA;

- defined separately for each of the COPs.

6.2.4. Acknowledgement of ABI

6.2.4.1. Acknowledgement

The ABI message shall be acknowledged by generating and transmitting a LAM message.

NOTE

A LAM message is generated regardless of the results of the flight plan association attempt.

6.2.4.2. No Acknowledgement

Recommendation

If no LAM message is received as an acknowledgement for an ABI message, a warning should be displayed at a supervisory position.

6.2.5. Examples

"Air 2000" 253, a Boeing 757 from Malta to Birmingham estimating BNE VOR at 1221 UTC, flying at FL350 at a true airspeed of 480 knots, planned to route via UB4 BNE UB4 BPK UB3 HON, transponding on A7012 and requesting FL390. The following are equivalent examples of the ABI message sent from Reims to London ACC.

6.2.5.1. ICAO

(ABIE/L001-AMM253/A7012-LMML-BNE/1221F350-EGBB-9/B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON)

6.2.5.2. ADEXP

-TITLE ABI -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 001 -ARCID AMM253 -SSRCODE A7012 -ADEP LMML -COORDATA -PTID BNE -TO 1221 -TFL F350 -ADES EGBB -ARCTYP B757 -ROUTE N0480F390 UB4 BNE UB4 BPK UB3 HON

6.3. Activate Message (ACT)

6.3.1. Purpose of the ACT Message

The ACT message satisfies the following operational requirements:

- Replace the verbal boundary estimate by transmitting automatically details of a flight from one ATC unit to the next prior to the transfer of control;

- Update the basic flight plan data in the receiving ATC unit with the most recent information;

- Facilitate distribution and display of flight plan data within the receiving ATC unit to the working positions involved;

- Expedite display of callsign/code correlation in the receiving ATC unit;

- Provide transfer conditions to the receiving ATC unit.

6.3.2. Message Contents

The ACT message shall contain the following items of data:

- Message Type;

- Message Number;

- Aircraft Identification;

- SSR Mode and Code

- Departure Aerodrome;

- Estimate Data;

- Destination Aerodrome;

- Aircraft number and type;

- Route (optional);

- Other flight plan data (optional).

NOTE

Data insertion rules, formats and field contents are specified at Annex A.

6.3.3. Rules of Application

6.3.3.1. General

6.3.3.1.1. One ACT message shall be sent for eligible flights crossing the boundary except as provided for in paragraph 6.3.3.1.10.

6.3.3.1.2. The ACT message shall be generated and transmitted automatically at the calculated time as specified in the LoA, unless manually initiated at an earlier time.

6.3.3.1.3. Recommendation

ATC staff should be provided with a means to trigger the transmission of ACT messages prior to the calculated time of transmission.

6.3.3.1.4. The operational contents of the ACT message due to be transmitted shall be displayed at the working position responsible for the co-ordination of the flight prior to the actual transmission.

6.3.3.1.5. Recommendation

In relation to 6.3.3.1.4, the time at which it is calculated that the ACT is to be transmitted automatically should be displayed together with its contents.

6.3.3.1.6. The ACT message shall contain the most recent information on the flight, reflecting the expected exit conditions.

6.3.3.1.7. The relevant working position shall be notified of the transmission of the ACT message.

6.3.3.1.8. As soon as a LAM has been received, the ACT message data becomes operationally binding to both of the ATC units. The co-ordinated transfer conditions and the fact that the LAM has been received shall be presented to the ATC staff at the transferring unit.

6.3.3.1.9. Acceptance by the receiving unit of the transfer conditions implied in the ACT message shall be assumed, unless the receiving unit initiates co-ordination to amend them.

6.3.3.1.10. A further ACT message may only be sent to the same co-ordination partner if the previous one has been abrogated by the use of a MAC.

6.3.3.1.11. Route and Other flight plan data shall be included if bilaterally agreed.

6.3.3.2. Processing in the Receiving Unit

6.3.3.2.1. The ATC system receiving an ACT message shall attempt association with the corresponding flight plan.

6.3.3.2.2. If a corresponding flight plan is found and no discrepancy is present in the message that would inhibit correct processing:

- the operational content shall be included with the flight plan;

- the required data shall be output at operational ATC and other positions as appropriate;

- a LAM shall be returned.

6.3.3.2.3. If a corresponding flight plan cannot be found, or a discrepancy is found that inhibits correct processing of the message:

- if the sector responsible for accepting control of the flight can be identified:

- the operational content of the message shall be displayed at the sector;

- a LAM shall be returned;

- a flight plan shall be created;

- in all other cases a LAM shall not be returned.

6.3.3.3. Parameters for Transmission

6.3.3.3.1. The message shall be transmitted at or as soon as possible after the earlier of the times determined from the following:

- a parameter number of minutes before the estimated time at the COP;

- the time at which the flight is at a bilaterally agreed distance from the COP.

6.3.3.3.2. The ACT generation parameter(s) shall be included in the LoA between the ATC units concerned.

6.3.3.3.3. The ACT generation parameter(s) shall be variable based on the provisions of the LoA.

6.3.3.3.4. Recommendation

ACT generation parameters should be defined separately for each of the COPs.

6.3.3.3.5. The specified parameters shall allow sufficient time for:

- the transmitting unit to update the transfer flight level to reflect the expected conditions at the COP;

and

- the receiving unit to process the ACT and generate and transmit a LAM but still allow for verbal co-ordination to be carried out by the transferring unit and resultant action initiated by the accepting unit if the exchange of data fails.

6.3.4. Acknowledgement of ACT

6.3.4.1. Acknowledgement

The ACT message shall be acknowledged by the generation and transmission of a LAM message.

6.3.4.2. No Acknowledgement Cases

If no LAM message is received as an acknowledgement for an ACT message, a warning shall be displayed at the ATC position responsible for the co-ordination of the flight.

6.3.5. Examples

The following examples are an extension of those provided for the ABI message in paragraph 6.2; all details are the same except the ETO at the COP, which is 1226 in the ACT message shown.

6.3.5.1. ICAO

(ACTE/L005-AMM253/A7012-LMML-BNE/1226F350-EGBB-9/B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON)

6.3.5.2. ADEXP

-TITLE ACT -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 005 -ARCID AMM253 -SSRCODE A7012 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F350 -ADES EGBB -ARCTYP B757 -ROUTE N0480F390 UB4 BNE UB4 BPK UB3 HON

6.4. Logical Acknowledgement Message (LAM)

6.4.1. Purpose of the LAM Message

The LAM is the means by which the receipt and safeguarding of a transmitted message is indicated to the sending unit by the receiving unit.

The LAM processing provides the ATC staff at the transferring unit with the following:

- a warning when no acknowledgement has been received;

- an indication that the message being acknowledged has been received, processed successfully, found free of errors, stored and, where relevant, is available for presentation to the appropriate working position(s).

6.4.2. Message Contents

The LAM message shall contain the following items of data:

- Message Type;

- Message Number;

- Message Reference.

NOTE

Data insertion rules, formats and field contents are specified at Annex A.

6.4.3. Rules of Application

6.4.3.1. General

6.4.3.1.1. The rules for the return of a LAM are specified in the sections of this document defining the processing of each message.

6.4.3.1.2. The LAM message shall be generated and transmitted without human intervention.

6.4.3.1.3. The LAM message shall not be used to avoid the need for technical messages to ensure the integrity of data transmissions.

6.4.3.1.4. The LAM message shall be generated and transmitted immediately so that the transaction time requirement of the message being acknowledged can be achieved.

6.4.3.1.5. With exception of ABI messages, the transmitting ATC system shall inform the controller responsible for co-ordination if a LAM message has not been received within the time parameter set for such warnings.

6.4.4. Acknowledgement of LAM

The LAM message shall not require any acknowledgement.

6.4.5. Examples

6.4.5.1. ICAO

(LAML/E012E/L001)

6.4.5.2. ADEXP

-TITLE LAM -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 012 -MSGREF -SENDER -FAC E -RECVR -FAC L -SEQNUM 001

7. BASIC PROCEDURE - COMPLEMENTARY MESSAGES

7.1. General

7.1.1. Description of Requirement

This section describes facilities applicable to the basic procedure which are additional to those described in Section 6 Basic Procedure - Mandatory Messages.

7.1.2. Implementation

7.1.2.1. The use of any of the facilities described in this section shall be bilaterally agreed before introduction.

7.1.2.2. Where such use is agreed, the rules described in this section shall be applied.

7.2. Preliminary Activate Message (PAC)

7.2.1. Purpose of the PAC Message

The PAC message satisfies the following operational requirements:

- notification and pre-departure co-ordination of a flight where the time of flight from departure to the COP is less than that which would be required to comply with the agreed time parameters for ACT message transmission;

- notification and pre-departure co-ordination of a flight before departure by a local (aerodrome/approach control) unit to the next unit that will take control of the flight;

- provide for acquisition of missing flight plan data in case of discrepancies in the initial distribution of flight plan data;

- request the assignment of an SSR code from the unit to which the above notification/co-ordination is sent, if required.

7.2.2. Message Contents

The PAC message shall contain the following items of data:

- Message Type;

- Message Number;

- Message Reference (optional);

- Aircraft Identification;

- SSR Mode and Code;

- Departure Aerodrome;

- Estimated Take-Off Time or Estimate Data;

- Destination Aerodrome;

- Type of Aircraft;

- Route (optional);

- Other flight plan data (optional).

NOTE

Data insertion rules, formats and field contents are specified at Annex A.

7.2.3. Rules of Application

7.2.3.1. General

7.2.3.1.1. One or more PAC messages shall be sent for each flight planned to cross the boundary of areas of responsibility where the time from departure to the COP would not permit the ACT message to be sent at the required time.

7.2.3.1.2. One or more PAC messages shall be sent by the Aerodrome/Approach unit to the next unit for each departing flight for which either notification or co-ordination is required.

7.2.3.1.3. Recommendation

For the implementation of PAC/LAM between units, the relevant TWR/APP systems should be provided with a means to input and forward "start-up", "push-back", "taxi" or similar information from which the ETOT may be derived in order to calculate the ETO at the COP and initiate the transmission of the PAC.

7.2.3.1.4. As bilaterally agreed, the message shall contain either:

- Estimated Take-Off Time;

or

- Estimate Data.

7.2.3.1.5. When the message reference is included, by bilateral agreement, it shall:

- contain the message number of the first PAC message sent for the flight;

- be included on second and subsequent PAC messages.

7.2.3.1.6. The use of the code request facility, if required, shall be agreed bilaterally.

7.2.3.1.7. A revised PAC message shall be sent if, before departure, any of the following conditions apply:

- the route of flight has been modified such that the COP in the previous message is no longer accurate;

- the type of aircraft has been changed;

- the destination aerodrome in the previous PAC has been found to be incorrect.

7.2.3.1.8. Recommendation

A revised PAC message should be sent if, before departure, the following data differs from that in the previous PAC message:

- the level (in the estimate data, if present);

- the expected SSR code at the transfer of control point;

- the Estimated Take-Off Time or the ETO at the COP by a time in excess of a bilaterally agreed value;

- there is a change in any other data, as bilaterally agreed.

7.2.3.2. Processing in the Receiving Unit

7.2.3.2.1. The ATC system receiving a PAC message shall attempt association with the corresponding flight plan.

7.2.3.2.2. If a corresponding flight plan is found and no discrepancy is present in the message that would inhibit correct processing:

- the operational content shall be included with the flight plan;

- the required data shall be output at operational ATC and other positions as appropriate;

- a LAM shall be returned.

7.2.3.2.3. If a corresponding flight plan cannot be found, or a discrepancy is found that inhibits correct processing of the message:

- if the sector responsible for accepting control of the flight can be identified:

- the operational content of the message shall be displayed at the sector;

- a LAM shall be returned;

- a flight plan shall be created;

- in all other cases a LAM shall not be returned.

7.2.3.2.4. The data in a second or subsequent PAC message shall supersede the data in the previous message.

7.2.3.2.5. If the PAC message includes a request for the assignment of an SSR code and is correctly processable as described in paragraph 7.2.3.2.2. above, a COD message shall be returned in addition to the LAM.NOTE

As the code assignment process requires detailed flight plan route information, no requirement is made in this document for the return of a COD message by the receiving unit where such data may not be available for the flight. This does not prevent a message being returned under such circumstances if a specific local capability exists and the procedure has been agreed bilaterally.

7.2.3.3. Time Parameters for Transmission

A transmission time parameter is not applicable since the message is sent as the result of a manually entered message identifying the imminent departure of the flight.

7.2.4. Acknowledgement of PAC

7.2.4.1. Acknowledgement

The messages to be sent in response to a PAC message are described in paragraph 7.2.3.2. above.

7.2.4.2. No Acknowledgement

If no LAM message is received as an acknowledgement for a PAC message, a warning shall be displayed at the position in the ATC unit responsible for co-ordination with the next unit.

7.2.4.3. No-LAM cases

In no-LAM cases, verbal co-ordination shall be initiated.

7.2.4.4. No COD Message

7.2.4.4.1. If a COD message is not received in response to a code request included in the PAC message, a warning shall be displayed at an appropriate position.

7.2.4.4.2. Where the code request function is to be used, the time-out value to be applied shall be agreed bilaterally.

7.2.5. Examples

7.2.5.1. Estimated Take-Off Time and Code Request

7.2.5.1.1. ICAO

(PACBA/SZ002-CRX922/A9999-LFSB1638-LSZA-9/B737/M)

7.2.5.1.2. ADEXP

-TITLE PAC -REFDATA -SENDER -FAC BA -RECVR -FAC SZ -SEQNUM 002 -ARCID CRX922 -SSRCODE REQ -ADEP LFSB -ETOT 1638 -ARCTYP B737 -ADES LSZA

7.2.5.2. Time at COP

7.2.5.2.1. ICAO

(PACD/L025-EIN636/A5102-EIDW-LIFFY/1638F290F110A-EBBR-9/B737/M)

7.2.5.2.2. ADEXP

-TITLE PAC -REFDATA -SENDER -FAC D -RECVR -FAC L -SEQNUM 025 -ARCID EIN636 -SSRCODE A5102 -ADEP EIDW -COORDATA -PTID LIFFY -TO 1638 -TFL F290 -SFL F110A -ARCTYP B737 -ADES EBBR

7.3. Revision Message (REV)

7.3.1. Purpose of the REV Message

The REV message is used to transmit revisions to co-ordination data previously sent in an ACT message provided that the accepting unit does not change as a result of the modification.

7.3.2. Message Contents

The REV message shall contain the following items of data:

- Message Type;

- Message Number;

- Message Reference (optional);

- Aircraft Identification;

- SSR Mode and Code (optional);

- Departure Aerodrome;

- Estimate Data;

- Co-ordination point (optional);

- Destination Aerodrome;

- Route (optional);

- Other flight plan data (optional).

NOTE

Data insertion rules, formats and field contents are specified at Annex A.

7.3.3. Rules of Application

7.3.3.1. General

7.3.3.1.1. One or more REV messages may be sent to the unit to which a flight has been currently co-ordinated by the use of an Activate message.

7.3.3.1.2. The following elements shall be subject to revisions:

- ETO at the COP;

- Transfer level(s);

- SSR Code.

7.3.3.1.3. A REV message shall be sent when:

- the ETO at the COP differs from that in the previous message by more than a value bilaterally agreed, rounded to the nearest integer value;

- there is any change to the transfer level(s) or SSR code.

7.3.3.1.4. Where bilaterally agreed, a REV message shall be sent when there is any change in the following:

- COP;

- route;

- other flight plan data (ICAO field 8, 10 and 18 data).

NOTE

Operational rules may require that modifications effected after ACT be subject to prior co-ordination between the units concerned.

7.3.3.1.5. When bilaterally agreed, the message reference shall be included in the REV message.

7.3.3.1.6. The message reference, when included, shall contain the message number of the preceding ACT message.

7.3.3.1.7. Acceptance by the receiving ATC unit of the transfer conditions implied by the REV message shall be assumed, unless the receiving ATC unit initiates co-ordination to amend them.

7.3.3.2. Formatting of Revision Messages

7.3.3.2.1. ICAO Format

All revision messages include field types 3, 7, 13, 14 and 16. The following types of revision are accommodated within those fields:

- a change to the ETO at the COP or transfer level(s) shall be incorporated by the inclusion of the revised data in field 14;

- a change to the SSR Code shall be included in field 7;

- route changes including changes to the COP shall be incorporated in field 14 and 15 data included in field 22 format after the initial five fields. Such messages shall include two field 14's, the first containing element a) only, the COP through which the flight had previously been co-ordinated. Rules for the co-ordination of such changes, including direct routings, are specified in Annex B Special Route Processing Requirements;

- modifications to fields 8, 10 and 18 shall be incorporated as field 22 data after the initial five fields.

7.3.3.2.2. ADEXP Format

All revision messages in ADEXP format shall include the following primary fields: TITLE REFDATA ARCID ADEP ADES. The following rules apply:

- a change to the ETO at the COP or transfer level(s) shall be incorporated by the inclusion of the revised data in primary field COORDATA;

- route changes, including changes to the COP, shall be incorporated in primary fields COORDATA and ROUTE. Such messages shall include primary field COP containing the Co-ordination Point through which the flight had previously been co-ordinated. Rules for the co-ordination of such changes, including direct routings, are specified in Annex B;

- a change to the SSR Code shall be indicated by the inclusion of primary field SSRCODE;

- modifications to other flight plan data shall be incorporated by the inclusion of the requisite primary field(s) as defined for other Flight Plan Data in Annex A.

If a revision message is sent to co-ordinate only SSR Code and/or Other Flight Plan Data, the primary field COP shall be included in place of COORDATA.

7.3.3.2.3. SSR Code

SSR Mode and Code shall be included in a REV message only when it is required to co-ordinate a change of SSR code.

7.3.3.3. Processing in the Receiving Unit

7.3.3.3.1. If an ACT has been received for the subject flight from the same ATC unit, the ATC system receiving a REV message shall attempt association with the corresponding flight plan.

7.3.3.3.2. If a corresponding flight plan is found and no discrepancy is present in the message that would inhibit correct processing:

- the operational content shall be included with the flight plan;

- the required data shall be output at operational ATC and other positions as appropriate.

7.3.3.4. Initiation of Transmission

7.3.3.4.1. The REV message is event driven and shall be transmitted immediately following the relevant input or update.

7.3.3.4.2. No changes may be effected by the use of the REV message after the flight is a specified time/distance from the transfer point. The time and distance parameters shall be bilaterally agreed.

7.3.3.4.3. Recommendation

The REV parameters should be defined separately for each of the COPs.

7.3.3.5. Change of Receiving ATC Unit

The REV message shall not be used if a revision of flight plan data leads to a change of the receiving ATC unit (see Message for the Abrogation of Co-ordination).

7.3.4. Acknowledgement of REV

7.3.4.1. Acknowledgement

If the REV message:

- can be associated with a flight plan within the receiving system, a LAM message shall be transmitted in acknowledgement;

- cannot be associated with a flight plan within the receiving system, a LAM message shall not be transmitted.

7.3.4.2. No Acknowledgement

7.3.4.2.1. If no LAM message is received as an acknowledgement for a REV message, a warning shall be displayed at the ATC position responsible for the co-ordination of the flights.

7.3.4.2.2. In no-LAM cases, a verbal revision shall be initiated by the transferring ATC unit.

7.3.5. Examples

7.3.5.1. ICAO

a. (REVE/L002-AMM253-LMML-BNE/1226F310-EGBB)

b. (REVE/L010-AMM253/A2317-LMML-BNE/1226F310-EGBB)

7.3.5.2. ADEXP

a. -TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 002 -ARCID AMM253 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F310 -ADES EGBB

b. -TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 010 -ARCID AMM253 -ADEP LMML -COP BNE -ADES EGBB -SSRCODE A2317

7.4. Message for the Abrogation of Co-ordination (MAC)

7.4.1. Purpose of the MAC Message

A MAC message is used to indicate to the receiving unit that the co-ordination or notification previously effected for a flight is being abrogated.

The MAC is not a replacement for a Cancellation (CNL) message, as defined by ICAO, and therefore, shall not be used to erase the basic flight plan data.

7.4.2. Message Contents

The MAC message shall contain the following items of data:

- Message Type;

- Message Number;

- Message Reference (optional);

- Aircraft Identification;

- Departure Aerodrome;

- Co-ordination Point;

- Destination Aerodrome;

- Co-ordination Status and Reason (optional).

NOTE

Data insertion rules, formats and field contents are specified at Annex A.

7.4.3. Rules of Application

7.4.3.1. General

7.4.3.1.1. A MAC message shall be sent to a unit to which co-ordination had previously been effected for a flight, by the use of an ACT or RAP message, when one of the following occurs:

- the expected level at the transfer point is different from the level contained in the previous message resulting in a change of the next unit in the co-ordination sequence;

- the route of flight has been altered which results in change of the next unit in the co-ordination sequence;

- the system flight plan is cancelled in the sending unit and the co-ordination is no longer relevant;

- a MAC is received from the previous unit in respect of the flight.

7.4.3.1.2. When the MAC message is sent due to a flight level or route change, notification and/or co-ordination, as appropriate, shall be effected with the new unit in the co-ordination sequence.

7.4.3.1.3. A MAC message shall be sent when the co-ordination for a departing flight, effected by the use of a PAC message, is abrogated.

7.4.3.1.4. Recommendation

A MAC message should be sent when the notification (ABI message) previously effected for a flight is cancelled due to any of the reasons specified in paragraph 7.4.3.1.1. above or the flight is delayed en-route and a revised estimate cannot be determined automatically.

7.4.3.1.5. A message reference shall be included if bilaterally agreed.

7.4.3.1.6. If included, the message reference shall contain the message number of the last ABI, PAC or ACT message transmitted for the flight and acknowledged.

7.4.3.1.7. The co-ordination point shall be the COP through which the flight had been previously notified or co-ordinated.

7.4.3.1.8. Recommendation

The MAC message should identify the status to which the co-ordination or notification is to revert and the reason for the abrogation.

7.4.3.1.9. If included, the status and reason shall be one of the following combinations:

- when the receiving unit is no longer the next co-ordination partner:

- the status is INI (initial);

- the reason is one of the following:

- TFL if the reason is a change of transfer level;

- RTE if the reason is a change of route;

- CSN if the reason is a change in the callsign;

- CAN if the reason is a cancellation;

- OTH for any other reason or if the reason is unknown;

- when one of the following conditions applies:

- the co-ordination effected by the use of the previous PAC or ACT message (as modified by any subsequent REV message) is abrogated but the flight is expected to be the subject of a new co-ordination sequence with the same unit;

or

- following the transmission of an ABI message, the flight is holding for an indefinite period and is expected to be subject to a revised ABI or ACT, as appropriate:

- the status is NTF (notification);

- the reason is one of the following:

- DLY if the reason is a delay;

- HLD if the reason is a hold;

- OTH for any other reason, or if the reason is unknown.

7.4.3.1.10. If the flight is to be re-notified or re-co-ordinated:

- a new notification and/or co-ordination message, as appropriate, shall be sent;

- the basic flight plan data stored in the receiving ATC unit shall not be affected by a MAC message;

- the system shall retain the capability to correctly process a new notification and/or co-ordination message from either the previous transferring unit or a different unit in a new co-ordination sequence.

7.4.3.2. Processing in the Receiving Unit

The working position(s) in the receiving ATC unit which are provided with flight details shall be notified of the abrogation.

7.4.4. Acknowledgement of MAC

7.4.4.1. Acknowledgement

7.4.4.1.1. If the MAC message can be associated with a flight plan within the receiving system and can be processed, a LAM message shall be transmitted in acknowledgement.

7.4.4.1.2. If the MAC message cannot be associated with a flight plan within the receiving system, or cannot be processed, a LAM message shall not be transmitted.

7.4.4.2. No Acknowledgement

7.4.4.2.1. If ATC co-ordination is being abrogated and no LAM message is received, a warning shall be displayed at the ATC position responsible for the co-ordination.

7.4.4.2.2. In such cases a verbal abrogation of co-ordination shall be effected by the transferring ATC unit.

7.4.5. Examples

An ABI message was sent by Amsterdam ACC to Brussels ACC for flight HOZ3188, planned at FL190; the flight subsequently requests to climb to FL270 and is so cleared, thus entering Maastricht airspace instead of Brussels. Examples 7.4.5.1 a and 7.4.5.2 a show how the MAC sent to Brussels by Amsterdam would appear both in ICAO and ADEXP formats.

An ABI and, later, an ACT message are sent to Maastricht, but, a few minutes before reaching the COP, the aircraft returns to Amsterdam Airport and the flight plan is cancelled in the sending unit's system; a MAC is sent to Maastricht as shown in examples (7.4.5.1 b and 7.4.5.2 b).

7.4.5.1. ICAO

a. (MACAM/BC112-HOZ3188-EHAM-NIK-LFPG-18/STA/INITFL)

b. (MACAM/MC096-HOZ3188-EHAM-NIK-LFPG-18/STA/INICAN)

7.4.5.2. ADEXP

a. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -FAC BC -SEQNUM 112 -ADEP EHAM -COP NIK -ADES LFPG -ARCID HOZ3188 -CSTAT -STATID INI -STATREASON TFL

b. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -FAC MC -SEQNUM 096 -ADEP EHAM -COP NIK -ADES LFPG -ARCID HOZ3188 -CSTAT -STATID INI -STATREASON CAN

7.5. SSR Code Assignment Message (COD)

7.5.1. Purpose of the COD Message

7.5.1.1. The Originating Region Code Allocation Method (ORCAM) is provided to permit a flight to respond on the same code to successive units within a participating area. Unless code allocation is performed centrally, e.g. by an ACC, airports may need to be individually allocated a set of discrete SSR codes. Such allocations are very wasteful of codes.

7.5.1.2. The COD message satisfies the operational requirement for the issue of a Mode A SSR code by one Air Traffic Service Unit to another for a specified flight when requested. An optional facility permits the issuing unit to include the route of flight if bilaterally agreed.

7.5.2. Message Contents

The COD message shall contain the following items of data:

- Message type;

- Message number;

- Message reference (optional);

- Aircraft identification;

- SSR mode and code;

- Departure aerodrome;

- Destination aerodrome;

- Route (optional).

NOTE

Data insertion rules, formats and field contents are specified at Annex A.

7.5.3. Rules of Application

7.5.3.1. General

7.5.3.1.1. A COD message shall be generated and transmitted automatically in response to a code assignment request received within a message.

7.5.3.1.2. The SSR code shall be the code being assigned to the flight.

7.5.3.1.3. The approved saturation code, as specified in the Air Navigation Plan for the European Region, shall be inserted if a discrete code is not available.

7.5.3.1.4. If bilaterally agreed, the message reference, containing the message number of the message to which the COD message is in response, shall be included.

7.5.3.1.5. The route shall be included if bilaterally agreed.

7.5.3.1.6. Acceptance of the SSR code by the unit receiving the COD message shall be assumed.

7.5.3.2. Processing in the Receiving Unit

7.5.3.2.1. Provided there is no discrepancy in the message that would inhibit correct processing, a LAM shall be returned.

7.5.3.2.2. If the message cannot be associated with a flight plan or a discrepancy is found that inhibits correct processing of the message a LAM shall not be returned.

7.5.3.2.3. Route data, if included, shall not be a reason to inhibit the return of a LAM unless it fails to comply with the format requirement as stated in Annex A.

7.5.3.3. Time Parameters for Transmission

A transmission time parameter shall not be applicable, since the COD message is sent as a result of the reception of a message requesting the assignment of an SSR code.

7.5.4. Acknowledgement of COD

7.5.4.1. Acknowledgement

The COD message shall be acknowledged by generating and transmitting a LAM message.

7.5.4.2. No Acknowledgement Cases

If no LAM message is received as an acknowledgement for a COD message, a warning shall be displayed at an appropriate position.

7.5.5. Examples

7.5.5.1. ICAO

(CODP/PO011-AAL905/A0767-LFPO-KEWR)

7.5.5.2. ADEXP

-TITLE COD -REFDATA -SENDER -FAC P -RECVR -FAC PO -SEQNUM 011 -ADEP LFPO -ADES KEWR -ARCID AAL905 -SSRCODE A0767

7.6. Information Message (INF)

7.6.1. Purpose of the INF Message

7.6.1.1. The INF message is used to provide information on specific flights to agencies not directly involved in the co-ordination process between two successive ATC units on the route of flight.

7.6.1.2. The INF message may be used to provide copies of messages and to communicate agreed co-ordination conditions to such agencies following a dialogue between controllers. For this purpose INF messages may be generated by the systems at the transferring or accepting unit.

7.6.1.3. The message may also be used to provide information in relation to any point on the route of flight to an agency.

7.6.1.4. The format allows the communication of initial data, revisions and cancellations.

7.6.2. Message Contents

The INF message shall contain the following items of data in the format of a message described in this document:

- Message type;

- Message number;

- All items of operational data as contained in the original message or resultant co-ordination being copied;

- Reference Message Type.

NOTE

Data insertion rules, formats and field contents are specified at Annex A.

7.6.3. Rules of Application

7.6.3.1. Message Types

The type(s) of message(s) to be duplicated by an INF message will be based upon users requirements and sending unit capabilities. Type(s) of message(s) and rules of application will, generally, be agreed upon bilaterally.

7.6.3.2. Message Addressees

One or more INF message(s) may be transmitted for the same flight to one or more addressee(s).

7.6.3.3. Operational Content

The operational content of the INF message shall be in the format of one of the existing messages.

7.6.3.4. Recommendations

1. Conditions forwarded in an initial dialogue message (e.g. ACT, RAP, REV, RRV message) may be changed or rejected before the dialogue is completed. Sending units should be capable of forwarding the final agreed co-ordination conditions.

2. The INF message should be sent immediately, or at a time related to the time at the COP, which is agreed bilaterally with the receiving agency.

7.6.4. Acknowledgement of INF

Recommendations

1. The INF message may be acknowledged dependent on the co-ordination partner by generating and transmitting a LAM message.

2. Subject to bilateral agreement between the units concerned, if no LAM message is received as an acknowledgement for an INF message, a warning should be displayed at an appropriate position.

7.6.5. Examples

A flight with callsign BAW011, B747 from EGLL to OMDB at FL290, requesting FL410, is estimating Koksy (KOK) VOR at 1905, transponding on A5437, proceeding via UG1 and UB6.

An ACT message is sent by London to Maastricht for the flight. A copy is sent from London to a unit identified as IT.

The following give examples of the INF message.

7.6.5.1. ICAO

(INFL/IT112-BAW011/A5437-EGLL-KOK/1905F290-OMDB-9/B747H-15/N0490F410 DVR KOK UG1 NTM UB6 KRH-18/MSG/ACT)

7.6.5.2. ADEXP

-TITLE INF -REFDATA -SENDER -FAC L -RECVR -FAC IT -SEQNUM 112 -ARCID BAW011 -SSRCODE A5437 -ADEP EGLL -COORDATA -PTID KOK -TO 1905 -TFL F290 -ADES OMDB -ARCTYP B747 -ROUTE N0490F410 DVR UG1 KOK NTM UB6 KRH -MSGTYP ACT

8. DIALOGUE PROCEDURE - COORDINATION

8.1. General

8.1.1. Introduction

8.1.1.1. The dialogue procedure provides facilities for communication and negotiation between controllers in the co-ordination phase and for communication in the transfer phase.

8.1.1.2. This section describes messages used in the dialogue procedure in the co-ordination phase where the conditions of transfer are planned. Those for the transfer phase where the handover of the flight is accomplished are described in Section 9 - Dialogue Procedure - Transfer of Communication.

8.1.1.3. Procedures for the two phases are not dependent on each other; they can be implemented individually or together.

8.1.1.4. A number of additional messages are introduced and the capability for either partner to initiate a dialogue is supported.

8.1.1.5. The co-ordination dialogue procedure allows the identification of:

- transfers that are in accordance with LoAs and can be accepted automatically; and

- those which require to be referred to the controller at the receiving unit for a decision regarding acceptance.

8.1.1.6. This procedure also allows the interpretation of the LoAs within the two systems to be monitored and for any discrepancy between them to be identified.

8.1.2. The Filter

8.1.2.1. General

8.1.2.1.1. The co-ordination dialogue procedure requires that systems identify whether or not transfers are in accordance with LoAs.

8.1.2.1.2. The process which checks such compliance is referred to in this document as "the filter". The database used for the filter will include the following, if required:

- agreed co-ordination points;

- eligible (or ineligible) flight levels which may also be associated with the co-ordination points;

- aerodromes of departure;

- destinations;

- agreed direct routes;

- time and/or distance limits prior to the COP, after which any co-ordination message is considered non-standard;

- any other conditions, as bilaterally agreed.

8.1.2.1.3. All items in this list may be combined to define more complex conditions.

8.1.2.1.4. Within Section 8 of this document the term "standard conditions" shall be interpreted as "in accordance with the LoA" and the term "non-standard conditions" as "not in accordance with the LoA". Unless bilaterally agreed, messages sent by transferring units for co-ordinations which are known to be standard shall utilise different message types from those for which the conditions are non-standard.

8.1.2.2. Action In the Transferring Unit

8.1.2.2.1. The filter in the transferring unit shall review the transfer conditions that are about to be sent to the accepting unit.

8.1.2.2.2. Recommendation

If the transfer conditions are found to be non-standard, the fact should be drawn to the attention of the transferring controller, for confirmation or modification.

8.1.2.3. Action in the Accepting Unit

8.1.2.3.1. All ACT and REV messages shall be checked against the filter.

8.1.2.3.2. If the check indicates that the received transfer conditions are non-standard, they shall be referred to the controller for a decision, otherwise they will be accepted automatically.

8.1.2.4. Synchronisation of the Filters

8.1.2.4.1. The use of different messages for standard and non-standard transfer conditions allows the identification of any discrepancy between standard conditions as held in the systems at the transferring and accepting units.

8.1.2.4.2. The identification in the accepting unit of non-standard transfer conditions in a message used to co-ordinate only standard transfers will signify a discrepancy between the two filters. Such discrepancies should be resolved for the effective operation of the dialogue procedure.

8.1.3. Message Sequence

8.1.3.1. General

8.1.3.1.1. Certain rules require to be followed to ensure that co-ordination is complete before any revisions or transfer of communication message exchange takes place and also to ensure that controllers at both units do not simultaneously make proposals on the same flight.

8.1.3.1.2. An ATC unit shall only transmit or acknowledge receipt of a Revision (REV or RRV) message for a flight when it is in the co-ordinated state, i.e. an ACT or RAP dialogue has been completed by a LAM or ACP.

8.1.3.1.3. CDN messages shall only be eligible for transmission by the accepting unit.

8.1.3.1.4. CDN messages shall only be transmitted and acknowledged:

- as part of a dialogue initiated by the receipt of an Activate (ACT, RAP) or Revision (REV or RRV) message; or

- when the flight plan for that flight is in the co-ordinated state.

8.1.4. Simultaneous Message Handling

8.1.4.1. General

8.1.4.1.1. A unit involved in a co-ordination or transfer message exchange for a flight shall not initiate a further co-ordination or transfer message exchange for the same flight with the same unit until either a LAM, ACP or RJC has been received, or a time-out has been reached.

8.1.4.1.2. It is possible for a CDN message to cross with a REV, RRV or MAC message for the same flight sent from the transferring unit. This situation may be identified in the transferring unit by the CDN arriving before the acknowledgement for the transmitted co-ordination message and in the accepting unit by the message from the transferring unit arriving before the acknowledgement of the CDN. In this event the CDN shall not be acknowledged and the REV, RRV or MAC processed.

8.1.5. Reject Handling

The RJC message terminates a system dialogue. A new system co-ordination must be initiated which reflects the telephone co-ordination where applicable.

8.1.6. Operational Reply Time-out

8.1.6.1. General

8.1.6.1.1. A time-out mechanism shall be applied at the sending and at the receiving centres for the reply to messages that are referred to the controller.

8.1.6.1.2. The duration of these time-outs shall be bilaterally agreed.

8.1.6.1.3. The expiry of the time-out at the transferring unit shall result in a warning being output to the transferring controller, to indicate the need to initiate a telephone co-ordination.

8.1.6.1.4. Recommendations

1. A warning should be displayed to the ATC position at the accepting unit responsible for the flight when the time-out in the transferring unit is imminent.

2. The warning should allow for the transmission time of the reply.

8.1.6.1.5. Systems shall be able to process replies which are received after the expiry of the time-out.

8.1.7. Implementation

8.1.7.1. The dialogue procedures address two phases, namely the co-ordination phase and the transfer phase. The dialogue in the two phases uses different messages and the required transaction times are different. The co-ordination messages are specified in ICAO and ADEXP formats, the transfer of communication messages only in ADEXP.

8.1.7.2. The minimum HMI requirements for the co-ordination dialogue are different from those for the transfer dialogue:

- the transfer dialogue addresses primarily the executive control function and requires a fast and user-friendly HMI;

- the co-ordination dialogue is not as time-critical and therefore its HMI requirements are of a lower order.

8.1.7.3. The dialogue procedure shall be implemented using one of the following alternative scenarios:

- co-ordination phase dialogue procedure plus any complementary messages as bilaterally agreed (Sections 7 and 8);

- basic co-ordination procedure and transfer phase dialogue procedure (Sections 6, 7 and 9);

- co-ordination and transfer phase dialogue procedure plus any complementary co-ordination messages as bilaterally agreed (Sections 7, 8 and 9).

The Advance Boundary Information message shall be sent in all scenarios.

8.1.7.4. The scenario used for the implementation shall be bilaterally agreed.

8.2. Activate Message (ACT)

8.2.1. Purpose of the ACT Message

The purpose of the ACT Message is described in paragraph 6.3.1. In a dialogue procedure, the ACT message is used to meet these requirements provided that the transfer conditions for the flight are standard and the transferring controller does not require to refer the flight to the accepting controller for acceptance.

8.2.2. Message Contents

The contents of the ACT message used in the dialogue procedure shall be as described for the ACT message in paragraph 6.3.2.

8.2.3. Rules of Application

8.2.3.1. General

8.2.3.1.1. The rules of application are as described for the ACT in paragraph 6.3 with the exception of the special rules described in this paragraph.

8.2.3.1.2. An ACT message shall be sent for a flight with standard transfer conditions which the transferring controller does not require to be referred to the accepting controller.NOTE

If these requirements do not apply, a RAP is sent (see paragraph 8.3 Referred Activate Proposal Message).

8.2.3.1.3. Recommendation

A new co-ordination procedure should be initiated if a Reject Co-ordination ( RJC) message is returned in response to an ACT message.

8.2.3.2. Processing in the Receiving Unit

8.2.3.2.1. The message is checked against the filter to confirm that the proposed conditions are standard.

8.2.3.2.2. The message shall be processed as a RAP message if:

- the transfer conditions are found to be non-standard;

- a corresponding system flight plan cannot be found and there is insufficient information available to identify whether or not the transfer conditions are standard.

8.2.3.2.3. ACT messages found to be standard shall be processed in accordance with paragraph 6.3.3.2.

8.2.3.2.4. Recommendation

If the transfer conditions in an ACT message are found to be non-standard, there is a discrepancy between the filters in the two systems. The fact that the ACT is non-standard should be drawn to the attention of supervisory staff in order that the discrepancy be resolved.

8.2.4. Acknowledgement of ACT

8.2.4.1. Acknowledgement

8.2.4.1.1. In a dialogue procedure an ACT message shall be acknowledged by:

- a LAM if the transfer conditions are found to be standard;

- an SBY message in all other cases.

8.2.4.1.2. When a LAM has been received, the operational contents of the ACT message shall become operationally binding to both of the ATC units.

8.2.4.1.3. Where bilaterally agreed, an ACP may be used in place of a LAM to indicate the acceptance of an ACT containing standard transfer conditions by the accepting unit.

8.2.4.2. No Acknowledgement Cases

If no acknowledgement is received for an ACT message, a warning shall be displayed at the ATC position responsible for the co-ordination of the flight.

8.3. Referred Activate Proposal Message (RAP)

8.3.1. Purpose of the RAP Message

The RAP message satisfies the following operational requirements, in addition to those specified for the ACT message in paragraph 6.3:

- the proposal by the transferring controller and referral to the accepting controller of flights with non-standard transfer conditions;

- allow the transferring controller, if he/she requires to do so, to force the referral to the accepting controller of standard transfer conditions for a specific flight.

8.3.2. Message Contents

The contents of the RAP message shall be the same data as described for the ACT message (paragraph 6.3) and may optionally include the following data element:

- reason, indicating manual referral (only available in ADEXP).

8.3.3. Rules of Application

8.3.3.1. General

8.3.3.1.1. A RAP message shall be sent in place of the ACT message for flights crossing the boundary meeting one of the following conditions:

- the transferring system has determined the transfer conditions are non-standard;

- the transferring controller has indicated that the proposed transfer conditions are to be referred to the accepting controller.

8.3.3.1.2. The operational contents of the RAP message due to be transmitted shall be displayed at the working position responsible for the co-ordination of the flight prior to the actual transmission.

8.3.3.1.3. Recommendation

The time when the RAP message is transmitted automatically should be displayed together with its contents.

8.3.3.1.4. The relevant working position shall be notified of the transmission of the RAP message.

8.3.3.2. Processing in the Receiving Unit

8.3.3.2.1. The ATC system receiving a RAP message shall attempt association with the corresponding flight plan.

8.3.3.2.2. If a corresponding flight plan is found and no discrepancy is present in the message that would inhibit correct processing:

- the operational contents shall be referred to the accepting controller;

- an SBY shall be returned.

8.3.3.2.3. Recommendation

An indication of the reason for the referral (non-standard conditions or manual referral) should be included.

8.3.3.2.4. If the message cannot be associated with a flight plan, or a discrepancy is found that inhibits correct processing of the message, then:

- the operational content of the message shall be displayed at the sector;

and

- an SBY message returned;

and

- a flight plan created.

8.3.3.2.5. In all other cases the message shall not be acknowledged.

8.3.3.3. Manual Trigger

8.3.3.3.1. When it is used to force the referral of a proposed co-ordination with standard transfer conditions to the accepting controller, the RAP will be initiated manually by the transferring controller and transmitted immediately.

8.3.3.3.2. Recommendation

Manual triggering of a RAP message before the calculated time of transmission should be allowed at the position responsible for co-ordination of the flight.

8.3.3.4. Time Parameters for Automatic Transmission

The time/distance before the boundary at which RAP messages are automatically transmitted shall be the same as for the ACT messages.

8.3.4. Acknowledgement of RAP

8.3.4.1. Acknowledgement

The message shall be acknowledged by the generation and transmission of an SBY message.

8.3.4.2. No Acknowledgement Case

If no SBY message is received as an acknowledgement for a RAP message, a warning shall be displayed at the ATC position responsible for the co-ordination of the flight.

8.3.5. Operational Reply to RAP

The accepting controller may either accept, counter-propose or reject transfer conditions.

8.3.5.1. Acceptance

8.3.5.1.1. When the accepting controller elects to accept the proposed transfer conditions, an ACP message shall be returned.

8.3.5.1.2. As soon as the ACP message has been received, the RAP message data becomes operationally binding to both of the ATC units. The co-ordinated transfer conditions and the fact that the ACP has been received shall be presented to the transferring controller.

8.3.5.2. Counter-Proposal

When the accepting controller elects to counter-propose transfer conditions, a CDN message shall be returned.

8.3.5.3. Recommendation

When the accepting controller elects to reject the proposed transfer conditions, an RJC message should be returned. A new co-ordination process should then be initiated.NOTE

With respect to the recommendation at 8.3.5.3, in most cases the new co-ordination will be with a different unit.

8.3.6. Examples

8.3.6.1. ICAO

(RAPE/L022-AMM253/A7012-LMML-BNE/1226F350-EGBB-9/B757/M)

8.3.6.2. ADEXP

-TITLE RAP -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 022 -ARCID AMM253 -SSRCODE A7012 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F350 -ADES EGBB -ARCTYP B757

8.4. Revision Message (REV)

8.4.1. Purpose of the REV Message

The purpose of the REV message is described in paragraph 7.3.1. In a dialogue procedure, the REV message is used to meet these requirements provided that the transfer conditions for the flight are standard and the transferring controller does not require to refer the flight to the accepting controller for acceptance.

8.4.2. Message Contents

The contents of the REV message shall be as described for the REV message in paragraph 7.3.2.

8.4.3. Rules of Application

8.4.3.1. General

8.4.3.1.1. One or more REV messages may be sent to the unit to which a flight has been currently co-ordinated by the use of an Activate or RAP message.

8.4.3.1.2. REV messages shall be sent under the conditions specified in paragraph 7.3.3.1 for flights with standard transfer conditions which the transferring controller does not require to be referred to the accepting controller.

8.4.3.2. Initiation of Transmission

The REV message shall be transmitted immediately following a detection of a change in the co-ordination data required to be co-ordinated as described in paragraph 7.3.3.

8.4.3.3. Processing in the Receiving Unit

8.4.3.3.1. If a corresponding flight plan is found in the co-ordinated state and no discrepancy is found that would inhibit correct processing of the message, then:

- the REV message shall be acknowledged;

- in all other cases the message shall not be acknowledged.

8.4.3.3.2. The transfer conditions shall be examined to ensure that they are standard.

8.4.3.3.3. If the transfer conditions are not standard they shall be presented to the accepting controller.

8.4.3.3.4. If the proposed transfer conditions are found to be standard, they shall be included with the flight plan and the required data output at operational ATC and other positions as appropriate.

8.4.3.3.5. Recommendation

If the transfer conditions in an REV message are found to be non-standard, there is a discrepancy between the filters in the two systems. The fact that the REV is non-standard should be drawn to the attention of supervisory staff in order that the discrepancy be resolved.

8.4.4. Acknowledgement of REV

8.4.4.1. Acknowledgement

8.4.4.1.1. If the REV message is to be acknowledged, it shall be acknowledged by:

- a LAM message if the transfer conditions are found to be standard;

- an SBY message if the transfer conditions are found to be non-standard.

8.4.4.1.2. When a LAM has been received, the operational contents of the REV message become operationally binding to both of the ATC units.

8.4.4.1.3. Where bilaterally agreed, an ACP may be used in place of a LAM to indicate the acceptance by the accepting unit of a REV containing standard transfer conditions.

8.4.4.2. No Acknowledgement Cases

If no acknowledgement is received for a REV message, a warning shall be displayed at the ATC position responsible for the co-ordination of the flights.

8.4.5. Operational Reply to REV

As the REV message is used to send standard transfer conditions, it will normally be accepted by the system in the accepting unit. If the transfer conditions are found to be non-standard by the filter in the accepting unit, the message shall be processed as an RRV message.

8.5. Referred Revision Proposal Message (RRV)

8.5.1. Purpose of the RRV Message

The RRV message shall provide for revision of previously sent and agreed transfer conditions in the following cases:

- when the proposed transfer conditions in the revision are non-standard;

- when the proposed revision is standard, but the transferring controller wants to refer the revision to the accepting controller.

8.5.2. Message Contents

The contents of the RRV message shall be as described for the REV message (paragraph 7.3.2) and may optionally include the following data element:

- reason, indicating manual referral (only available in ADEXP format).

8.5.3. Rules of Application

8.5.3.1. General

One or more RRV messages shall be sent, in place of REV messages, for each revision, if either:

- the transferring system has determined the transfer conditions are non-standard;

or

- the transferring controller has indicated that the proposed transfer conditions are to be referred to the accepting controller. This use of the RRV is optional.

8.5.3.2. Initiation of Transmission

The RRV message shall be transmitted immediately following the detection of a change in the co-ordination data or when manually initiated.

8.5.3.3. Processing in the Receiving Unit

8.5.3.3.1. If a corresponding flight plan is found in the co-ordinated state and no discrepancy is found that would inhibit correct processing of the message, then:

- The RRV message shall be acknowledged;

- in all other cases the message shall not be acknowledged.

8.5.3.3.2. The proposed transfer conditions shall be displayed at the ATC position responsible for the co-ordination of the flight.

8.5.3.3.3. Recommendation

An indication of the reason for the referral (non-standard conditions or manual referral) should be included.

8.5.4. Acknowledgement of RRV

8.5.4.1. Acknowledgement

The message shall be acknowledged by the generation and transmission of an SBY message.

8.5.4.2. No Acknowledgement Cases

If no SBY message is received as an acknowledgement for an RRV message, a warning shall be displayed at the ATC position responsible for the co-ordination of the flight.

8.5.5. Operational Reply to RRV

The accepting controller can either accept, counter-propose or reject an RRV message.

8.5.5.1. Acceptance

When the accepting controller elects to accept the proposed amendment to the agreed transfer conditions, an ACP message shall be returned.

8.5.5.2. Counter-Proposal

When the accepting controller elects to counter-propose transfer conditions, a CDN message shall be returned.

8.5.5.3. Rejection

When the accepting controller elects to reject the proposed amendment to the agreed transfer conditions:

- an RJC message shall be returned;

and

- a new co-ordination process shall be initiated.

Rejection is implied if neither an ACP or CDN is received in response to the RRV message.

8.5.6. Examples

8.5.6.1. ICAO

(RRVE/L059-AMM253-LMML-BNE/1226F310-EGBB)

8.5.6.2. ADEXP

-TITLE RRV -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 059 -ARCID AMM253 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F310 -ADES EGBB

8.6. Stand-by Message (SBY)

8.6.1. Purpose of the SBY Message

The SBY message acknowledges the receipt of a message proposing transfer conditions and indicates that the proposal is being referred to the controller for a decision.

8.6.2. Message Contents

The SBY message shall contain the following items of data:

- Message Type;

- Message Number;

- Message Reference.

NOTE

Data insertion rules, formats and field contents are specified at Annex A.

8.6.3. Rules of Application

8.6.3.1. General

The SBY message shall be generated and transmitted automatically immediately in response to:

- a RAP, RRV or CDN message;

- an ACT or REV message which fails the filter.

8.6.4. Acknowledgement of SBY

The SBY message shall not be acknowledged.

8.6.5. Examples

8.6.5.1. ICAO

(SBYL/E027E/L002)

8.6.5.2. ADEXP

-TITLE SBY -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 027 MSGREF-SENDER -FAC E -RECVR -FAC L -SEQNUM 002

8.7. Acceptance Message (ACP)

8.7.1. Purpose of the ACP Message

The ACP message satisfies the following operational requirements during the ATC co-ordination and transfer phases:

- indicate the manual acceptance by a controller in one unit of the transfer conditions proposed by the controller in the other unit in one of the following messages:

- RAP;

- RRV;

- CDN;

- ACT and REV, if either is found to be non-standard;

- when bilaterally agreed, provide the automatic acceptance of an ACT or REV message that has passed the filter in the accepting unit (in place of the LAM);

- when bilaterally agreed, indicate the manual acceptance of a HOP message (in place of the ROF message).

8.7.2. Message Contents

The ACP message consists of the following items of data:

- Mandatory data - the message shall contain:

- Message Type;

- Message Number;

- Message Reference;

- Optional data - the message may also include:

- Frequency;

- ICAO format messages optional data - the message may also contain all of the following items:

- Aircraft Identification;

- Departure Aerodrome;

- Destination Aerodrome.

NOTE

Data insertion rules, formats and field contents are specified at Annex A.

8.7.3. Rules of Application

8.7.3.1. General

8.7.3.1.1. The Message Reference of the ACP shall include the Message Number of the message to which it is in response.

8.7.3.1.2. The Frequency field, when included, shall contain the frequency on which the flight is to contact the accepting unit when the hand-over takes place.

8.7.3.1.3. The ACP message shall be sent following manual acceptance by the controller of proposed transfer conditions, forwarded by an ACT, RAP, REV, RRV or CDN.

8.7.3.1.4. The ACP message may be sent as an alternative to a ROF message in response to a HOP message.

8.7.3.1.5. When bilaterally agreed, the ACP message shall be generated and transmitted automatically by the system as a reply to an ACT/REV that has passed the filter.

8.7.3.1.6. When an ACP has been received, the agreed transfer conditions shall be binding for both units.

8.7.3.2. Processing in the Receiving Unit

8.7.3.2.1. The ATC system receiving an ACP message shall attempt association with the corresponding flight plan.

8.7.3.2.2. if the ACP can be associated with a flight plan the acceptance shall be indicated to the controller.

8.7.3.2.3. If the ACP cannot be associated with a flight plan:

- a warning shall be output at the appropriate position; and

- a LAM shall not be sent.

8.7.4. Acknowledgement of ACP

8.7.4.1. Acknowledgement

8.7.4.1.1. A LAM shall not be returned where the ACP is used as an automatic reply for an ACT or REV message that has passed the filter.

8.7.4.1.2. An ACP message sent as a result of a manual acceptance shall be acknowledged by generating and transmitting a LAM message.

8.7.4.2. No Acknowledgement Cases

If no LAM message is received as an acknowledgement for an ACP message sent as a result of a manual acceptance, a warning shall be displayed at the ATC position responsible for the co-ordination of the flight.

8.7.5. Examples

8.7.5.1. ICAO

(ACPL/E027E/L002-18/FRQ/242150)

8.7.5.2. ADEXP

-TITLE ACP -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 027 -MSGREF-SENDER -FAC E -RECVR -FAC L -SEQNUM 002 -FREQ 242150

8.8. Co-ordination Message (CDN)

8.8.1. Purpose of the CDN Message

The CDN message satisfies the following operational requirements:

- to forward a counter proposal from the accepting controller to the transferring controller as a reply to an ACT, a RAP, a REV or an RRV message;

- to initiate a proposed modification to agreed transfer conditions by the accepting controller to the transferring controller.

8.8.2. Message Contents

The CDN message consists of the following items of data:

- Mandatory data - the message shall contain:

- Message Type;

- Message Number;

- Message Reference (only if in response to another message);

- Aircraft Identification;

- Departure Aerodrome;

- Destination Aerodrome;

NOTE

The message shall also contain one, or both, of the following:

- Estimate Data (if an ICAO message) or Transfer Flight Level (if an ADEXP message);

- Direct Routing Request.

- Bilaterally agreed data - The following data may also be included, when bilaterally agreed:

- Frequency.

NOTE

Data insertion rules, formats and field contents are specified at Annex A.

8.8.3. Rules of Application

8.8.3.1. General

8.8.3.1.1. CDN messages shall be initiated by the accepting controller only.

8.8.3.1.2. It shall be used to transmit a counter proposal from the accepting controller to the transferring controller.NOTE

This can be in a dialogue as a reply to a proposal forwarded by an ACT, RAP, REV, or RRV, or as the start of a dialogue to amend previously agreed transfer conditions.

8.8.3.1.3. The message reference shall only be inserted when the CDN message is in reply to another message.

8.8.3.1.4. When inserted, the message reference shall contain the message number of the message to which the CDN is in reply.

8.8.3.1.5. The Direct Routing Request facility (described in detail in Annex A) shall:

- only be used if bilaterally agreed; and

- if agreed, define any operational limits to its use.

8.8.3.1.6. The CDN shall not be sent after a time/distance before the boundary specified in the LoA between the units concerned.

8.8.3.1.7. In the event that a CDN is transmitted effectively simultaneously with a message for the same flight from the transferring unit, e.g. a revision or an abrogation of co-ordination, neither an acknowledgement nor an operational reply shall be returned.NOTE

The effect of this is that when two messages cross, the one from the transferring unit takes priority and the CDN is dropped by both. Both units can sense the situation by the receipt of the message from the other before receiving the acknowledgement.

8.8.3.1.8. As soon as an acceptance has been received the CDN message data becomes operationally binding to both of the ATC units. The co-ordinated transfer conditions and the fact that the ACP has been received shall be presented to the ATC staff concerned.

8.8.3.2. Processing in the Receiving Unit

8.8.3.2.1. If a corresponding flight plan is found and no discrepancy is present in the message that would inhibit correct processing:

- the operational content shall be presented at the ATC position responsible for the co-ordination of the flight;

and

- an SBY shall be returned.

8.8.3.2.2. If the CDN cannot be associated, or a discrepancy is found that inhibits correct processing of the message, no SBY shall be returned.

8.8.4. Acknowledgement of CDN

8.8.4.1. Acknowledgement

Under the conditions specified above, the CDN message shall be acknowledged by the generation and transmission of an SBY message.

8.8.4.2. No Acknowledgement Cases

If no SBY message is received as an acknowledgement for a CDN message, a warning shall be displayed at the ATC position responsible for the co-ordination of the flight.

8.8.5. Operational Reply to CDN

The controller may either accept or reject the transfer conditions proposed in a CDN message.

8.8.5.1. Acceptance

When the transferring controller elects to accept the proposed transfer conditions, an ACP message shall be returned.

8.8.5.2. Recommendation

When the transferring controller elects to reject the proposed transfer conditions, an RJC message should be sent (explicit rejection).

NOTE

The proposed co-ordination is implicitly rejected if no acceptance has been received by the time that the CDN message times-out.

8.8.6. Examples

8.8.6.1. ICAO

(CDNL/D041D/L025 -EIN636 -EIDW -LIFFY/1638F270F110A -EBBR)

8.8.6.2. ADEXP

-TITLE CDN -REFDATA -SENDER -FAC L -RECVR -FAC D -SEQNUM 041 -MSGREF -SENDER -FAC D -RECVR -FAC L -SEQNUM 025 -ARCID EIN636 -ADEP EIDW -ADES EBBR -PROPFL -TFL F270 -SFL F110A

8.9. Reject Co-ordination Message (RJC)

8.9.1. Purpose of the RJC Message

The RJC message indicates the rejection by a controller at one unit of the transfer conditions proposed by the controller at the other unit in one of the following messages:

- RAP;

- RRV;

- CDN;

- ACT and REV, if either is found to be non-standard.

The RJC message can only be used in direct response to one of the above messages.

8.9.2. Message Contents

The RJC message shall contain the following items of data:

- Message Type;

- Message Number;

- Message Reference.

NOTE

Data insertion rules, formats and field contents are specified at Annex A.

8.9.3. Rules of Application

8.9.3.1. General

8.9.3.1.1. The RJC shall be sent as required in response to a RAP, RRV, CDN message or to a ACT or REV message found to be non-standard at the accepting unit.

8.9.3.1.2. The RJC message terminates the system dialogue and any previously agreed co-ordination remains valid.

8.9.3.1.3. Recommendation

Following the reception of an RJC message a new co-ordination sequence should be initiated, reflecting the telephone co-ordination where applicable.

8.9.3.2. Processing in the Receiving Unit

8.9.3.2.1. If a corresponding message to which the RJC message refers is found;

- the rejection shall be indicated at the ATC position responsible for the co-ordination of the relevant flight; and

- a LAM shall be returned in acknowledgement.

8.9.3.2.2. If no such message is found to be awaiting reply, or a discrepancy is present in the message which prevents processing, no acknowledgement shall be returned.

8.9.4. Acknowledgement of RJC

8.9.4.1. Acknowledgement

The RJC message shall be acknowledged by the generation and transmission of a LAM message.

8.9.4.2. No Acknowledgement Cases

If no LAM message is received as an acknowledgement for an RJC message, a warning shall be displayed at the ATC position responsible for the co-ordination of the flights.

8.9.5. Examples

8.9.5.1. ICAO

(RJCMC/E746E/MC324)

8.9.5.2. ADEXP

-TITLE RJC -REFDATA -SENDER -FAC MC -RECVR -FAC E -SEQNUM 746 -MSGREF -SENDER -FAC E -RECVR -FAC MC -SEQNUM 324

9. DIALOGUE PROCEDURE - TRANSFER OF COMMUNICATION

9.1. General

9.1.1. Introduction

9.1.1.1. This section of the Standard describes the facilities and messages that support the radar hand-over aspect of the transfer of control procedure. They shall be implemented where bilaterally agreed.

9.1.1.2. Transfer of Communication facilities shall not be implemented unless the unit is utilising either the co-ordination facilities described in Section 6 (Basic Procedure - Mandatory Messages) or those in Section 8 (Dialogue Procedure - Co-ordination).

9.1.1.3. The messages described in this section of the document are available only in ADEXP format and it is not planned that they be made available in ICAO format.

9.1.2. Message Sequence

9.1.2.1. Transfer of Communication message exchange, other than the Supplementary Data Message (SDM), shall not take place unless co-ordination is complete, i.e. an ACT or RAP dialogue has been completed by a LAM or ACP.

9.1.2.2. An acknowledgement shall not be returned whilst co-ordination is outstanding.

9.1.3. Transfer of Communications

9.1.3.1. The method of signifying the actual change of communication of flights shall be bilaterally agreed between the two units concerned.

9.1.3.2. The conditions shall be one or both of the following:

- the transferring unit sends a Change Of Frequency message (COF);

- the accepting unit sends a Manual Assumption of Communication message (MAS);

9.1.3.3. The method shall be agreed between the two units for each traffic flow.NOTE

Alternative methods may be used for different flows, e.g. one unit may generate COF messages for flights leaving its airspace and MAS messages for flights entering its airspace. In such a case it would not be necessary for the other unit to enter any messages to signify transfer of communication.

9.2. Transfer Initiation Message (TIM)

9.2.1. Purpose of the TIM Message

The purpose of the TIM is to:

- signify the Transfer Initiation (TI) event (the end of the co-ordination phase and the start of the transfer phase);

- simultaneously forward executive control data from the transferring to the accepting unit.

9.2.2. Message Contents

The TIM message shall consist of the following items of data:

- Mandatory data - the message shall contain:

- Message Type;

- Message Number;

- Aircraft Identification;

- Available data - the message shall also contain any of the following, if available:

- Cleared Flight Level;

- Assigned Heading or Direct Clearance;

- Assigned Speed;

- Assigned Rate of Climb/Descent;

- Optional data - the message may also contain:

- Position.

NOTE

Data insertion rules, formats and field contents are specified at Annex A.

9.2.3. Rules of Application

9.2.3.1. General

9.2.3.1.1. The TIM message shall be generated and transmitted by the transferring unit to the accepting unit without human intervention at a bilaterally agreed time/distance of the flight from the boundary.

9.2.3.1.2. A TIM message shall also be sent automatically when the Request On Frequency message (ROF) is received by the transferring unit.

9.2.3.1.3. A TIM shall not be sent before the flight has been co-ordinated.

9.2.3.1.4. The TIM message shall contain the most recent data available in the system.

9.2.3.2. Time Parameters for Transmission

9.2.3.2.1. The TIM generation parameter shall be a Variable System Parameter which may be changed, based on the provisions of the LoAs.

9.2.3.2.2. Recommendation

The TIM generation system parameter should be defined separately for each of the COPs.

9.2.3.2.3. The co-ordination partners shall include the TIM generation parameters in their LoA.

9.2.3.2.4. The system parameter triggering the TIM message may be related to the calculated ground speed of the aircraft. However, initiation of a TIM message shall always commence before the current flight plan position is closer to COP than a minimum distance specified bilaterally.

9.2.3.2.5. The specified system parameter for TIM transmission shall allow sufficient time for verbal co-ordination before the hand-over.

9.2.3.3. Processing in the Receiving Unit

9.2.3.3.1. The data received in a TIM shall be made available to the accepting controller.

9.2.4. Acknowledgement of TIM

9.2.4.1. Acknowledgement

If the TIM message:

- can be unambiguously associated with a flight plan, it shall be acknowledged by the generation and transmission of a LAM message;

- cannot be unambiguously associated with a flight plan, no acknowledgement shall be sent.

9.2.4.2. No Acknowledgement Cases

If no LAM message is received as an acknowledgement for an TIM message, a warning shall be displayed at the appropriate position.

9.2.5. Example

-TITLE TIM -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 029 -ARCID AMM253

9.3. Supplementary Data Message (SDM)

9.3.1. Purpose of the SDM Message

9.3.1.1. General

9.3.1.1.1. The primary purpose of the SDM is to transmit control data and changes thereto from the transferring unit to the accepting unit, provided that it has been bilaterally agreed that the changes do not need to be acknowledged by the accepting controller.

9.3.1.1.2. The SDM message may also be used by the accepting unit to notify the transferring unit of the radio telephony frequency to which the flight is to be transferred.

9.3.2. Message Contents

9.3.2.1. Messages from the Transferring Unit

The SDM message shall consist of the following items of data:

- Mandatory data - the message shall contain:

- Message Type;

- Message Number;

- Aircraft Identification;

- Additional data - the message shall also contain one or more of the following:

- Assigned Heading or Direct Clearance;

- Assigned Speed;

- Assigned Rate of Climb/Descent;

- Cleared Flight Level.

9.3.2.2. Messages from the Accepting Unit

The SDM shall contain the following data:

- Message Type;

- Message Number;

- Aircraft Identification;

- Frequency.

NOTE

Data insertion rules, formats and field contents are specified at Annex A.

9.3.3. Rules of Application

9.3.3.1. Messages from the Transferring Unit

9.3.3.1.1. SDM messages shall be transmitted after the initiation of the transfer phase (see TIM, paragraph 9.2) following any change to the following items:

- cleared flight level;

- assigned speed;

- assigned rate of climb/descent;

- assigned heading; or

- issue or change of a clearance for the flight to proceed direct to a specified point.

NOTE

The HOP message is required to be used when approval by the accepting controller is required prior to the transfer of communication.

9.3.3.1.2. The message shall contain only the fields which have changed.

9.3.3.1.3. SDM messages containing the data described in 9.3.3.1.1 shall be transmitted before TI, if bilaterally agreed.

9.3.3.1.4. Such messages shall commence at a bilaterally agreed time relative to TI, provided that there is data for which there is a value available in the system.

9.3.3.2. Messages from the Accepting Unit

9.3.3.2.1. SDM messages may be transmitted to indicate the frequency on which the flight is to contact the accepting unit.NOTE

Units may agree bilaterally to send other information. Such transfer is not defined in, and therefore, not part of, this Standard.

9.3.3.2.2. SDM messages from the accepting unit shall be transmitted during the co-ordination phase if bilaterally agreed.

9.3.3.3. Processing in the Receiving Unit

9.3.3.3.1. The ATC system receiving an SDM message shall attempt association with the corresponding flight plan.

9.3.3.3.2. If a corresponding flight plan in the co-ordinated state is found:

- a LAM shall be returned; and

- the operational contents of the SDM message shall be made available to the appropriate controller.

9.3.3.3.3. If a corresponding flight plan cannot be found, or a discrepancy is found that inhibits correct processing of the message:

- no LAM shall be returned; and

- a warning shall be output at an appropriate position.

9.3.4. Acknowledgement of SDM

9.3.4.1. Acknowledgement

The SDM message shall be acknowledged by the generation and transmission of a LAM message.

9.3.4.2. No Acknowledgement Cases

If no LAM message is received as an acknowledgement for an SDM message, a warning shall be displayed at an appropriate position.

9.3.5. Example

-TITLE SDM -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 028 -ARCID AMM253 -AHEAD 290

9.4. Hand-Over Proposal (HOP)

9.4.1. Purpose of the HOP Message

The purpose of the HOP Message is:

- for the transferring controller to draw the attention of the accepting controller to a specific flight for handover purposes;

- for the transferring controller to propose the flight for hand-over to the accepting controller when it is required to do so;

- to forward modifications to the executive control data which require the approval of the accepting controller, as bilaterally agreed.

It is not necessary to utilise the HOP for all flights; it is used at the discretion of the transferring controller.NOTE

With respect to paragraph c) above, the SDM is used to forward modifications to executive control data which do not require the approval of the accepting controller.

9.4.2. Message Contents

The HOP message shall consist of the following items of data:

- Mandatory data - the message shall contain:

- Message Type;

- Message Number;

- Aircraft Identification;

- Available data - the message shall also contain any of the following, if available:

- Cleared Flight Level;

- Assigned Heading/Direct Clearance;

- Assigned Speed;

- Assigned Rate of Climb/Descent;

- Optional data - the message may also contain:

- Position.

NOTE

Data insertion rules, formats and field contents are specified at Annex A.

9.4.3. Rules of Application

9.4.3.1. General

9.4.3.1.1. The HOP message, when used, shall be manually initiated by the transferring controller.

9.4.3.1.2. The message shall include any flight data described in paragraph 9.4.2 above which has changed from that previously transmitted.

9.4.3.1.3. If a HOP message is sent before TI, the Transfer phase shall be initiated.NOTE

A Transfer Initiation Message (TIM) is not required in addition to the HOP.

9.4.3.1.4. The earliest time or distance before the COP or boundary at which a HOP may be sent shall be bilaterally agreed.

9.4.3.1.5. Recommendation

The time/distance should be specified separately for each COP.

9.4.3.2. Processing in the Receiving Unit

9.4.3.2.1. The ATC system receiving a HOP message shall attempt association with the corresponding flight plan.

9.4.3.2.2. The flight data received in the message shall be displayed immediately to the accepting controller.

9.4.3.2.3. If the accepting controller accepts the flight under the conditions proposed in the HOP, a ROF may be sent in response to the transferring unit. When bilaterally agreed an ACP may be sent as a reply to a HOP.

9.4.3.2.4. If the accepting controller is unable to accept the flight, the transfer shall be agreed verbally.NOTE

Due to the urgency of the handover procedure, system support in monitoring the return of the ROF (or ACP) is not required by this Standard; it is assumed that the transferring controller will be well aware of the absence of a response from the accepting controller and will take action as necessary. However, this Standard does not prevent a warning being provided to the transferring controller if it is considered operationally necessary.

9.4.3.2.5. As soon as a ROF (or ACP) has been received, the HOP message data shall become operationally binding to both of the ATC units.

9.4.4. Acknowledgement of HOP

9.4.4.1. Acknowledgement

If it can be associated with a flight plan, the HOP message shall be acknowledged automatically by a LAM.

9.4.4.2. No Acknowledgement Cases

If no LAM message is received as an acknowledgement for a HOP message, a warning shall be displayed at the appropriate position.

9.4.5. Example

-TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253 -CFL F190 -ASPEED N0420 -RATE D25 -DCT BEN STJ

9.5. Request on Frequency Message (ROF)

9.5.1. Purpose of the ROF Message

The ROF is sent by the accepting unit to the transferring unit, when required, requesting the transferring controller to instruct the aircraft to change to the frequency of the accepting controller. The message may be used:

- in reply to a HOP to signify the acceptance of the flight under the proposed conditions;

- to request the early transfer of the flight.

9.5.2. Message Contents

The ROF message shall consists of the following items of data:

- Mandatory data - the message shall contain:

- Message Type;

- Message Number;

- Aircraft Identification;

- Optional data - the message may also contain:

- Frequency.

NOTE

Data insertion rules, formats and field contents are specified at Annex A.

9.5.3. Rules of Application

9.5.3.1. General

9.5.3.1.1. The ROF message shall be manually initiated by the accepting controller.

9.5.3.1.2. The accepting controller may trigger a ROF, either:

- when the accepting controller requires to have the aircraft early on frequency;

- as a reply to a HOP message.

9.5.3.2. Processing in the Receiving Unit

9.5.3.2.1. The ATC system receiving an ROF message shall attempt association with the corresponding flight plan.

9.5.3.2.2. The reception of the ROF shall be indicated to the transferring controller without delay.

9.5.3.2.3. If the flight is not in the Transfer phase, the Transfer phase shall be initiated and a TIM message shall be transmitted.

9.5.4. Acknowledgement of ROF

9.5.4.1. Acknowledgement

9.5.4.1.1. If the ROF message can be unambiguously associated with a flight plan, it shall be acknowledged by the generation and transmission of a LAM message.

9.5.4.1.2. If the ROF message cannot be unambiguously associated with a flight plan, no acknowledgement shall be sent.

9.5.4.2. No Acknowledgement Cases

If no LAM message is received as an acknowledgement for an ROF message, a warning shall be displayed at the appropriate ATC position.

9.5.5. Example

-TITLE ROF -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253

9.6. Change of Frequency Message (COF)

9.6.1. Purpose of the COF Message

9.6.1.1. General

9.6.1.1.1. The COF is sent by the transferring unit to the accepting unit, to indicate that the flight has been instructed to contact the accepting controller.

9.6.1.1.2. The message may include the facility for the transferring controller to release the flight from the agreed transfer conditions when it has established radio communication with the accepting controller.

9.6.2. Message Contents

The COF message shall consist of the following items of data:

- Mandatory data - the message shall contain:

- Message Type;

- Message Number;

- Aircraft Identification;

- Available data - the message shall also contain any of the following, if available:

- Release Indication;

- Frequency;

- Cleared Flight Level;

- Assigned Heading or Direct Clearance;

- Assigned Speed;

- Assigned Rate of Climb/Descent;

- Optional data - the message may also contain:

- Position.

NOTE

Data insertion rules, formats and field contents are specified at Annex A.

9.6.3. Rules of Application

9.6.3.1. General

9.6.3.1.1. The COF message shall be manually initiated by the transferring controller.

9.6.3.1.2. The use of the COF message is mandatory if, by bilateral agreement, the MAS message is not used.

9.6.3.1.3. If a COF message is sent before TI, the Transfer phase shall be initiated.NOTE

A Transfer Initiation Message (TIM) is not required in addition to the COF.

9.6.3.2. Processing in the Receiving Unit

9.6.3.2.1. The ATC system receiving a COF message shall attempt association with the corresponding flight plan.

9.6.3.2.2. The reception of the COF shall be indicated to the accepting controller without delay.

9.6.4. Acknowledgement of COF

9.6.4.1. Acknowledgement

9.6.4.1.1. If the COF message can be unambiguously associated with a flight plan, it shall be acknowledged by the generation and transmission of a LAM message.

9.6.4.1.2. If the COF message cannot be unambiguously associated with a flight plan, no acknowledgement shall be sent.

9.6.4.2. No Acknowledgement Cases

If no LAM message is received as an acknowledgement for a COF message, a warning shall be displayed at the appropriate ATC position.

9.6.5. Examples

-TITLE COF -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253

9.7. Manual Assumption of Communications Message (MAS)

9.7.1. Purpose of the MAS Message

The MAS is sent by the accepting unit to the transferring unit indicating that two-way radio contact has been established with the flight.

9.7.2. Message Contents

The MAS message shall contain the following items of data:

- Message Type;

- Message Number;

- Aircraft Identification.

NOTE

Data insertion rules, formats and field contents are specified at Annex A.

9.7.3. Rules of Application

9.7.3.1. General

9.7.3.1.1. The MAS message shall be manually initiated by the accepting controller.

9.7.3.1.2. The use of the MAS message is mandatory if, by bilateral agreement, the COF message is not used.

9.7.3.2. Processing in the Receiving Unit

9.7.3.2.1. The ATC system receiving a MAS message shall attempt association with the corresponding flight plan.

9.7.3.2.2. The fact that the MAS has been received shall be presented immediately to the controller.

9.7.4. Acknowledgement of MAS

9.7.4.1. Acknowledgement

9.7.4.1.1. If the MAS message can be unambiguously associated with a flight plan, it shall be acknowledged by the generation and transmission of a LAM message.

9.7.4.1.2. If the MAS message cannot be unambiguously associated with a flight plan, no acknowledgement shall be sent.

9.7.4.2. No Acknowledgement Cases

If no LAM message is received as an acknowledgement for an MAS message, a warning shall be displayed at the appropriate ATC position, as required.

9.7.5. Example

-TITLE MAS -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253

ANNEX A (Normative)

DATA INSERTION RULES

CONTENTS

>TABLE>

A.1. Purpose

This Annex describes the general rules for the insertion of data in the messages described in this Standard. These rules apply to all messages except where other alternatives or exceptions to these rules are specifically stated in the Rules of Application for a specific message.

A.2. Generic Message Formats

A.2.1. All messages described in the following sections may be transmitted using ICAO format:

6 Basic Procedure - Mandatory Messages;

7 Basic Procedure - Complementary Messages;

8 Dialogue Procedure - Co-ordination.

A.2.2. ICAO message field formats are specified in the Procedures for Air Navigation Services - Rules of the Air and Air Traffic Control (Document 4444). In messages where they occur, the following ICAO Field types shall be transmitted before any other Field types in the following order: 3, 7, 13, 14, and 16. As they are in Field type 22 format, the order of other ICAO Field types is not important, other than that they do not precede the Field types listed above.

A.2.3. All messages described in this document may be transmitted using Eurocontrol ADEXP format. The contents, structure, and usage of ADEXP data fields shall be in accordance with Reference 2.NOTES

1. Only the Primary ADEXP data fields are listed in this Annex, except where associated Sub-fields require specific comment. The ADEXP Standard lists all optional and mandatory Sub-fields required within each Primary field.

2. Messages described in Section 9, Dialogue Procedure - Transfer of Communication, are described only in ADEXP format.

A.3. Message Type

The message type shall be the abbreviation for the message as described in the following list:

ABI: Advance Boundary Information.

ACP: Acceptance.

ACT: Activate.

CDN: Co-ordination.

COD: SSR Code Assignment.

COF: Change of Frequency.

HOP: Hand-Over Proposal.

INF: Information.

LAM: Logical Acknowledgement Message.

MAC: Message for Abrogation of Co-ordination.

MAS: Manual Assumption of Communications.

PAC: Preliminary Activation.

RAP: Referred Activate Proposal.

REV: Revision.

RJC: Reject Co-ordination.

ROF: Request on Frequency.

RRV: Referred Revision Proposal.

SBY: Stand-by.

SDM: Supplementary Data Message.

TIM: Transfer Initiation Message.

A.3.1. ICAO

Field type 3, element (a).

A.3.2. ADEXP

Primary field "title".

A.4. Message Number

The message number data includes the identifiers assigned to the transmitting and receiving units and the message sequence number. The message sequence number progresses sequentially from 001 to 000 (representing 1000), thence repeats from 001 for all messages sent to the same addressee, regardless of the type of message.

A.4.1. ICAO

Field type 3, element (b).

A.4.2. ADEXP

Primary field "refdata".

Sub-field "fac", within sub-fields "sender" and "recvr", shall contain the identifiers assigned to the ATC units. These identifiers shall be not greater than eight characters in length.

Sub-field "seqnum" shall contain the sequence number.

A.5. Message Reference

A.5.1. ICAO

Field type 3, element (c) (called "reference data" in ICAO document 4444).

The content of element (c) shall be that of Field type 3, element (b), of the OLDI message referred to.

A.5.2. ADEXP

Primary field "msgref".

The values of Sub-fields "sender", "recvr", and "seqnum", within Primary field "msgref", shall be those of the same Sub-fields within Primary field "refdata" of the OLDI message referred to.

A.6. Aircraft Identification

A.6.1. ICAO

Field type 7, element (a).

A.6.2. ADEXP

Primary field "arcid".

A.7. SSR Mode and Code

Either:

1. if known, the SSR mode/code on which the receiving unit can expect the aircraft to respond at the transfer of control point;

or

2. an indicator that the SSR code is being requested from the receiving unit.

A.7.1. ICAO

Field type 7, elements (b) and (c).

If no SSR code is assigned or the mode/code is not known, elements (b) and (c) shall be omitted.

When requesting an SSR code/mode, elements b) and c) shall contain the value "A9999".

A.7.2. ADEXP

Primary field "ssrcode".

If no valid SSR code is assigned or the mode/code is not known, the field shall be omitted.

When requesting an SSR code/mode via the PAC message, primary field "ssrcode" shall contain the indicator "REQ".

A.8. Departure Aerodrome

A.8.1. ICAO

Field type 13, element (a).

A.8.2. ADEXP

Primary field "adep".

A.9. Estimate Data

A.9.1. General

A.9.1.1. Estimate data shall include the COP, time at the COP and transfer level.

A.9.1.2. The co-ordination point shall be defined as either a known reference point, a range and bearing from a known reference point, or a latitude and longitude.

A.9.1.3. The cleared (transfer) level shall correspond to the proposed transfer conditions.

A.9.1.4. Recommendation

For climbing or descending flights, the estimate data should also contain supplementary crossing data and crossing conditions.

A.9.1.5. If used, the supplementary crossing data shall contain the supplementary crossing level at the transfer of control point. The crossing conditions shall be:

- Letter 'A'; - if the flight will be at or above the level in the supplementary crossing data; or

- Letter 'B'; - if the flight will be at or below the level in the supplementary crossing data.

A.9.2. ICAO

Field type 14.

A.9.3. ADEXP

Primary field "coordata".

Subfield "ptid" within Primary field "coordata" shall contain either:

- a known reference point; or

- a bearing and distance from a known reference point, as defined in the same message by Primary field "REF" or "GEO".

A.10. Co-ordination Point

A.10.1. General

A.10.1.1. The co-ordination point referred to by the transferring and receiving ATC units for the purposes of the transfer concerned.

A.10.1.2. The co-ordination point shall be defined as either a known reference point, a range and bearing from a known reference point, or a latitude and longitude.

A.10.2. ICAO

Field 14, element (a).

A.10.3. ADEXP

Primary field "cop" containing:

- a known reference point; or

- a bearing and distance from a known reference point, as defined in the same message by Primary field "REF" or "GEO".

A.11. Destination Aerodrome

A.11.1. ICAO

Field 16, element (a).

A.11.2. ADEXP

Primary field "ades".

A.12. Aircraft Number and Type

Aircraft number and type shall contain the type of aircraft. The number of aircraft shall be included in the case of formation flights.

A.12.1. ICAO

Field type 9 in field type 22 format. Element c of field type 9 shall contain either the wake turbulence category appropriate to the type of aircraft or the letter "Z".

A.12.2. ADEXP

Primary field "arctyp". In addition, if there is more than one aircraft in the flight, Primary field "nbarc".

A.13. Route

Both formats support the route description as defined for ICAO messages which requires as the first element speed and requested flight level or altitude information. After the speed level group, the route data will include as a minimum that specified in the following paragraph. Further route data may be inserted after item c) if available. See also Annex B "Special Route Processing Requirements" for insertion rules for route data.

A.13.1. Content

A.13.1.1. Flights Proceeding via a Defined COP

- the route element before the COP (ATS route, SID identifier, DCT or significant point);

- the COP;

- the route element after the COP (ATS route or significant point).

A.13.1.2. Flights Proceeding Off ATS Route

- the point from which the flight is proceeding on the direct route segment;

- the element "DCT";

- the point to which the flight is proceeding on the direct route segment.

A.13.2. Format

A.13.2.1. ICAO

Field type 15, in field type 22 format.

A.13.2.2. ADEXP

Primary field "route".

A.14. Other Flight Plan Data

A.14.1. ICAO

Field types 8, 10, and 18, in the field type 22 format.

A.14.2. ADEXP

Primary fields: "afildata", "ceqpt", "com", "comment", "depz", "destz", "eetfir", "eetpt", "fltrul", "flttyp", "mach", "nav", "opr", "per", "reg", "rif", "rmk", "sel", "seqpt", "sts", and "typz".

A.15. Co-ordination Status and Reason

Co-ordination status and Reason shall include the following elements:

- a three letter indicator confirming the new status of the system flight plan, to be one of the following:

- INI, when the system flight plan is to be in an initial state, i.e. no notification message received;

- NTF, when the system flight plan is to be in a notified status;

- CRD, when the system flight plan is to be in co-ordinated status, i.e. basic ACT received or initial co-ordination dialogue completed with conditions agreed.

- a three letter indicator specifying the reason for the status to be one of the following:

- TFL, if the reason is a change of transfer level;

- RTE, if the reason is a change of route;

- HLD, to indicate that the flight is holding for an indefinite period and will be subject to a further message;

- DLY, to indicate that the departure is delayed;

- CAN, if the reason is a cancellation;

- CSN, for a change of callsign;

- OTH, for any other reason or if the reason is unknown.

A.15.1. ICAO

A.15.1.1. The co-ordination status and reason shall be in the Field type 18 format.

A.15.1.2. The co-ordination status and reason shall include the following elements as a ten character group:

- STA followed by an oblique stroke;

- the indicator to confirm the new status of the notification/co-ordination;

- the indicator specifying the reason.

A.15.2. ADEXP

Primary field "cstat".

Auxiliary items "coordstatusident" and "coordstatusreason" shall contain the new status and reason as specified above respectively.

A.16. Assigned Heading (ADEXP only)

Primary field "ahead" shall contain either:

- the heading assigned to a flight, expressed in degrees;

or

- if no heading is assigned, the indicator "ZZZ", e.g. when an SDM message is used to indicate that a previously assigned heading no longer applies.

A.17. Assigned Speed (ADEXP only)

Primary field "aspeed" shall contain either:

- the speed assigned to a flight, expressed in knots, mach number, or kilometres/hour;

or

- if no speed is assigned, the indicator "ZZZ", e.g. when an SDM message is used to indicate that a previously assigned speed no longer applies.

A.18. Assigned Rate of Climb/Descent (ADEXP only)

Primary field "rate" shall contain:

- the climb or descent rate assigned to a flight, expressed in hundreds of feet per minute;

or

- if no rate of climb/descent is assigned, the indicator "ZZZ" in the digit portion of the field, e.g. when an SDM message is used to indicate that a previously assigned rate of climb/descent no longer applies.

A.19. Direct Clearance (ADEXP only)

A direct route, not defined as an ATS route, between two points. The points can be defined as either a known reference point or a range and bearing from a reference point. All endpoint designators used shall be bilaterally agreed, i.e. known to both systems.

Primary field "DCT" containing:

- the point at which the deviation has or will commence, defined as one of:

- a known reference point;

or

- a range and bearing from a known reference point, as defined in the same message by Primary field "REF";

or

- the value "ZZZ" if the sending unit does not require to designate the deviation point.

- the point situated on the original flight plan route to which the aircraft has been or will be cleared, defined as:

- a known reference point;

or

- a range and bearing from a known reference point, as defined in the same message by Primary field "REF".

A.20. Direct Routing Request

Request for a direct route, not defined as an ATS route, between two points. The points can be defined as either a known reference point or a range and bearing from a reference point.

All endpoint designators used shall be bilaterally agreed, i.e. known to both systems.

A.20.1. ICAO

Field type 15, excluding the initial speed/level group, in field 22 format.

It shall contain:

- the point at which the deviation is requested to commence, defined as one of:

- a known reference point;

or

- a range and bearing from a known reference point;

or

- the value "ZZZ" if a direct routing is being requested by the receiving ATC unit.

- the abbreviation "DCT",

- followed by the point situated on the original flight plan route to which the aircraft is requested to be cleared, defined as:

- a known reference point;

or

- a range and bearing from a known reference point.

A.20.2. ADEXP

Primary field "DCT" containing:

- the point at which the deviation is requested to commence, defined as one of:

- a known reference point;

or

- a range and bearing from a known reference point, as defined in the same message by Primary field "REF";

or

- the value "ZZZ" if a direct routing is being requested by the receiving ATC unit but the precise point at which it would commence is not known.

- the point situated on the original flight plan route to which the aircraft is requested to be cleared, defined as:

- a known reference point;

or

- a range and bearing from a known reference point, as defined in the same message by Primary field "REF".

A.21. Position (ADEXP only)

A.21.1. General

A.21.1.1. The current position of the flight expressed in either geographic co-ordinates or by bearing and distance from a designated point.

A.21.1.2. Primary field "ref" or "geo" shall define the current horizontal location of the aircraft. Points used for range and bearing purposes in primary field "ref" shall be bilaterally agreed, i.e. known to both systems. Primary field "position" shall contain the subfield "ptid" which refers to the defined reference or geographic point. If time information is to be included, either sub-field "to" (hhmm) or "sto" (hhmmss) is to be used, as bilaterally agreed.

A.22. Release Indication (ADEXP only)

Primary field "release" shall contain one of the following:

- C, if the flight is released for climb;

- D, if the flight is released for descent;

- T, if the flight is released for turns;

- F, if the flight is fully released for all actions.

A.23. Frequency

A.23.1. ICAO

Field type 18 shall include the following elements in field 22 format:

- FRQ, followed by an oblique stroke;

- 6 digits indicating the frequency, expressed in MHz to three decimal places.

A.23.2. ADEXP

Primary field "freq".

A.24. Reason (ADEXP only)

Primary field "reason", containing the value "MANUAL" for manually referred messages.

A.25. Cleared Flight Level (ADEXP only)

Primary field "cfl".

A.26. Proposed Transfer Flight Level (ADEXP only)

Primary field "propfl".

A.27. Estimated Take-Off Time

A.27.1. ICAO

Field type 13 element (b).

A.27.2. ADEXP

Primary field "etot".

A.28. Reference Message Type

The field contains the message type as specified in paragraph A.1 of this Annex.

A.28.1. ICAO

Field type 18 in field type 22 format. The element indicator shall be "MSG".

A.28.2. ADEXP

Primary field "msgtyp".

ANNEX B (Normative)

SPECIAL ROUTE PROCESSING REQUIREMENTS

B.1. Introduction

B.1.1. General

B.1.1.1. This Annex describes the rules and data insertion requirements in the following cases, when permitted:

- a flight routes on a direct track, off route, across the boundary as the result of a direct route segment filed in the flight plan;

- after transmission of the ABI or ACT message, a flight is re-routed via either:

- a different ATS route;

- a direct track to rejoin the original route at a later point.

B.1.1.2. With respect to the re-routing of flights (paragraph B.1.1.1), the data exchange described in this Annex supports the modification of the route of flight as held in both systems by the use of notification and co-ordination messages.

B.2. Application of Messages

B.2.1. Basic Rules for Direct Routings

B.2.1.1. Conditions for the use of OLDI for the co-ordination of flights on direct routings shall be agreed bilaterally.

B.2.1.2. The data required for the notification and co-ordination of flights on direct routings is contained in the co-ordination point (estimate data (ICAO format) and co-ordination data (ADEXP format)) and route in the applicable messages.

B.2.2. Direct Route Filed

When the route indicates that the flight will cross the boundary on a direct track, the direct route segment and the resultant COP will be included in the ABI message(s). This COP is included in the subsequent ACT or RAP message.

The COP and route data shall be formatted as described in paragraph B.3.2.

B.2.3. Re-routings after ABI and before ACT Transmission

A new ABI message shall be sent with data corresponding to the new route.

B.2.4. Re-routing after ACT transmission

B.2.4.1. A REV message shall be used to indicate re-routings after the ACT message has been sent until a bilaterally agreed time before the ETO at the COP previously co-ordinated.NOTE

A REV message is only used where the accepting unit does not change as the result of the modification. If it does change, a MAC message must be sent to the original accepting unit or the co-ordination verbally cancelled.

B.2.4.2. The message shall contain the following data elements:

- Co-ordination point (previous COP, for reference purposes);

- Estimate data;

- Route.

B.2.4.3. ICAO format messages shall contain the following fields:

3 Message type and number; message reference if bilaterally agreed;

7 Aircraft identification. Elements b and c shall not be included unless a revision o the SSR code is being co-ordinated simultaneously;

13 Departure aerodrome;

14 Element a only, containing the previous COP for reference purposes;

16 Destination;

22 Field 14 containing the estimate data for the new boundary crossing conditions in field 22 format;

22 Field 15 containing the new route in field 22 format.

B.2.4.4. ADEXP format messages shall include, in addition to the message type and number, aircraft identification, departure aerodrome, destination and, if bilaterally agreed, the message reference number:

- the previous COP in the COP field;

- the new co-ordination conditions in the COORDATA field;

- the new route in the ROUTE field.

B.2.4.5. Route revisions sent as part of the dialogue procedure shall be sent as RRV messages unless bilaterally agreed to be considered "standard".

B.3. Field Contents

B.3.1. ATS Routes

For flights which re-route via an alternative ATS Route, the estimate and route fields are formatted as for ABI and ACT messages.

B.3.2. Direct Routes

B.3.2.1. The co-ordination point in the estimate data shall be the point of boundary crossing expressed as a bearing and distance from a reporting point. Such points shall be bilaterally agreed. Where the distance is zero or a flight will pass within a bilaterally agreed distance from such a point, only the identifier of the point shall be included.

B.3.2.2. When bilaterally agreed, the co-ordination point for a flight on a direct route may be expressed by reference to latitude/longitude.

B.3.2.3. The route shall contain:

- the point situated on the original route from which the aircraft is to route direct; where a flight is routed direct from "present position", the point may be expressed as a bearing and distance from a reporting point. When bilaterally agreed, the point may be expressed by reference to latitude/longitude;

- the abbreviation "DCT";

- the point to which the aircraft is to proceed directly;

- the remainder of the further route of flight (FRF), if known to the sending system.

B.4. Examples

B.4.1. Direct Routes

B.4.1.1. ABI and ACT Messages

B.4.1.1.1. The flight (identification Jetset 253) is to cross the boundary on a direct track from Point A (PTA), to Point C (PTC) after which it will follow ATS route UA134. The system determines a COP of bearing 350, distance 22 NM from Point B (PTB).

>PIC FILE= "L_2000254EN.008401.EPS">

The following ABI message is sent:

- ICAO

(ABIE/L003-AMM253/A0701-LMML-PTB350022/1440F350-EGBB-9/B757/M-15/N0490F390 PTA DCT PTC UA134)

- ADEXP

-TITLE ABI -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 003 -ARCID AMM253 -SSRCODE A0701 -ADEP LMML-COORDATA -PTID REF01 -TO 1440 -TFL F350 -ADES EGBB-ARCTYP B757-REF-REFID REF01 -PTID PTB -BRNG 350 -DSTNC 022 -ROUTE N0490F390 PTA DCT PTC UA134

B.4.1.1.2. The ACT message has the same format as the ABI message except that the route of flight is optional.

B.4.1.2. REV Message

Flight HZT2051 was previously the subject of the following ACT message (or ADEXP equivalent):

(ACTQW/FG455-HZT2051/A3347-HECA-WSS/1838F310-EHBK-9/B737/M

>PIC FILE= "L_2000254EN.008501.EPS">

The flight is then routed from 40 NM west of point RQA direct to MYY. The closest point to the boundary crossing is TDS from which the distance to the actual crossing point is 26 NM at bearing 240 degrees. The following revision message is sent:

(REVQW/FG464-HZT2051-HECA-WSS-EHBK-14/TDS240026/1842F310-15/N0458F310 RQA270040 DCT MYY)

>PIC FILE= "L_2000254EN.008502.EPS">

The ADEXP equivalent of the message is:

-TITLE REV -REFDATA -SENDER -FAC QW -RECVR -FAC FG -SEQNUM 464 -ARCID HZT2051 -ADEP HECA -COP WSS -ADES EHBK -COORDATA -PTID REF01 -TO 1842 -TFL F310 -REF -REFID REF01 -PTID TDS -BRNG 240 -DSTNC 026 -ROUTE N0458F310 RQA270040 DCT MYY

A subsequent revision message would indicate TDS240026 as the COP.

B.4.2. Re-route via ATS Routes after ACT Transmission

B.4.2.1. ACT Message

Flight GKP217 is planned to route via co-ordination point EMT. The following ACT is transmitted:

(ACTK/G206-GKP217/A2332-EGNX-EMT/1211F270-DTTA-9/FK28/M)

>PIC FILE= "L_2000254EN.008601.EPS">

The flight subsequently re-routes via ATS route UM247 within the sending centre's airspace to new co-ordination point XAT following which it is to follow ATS route UJ124. The accepting centre remains the same. The following revision message is sent:

(REVK/G214-GKP217-EGNX-EMT-DTTA-14/XAT/1225F270-15/N0430F290 UM247 XAT UJ124)

>PIC FILE= "L_2000254EN.008602.EPS">

The flight is then cleared to FL290 resulting in the following message (containing the new COP):

(REVK/G233-GKP217-EGNX-XAT/1225F290-DTTA)

>PIC FILE= "L_2000254EN.008701.EPS">

B.4.2.2. ADEXP Equivalents

The ADEXP equivalents of the two revision messages are as follows:

a. -TITLE REV -REFDATA -SENDER -FAC K -RECVR -FAC G -SEQNUM 214 -ARCID GKP217 -ADEP EGNX -COP EMT -ADES DTTA -COORDATA -PTID AT -TO 1225 -TFL F270 -ROUTE N0430F290 UM247 XAT UJ124

b. -TITLE REV -REFDATA -SENDER -FAC K -RECVR -FAC G -SEQNUM 233 -ARCID GKP217 -ADEP EGNX -COORDATA -PTID XAT -TO 1225 -TFL F290 -ADES DTTA

ANNEX C (Informative)

DIALOGUE PROCEDURE (SYSCO LEVEL 1) PHASES - MESSAGE SEQUENCE

Message Sequence

>PIC FILE= "L_2000254EN.008802.EPS">

ANNEX II

AIR TRAFFIC SERVICES DATA EXCHANGE PRESENTATION (ADEXP) EDITION 2.0

(Eurocontrol document reference DPS.ET1.ST09-STD)

TABLE OF CONTENTS

>TABLE>

COPYRIGHT NOTICE

This document has been produced by the Eurocontrol Agency.

Copyright is vested with the Eurocontrol Agency.

The content, or any part thereof, is thus freely available to Member States' representatives, but copy or disclosure to any other party is subject to prior consent in writing by the Eurocontrol Agency.

FOREWORD

1. Responsible Body

This Standard has been developed and is maintained by the User Requirements Section of the Central Flow Management Unit (CFMU) of the European Organisation for the Safety of Air Navigation (Eurocontrol).

2. EATCHIP Work Programme Document

This Standard has been produced as a deliverable of the EATCHIP Work Programme Document (EWPD), Data Processing Systems Domain (DPS), Executive Task 09.

3. Approval of the Standard

3.1. This Standard is adopted in accordance with the procedures outlined in the Directives for Eurocontrol Standardisation, Ref. 000-2-93, Edition 1.0.

3.2. The provisions of this Standard became effective after adoption of edition 1.0 by the Permanent Commission of Eurocontrol in 1995 and had a date of application with effect from 1st. December 1997.

4. Technical Corrigenda and Amendments

This Standard is kept under review to ascertain required amendments or technical corrigenda. The procedure for the maintenance of this Standard is laid down in Annex H of the Directives for the Uniform Drafting and Presentation of Eurocontrol Standard Documents.

Amendments or additions affecting the basic principles or grammar of the ADEXP format shall only be made following the formal review procedure as provided in the Directives for the Uniform Drafting and Presentation of Eurocontrol Standard Documents.

Amendments or additions to this Standard shall be proposed in writing to: CFMU Users Requirements Section (ADEXP), Eurocontrol Agency.

5. Editorial Conventions

5.1. The format of this Standard complies with the Directives for the Uniform Drafting and Presentation of Eurocontrol Standard Documents, there are however some departures from the Directives. The minor formatting exemptions from the Directives are to avoid confusion with the ATS Data Exchange Presentation (ADEXP) notation.

5.2. The following notation has been used to indicate the status of each statement:

- Normative Elements use the operative verb "shall" and have been printed in light faced roman text;

- Recommended Elements use the operative verb "should" and have been printed in light faced italics, the status being indicated by the prefix; Recommendation.

6. Relationship to other Standard Documents

This Standard is related to:

Eurocontrol Standard Document for On-Line Data Interchange (OLDI)

7. Status of Annexes to this Standard

>TABLE>

8. Language used

The English language has been used for the original text of this Standard.

1. SCOPE

1.1. ADEXP is a format, not a protocol. No restrictions are imposed on the transmission media or protocols to be used, other than that of the character set.

1.2. ADEXP provides a format for use primarily in on-line, computer to computer message exchange.

1.3. This document defines the principles and syntax rules of the ADEXP format. It provides this definition in terms of a comprehensive definition of the ADEXP fields.

1.4. The ADEXP format has been specified for use within the following areas of message exchange (for document reference information see Section 2, page 3):

- Flight Planning: exchange of flight plan data and associated messages between the Integrated Initial Flight Plan Processing System (IFPS), Air Traffic Services (ATS) and Aircraft Operators (AO). (Document Ref. 3)

- Air Traffic Flow Management (ATFM): exchange of messages between the Tactical System (TACT) of the CFMU, AO and ATS. (Document Ref. 5)

- Air Traffic Control Co-ordination: exchange of tactical co-ordination messages between Air Traffic Control Units (ATCU). (Document Ref. 6)

- Airspace Management: exchange of data between National ATS Units, the CFMU and AO, concerning airspace availability. (Document Ref. 7)

- Civil / Military Co-ordination: messages concerning civil/military flight data and airspace crossing messages. (Document Ref. 7).

1.5. Detailed specifications concerning the usage and content of the messages within each of the above groups shall be found in the referenced documents.

2. REFERENCES

2.1. The following documents and standards contain provisions which, through reference in this text, constitute provisions of this Eurocontrol Standard Document.

At the time of publication of this Eurocontrol Standard Document, the editions indicated for the referenced documents and standards were valid.

Any revision of the referenced International Civil Aviation Organisation (ICAO) Documents shall be immediately taken into account to revise this Eurocontrol Standard Document.

Revisions of the other referenced documents shall not form part of the provisions of this Eurocontrol Standard Document until they are formally reviewed and incorporated into this Eurocontrol Standard Document.

In the case of conflict between the requirements of this Eurocontrol Standard Document and the contents of these other referenced documents, this Eurocontrol Standard Document shall take precedence.

2.2. At the time of publication, the documents listed below are those that are referenced from this Standard however users are invited to check the usage and message field composition tables in the latest editions of these documents.

1. ICAO Chicago Convention Annex 10 Volume I, edition dated November 1985;

2. ICAO Chicago Convention Annex 10 Volume II, edition dated July 1995;

3. IFPS and RPL Dictionary of Messages, edition 1.0, dated March 1998;

4. "Rules of the Air and Air Traffic Services", PANS-RAC Doc 4444, edition dated November 1985 (including Amendment No 6 dated November 1995);

5. Guide To ATFM Message Exchange Eurocontrol Document Ref. TACT/USD/MSGGUID, edition 6.0, effective March 1998,

6. Eurocontrol Standard for On-Line Data Interchange, edition 2.0, dated October 1996.

7. Functional Specifications for System Support to Airspace Data Distribution and Civil Military Co-ordination, edition 1.0, dated May 1996.

3. DEFINITIONS, SYMBOLS AND ABBREVIATIONS

3.1. Notation

The notation used to define the syntax is termed Backus Naur Form (BNF). BNF defines a set of rules which determines a class of character strings. In this case, the class of character strings is the set of messages which can be called a syntactically valid ADEXP message.

3.2. Definitions

For the purposes of this Eurocontrol Standard document, the following definitions shall apply:

Token: A character or set of characters which can be "extracted" by a lexical analyser due to the presence of separators.

Symbol: Any "term" which appears in a BNF rule but which is not a character.

Terminal Symbol: A symbol which is represented in terms of a sequence of characters.

Non-Terminal Symbol: A symbol which is represented by one or more terminal symbols.

NOTE

A non-terminal symbol may also be represented as a mixture of terminal and non-terminal symbols.

3.3. Construction

3.3.1. BNF consists of a set of rules or constructs of the form:

symbol ::= expression

NOTES

1) The "::=" notation should be read as "can be replaced by".

2) The "symbol" is classed as non-terminal.

3) The "expression" part contains terminal and non-terminal symbols.

3.3.2. Terminal symbols have a direct representation as a sequence of characters which can be identified as a token by a lexical analyser, using the presence of separators.

3.4. Conventions

For the purposes of this Eurocontrol Standard document, the following conventions shall apply:

- Terminal symbols are in upper case.NOTE

By convention, the NIL terminal symbol stands for "no terminal symbol".

It is used in choices as in the following example:

a ::= b (c | NIL) where a can be replaced by (b followed by c) or by b only.

- Non-Terminal symbols (e.g. the left hand side of a grammar production) are in lower case.

- Characters and String Literals appearing inside rules are respectively enclosed in quotes (') or double quotes (").

Examples

1) HYPHEN::= '-'

2) title::= '-' "TITLE" titleid

It may be required, for some data modelling applications, to distinguish between terminal and non-terminal symbols by means other than the use of upper and lower case lettering.

Whenever it is required to explicitly distinguish between terminal and non-terminal symbols, other than by the use of upper and lower case lettering, it is recommended to use the addition of a suffix as follows: "_at" for an Auxiliary term, "_pf" for a Primary field and "_sf" for a Subfield.

3.5. Operators

For the purposes of this Eurocontrol Standard document, the following operators shall apply:

Optional: When some symbols can legally appear or not appear at some point in the grammar. The optional symbols are enclosed in square brackets "[" and "]".

Closure: When a group of symbols may appear zero or more times. The symbols are enclosed in curly brackets "{" and "}". If a number is specified before the "{" it gives the minimum number of times that the group of symbols may appear. If a number is specified after the "}" it gives the maximum number of times that the group of symbols may appear.

Choice: When a number of alternative symbols may appear at some point in the grammar. Choice is represented by "|".

Concatenation: Representation of symbols that follow sequentially, even though one or more separators may come in the middle. There is no explicit representation of this. They are two types:

- Strict Concatenation: at the lexical level, rules may involve concatenation of terminals indicating that they strictly follow each other (no separator in the middle), in this case the "!" symbol shall be used.Example

datetime:: = date ! timehhmm

e.g. "9912251200" meaning 25th December 1999, at 12h00.

- Loose Concatenation: the allowed presence of separators between terminals. The representation of Loose Concatenation within a rule may be either Implicit or ExplicitExamples

1) Implicit:

dct::= '-' "DCT" point point

2) Explicit

dct::= '-'!{SEP}!"DCT"!1{SEP}!point!1{SEP}!point

>TABLE>

NOTES

1) Concatenation shall always takes precedence over choice. Parenthesis "(" and ")" are used to alter the expression evaluation order.Example

>TABLE>

2) In all rules, the allowed presence of separators between the symbols will be left implicit, in order to preserve readability.

Recommendation

When there is a risk of confusion due to precedence between the above mentioned operators, it is recommended to use the parenthesis, in order to clarify the desired evaluation order.

3.6. Abbreviations

>TABLE>

4. ADEXP PRINCIPLES

4.1. Textual, Human Readable Format

4.1.1. The ADEXP format is a textual format, based on characters.

4.1.2. The ADEXP messages remain readable to a human operator which enables better tuning, or operational issues, to be addressed.

4.1.3. A textual format is also more open and understandable.

4.2. Identified and Retrievable Fields

4.2.1. A message in ADEXP format shall be composed of fields.

4.2.2. Fields shall be delimited by a special start-of-field character, the hyphen character ("-") and identified by specific keywords.NOTE

It should be noted that certain fields (those syntactically defined as containing the lexical item "CHARACTER") may legally contain a "-" character as part of the field content.

4.2.3. This approach improves the extensibility and robustness of the format. (If a field is absent or incorrect, it can be skipped, and the remaining part of the message can still be interpreted. (See section 4.3).

4.2.4. As another consequence, the order of fields in a message shall not be relevant to determine its legality, except for the first field (mandatory title field) which determines the allowed fields.

4.2.5. Fields may be basic or compound.

4.2.6. The constituent parts of compound fields are called subfields, and are defined by the presence of keywords, delimited by the a start-of-field character.

4.2.7. Basic fields are fields which do not contain subfields.

4.2.8. The basic or compound fields composing the first level of definition of a message are called its primary fields.

4.2.9. All lower level constituents are by definition subfields, which in turn, may be basic or compound.

4.2.10. Compound fields are of two kinds, structured fields or list fields.

4.2.11. Structured fields have a pre-defined content made exclusively of subfields. The order of subfields in a structured field is NOT significant.

4.2.12. List fields are introduced by the BEGIN keyword and terminated by the END keyword. Between these, repeating occurrences of a same subfield or combination of subfields may take place. The order of the occurrences inside a list field is semantically significant.

4.2.13. In the following, the term "field" will be used generically to mean primary and/or subfields, except when explicitly qualified otherwise.

4.2.14. Fields in a message may be optional or mandatory, as defined by their syntax.

4.3. Unrecognised Fields

4.3.1. If an unknown field appears in a message, it shall be ignored.

4.3.2. In other words, if the system which analyses the message does not recognise a keyword, all the text up to the next known Primary Field, which is not within a List Field, will be ignored.

4.3.3. Depending on the message title, the ignored field may or may not cause a rejection of the message being parsed.NOTE

It should be noted that although ADEXP is designed to provide this type of flexibility, it is at the discretion of those responsible for defining the interface requirements, to indicate, for each message, how the system should react to an unrecognised field.

4.3.4. If the unknown field is a list field, (this has been found due to the -BEGIN keyword), then all its contents (up to the corresponding -END keyword) are ignored.

4.3.5. In order to avoid any ambiguity during the recovery that follows skipping an unrecognised field, it is required that a keyword introduces either a primary field, or a subfield.

4.3.6. This allows the definition of two kinds of keywords:

- Primary keywords;

- Sub-keywords.

4.3.7. Once it is defined as being of one kind, a keyword shall not be further re-used in another group of messages as the other kind, with the one exception when it is inside a list field. It is possible to have inner occurrences of a primary keyword anywhere within a list field without creating ambiguity, since the presence of the BEGIN keyword indicates we may consider the inner occurrence as a subfield.Examples (of use of keyword types)

1) Primary Field

-RFL F330

2) Sub-Field: always within a "Compound Field"

-GEO -GEOID 01 -LATTD 520000N -LONGTD 0150000W

where -GEO is a primary compound field and -GEOID, -LATTD and LONGTD are all sub-fields.

3) List Field

-BEGIN RTEPTS -PT -PTID CMB -ETO 9305091430 -RFL F370 -PT -PTID

...

-END RTEPTS

where "-BEGIN" is the list field indicator and "RTEPTS" is a primary field.

NOTE

"RFL" is defined as a primary field. Inclusion within a list field is the only occasion when a primary field may be used as a subfield. (See Example 3 above)

5. ADEXP SYNTAX RULES

5.1. Lexical Elements

5.1.1. Character Set

5.1.1.1. The character set to be used for the exchange of messages in ADEXP format shall be International Alphabet Number 5 (IA-5) as defined in Reference 1.

5.1.1.2. The ADEXP format is designed as a computer to computer exchange format which may be transmitted on different computer networks or on dedicated computer-computer links. In addition, a requirement exists to be able to exchange some ADEXP messages, typically Flight Planning and ATFM related, on the Aeronautical Fixed Telecommunication Network (AFTN).

5.1.1.3. Messages which may be required to be transmitted via AFTN shall have their character set restricted to those characters that have a direct correlation between International Telegraph Alphabet Number 2 (ITA-2) and IA-5, as defined in Reference 1.NOTE

Besides graphic characters and format effectors as defined below, the ITA-2 character set defines "signals" (like perforated tape, for instance). They are not part of the allowed character set for ADEXP messages.

5.1.1.4. The characters which are permitted for use within ADEXP messages which may be transmitted via AFTN, are the graphic characters and the format effectors as defined below:

Graphic Characters

a) upper case letters (A to Z)

b) digits (0 to 9)

c) special graphic characters, as follows:

1) space character " "

2) open bracket "("

3) close bracket ")"

4) hyphen "-"

5) question mark "?"

6) colon ":"

7) full stop "."

8) comma ","

9) apostrophe "'"

10) equal sign "="

11) plus sign "+"

12) oblique "/"

Format Effectors

a) Carriage-Return

b) Line-Feed

5.1.2. Basic Lexical Items

The following basic lexical items are defined for use in this specification:

- ALPHA ::= 'A'|'B'|'C'|'D'|'E'|'F'|'G'|'H'|'I'|'J'|'K'|'L'|'M'|'N'|'O'|'P'|'Q'|'R'|'S'| 'T'|'U'|'V'|'W'|'X'|'Y'|'Z'

- DIGIT ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'

- ALPHANUM ::= ALPHA | DIGIT

- SPACE ::= ' '

- HYPHEN ::= '-'

- FEF ::= Carriage_return | Line_Feed

- SEP ::= 1{ SPACE | FEF }

- SPECIAL ::= SPACE | '(' | ')' | '?' | ':' | '.' | ',' | ''' | '=' | '+' | '/'

- CHARACTER ::= ALPHA | DIGIT | SPECIAL | FEF | HYPHEN

- LIM_CHAR ::= ALPHA | DIGIT | SPECIAL | FEF

- START-OF-FIELD ::= HYPHEN

NOTE

LIM_CHAR represents any allowed character except HYPHEN which is reserved to indicate the start of a field. On the contrary, CHARACTER represents any allowed element of the character set.

5.1.3. Lines, Separators and Delimiters

5.1.3.1. The division into lines of the text of a message shall have no syntactic effect.

5.1.3.2. A separator can be a space character or format effector.

5.1.3.3. Fields shall be delineated only by the presence of a start-of-field character followed by a keyword.

5.1.3.4. Hence the whole message could legally be on one line.

5.1.4. Signed Values

5.1.4.1. It may be required to indicate a numeric value as being negative.

5.1.4.2. Fields which are required to indicate a negative value shall, within their syntax definition, explicitly indicate the value as being a "signed value" i.e. as being either positive or negative. A field which has not been so defined may not represent a negative value.

5.1.4.3. A "signed value" shall always be preceded by either the letter "N" meaning negative or "P" meaning positive. A zero value may be preceded by either "N" or "P".

5.1.4.4. The syntax of a field which allows a "signed value" shall be as follows:

'-' "KEYWORD" ("P" | "N") ! 1{DIGIT}

Example:

A field called "NUMBER" which may contain a negative value of one to eight digits would be defined as:

'-' "NUMBER" ("P" | "N") ! 1{DIGIT}8

Therefore:

-NUMBER P5 - value of "number" is +5

-NUMBER N5 - value of "number" is -5

-NUMBER 5 - invalid syntax, either a "P" or a "N" must be present

5.1.5. Keywords

5.1.5.1. A keyword is any sequence of upper case letters or digits. It introduces a field only when it is preceded by a start-of-field character ("-").

keyword::= 1{ ALPHANUM }

5.1.5.2. Keywords shall comply with the following syntax:

'-'!{SEP}!"KEYWORD"!1{SEP}! < subfield/s or contained value >

i.e. a keyword shall be separated from it's "start-of-field character" by zero or more separators. It shall be followed immediately by one or more separators, followed by the relevant subfield/s or contained value.

NOTE

It is important to note that a keyword and its preceding start-of-field character may be separated by any number of separators, including none.Examples (The following sequences all validly introduce a field)

1) -TITLE IFPL

2) - TITLE IFPL

3) - TITLE IFPL

4) -

TITLE IFPL

5.1.5.3. Recommendation

It is a recommended practice to avoid the use of a separator between the start-of-field character "-" and the subsequent keyword.

NOTE

1) In the examples above, the first occurrence is the recommended choice.

2) It is also important to note that a keyword must be immediately followed by at least one separator.

5.1.5.4. Throughout the document the concatenation of items separated by at least one separator is implicitly represented by the notation of "Loose Concatenation" (see 3.5).NOTE

As will be explained later, keywords also introduce list fields when they are preceded by the BEGIN keyword.

5.1.5.5. Keywords shall be as short as possible while remaining semantically meaningful.

5.1.5.6.

>TABLE>

5.1.5.7. In order to avoid ambiguity (duplicate use of a same keyword with different meanings) or redundancy (different keywords with the same meaning), a Central Definition Table of Primary Fields (i.e. primary keywords) is maintained in this Standard at Annex A (A3) and a Central Definition Table of Subfields (i.e. sub-keywords) is also maintained at Annex A (A4).

5.2. Fields

5.2.1. Field Syntax

field::= basic_field | structured_field | list_field

basic_field::= '-' keyword contained_values

contained_values::= {CHARACTER}

list_field::= '-' "BEGIN" keyword {subfields} '-' "END" keyword

structured_field::= '-' keyword field_1 field_2 ...field_n

NOTE

As will be seen, in the case of list fields, the keyword is not preceded directly with "-" but with the "-""BEGIN" construct.

5.2.2. Message Composition in Terms of Fields

5.2.2.1. The first field of an ADEXP message shall always be a TITLE field (i.e. a field introduced by the TITLE keyword).

5.2.2.2. The remaining contents of a message in terms of its primary fields, shall be defined by its TITLE.

5.2.2.3. The syntax of messages corresponding to a given TITLE shall be defined by the fields it contains (defined by their keywords):

- The name and allowed content of its primary fields;

- The name and allowed content of its subfields.

5.2.3. Basic Fields

5.2.3.1. The syntax of basic field shall be as follows:

basic_field::= '-' keyword contained_values

5.2.3.2. "Contained_values" defines the text which provides the value of the field, and may not introduce any subfield.Example rule

arctyp::= '-' "ARCTYP" (icaoaircrafttype | "ZZZZ")NOTE

1) An explicit equivalent rule of which being:

arctyp::= '-'!{SEP}!"ARCTYP"!1{SEP}!(icaoaircrafttype | "ZZZZ").

2) An example portion of a message is:: "-ARCTYP ZZZZ".

5.2.3.3. Recommendation

Where there are more than two contained values within a basic field and there is, in addition, the need to express "choice" or "option" amongst the values, it is recommended to make the field a structured field and to include the contained values within subfields.

5.2.4. List Fields

5.2.4.1. The syntax of list fields shall be as follows:

list_field ::='-' "BEGIN" keyword { subfields } '-' "END" keyword

5.2.4.2. The "subfields" may be any combination of subfields, the occurrence of which may appear zero or more times inside the list field.

5.2.4.3. The list of subfields contained in a given list field shall form an ordered set (the order of subfields is significant).Example rule

addr ::= '-' "BEGIN" "ADDR" { fac } '-' "END" "ADDR"NOTE

1) This example shows that an "addr" field is a list field containing 0 or more occurrences of a "fac" subfield (an ATS facility).

2) An example portion of a message showing ADDR as a list field containing FAC subfields is:

-BEGIN ADDR -FAC LLEVZPZX -FAC LFFFZQZX -END ADDR.

3) An example portion of a message showing a combination of subfields is:

xxx::= '-' "BEGIN" "XXX" { yyy | zzz } '-' "END" "XXX".

5.2.5. Structured Fields

5.2.5.1. The syntax of structured fields shall be as follows:

structured_field::= '-' keyword field_1 field_2...field_n

5.2.5.2. The allowed contained subfields in a given structured field shall depend only on the structured field itself.

5.2.5.3. The order of appearance of subfields in a structured field shall not be significant, which allows for easy future extensions (by adding new contained subfields).Example rule

pt::= '-' "PT" ptid [fl] [eto]NOTES

1) This defines the "pt" field as a structured field containing a point ("ptid" subfield), optionally followed by a calculated flight level ("fl" subfield), optionally followed by an estimated time over the point ("eto" subfield).

2) An example occurrence of that field may be for instance:

"-PT -PTID RMS -FL F250 -ETO 921225120000".

5.2.5.4. Recommendation

Wherever it is felt that the contents of a field might evolve in the future, it is desirable to make it a structured field. This will allow progressive extensions of its subfields.On the contrary, a basic field may be simpler or more familiar to use, but it imposes a fixed sequence of elements (values) with very reduced extension possibilities.

5.2.6. The COMMENT Field

5.2.6.1. The comment field introduces an area of free text where all available characters except the start-of-field character ("-") can be used, and which extends to the next field.

comment::= '-' "COMMENT" { LIM_CHAR }

Example

COMMENT THIS IS THE BEGINNING OF A FREE ROUTE TEXT AREA

5.2.7. The TITLE Field

5.2.7.1. The first field of an ADEXP message shall always be a title field. The syntax of which shall be as follows:

title::= '-' "TITLE" 1{ ALPHA }10

5.2.7.2. The possible values of the title field consist of the set of ADEXP message titles, as listed in Annex B of this Standard.Example

-TITLE IFPL

6. NORMALISED DESCRIPTION OF ADEXP MESSAGES

6.1. Introduction

6.1.1. The following paragraphs define how the ADEXP format of different categories of messages shall be described in a normalised way, in the frame of the present Standard.

6.1.2. The Normalised description involves:

- Definition of auxiliary terms;

- Definition of each individual primary field's syntax and semantic;

- Definition of each individual subfield's syntax and semantic;

- Definition of each group of messages with reference to their defining documentation.

6.1.3. This Standard does not provide the detail concerning the field composition and data insertion rules for each message title.

6.1.4. Reference should be made to the defining documentation (Interface Specification) which is applicable to the relevant message group (See section 6.5.7).

6.1.5. Defining documentation should provide, in a normalised manner, the following information for each message title:

- a list of compulsory primary fields;

- a list of optional primary fields;

- the data insertion rules for each field, and in particular, the rules concerning the use of subfields defined as optional within this Standard;

- the rules concerning recovery following the detection of an unrecognised field.

6.1.6. The fields currently defined and agreed throughout Eurocontrol member states for use within the different categories of messages which have been defined for use using ADEXP, are those provided in Annex A of this document.

6.1.7. A field shall not be used for a purpose other than that specified in it's semantic description.

6.1.8. A central index of reserved fields is provided at Annex D. "Reserved fields" have not been agreed for use within the currently defined ADEXP messages. Typically they are fields which have been foreseen for possible future use, or they are used locally within national systems. The purpose of including them in this Standard is to assist in ensuring the uniqueness of field titles and avoidance of unnecessary redundancy.

6.2. Auxiliary Terms

6.2.1. In order to provide a readable definition of fields, it is often useful to introduce auxiliary terms in the grammar description.

6.2.2. Auxiliary terms do not introduce a field or subfield and hence, are not associated with a particular keyword. However, they may appear in the definition of more than one field, or subfield, or auxiliary. For instance an auxiliary term like "date" may be used in the definition of many fields.

6.2.3. All necessary auxiliary terms shall be introduced in alphabetical order and are defined in Annex A (A2) of this Standard.

6.2.4.

>TABLE>

6.3. Definition of Primary Fields

6.3.1. All primary fields used in ADEXP messages shall conform to the syntax and semantics as expressed in Annex A (A3) of this Standard.

6.3.2. The syntax of each field will be given first, then its semantic in plain clear and unambiguous terms.

6.3.3. The syntax of fields will be expressed using the BNF notation as introduced in section 3 of this Standard.

6.3.4.

>TABLE>

6.4. Definition of Subfields

6.4.1. All subfields used in ADEXP messages shall conform to the syntax and semantics expressed in Annex A (A4) of this Standard.

6.4.2. Additionally, for cross-reference purposes, the primary fields inside which a given subfield appears are identified.

6.4.3. A subfield may also be a subfield of other subfields, therefore a cross-reference to these subfields is also given.

6.4.4.

>TABLE>

6.5. Group of Messages

6.5.1. The operational categories (groups) of messages which have been defined for use using the ADEXP format are introduced in Annex E of this Standard.

6.5.2. The groups are defined in terms of the operational nature of the messages being exchanged and are often characterised by the systems concerned.

6.5.3. Reference to the defining documentation shall be made for each group of messages.

6.5.4. No title value already used for a group of messages shall be reused for another group with a different meaning.

6.5.5. A central index of message titles shall be maintained in Annex B of this Standard.

6.5.6. A reference to the related group is given for each message title listed in the central index of message titles. Reference to the defining documentation for each message title is therefore provided via the message group.

6.5.7. A central index of reserved message titles is also provided at Annex C. "Reserved" message titles have not been agreed for use within the currently defined groups of messages using ADEXP. Typically they are messages which have been foreseen for possible future use within one of the defined groups, or they are used locally within national systems. The purpose of including them in this Standard is to assist in ensuring the uniqueness of message titles and avoidance of unnecessary redundancy.

ANNEX A (Normative)

ADEXP FIELD DEFINITIONS

A.1. Introduction

This Annex provides a listing of all the fields; Auxiliary Terms, Primary Fields and Sub-Fields which have been defined for use in ADEXP.

A.2. ADEXP Auxiliary Terms

>TABLE>

A.3. ADEXP Primary Fields

>TABLE>

A.4. ADEXP Subfields

>TABLE>

ANNEX B (Normative)

CENTRAL INDEX OF ADEXP MESSAGE TITLES

>TABLE>

ANNEX C (Normative)

CENTRAL INDEX OF RESERVED MESSAGE TITLES

C.1. Introduction

This annex contains a central index of reserved message titles which have not yet been defined for use in ADEXP. Their inclusion in this annex indicates that they have either been foreseen for future use or that they are already in use but their usage is limited to within local systems.

C.2. Purpose

The purpose of providing a listing of titles which have not yet been formally adopted for use within this ADEXP Standard is to prevent, in so far as possible, either the creation of redundancy whenever a new title is required for a particular purpose or the creation of a title which is already in use within a local system.

C.3. Reserved Message Titles

>TABLE>

ANNEX D (Normative)

CENTRAL INDEX OF RESERVED FIELDS

D.1. Introduction

This annex contains a central index of reserved fields, Primary, Subfield and Auxiliary Terms, which have not yet been defined for use in ADEXP. Their inclusion in this annex indicates that they have either been foreseen for future use or that they are already in use but their usage is limited to within local systems.

D.2. Purpose

The purpose of providing a listing of fields which have not yet been formally adopted for use within this ADEXP Standard is to prevent, in so far as possible, either the creation of redundancy whenever a new field is required for a particular purpose or the creation of a keyword which is already in use within a local system.

D.3. Reserved Auxiliary Terms

>TABLE>

D.4. Reserved Primary Fields

>TABLE>

D.5. Reserved Subfields

>TABLE>

ANNEX E (Informative)

INTRODUCTION OF MESSAGE GROUPS

INTRODUCTION

This Annex provides an introduction to the different groups or categories of messages which can be exchanged in ADEXP. A complete listing of all ADEXP message titles is given in Annex B.

NOTE

For the exact conditions, rules of application and field usage, particularly the use of optional fields, reference should be made to the relevant documentation (e.g. Interface Specification document) of the systems concerned.

E.1. Flight Plan Messages

E.1.1. Introduction

Messages within this category are exchanged primarily between the AO, IFPS and the relevant ATS Units.

E.1.2. Definition of Message Titles

Message titles within this category are:

ACK, IACH, IAFP, IAPL, IARR, ICHG, ICNL, IDEP, IDLA, IFPL, IRPL, IRQP, MAN, RCHG, RCNL, REJ.

All defining material for these messages is held within Document Ref. 3

E.1.3. Primary Fields Composition

Detailed definition of message content, data insertion rules and the use of compulsory and optional fields can be found in Document Ref. 3.

Example

Flight Plan Message

-TITLE IFPL

-BEGIN ADDR -FAC CFMUTACT -FAC EGZYTTFO -FAC EGZYTTTE -FAC EGTTZGZP

-FAC EGKKZPZI -FAC LFFBTEST -FAC LESCYFPX -FAC LPPCIFPS -FAC LPPTYWYA

-FAC LPAMYWYA -FAC LPAMYCYX -FAC LPPTIFPS

-END ADDR

-ADEP EGKK -ADES LPPT -ARCID AZX752 -ARCTYP BA11 -CEQPT S

-EOBD 980305 -EOBT 1130 -FILTIM 041530 -IFPLID AA00463686 -ORGNID AZXRPLO

-SEQPT C -SRC RPL -WKTRC M -TTLEET 0230 -RFL F330 -SPEED N0400 -FLTRUL I

-FLTTYP S

-ROUTE N0400F330 SAM UR41 ORTAC UR1 QPR UR107 AVS UG41 FTM

-BEGIN RTEPTS

-PT -PTID EGKK -FL F000 -ETO 980305113000

-PT -PTID SAM -FL F196 -ETO 980305114012

-PT -PTID ASPEN -FL F288 -ETO 980305114658

-PT -PTID ORTAC -FL F311 -ETO 980305114959

-PT -PTID GUR -FL F330 -ETO 980305115617

-PT -PTID AKEMI -FL F330 -ETO 980305120118

-PT -PTID LARSI -FL F330 -ETO 980305120626

-PT -PTID QPR -FL F330 -ETO 980305121236

-PT -PTID ERWAN -FL F330 -ETO 980305123152

-PT -PTID LOTEE -FL F330 -ETO 980305124401

-PT -PTID AVS -FL F330 -ETO 980305125357

-PT -PTID KORET -FL F330 -ETO 980305130137

-PT -PTID BARKO -FL F330 -ETO 980305130734

-PT -PTID CANAR -FL F330 -ETO 980305131544

-PT -PTID VIS -FL F330 -ETO 980305132220

-PT -PTID FTM -FL F234 -ETO 980305133230

-PT -PTID LPPT -FL F000 -ETO 980305134529

-END RTEPTS

-ATSRT UR41 SAM ORTAC -ATSRT UR1 ORTAC QPR -ATSRT UR107 QPR AVS

-ATSRT UG41 AVS FTM

E.2. Air Traffic Flow Management Messages

E.2.1. Introduction

Messages within this category are exchanged primarily between the TACT system of the Eurocontrol CFMU, Aircraft Operators and ATS Units.

E.2.2. Computer Assisted Slot Allocation Messages (CASA)

Message titles within this category are:

DES, ERR, FCM, FLS, RDY, RJT, RRP, SAM, SIP, SLC, SMM, SPA, SRJ, SRM, SRR.

E.2.2.1. Definition of Message Titles

All defining material for these messages is held within Document Ref. 5

E.2.2.2. Primary Fields Composition

Detailed definition of message content, data insertion rules and the use of compulsory and optional fields can be found in Document Ref. 5.

Example

-TITLE SAM -ARCID AMC101 -ADEP EGLL -ADES LMML -EOBD 980324 -EOBT 0945

-CTOT 010 -REGUL UZZU11 -TAXITIME 0020

E.2.3. Information Messages

Message titles within this category are:

FSA

E.2.3.1. Definition of Message Titles

Defining material for this message will be available in Document Ref. 5

E.2.3.2. Primary Fields Composition

Definition of message content, data insertion rules and the use of compulsory and optional fields will be found in Document Ref. 5.

Example

First System Activation Message

-TITLE FSA -ARCID EIN636 -ADEP EIDW -ADES EBBR -POSITION -PTID LIFFY -TO 1646

E.3. ATC Co-ordination Messages

E.3.1. Introduction

Co-ordination Messages are used to automate operational co-ordination and the exchange of information between ATC units. The messages ensure the timely delivery of operational information related to co-ordination through standardised data extraction and transmission capabilities.

E.3.2. Definition of Message Titles

Message titles within this category are:

ABI, ACT, CDN, COD, COF, HOP, INF, LAM, LRM, MAC, MAS, PAC, RAP, REV, ROF, RRV, SBY, SDM, TIM.

All defining material for these messages is held within Document Ref. 6

E.3.3. Primary Fields Composition

All defining material for these messages is held within Document Ref. 6.

Examples

Hand-Over Proposal Message

-TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253

-CFL F190 -ASPEED N0420 -RATE D25 -DCT BEN STN

Activate Message

-TITLE ACT -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 005 -ARCID AMM253

-SSRCODE A7041 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F350

-ADES EGBB -ARCTYP B757 -ROUTE N0480F390 UB4 BNE UB4 BPK UB3 HON

E.4. Airspace Management Messages

E.4.1. Introduction

Messages used in the of co-ordination of airspace management. These messages cover the management of the environment in which the traffic is moving: the permanent and conditional routes, temporary segregated areas, danger and prohibited areas, etc.

E.4.2. Definition of Message Titles

Message titles within this category are:

AUP, CRAM, UUP.

All defining material for these messages is held within Document Ref.7.

E.4.3. Primary Fields Composition

All defining material for these messages is held within Document Ref. 7.

Example:

Conditional Route Availability Message

-TITLE CRAM -PART -NUM 001 -LASTNUM 010

-FILTIME 281353 -MESVALPERIOD 199803290600 1998703300600

-BEGIN LACDR

-AIRROUTE -NUM 001 -REFATSRTE UA23 ELVAR LP BEJ LP

-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803290600 199803300600

-AIRROUTE -NUM 002 -REFATSRTE UA44 ESP LP BEJ LP

-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803290600 199803290730

-AIRROUTE -NUM 003 -REFATSRTE UA44 ESP LP BEJ LP

-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803291830 199803300600

-AIRROUTE -NUM 004 -REFATSRTE A44 ESP LP BEJ LP

-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803290600 199803290730

-AIRROUTE -NUM 005 -REFATSRTE A44 ESP LP BEJ LP

-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803291830 199803300600

-AIRROUTE -NUM 006 -REFATSRTE A44 BEJ LP ROSAL LP

-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803292030 199803300530

-AIRROUTE -NUM 007 -REFATSRTE UA57 FFM ED DIK EL

-FLBLOCK -FL F250 -FL F450 -VALPERIOD 199803290700 199803291330

-END LACDR

E.5. Civil / Military Co-ordination Messages

E.5.1. Introduction

Messages used in the co-ordination of flight data and airspace crossing requests between civil and military ATS units.

E.5.2. Definition of Message Titles

Message titles within this category are:

ACP, BFD, CFD, LAM, RJC, XAP, XCM, XIN, XRQ.

All defining material for these messages is held within Document Ref. 7.

E.5.3. Primary Fields Composition

All defining material for these messages is held within Document Ref. 7.

Example:

Crossing Clearance Request Message

-TITLE XRQ -REFDATA -SENDER -FAC EBSZZXZQ -RECVR -FAC EBBUZXZQ

-SEQNUM 012 -ARCID DEUCE22 -SSRCODE A1240 -ARCTYP F111 -SECTOR SOUTH

-BEGIN RTEPTS

-PT -PTID GEO01 -TO 1630 -FL F250

-PT -PTID GEO02 -TO 1631 -FL250

-END RTEPTS

-GEO -GEOID GEO01 -LATTD 500000N -LONGTD 0051000E

-GEO -GEOID GEO02 -LATTD 500000N -LONGTD 0051500E

Acceptance Message

-TITLE ACP -REFDATA -SENDER -FAC EBBUZXZQ -RECVR -FAC EBSZZXZQ

-SEQNUM 014 -MSGREF -SENDER -FAC EBSZZXZQ -RECVR -FAC EBBUZXZQ

-SEQNUM 012

ANNEX F (Informative)

EXAMPLES OF ADEXP MESSAGE FORMAT

The following examples are provided as a demonstration of the ADEXP format, not as an example of message content. The message used is an IFPL and although correct at the time of publication, accuracy of field composition etc. is not guaranteed.

The EXAMPLE 1 below has been presented in a manner which makes it easily readable. This has been achieved through the use of carriage returns, line feeds, indents etc. Such a layout however does not form part of the ADEXP format rules.

Presentation of a message is therefore at the discretion of the receiving system. The examples provided as EXAMPLE 2 and EXAMPLE 3 are both valid representations of the same message as that in EXAMPLE 1.

EXAMPLE 1

-TITLE IFPL

-BEGIN ADDR

-FAC CFMUTACT

-FAC LFFFSTIP

-FAC EDFFZRZL

-FAC EDZZZQZA

-FAC EDUUZQZA

-FAC LOVVZQZX

-FAC LHBPZEZX

-FAC LYBAZQZX

-FAC LWSSZQZX

-FAC LGTSZAZX

-END ADDR

-ADEP EDDF

-ADES LGTS

-ARCID DLH3728

-ARCTYP B73A

-CEQPT SDMRY

-EOBD 980517

-EOBT 0715

-FILTIM 170421

-IFPLID AA05966101

-ORGNID DLHAOCC

-ORIGIN -NETWORKTYPE SITA -FAC FRAOXLH

-REG DABHM

-SEL KMGJ

-SRC FPL

-FLTTYP S

-WKTRC M

-TTLEET 0210

-RFL F330

-SPEED N0417

-FLTRUL I

-SEQPT C

-ROUTE N0417F330 NDG3D NDG UW70 MUN UB103 UNKEN UT23 BABIT UR26

SAVIN UG18 BUI UB1 TALAS

-ALTRNT1 LBSF

-EETFIR EDUU 0014

-EETFIR LOVV 0035

-EETFIR LJLA 0054

-EETFIR LHCC 0057

-EETFIR LYBA 0113

-EETFIR LWSS 0148

-EETFIR LGGG 0159

-BEGIN RTEPTS

-PT -PTID EDDF -FL F000 -ETO 980317071500

-PT -PTID NDG -FL F311 -ETO 9803173414

-PT -PTID RIDER -FL F327 -ETO 980317073726

-PT -PTID MAH -FL F330 -ETO 980317074130

-PT -PTID MUN -FL F330 -ETO 980317074449

-PT -PTID CHIEM -FL F330 -ETO 980317074754

-PT -PTID UNKEN -FL F330 -ETO 980317075109

-PT -PTID GRZ -FL F330 -ETO 9803170080830

-PT -PTID DIMLO -FL F330 -ETO 980317081443

-PT -PTID BABIT -FL F330 -ETO 980317083107

-PT -PTID SAVIN -FL F330 -ETO 980317083613

-PT -PTID UPIVO -FL F330 -ETO 980317084054

-PT -PTID KLENA -FL F330 -ETO 980317084204

-PT -PTID VAL -FL F330 -ETO 980317084629

-PT -PTID KAVOR -FL F330 -ETO 980317085329

-PT -PTID BUI -FL F330 -ETO 980317090135

-PT -PTID SARAX -FL F330 -ETO 980317090650

-PT -PTID PEP -FL F312 -ETO 980317091414

-PT -PTID TALAS -FL F241 -ETO 980317091746

-PT -PTID LGTS -FL F000 -ETO 980317093138

-END RTEPTS

-SID NDG3D

-ATSRT UW70 NDG MUN

-ATSRT UB103 MUN UNKEN

-ATSRT UT23 UNKEN BABIT

-ATSRT UR26 BABIT SAVIN

-ATSRT UG18 SAVIN BUI

-ATSRT UB1 BUI TALAS

EXAMPLE 2

-TITLE IFPL -BEGIN ADDR -FAC CFMUTACT -FAC LFFFSTIP -FAC EDFFZRZL -FAC EDZZZQZA -FAC EDUUZQZA -FAC LOVVZQZX -FAC LHBPZEZX -FAC LYBAZQZX -FAC LWSSZQZX -FAC LGTSZAZX -END ADDR -ADEP EDDF -ADES LGTS -ARCID DLH3728 -ARCTYP B73A -CEQPT SDMR -EOBD 980517 -EOBT 0715 -FILTIM 170421 -IFPLID AA05966101 -ORGNID DLHAOCC -ORIGIN -NETWORKTYPE SITA -FAC FRAOXLH -REG DABHM -SEL KMGJ -SRC FPL -FLTTYP S -WKTRC M -TTLEET 0210 -RFL F330 -SPEED N0417 -FLTRUL I -SEQPT C -ROUTE N0417F330 NDG3D NDG UW70 MUN UB103 UNKEN UT23 BABIT UR26 SAVIN UG18 BUI UB1 TALAS -ALTRNT1 LBSF -EETFIR EDUU 0014 -EETFIR LOVV 0035 -EETFIR LJLA 0054 -EETFIR LHCC 0057 -EETFIR LYBA 0113 -EETFIR LWSS 0148 -EETFIR LGGG 0159 -BEGIN RTEPTS -PT -PTID EDDF -FL F000 -ETO 980317071500 -PT -PTID NDG -FL F311 -ETO 9803173414 -PT -PTID RIDER -FL F327 -ETO 980317073726 -PT -PTID MAH -FL F330 -ETO 980317074130 -PT -PTID MUN -FL F330 -ETO 980317074449 -PT -PTID CHIEM -FL F330 -ETO 980317074754 -PT -PTID UNKEN -FL F330 -ETO 980317075109 -PT -PTID GRZ -FL F330 -ETO 9803170080830 -PT -PTID DIMLO -FL F330 -ETO 980317081443 -PT -PTID BABIT -FL F330 -ETO 980317083107 -PT -PTID SAVIN -FL F330 -ETO 980317083613 -PT -PTID UPIVO -FL F330 -ETO 980317084054 -PT -PTID KLENA -FL F330 -ETO 980317084204 -PT -PTID VAL -FL F330 -ETO 980317084629 -PT -PTID KAVOR -FL F330 -ETO 980317085329 -PT -PTID BUI -FL F330 -ETO 980317090135 -PT -PTID SARAX -FL F330 -ETO 980317090650 -PT -PTID PEP -FL F312 -ETO 980317091414 -PT -PTID TALAS -FL F241 -ETO 980317091746 -PT -PTID LGTS -FL F000 -ETO 980317093138 -END RTEPTS -SID NDG3D -ATSRT UW70 NDG MUN -ATSRT UB103 MUN UNKEN -ATSRT UT23 UNKEN BABIT -ATSRT UR26 BABIT SAVIN -ATSRT UG18 SAVIN BUI -ATSRT UB1 BUI TALAS

EXAMPLE 3

-TITLE IFPL-BEGIN ADDR-FAC CFMUTACT-FAC LFFFSTIPFAC EDFFZRZL-FAC EDZZZQZA-FAC EDUUZQZA-FAC LOVVZQZX-FAC LHBPZEZX-FAC LYBAZQZX-FAC LWSSZQZX-FAC LGTSZAZX-END ADDR-ADEP EDDF-ADES LGTS-ARCID DLH3728-ARCTYP B73A-CEQPT SDMR-EOBD 980517-EOBT 0715-FILTIM 170421-IFPLID AA05986101-ORGNID DLHAOCC-ORIGIN-NETWORKTYPE SITA-FAC FRAOXLH-REG DABHM-SEL KMGJ-SRC FPL-FLTTYP S-WKTRC M-TTLEET 0210-RFL F330-SPEED N0417-FLTRUL I-SEQPT C-ROUTE N0417F330 NDG3D NDG UW70 MUN UB103 UNKEN UT23 BABIT UR26 SAVIN UG18 BUI UB1 TALAS-ALTRNT1 LBSF-EETFIR EDUU 0014-EETFIR LOVV 0035-EETFIR LJLA 0054-EETFIR LHCC 0057-EETFIR LYBA 0113-EETFIR LWSS 0148-EETFIR LGGG 0159-BEGIN RTEPTS-PT-PTID EDDF-FL F000-ETO 980317071500-PT-PTID NDG-FL F311-ETO 9803173414-PT-PTID RIDER-FL F327-ETO 980317073726-PT-PTID MAH-FL F330-ETO 980317074130-PT PTID MUN-FL F330-ETO 980317074449-PT-PTID CHIEM-FL F330-ETO 980317074754-PT-PTID UNKENFL F330-ETO 980317075109-PT-PTID GRZ-FL F330-ETO 9803170080830-PT-PTID DIMLO-FL F330-ETO 980317081443-PT-PTID BABIT-FL F330-ETO 980317083107-PT-PTID SAVIN-FL F330-ETO 98031708361-PT-PTID UPIVO-FL F330-ETO 980317084054-PT-PTID KLENA-FL F330-ETO 980317084204-PT-PTID VAL-FL F330-ETO 980317084629-PT-PTID KAVOR-FL F330-ETO 980317085329-PT-PTID BUI-FL F330-ETO 980317090135-PT-PTID SARAX-FL F330-ETO 980317090650-PT-PTID PEP-FL F312-ETO 980317091414-PT-PTID TALAS-FL F241-ETO 980317091746-PT-PTID LGTS-FL F000-ETO 980317093138-END RTEPTS-SID NDG3D-ATSRT UW70 NDG MUN-ATSRT UB103 MUN UNKEN-ATSRT UT23 UNKEN BABIT-ATSRT UR26 BABIT SAVIN-ATSRT UG18 SAVIN BUI-ATSRT UB1 BUI TALAS

ANNEX G (Informative)

FUTURE DEVELOPMENTS

G.1. Introduction

This annex is intended to provide an indication of the proposed future development of ADEXP and the reasons and objectives behind the development.

G.2. Objectives

One of the most important objectives during the development of ADEXP was the requirement to develop a format which would enable a receiving system to successfully "ignore" or "skip" an unknown or unrecognised field without necessarily having to invalidate the message being processed. This implementation can allow the addition of a new field within a message without the requirement to have all receiving systems modified in advance followed by a very carefully co-ordinated "switch-over". The enormous flexibility that this can provide is one of the advantages of the ADEXP format.

This objective is achieved in the current standard through the use of pre-defined primary and sub-fields, introduced by unique keywords. A lexical analyser or parser which does not "recognise" a keyword is required to ignore all the text up to the next known Primary Field, which is not within a List Field. Recovery is therefore achieved at the level of primary fields.

Current and future development in the definition of new messages indicate that in certain areas a greater level of complexity is required, where third and even fourth level nesting of fields is needed. (The Conditional Route Allocation Message (CRAM) is a current example of this requirement). ADEXP today provides the ability to build a message with any level of nesting. However, the ability to recover from an unrecognised subfield, which occurs at perhaps the third or fourth level of nesting, without the chance of misinterpretation of data or of having to invalidate the message, does not exist. The proposed modifications required of the ADEXP format are designed to ensure that a lexical analyser or parser is able, at all times, to determine where it is within the structure of a message or individual field and in so doing, to enable recovery to take place at any level of nesting without the danger of misinterpretation of data.

G.3. Proposal

In order to achieve the objective of recovery at any level within a message it is necessary for the lexical analyser to be able to determine the end, as well as the start, of a field. The current format allows only the determination of the start of a field using the "-" character.

It will be proposed, in a future release of ADEXP, to introduce the use of parenthesis to indicate respectively the start and end of a field. The current use of the "-" character to introduce the start of field would be replaced by the "(" character. The end of field, which is not explicitly indicated today, would be indicated in future by the ")" character. The following examples are intended to demonstrate the principle.

Examples

>TABLE>

ANNEX III

FLIGHT DATA EXCHANGE - INTERFACE CONTROL DOCUMENT (FDE-ICD), EDITION 1.0

(Eurocontrol document reference COM.ET1.ST12-STD)

TABLE OF CONTENTS

>TABLE>

COPYRIGHT NOTICE

This document has been produced by the Eurocontrol Agency.

Copyright is vested with the Eurocontrol Agency.

The content, or any part thereof, is thus freely available to Member States' representatives, but copy or disclosure to any other party is subject to prior consent in writing by the Eurocontrol Agency.

FOREWORD

1. Responsible Body

This Standard Document has been prepared by and is maintained by the Flight Plan related Data Exchange (FPDE) Task Force of the European Organisation for the Safety of Air Navigation (Eurocontrol).

2. EATCHIP Work Programme Document

This Standard relates to the EATCHIP Work Programme Document (EWPD), Communications Domain, Executive Task 01, Specialist Task 12

3. Approval of the Standard

3.1. This Standard is adopted in accordance with the procedures outlined in the Directives for Eurocontrol Standardisation Ref. 000-2-93.

3.2. This Standard becomes effective upon adoption by the Permanent Commission of Eurocontrol and supersedes Eurocontrol Standard for On-Line Data Interchange (OLDI), Edition 1, Part 3: TECHNICAL REQUIREMENTS (Short Term Interface Control Document) Ref. 001-3-92.

4. Technical Corrigenda and Amendments

This Standard is kept under review to ascertain required amendments or technical corrigenda. The procedure for the maintenance of this Standard is laid down in Annex H of the Directives for the Uniform Drafting and Presentation of Eurocontrol Standard Documents Ref. 000-1-92.

5. Editorial Conventions

5.1. The format of this Standard complies with the Directives for the Uniform Drafting and Presentation of Eurocontrol Standard Documents.

5.2. The following notation has been used to indicate the status of each statement:

- Normative statements use the operative verb "shall" and have been printed in light faced roman text;

- Recommended statements use the operative verb "should" and have been printed in light faced italics, the status being indicated by the prefix Recommendation.

5.3. Any other information which is considered essential to the understanding of a particular indent will be integrated within the text as a NOTE. A note is considered to be informative only, therefore does not contain specifications and is placed immediately after the indent to which it refers.

5.4. Exceptionally, in order to present the Profile Requirements Lists (PRLs) in Annex E in a suitable format, some tables are not indented and are not continued over several pages.

6. Relationship to other Standard Documents

6.1. This Eurocontrol Standard Document supersedes the OLDI Short Term Interface Control Document (ST-ICD), Part 3, Edition 1 of the OLDI Eurocontrol Standard [Reference 13].

6.2. This Eurocontrol Standard Document is the first part in a expected series of Eurocontrol Standard Interface Control Documents (ICDs) for Flight Data Exchange.

7. Status of Annexes to this Standard

The Annexes to this Standard have the following status:

- Annex A - Normative

- Annex B - Normative

- Annex C - Normative

- Annex D - Normative.

- Annex E - Normative

- Annex F - Informative

- Annex G - Informative

- Annex H - Informative

8. Language Used

The English language has been used for the original text of this Standard.

1. INTRODUCTION

This Eurocontrol Standard is based on the Short Term Interface Control Document developed by the former OLDI Technical Sub-Group which was tasked with defining new interface standards for the future operation of OLDI between Area Control Centres.

Earlier OLDI links were based on proprietary protocols such as INTERCAUTRA or Datenübertragungs- und Verteilungssystem (DÜV), which run over dedicated point-to-point circuits or limited networks, and require the use of specialised hardware and software.

For the larger number of new links planned, it was felt to be desirable to move towards a network-based architecture and the adoption of international telecommunications standards, enabling links to be implemented in a more cost-effective manner, by reducing the number of connections at each Centre and allowing the use of standard "off the shelf" hardware and software.

This Eurocontrol Standard formalises and extends the Short Term ICD. The ST-ICD has been rewritten to give a more rigorous specification that will improve interoperability and, in addition, is suitable to form the basis of future ICDs to meet the evolving requirements for Flight Data Exchange (FDE), including wider use of shared networks and the introduction of new lower layer standards. This Eurocontrol Standard provides a minimum set of functionalities that can be supported by existing OLDI implementations with minimal modifications, using either point-to-point links or Comité Consultatif des Téléphones et Télégraphes (CCITT) Recommendation X.25, 1980 or later, packet-switched networks. For procurement, more possibilities can be specified. This ICD does not prevent agreements on a bilateral basis to go further.

Installations wishing to run other application protocols in addition to, or in place of the one described in this document may either apply for amendment of the present protocol, or separate their protocol using different virtual circuits.

2. SCOPE

2.1. This Eurocontrol Standard Document specifies a data communications interface for the exchange of flight-related data messages between Area Control Centres (ACCs). It is presented in the form of an Open Systems Interconnection (OSI) profile as defined in International Organisation for Standardisation/International Electrotechnical Commission (ISO/IEC) Technical Report (TR) 10000-2 [Reference 3]. The profile covers both lower layers (T-profile) and upper layers (A-profile).

2.2. This Eurocontrol Standard Document is applicable to the following scenarios:

- support of OLDI as described in Eurocontrol Standard No. 001-92 Edition 1;

- support of transmission of OLDI application messages from ACCs to the Central Flow Management Unit (CFMU) systems.

2.3. The Standard is applicable for connection using either:

- leased line point-to-point circuits, or

- Public Switched Telephone Network (PSTN) point-to-point circuits, or

- packet-switched data networks, or interconnected packet-switched data networks, that provide an interface conforming to CCITT Recommendation X.25, 1980 or later.

NOTES

1. The arrangement between Flight Plan Processing Systems (FPPSs) is represented in Figure 1.

2. Figure 1 does not illustrate potential backup connections, such as PSTN, for which guidance is given in Annex H.

Figure 1

Interface Arrangement

>PIC FILE= "L_2000254EN.017801.EPS">

2.4. Detailed security aspects of the specified data communications interface are not mandated by this Standard. However, a basic provision is specified in Annex and further guidance may be found in Annex H of this Eurocontrol Standard.

3. REFERENCES

3.1. Introduction

The following documents and standards contain provisions which, through reference in this text, constitute provisions of this Eurocontrol Standard.

At the time of publication of this Eurocontrol Standard, the editions indicated for the referenced documents and standards were valid.

Any revision of the referenced International Civil Aviation Organisation (ICAO) Documents shall be immediately taken into account to revise this Eurocontrol Standard.

Revisions of the other referenced documents shall not form part of the provisions of this Eurocontrol Standard until they are formally reviewed and incorporated into this Eurocontrol Standard Document.

In case of conflict between the requirements of this Eurocontrol Standard Document and the contents of these other referenced documents, this Eurocontrol Standard shall take precedence.

3.2. References

1. ITU-T Recommendation X.25 (1993) (Rev. 1), Interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated circuit.

2. ISO/IEC TR 10000-1:1992, Information technology - Framework and taxonomy of International Standardized Profiles: - Part 1: Framework (2nd edition).

3. ISO/IEC TR 10000-2:1994, Information technology - Framework and taxonomy of International Standardized Profiles - Part 2: Principles and Taxonomy for OSI Profiles (3rd edition).

4. ITU-T Recommendation X.21 (1992) (Rev. 1), Interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) for synchronous operation on public data networks.

5. CCITT Recommendation X.21bis (1988), Use on public data networks of data terminal equipment (DTE) which is designed for interfacing to synchronous V-Series modems.

6. ISO/IEC 7776:1994, Information technology - Telecommunications and information exchange between systems - High-level data link control procedures - Description of the X.25 LAPB-compatible DTE Data Link procedures (2nd edition).

7. ISO/IEC 8208:1993, Information Technology - Data communications - X.25 Packet Layer Protocol for Data Terminal Equipment (3rd edition).

8. ISO/IEC ISP 10609-9:1992, Information technology - International Standardized Profiles TB, TC, TD and TE - Connection-mode Transport Service over Connection-mode Network Service - Part 9: Subnetwork-type dependent requirements for Network Layer, Data Link Layer and Physical Layer concerning permanent access to a packet-switched data network using virtual calls.

9. ISO/IEC 7498-1:1994, Information technology - Open Systems Interconnection - Basic Reference Model: The Basic Model (2nd edition).

10. ISO/IEC 8348:1993, Information technology - Open Systems Interconnection - Network Service Definition (1st edition).

11. ISO/IEC 8072:1994, Information technology - Open Systems Interconnection - Transport service definition (2nd edition).

12. ISO/IEC 8878:1992, Information Technology - Telecommunications and information exchange between systems - Use of X.25 to provide the OSI connection-mode Network Service (2nd edition).

13. Eurocontrol Standard for On-Line Data Interchange (OLDI), No. 001-92, Edition 1, 1992.

14. ISO/IEC 9646-1:1994, Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 1: General concepts (2nd edition).

15. Eurocontrol (Maastricht Upper Area Control (UAC) Systems Division) FDE ICD Part 1 Integration Test Plan Version 1.0, dated 10 May 1996.

16. Eurocontrol FDE ICD Part 1 - Reliability, Availability and Security - Technical Report version 1.0, dated 20 April 1997.

17. ITU-T Recommendation X.32 (1993) (Rev. 1), Interface between DTE and DCE for terminals operating in the packet mode and accessing a packet switched public data through a public switched telephone network or an integrated services digital network or a circuit switched public data network.

18. ITU-T Recommendation E.164 (1991) (Rev. 1), Numbering plan for the ISDN era.

19. ITU-T Recommendation X.75 (1993) (Rev. 1), Packet-switched signalling system between public network providing data transmission service.

20. ITU-T Recommendation X.121 (1993), International numbering plan for public data networks.

4. DEFINITIONS, SYMBOLS AND ABBREVIATIONS

4.1. Definitions

4.1.1. For the purposes of this Eurocontrol Standard Document, the following definitions shall apply:

4.1.2. Profile: A set of one or more base standards, and, where applicable, the identification of chosen classes, subsets, options and parameters of those base standards, necessary for accomplishing a particular function [Reference 2].

4.1.3. Profile Requirements List (PRL): The profile requirements are expressed in the form of conformance requirements and are arranged in a tabular list format [Reference 2].

4.1.4. T-profile: Transport Profile providing a Connection mode Transport Service [Reference 3].

4.1.5. A-profile: Application Profile requiring a Connection-mode Transport Service [Reference 3].

4.1.6. Protocol Implementation Conformance Statement (PICS): A statement made by the supplier of an OSI system, stating which capabilities have been implemented, for a given OSI protocol [Reference 14].

4.2. Symbols and Abbreviations

>TABLE>

4.3. Notations

4.3.1. For the purpose of this Eurocontrol Standard Document, binary values or a sequence of bits are denoted in hexadecimal using the notation 'd'H, where the letter d stands for a digit or a sequence of hexadecimal digits.

4.3.2. For the purpose of this Eurocontrol Standard Document, the hexadecimal representation of a bit sequence is formed by taking 4 bits at a time from the most significant bit (MSB) to the least significant bit (LSB).NOTE

Unless otherwise specified in the referred international Standards, a sequence of bits is transmitted from MSB to LSB.

4.3.3. For the purpose of this Eurocontrol Standard Document, the status of the support for features of a base standard, or this Eurocontrol Standard, shall be shown in upper case (e.g. M, O, O.< n >, X). The exact meaning of each status symbol is described in the Annexes of this Eurocontrol Standard prior to their use.

4.3.4. For the purpose of defining the FDE ICD Part 1 profile in this Eurocontrol Standard Document, the status of the support for features of a base standard or this Eurocontrol Standard, shall be shown in lower case (e.g. m, o, o.< n >, x).NOTE

The result is a further refinement of the features of the base standards that areconditional, optional, or value dependent (see E.3.1).

5. TECHNICAL OVERVIEW

5.1. Protocol Stack

NOTE

The protocol stack for the profile of this Eurocontrol Standard is illustrated in Figure 2. The figure places the protocols in the framework of the OSI Basic Reference Model [Reference 9] by aligning the stack with the corresponding OSI layers. However, the protocol stack is a specification for pre-OSI systems and it does not support the many functions that are allowed in the OSI protocols of the corresponding OSI layers.

Figure 2

Profile Protocol Stack

>PIC FILE= "L_2000254EN.018201.EPS">

5.2. Structure of the Profile

NOTES

1. As shown in Figure 2, the profile stack combines several lower layer protocols, of which only the X.25 Packet Layer Protocol (PLP) [Reference 1] and its supporting protocols, X.21 [Reference 4] and X.21bis [Reference 5], are defined in existing ISO/IEC and International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) standards. The other higher layer protocols are defined in Annexes (Annexes A, B and C) in this Eurocontrol Standard Document.

2. Conformance requirements for the profile can refer to these specifications on an equal footing with external standards and are stated in Section 6. The detailed requirements are stated using the tabular format of PRLs (Annex E) and PICS proformas (proformas for protocols defined in the Annexes are given in Annex D). The use of these PRLs and PICS proformas in development and/or procurement is explained in Annex E.

5.3. Relation to Previous Versions of the Specification

NOTES

1. This profile is based on the ST-ICD developed by the former OLDI Technical Sub-Group. The protocols and packet formats defined in this Eurocontrol Standard Document are a compatible subset of those of the ST-ICD with the exception that this Eurocontrol Standard makes more detailed requirements on the use of the X.25 PLP, includes mandatory support of the M-bit and corrects the inconsistent specification of the Authority and Format Identifier (AFI) value in the Network Service Access Point (NSAP) address.

2. The main change in the style of this Eurocontrol Standard Document relates to the structure of the ICD specification. The Message Transfer Protocol (Annex A) is separated from the supporting T-profile. This will facilitate the use of other T-profiles as this becomes necessary to support evolving FDE requirements.

3. Those parts of the ST-ICD specification dealing with control of X.25 virtual circuits and delimiting application messages are now found in the Message Header Protocol (Annex B), which constitutes a minimal transport layer for FDE.

6. PROFILE REQUIREMENTS

6.1. Conformance Requirements

6.1.1. An implementation claiming conformance to this specification shall meet the requirements laid down in sections 6.2 and 6.3 below.

6.1.2. A claim of conformance shall be supported by a Profile Implementation Conformance Statement as described in and Annex D and Annex E.

6.2. Upper-layer Requirements

6.2.1. A conforming implementation shall satisfy the requirements of the base standard, given at Annex A.

6.2.2. A conforming implementation shall satisfy the constraints given in the Profile Requirements List at Annex E.7.

6.3. Lower-layer Requirements

6.3.1. Transport Layer Requirements

6.3.1.1. A conforming implementation shall satisfy the requirements of the base standard, given at Annex B.

6.3.1.2. A conforming implementation shall satisfy the constraints given in the Profile Requirements List at Annex E.8.1.

6.3.1.3. A conforming implementation shall satisfy the requirement of supporting Transport Service Data Unit (TSDU) sizes of up to and including 4097 octets.NOTE

The first octet of the TSDU corresponds to a field of the Message Header (see and A.4.10, B.4.4), leaving a maximum of 4096 octets for user data.

6.3.2. Network Layer Requirements

6.3.2.1. A conforming implementation shall satisfy the requirements of ISO/IEC 8208 [Reference 7] in accordance with the protocol mapping given at Annex C.

6.3.2.2. A conforming implementation shall satisfy the constraints given in the Profile Requirements List at Annex E.8.2.

6.3.2.3. A conforming implementation shall, if data terminal equipment (DTE)-DTE operation is supported, be capable of configuring by system management mechanisms the choice of DTE or data circuit-terminating equipment (DCE) role for the DTE-DTE operation.

6.3.2.4. A conforming implementation shall, in either role defined by 6.3.2.3, be capable of initiating a connection according to the specification of Annex C i.e. the protocol is totally symmetric.NOTE

Some existing implementations based on the ST-ICD, may not be able to initiate network connections according to the protocol of Annex C.

6.3.2.5. A conforming implementation shall agree for a period of time to the facility of Non-standard Default Packet Sizes, with the value 256 for both directions of transmission.

6.3.2.6. A conforming implementation shall use NSAP addresses as defined in Annex C.

6.3.2.7. A conforming implementation shall set the D-bit to 0 in CALL REQUEST, CALL ACCEPTED and DATA packets.NOTE

Setting D=0 in CALL REQUEST and CALL ACCEPTED packets has the effect of not using Delivery Confirmation.

6.3.3. Datalink Layer Requirements

6.3.3.1. A conforming implementation shall satisfy the conformance requirements of ISO/IEC 7776 [Reference 6] for the Link Access Protocol Balanced (LAPB) Single Link Protocol.

6.3.3.2. A conforming implementation shall also satisfy the constraints given in the Profile Requirements List at Annex E.8.3.

6.3.4. Physical Layer Requirements

A conforming implementation shall satisfy the conformance requirements of ISO/IEC ISP 10609-9 clause 7 [Reference 8].

7. TEST METHODS

NOTES

1. An approach to conformance testing of implementations of this specification is outlined in Annex F.

2. The use of the PRLs and PICS proformas provided with this specification to document conformance is outlined in Annex E.

ANNEX A (Normative)

MESSAGE TRANSFER PROTOCOL

A.1. Introduction

This specification defines a protocol to implement a simple message transfer service for applications that require flight data exchange.

A.2. Service Implemented

The Message Transfer (MT) protocol implements the following unconfirmed services:

MT-Associate: establish an application message transfer association;

MT-Data: transfer an application message consisting of American Standard Code for Information Interchange (ASCII) characters;

MT-Abort: terminate an application message transfer association.

A.3. Service Assumed

This Message Transfer protocol assumes a subset of the Connection-mode Transport Service as defined in ISO/IEC 8072 [Reference 11], such as that offered by the protocol defined in of this Eurocontrol Standard.

A.4. Protocol Specification

A.4.1. Introduction

In the following text, only the operation of one application initiated Message Transfer association is described. Further associations may be supported on the same network interface, by repeating these procedures for each underlying transport connection.

A.4.2. Types of Data

This Annex identifies four types of application messages that are equivalent to those defined in Eurocontrol Standard No 001-3-92 Edition 1:

System Messages: These messages shall be used for link monitoring (HEARTBEAT message) and application control (STARTUP and SHUTDOWN messages).

Operational Messages: These messages shall be linked to a specific operational context and are defined in the Eurocontrol Standards and Documents that make use of this Standard for data interchange. Eurocontrol Standard Document for On-Line Data Interchange defines operational messages such as the Activation (ACT), Advanced Boundary Information (ABI), Logical Acknowledgement (LAM) messages.

Operator Messages: These messages shall contain free text. Their use shall be bilaterally agreed. For example, they may be used to exchange test information or to inform the other side about operator actions.

Status Messages: The use and the contents of these messages shall be bilaterally agreed. For example, they may be used to exchange system management information.

NOTES

1. The use of System messages is part of the operation of this protocol and their format is specified in paragraph A.4.10.3 of this Annex.

2. The use and format of Status messages are subject to bilateral agreement, and are not further specified in this Eurocontrol Standard.

3. The state of the protocol determines which types of messages can be transmitted, as specified in the following paragraphs.

A.4.3. Association Establishment

A.4.3.1. The protocol is initially in the IDLE state.

A.4.3.2. The MT-Associate-Request primitive is executed to establish an application association and bring the protocol into the DATA_READY state. The primitive has to be invoked by both the local and remote applications.

A.4.3.3. It is first necessary to establish an underlying transport connection, following the T-connect primitive procedures described in Annex B paragraph B.4.1, after which the protocol enters the READY state. At this stage only System messages (and possibly, by bilateral agreement, Operator messages) can be transferred. To transfer a System or Operator message, the sender uses the T-Data primitive (see B.4.4), with the message as parameter.

A.4.3.4. A STARTUP message (system message) shall then be transmitted, timer Tr (see A.4.7) shall be started, and the protocol enters the ASSOCIATION_PENDING state. If timer Tr expires while the protocol is still in this state, the STARTUP message shall be retransmitted and the timer shall be restarted.NOTE

The protocol will remain in the ASSOCIATION_PENDING state until a STARTUP message is received. Continuous time-outs of the Tr timer could be signalled locally.

A.4.3.5. Receipt of the STARTUP message shall cause the following actions:

- in the ASSOCIATION_PENDING state, a further STARTUP message is transmitted, the protocol enters the DATA_READY state and the MT-Associate-Indication primitive is signalled;

- in any other state, the message is ignored.

A.4.3.6. Receipt of the STARTUP message in state ASSOCIATION_PENDING corresponds to either:

- the remote application issued a MT-Associate-Request primitive and its Message Transfer protocol has entered the ASSOCIATION_PENDING state, or

- the remote Message Transfer protocol is responding to a previously received STARTUP message and has entered the DATA_READY State.

NOTE

This uncertainty occurs because the same message is used for STARTUP and for response to STARTUP. As a result, the Message Transfer protocol that first entered the DATA_READY state will receive a further STARTUP message. As specified in A.4.3.5, this STARTUP message is ignored.

A.4.3.7. Once STARTUP messages have been exchanged, the association is established and all the identified types of messages can be transferred (DATA_READY state).

A.4.4. Data Transfer

Other types of messages are transferred in the same way as System messages, using the T-Data service, with the message as parameter. This corresponds to the MT-Data-Request and the MT-Data-Indication service primitives. NOTE

Each message is sent as a single TSDU: there is no concatenation or segmentation of messages at this level.

A.4.5. Orderly Association Release

A.4.5.1. The Message Transfer association between two applications can be cleared by either one. This corresponds to the MT-Abort-Request service primitive.

A.4.5.2. The following actions shall be taken:

- in the DATA_READY state, a SHUTDOWN message (system message) shall be transmitted, timers Tr and Ts shall be stopped, and the transport connection shall be released;

- in the ASSOCIATION_PENDING state, a SHUTDOWN message (system message) shall be transmitted, timer Tr shall be stopped, and the transport connection shall be released;

- in the READY state the transport connection shall be released;

- otherwise no action is taken.

NOTE

The SHUTDOWN message is not an early warning - the association is terminated immediately. There is no confirmation of this message from the other side.

A.4.5.3. Receipt of a SHUTDOWN message shall cause the following actions:

- in the DATA_READY state, timer Ts (see A.4.7) shall be stopped, MT-Abort-Indication is signalled and the interface enters the ASSOCIATION_PENDING state without sending a STARTUP message;

- in any other state, no action is taken.

A.4.6. Association Re-establishment

The application which initiated the clearing of the association has the responsibility, when it is ready, for re-establishing the application association and any lower levels (if necessary).NOTE

If the clearing of the association has resulted in the release of the underlying network connection, the association establishment procedure specified in paragraph A.4.3 must be followed.

A.4.7. Association Integrity

A.4.7.1. The integrity of the association between two applications is provided by the idle heartbeat facility.

A.4.7.2. On entering the DATA_READY state and on transmitting any type of message on the transport connection, a configurable timer Ts shall be (re)started. If the timer Ts expires in the DATA_READY state, a HEARTBEAT message (System message) shall be transmitted (and the timer shall be restarted).

A.4.7.3. Similarly, on entering the DATA_READY state and on receiving any message except a STARTUP message on the connection, a configurable timer Tr shall be (re)started. If the timer Tr expires in the DATA_READY state, MT-Abort-Indication is signalled, the transmission of all messages is stopped, timer Ts is stopped and the timer Tr is restarted. The interface is in the ASSOCIATION_PENDING state.NOTE

The applications will recover and resynchronise through the exchange of STARTUP messages (see A.4.3).

A.4.8. Disorderly Association Release

A.4.8.1. There can be an abnormal association release if:

- the transport connection fails (e.g. line failure, protocol error),

- one of the two applications or systems fails (this could be due to hardware or software failure; in some cases, the underlying transport connection can still be working).

NOTE

Following the definition of the transport procotol in Annex B, there is no end-to-end transport connection. As a result, failure of the transport connection is a direct result of the network connection failure.

A.4.8.2. An application or system failure can be detected by the expiry of a time-out for the receipt of an expected HEARTBEAT message (see A.4.7) from this application.

A.4.9. Recovery From Failure

A.4.9.1. Two cases have to be considered:

- after a transport connection failure;

- after an application failure.

A.4.9.2. In both cases, the re-establishment involves the normal association establishment procedure (see A.4.3), including exchange of STARTUP messages.NOTE

In the event of a failure at the application level that does not cause the underlying connection to be released, the failed system may transmit a SHUTDOWN message (i.e. L_shutdown invoked either manually or as part of the application logic) before attempting to restart the link. This will curtail the remote application's time-out Tr and may result in a quicker recovery with less chance of lost data.

A.4.10. Message Formats

A.4.10.1. General Message Structure

>TABLE>

A.4.10.2. Message Body Length

Message bodies of length up to and including 4096 octets shall be supported.

A.4.10.3. System Message Formats

>TABLE>

A.4.10.4. Other Message Formats

>TABLE>

NOTES

1. The format of the message body for Status messages is beyond the scope of this Eurocontrol Standard Document.

2. The format for Operational messages is specified in Eurocontrol Standards and Documents that define messaging applications such as On-Line Data Interchange [Reference 13].

3. Operator messages consist of printable ASCII text. If these messages are supported, a user interface must be provided to display received messages and to allow the composition of messages for transmission.

A.5. Protocol State Transition Tables

A.5.1. Introduction

The state tables given below are the definitive specification of the protocol. In case of discrepancy with the main text above, the specification below shall prevail.NOTE

The notation used to describe states, events, timers and actions are based on the ST-ICD. However, the following definitions and resulting actions have been reviewed and may differ from the ST-ICD.

A.5.2. State Definitions

Table 1

State Definitions

>TABLE>

A.5.3. Possible Events

Table 2

Possible Events

>TABLE>

A.5.4. Timers

Table 3

Timers

>TABLE>

The value of these timers shall be such that Tr = 2Ts + transit time.NOTE

Typical values of these timers are: Ts = 30s, Tr = 70s.

A.5.5. State Transition Table

Table 4

State Transitions

>TABLE>

A.5.6. State Transition Diagram

NOTE

The protocol is described in Figure A.1 in the form of a state transition diagram. The diagram is only informative: in case of conflict between the diagram and the state tables above, the latter shall take precedence.

Figure A.1

Message Transfer Protocol: State Transition Diagram

>PIC FILE= "L_2000254EN.019301.EPS">

ANNEX B (Normative)

MESSAGE HEADER PROTOCOL

B.1. Introduction

This Annex defines the Message Header protocol, a minimal transport protocol to be used for applications such as OLDI.

B.2. Service Implemented

B.2.1. The Message Header protocol corresponds to a subset of the Connection-mode transport Service, as defined in ISO/IEC 8072 [Reference 11], comprising the following service primitives.

T-Connect: establish a transport connection for an application

T-Data: transfer ASCII data

T-Disconnect: terminate the transport connection of an application

B.2.2. The service does not support multiplexing, error recovery, or segmentation and reassembly.

B.3. Service Assumed

The protocol assumes a reliable basic network service as provided by the X.25 Packet Layer Protocol.NOTE

Only a single transport connection is supported on each network connection.

B.4. Protocol Specification

B.4.1. Connection Establishment

The T-Connect primitive shall be implemented by using the N-Connect service of the underlying network service. There is a direct mapping between the two sets of (request, indication) primitives. Alternatively, an existing network connection may be used (e.g. one established by system management mechanisms).Recommendations

1. In the latter case above the network connection should be reset before use. The N-Connect primitive may be reissued automatically if no response has been received within a certain time.

2. If this automatic retry is implemented, retries should be attempted approximately every 15s.

B.4.2. Avoidance of Redundant Network Connections

If an N-Connect-Request primitive is outstanding (i.e. no corresponding N-Connect-Confirm or N-Disconnect primitive has been signalled) and an N-Connect-Indication is signalled, then the incoming network establishment attempt shall be rejected or cleared, by responding with an N-Disconnect-Request primitive, only when both the following conditions apply:

- the calling NSAP address of the N-Connect-Indication is the same as the called NSAP address of the outstanding N-Connect-Request;

- the calling NSAP address of the outstanding N-Connect-Request is greater than the called NSAP address of the outstanding N-Connect-Request, the comparison being made on the bit strings formed by the preferred binary encoding of each NSAP address, as defined in ISO/IEC 8348 Annex A [Reference 10] (a string shall be considered greater than any of its proper initial substrings, e.g. '8800'H > '88'H).

B.4.3. Connection Release

B.4.3.1. Connection release shall use the N-Disconnect and N-Reset service primitives of the underlying network service.

B.4.3.2. To implement a T-Disconnect-Request, an N-Disconnect-Request shall be signalled. Alternatively, if the establishment of network connections using N-Connect primitives is not supported, the network connection shall not be explicitly released.Recommendation

In the latter case, above the network connection should be reset.

B.4.3.3. A T-Disconnect-Indication shall be signalled on the receipt of either of the following network service primitives on a network connection corresponding to a wholly or partly established transport connection:

- N-Disconnect-Indication;

- N-Reset-Indication.

B.4.4. Data Transfer

B.4.4.1. The T-Data primitive shall be implemented by using the N-Data primitive of the underlying network service. There is a direct mapping between the two sets of (request, indication) primitives. The mapping uses a Transport Protocol Data Unit (TPDU) which is transferred by the network service.

B.4.4.2.

>TABLE>

NOTES

1. This header is defined so as to be identical to that used in the INTERCAUTRA procedure defined for ACT message exchange between CAUTRA Paris, the 9020D system of the London Air Traffic Control Centre and Digital Communications Terminal System (DCTS) Maastricht/Karlsruhe, when carrying the message formats defined in ; in this case the field "data(1)" corresponds to the TYP field.

2. The use of the fields ADEST, DEST, AEMM, EMM, and ADR with values other than '40'H is beyond the scope of this Eurocontrol Standard Document, but may be subject to bilateral agreement.

B.4.4.3. The T-Data service shall be restricted to the transfer of printable ASCII character data. In particular, none of the data octets shall have the value '03'H (the character ETX).

B.4.4.4. A conforming implementation shall satisfy the requirement of supporting Network Service Data Unit (NSDU) sizes of up to and including 4105 octets.

B.4.4.5. A conforming implementation shall prohibit concatenation of multiple TSDUs into a single NSDU.

B.4.4.6. A conforming implementation shall prohibit segmentation of a single TSDU into multiple NSDU's.

ANNEX C (Normative)

NETWORK PROTOCOL

C.1. Introduction

This Annex specifies a basic Network Protocol using the X.25 packet layer protocol, for use in both point-to-point and packet-switched network environments, to support the transfer of flight data. The protocol subset is compatible with that defined in versions of [Reference 1] from the 1980 edition on.

C.2. Service Provided

C.2.1. The protocol implements the connection-mode OSI Network Service as defined in ISO/IEC 8348 [Reference 10], with the following exceptions.

- NSAP addresses are restricted to the form defined in ;

- there is no facility for establishing agreement between the Network Service (NS) users and the NS provider on the quality of service associated with a network connection;

- transfer of NS-User-Data during network connection establishment and release is not supported except for provisions described in C.5.3.

C.2.2. The following NS provider-options are not offered:

- Receipt Confirmation;

- Expedited Data Transfer.

C.3. Service Assumed

The protocol assumes the provision of an OSI Datalink Service, such as that offered by ISO/IEC 7776 (LAPB) [Reference 6].

C.4. NSAP Addressing

C.4.1. Introduction

C.4.1.1. The structure of the NSAP addresses follows that defined in ISO/IEC 8348 Annex A [Reference 10], as illustrated below.

>PIC FILE= "L_2000254EN.019702.EPS">

C.4.1.2. The components of the NSAP address are defined below:

IDP: Initial Domain Part, comprising the AFI and IDI fields

AFI: Authority and Format Identifier, and

IDI: Initial Domain Identifier

DSP: Domain Specific Part

C.4.2. NSAP Address Structure

C.4.2.1. For the purpose of this Eurocontrol Standard Document, the address components shall be limited to the following form.

C.4.2.2. The AFI value 48 shall be used, indicating a Local format IDI with decimal abstract syntax.

C.4.2.3. The IDI is null, following the Local format.

C.4.2.4. The DSP shall consist of 2 pairs of decimal digits, as follows:

- the first pair is an Air Traffic Control (ATC) unit identifier, which identifies an ATC system and thus indirectly a location;

- the second pair is an ATC unit selector, which may be used to identify a particular end point within an ATC unit.

C.4.2.5.

>TABLE>

C.4.3. Assignment of ATC Unit Identifiers and Selectors

C.4.3.1. Assignment of unique ATC unit identifiers to each ATC system will be the responsibility of Eurocontrol, while ATC unit selectors will be assigned by the relevant authority within the ATC Administration or Organisation.

C.4.3.2. The allocation of ATC unit identifiers at the time of preparing this Standard is shown in

C.5. Protocol Specification

C.5.1. Overview

The protocol is based on the Subnetwork-Dependent Convergence Protocol for X.25(1980) defined in of ISO/IEC 8878 [Reference 12], with the following differences:

- the Fast Select user facility is not used; however, the encoding defined in Annex A of ISO/IEC 8878 [Reference 12] for use with the extended format User Data field available with the Fast Select facility is used here with the basic format User Data field in CALL REQUEST and INCOMING CALL packets, since restrictions on the allowed network service parameters ensure that the encoded information fits into 16 octets;

- of the network service parameters for which encodings are defined in ISO/IEC 8878 [Reference 12], only the called and calling NSAP addresses (and only in the form defined in ) are sent in the CALL REQUEST packet;

- the User Data field is not used in the CALL ACCEPTED, CALL CONNECTED, CLEAR REQUEST, or CLEAR INDICATION packets;

- the alternative procedures for network connection establishment and release are not used;

- receipt confirmation using the D-bit is not supported.

NOTE

The first three of these restrictions ensure that all information which will be transmitted between two DTEs will respect the limitations of the User Data field in X.25 (1980) PLP.

C.5.2. Address Encoding

The calling and called NSAP addresses shall be encoded using the preferred binary encoding defined in ISO/IEC 8348 Annex A [Reference 10].

C.5.3. Encoding of the User Data Field

C.5.3.1. As a result of the requirements stated above, the User Data field in CALL REQUEST and INCOMING CALL packets shall be encoded as illustrated below. All 16 octets shall be transmitted.

Table 1

User Data Field Encoding

>TABLE>

C.5.3.2. Other parameters described in ISO/IEC 8878 [Reference 12] shall not be used.

C.5.4. Treatment of Addresses in INCOMING CALL Packets

C.5.4.1. DTE Adresses

The calling DTE address in an INCOMING CALL packet shall be validated against a local list of valid remote DTE addresses for the system. If an invalid address is detected, the call shall be cleared.

NOTES

1. The called DTE address, if present, in an INCOMING CALL packet, if present, may optionally also be validated against a list (typically of one item) of valid local DTE addresses for the system.

2. In some instances the DTE address of a unit may differ in value and/or length when the unit is acting as the calling or called system. Therefore, particular attention must be given to this issue when specifying or implementing the DTE address validation functionality

C.5.4.2. NSAP Adresses

The calling NSAP address encoded as described above in an INCOMING CALL packet shall be validated against a local list of valid remote NSAP addresses for the system. If an invalid address should be detected, the call shall be cleared.

NOTE

The called NSAP address may optionally also be validated against a list of (typically of one item) valid local NSAP addresses for the system.

C.5.5. Data Transfer

C.5.5.1. As described in ISO/IEC 8878 Annex A.5.3 [Reference 12], NSDUs are transferred in the User Data field of a DATA packet.

NOTE

As a consequence, it is prohibited to transmit more than one user message, such as an OLDI message, per X.25 packet or M-bit sequence.

C.5.5.2. NSDUs longer than the maximum User Data allowed for the virtual circuit shall be segmented and transmitted in the User Data fields of a sequence of DATA packets where all except the last shall have both maximum length and the M-bit set (i.e. a More-bit-sequence).

C.5.5.3. On reception, the User Data fields of a More-bit-sequence shall be reassembled in order to form the received NSDU.

ANNEX D (Normative)

PROFILE-SPECIFIC PICS PROFORMAS

D.1. Introduction

D.1.1. The supplier of a protocol implementation which is claimed to conform to the specifications in Annexes A-C shall complete the following PICS proformas.NOTE

Copyright release for PICS proformas: users of this Eurocontrol Standard Document may freely reproduce the PICS proformas in this Annex so that it can be used for the intended purpose and may further publish the completed PICS.

D.1.2. A completed PICS proforma is the PICS for the implementation in question. The PICS is a statement of which capabilities and options of the protocol have been implemented.

D.1.3. The PICS can have a number of uses, including use:

- by the protocol implementor, as a check-list to reduce the risk of failure to conform to the standard through oversight;

- by the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication of the capabilities of the implementation, stated relative to the common basis for understanding provided by the standard PICS proforma;

- by the user, or potential user, of the implementation, as a basis for initially checking the possibility of interworking with another implementation (note that, while interworking can never be guaranteed, failure to interwork can often be predicted from incompatible PICSs);

- by a protocol tester, as the basis for selecting appropriate tests against which to assess the claim for conformance of the implementation.

D.2. Instructions for Completing the PICS Proformas

D.2.1. General Structure of the PICS Proformas

D.2.1.1. The Implementation Identification and Protocol Summary is the first part of each PICS proforma and shall be completed as indicated with the information necessary to identify fully both the supplier and the implementation.

D.2.1.2. The main part of the PICS proforma is a fixed-format questionnaire. Answers to the questionnaire items shall be provided in the rightmost column, either by simply marking an answer to indicate a restricted choice (usually Yes or No), or by entering a value or a set or range of values.NOTES

1. Each item is identified by a unique item reference in the first column; the second column contains the question to be answered; the third column contains the reference or references to the material that specifies the item in this Eurocontrol Standard. The remaining columns record the status of the item (whether support is mandatory, optional, prohibited or conditional) and provide space for the answers: see also below.

2. A supplier may also provide, or be required to provide, further information categorised as either Additional Information or Exception Information. When present, each kind of further information is to be provided in a further subclause of items labelled A< i > or X< i > respectively for cross-referencing purposes, where < i > is any unambiguous identification for the item (e.g. simply a numeral): there are no other restrictions on its format and presentation.

D.2.1.3. A completed PICS proforma, including any Additional Information and Exception Information, shall be referred to as the Protocol Implementation Conformance Statement for the implementation in question. NOTE

Where an implementation is capable of being configured in more than one way, a single PICS may be able to describe all such configurations. However, the supplier has the choice of providing more than one PICS, each covering some subset of the implementation's configuration capabilities, in case that makes for easier and clearer presentation of the information.

D.2.2. Additional Information

Items of Additional Information allow a supplier to provide further information intended to assist the interpretation of the PICS.NOTES

1. It is not intended or expected that a large quantity will be supplied, and a PICS can be considered complete without any such information. Examples might be an outline of the ways in which a (single) implementation can be set up to operate in a variety of environments and configurations; or a brief rationale (based perhaps upon specific application needs) for the exclusion of features which, although optional, are nonetheless commonly present in implementations of this protocol.

2. References to items of Additional Information may be entered next to any answer in the questionnaire, and may be included in items of Exception Information.

D.2.3. Exception Information

D.2.3.1. It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status (after any conditions have been applied) in a way that conflicts with the indicated requirement. No pre-printed answer will be found in the Support column for this: instead, the supplier shall write the missing answer into the Support column, together with an X< i > reference to an item of Exception Information.

D.2.3.2. The supplier shall provide the appropriate rationale in the Exception item itself.

D.2.3.3. An implementation for which an Exception item is required in this way does not conform to this specification.NOTE

A possible reason for the situation described above is that a defect in the standard has been reported, a correction for which is expected to change the requirement not met by the implementation.

D.2.4. Conditional Items

D.2.4.1. Individual conditional items are indicated by a conditional symbol of the form "< item >: < s >" in the Status column, where "< item >" is an item reference that appears in the first column of the table for some other item, and "< s >" is a status symbol, M, O, O.< n > or X.NOTE

A PICS proforma may contain a number of conditional items. These are items for which both the applicability of the item itself, and its status if it does apply (mandatory, optional or prohibited) are dependent upon whether or not certain other items are supported.

D.2.4.2. If the item referenced by the conditional symbol is marked as supported, the conditional item is applicable, and its status is given by "< s >": the support column shall be completed in the usual way. Otherwise, the conditional item is not relevant and the Not Applicable (NA) answer shall be marked.

D.2.4.3. Each item whose reference is used in a conditional symbol is indicated by an asterisk in the Item column.

D.3. PICS Proforma for the Message Transfer Protocol

D.3.1. Abbreviations and Special Symbols

D.3.1.1. Status Symbols

M: Mandatory

O: Optional

D.3.1.2. Item References

Items in the PICS proforma are identified by mnemonic item references. PICS items dealing with related functions are identified by item references sharing the same initial letter or letter-pair (in capitals). There follows a list of those initials, in the order in which the groups of items occur in the PICS proforma.

>TABLE>

D.3.2. Identification

>PIC FILE= "L_2000254EN.020301.EPS">

D.3.3. Protocol Implementation

>PIC FILE= "L_2000254EN.020401.EPS">

D.4. PICS Proforma for the Message Header Protocol

D.4.1. Abbreviations and Special Symbols

D.4.1.1. Status Symbols

M mandatory

O optional

O.< n > optional, but support of at least one of the group of options labelled by the same numeral < n > is required

X prohibited

< item > conditional-item symbol, dependent upon the support marked for < item > (see D.2.4)

D.4.1.2. Abbreviations

NA not applicable

D.4.1.3. Item References

>TABLE>

D.4.2. Identification

>PIC FILE= "L_2000254EN.020501.EPS">

D.4.3. Protocol Implementation

>PIC FILE= "L_2000254EN.020601.EPS">

D.5. PICS Proforma for the Network Protocol

D.5.1. Abbreviations and Special Symbols

D.5.1.1. Status Symbols

M mandatory

O optional

D.5.1.2. Item References

>TABLE>

D.5.2. Identification

>PIC FILE= "L_2000254EN.020701.EPS">

D.5.3. Protocol Implementation

>PIC FILE= "L_2000254EN.020702.EPS">

ANNEX E (Normative)

PROFILE REQUIREMENTS LIST

E.1. Introduction

E.1.1. This Annex provides the PRL for the FDE ICD profile defined in this Eurocontrol Standard Document. The Implementation Conformance Statement for an implementation claiming conformance to this profile shall be generated in accordance with the instructions given below.NOTE

The proformas in this Annex are based on those accompanying the referenced base standards.

E.1.2. A conforming implementation shall satisfy the mandatory conformance requirements of the base standards referenced in this profile.

E.2. The Role of the PRL and PICS Proformas

The status of this section (E.2) is informative: it does not constitute a provision of this Part of this Eurocontrol Standard.

- The objective of presenting the conformance requirements in the tabular form of the PRL and PICS proformas is to provide a check-list of the features which must or may be implemented. The underlying concepts are defined and described in ISO/IEC 9646-1 [Reference 14] (ITU-T Recommendation X.290 is equivalent) and ISO/IEC TR 10000-1 [Reference 2].

- A profile combines and selects the options of several base standards in order to fulfil a specific information processing function. Each base standard has a PICS proforma, listing the requirements of the standard. The PRL comprises the subset of the base standard PICS proforma items that are constrained by the profile, together with the specific profile requirements; it defines answers required on the base standard PICS proformas to conform with the profile. In addition, the PRL will contain PICS-type items which are specific to the profile (at the least, there will be a item testing whether all the required PICS proformas have been correctly completed); these items must be completed together with the base standard PICS proformas. The completed proformas together constitute the profile Implementation Conformance Statement (ICS).

- Following the methodology of ISO/IEC TR 10000-1 [Reference 2], a claim of conformance to a profile has to be supported by PICS proformas completed in accordance with the PRL. The use of this material will depend on the procurement approach for an FDE ICD implementation.

- Several possible approaches to an FDE implementation can be imagined:

- In-house implementation by a National Administration or Organisation: the PRL should be used as the basis of the requirements specification and acceptance test specification for the implementation; the completed ICS should be produced as part of the acceptance procedure.

- Implementation of the profile by a contractor: the material will be used and produced as for an in-house implementation, but the contractor should provide the ICS and the need for this must be a contractual requirement.

- Implementation of the profile by a contractor as part of a turn-key or system integration contract: the material will be used and produced as for an in-house implementation, but the contractor must be required to do this internally as well as providing the completed ICS. Conformance to the profile ensures, for instance, that a supplier working for two administrations cannot introduce its proprietary protocols to meet the FDE requirement and thus helps to give control to the contracting administrations.

- Integration of off-the-shelf products into a profile implementation in any of the previous cases: the supplier of a product should be required to provide those PICS proformas relevant to the product completed in accordance with the PRL given here and to warrant the conformance of the product with the applicable profile requirements; this PICS can then be forwarded as part of the profile ICS.

- Following implementation, the ICS should be maintained as part of the documentation of the implementation; it can be used to predict interoperability with other administrations, and to identify changes that may be needed in moving to different protocols.

E.3. Notation

E.3.1. The following notations from ISO/IEC TR 10000-1 [Reference 2] are used in the PRL to indicate the status of features:

m: mandatory

o: optional

-: not applicable (i.e. logically impossible in the scope of the profile)

x: excluded

NOTES

1. Two-character combinations may be used, in which case the first character refers to the static (implementation) status, and the second to the dynamic (use); thus "mo" means "mandatory to be implemented, optional to be used".

2. The "o.< n >" notation is used to show a set of selectable options (i.e. at least one of the set must be implemented) with the same identifier n.

3. A feature marked "x" may nonetheless be part of an implementation so long as it is not used when the implementation is operating in conformance with the profile.

4. Use of features marked "x" would require bilateral agreement. In this event, the status of the features should be revised as they may be of interest to other implementations.

E.3.2. The following predicate notation is used:

< predicate >:: introduces a group of items, all of which are conditional on < predicate > (the extent of the group is shown by the layout).

< predicate >: introduces a single item which is conditional on < predicate >.

NOTE

In each case, the predicate may be the identifier of a profile feature, or a boolean combination of predicates ("¬" is the symbol for logical negation).

E.3.3. Base standard requirements are shown using the equivalent notations in upper case (i.e. M, O, O.< n >, X).

E.4. Instructions for Completing the PICS Proformas

E.4.1. To provide the profile ICS, the PICS proformas for the referenced base standards shall be completed, together with the additional profile-related PICS items provided in this Annex.

E.4.2. Where this profile refines the features of the base standards, the requirements expressed in this PRL shall be applied (as indicated in PRL items with a "Profile features" column) to constrain the allowable responses in the base standard PICS proformas.

E.4.3. Where this profile makes additional requirements, the response column for such items shall be completed. In this column, each response shall either be selected from the indicated set of responses, or comprise a parameter value or values or range of values as requested.

E.4.4. If a mandatory requirement is not satisfied, exception information must be supplied, by entering a reference X< i >, where < i > is a unique identifier, to an accompanying rationale for the non-compliance.NOTE

A possible reason for such an exception is compliance with a pending defect report on a provision of the profile; if the defect report is accepted, the implementation will then be conformant.

E.5. References

E.5.1. This profile references the following protocol specifications:

- Message Transfer Protocol (Annex A to this Eurocontrol Standard Document);

- Message Header Protocol (Annex B to this Eurocontrol Standard Document);

- Connection-mode Network Protocol using ISO/IEC 8208 (Annex C to this Eurocontrol Standard Document);

- ISO/IEC 7776 [Reference 6];

- Physical Layer Standards called up by ITU-T Recommendation X.25 (1993) clause 1 [Reference 1].

E.5.2. As there are no explicit PICS proformas for the relevant Physical Layer Standards, the interim physical layer PICS proformas in ISO/IEC ISP 10609-9 clause A.4 [Reference 8] shall be used.

E.6. Conformance Statement

E.6.1. Conformance Overview

>PIC FILE= "L_2000254EN.021101.EPS">

E.6.2. Dynamic Conformance Requirements

>PIC FILE= "L_2000254EN.021201.EPS">

E.7. Upper Layer Requirements

Table 3

Message Transfer Protocol

>TABLE>

E.8. Lower Layer Requirements

E.8.1. Transport Layer Requirements

Table 4

Message Header Protocol

>TABLE>

E.8.2. Network Layer Requirements

The PRLs given in this section are based on the PICS proforma for ISO/IEC 8208:1993 [Reference 7]. The entries in the "References" column under "Base standard features" of the following tables are references to clauses in that standard.

E.8.2.1. General DTE Characteristics

Table 5

General DTE Characteristics

>TABLE>

E.8.2.2. Procedures, Packet Types and Packet Formats

Table 6

Packet Layer Functions Independent of Logical Channels

>TABLE>

Table 7

Call Setup

>TABLE>

Table 8

Call Clearing

>TABLE>

Table 9

Resetting of Logical Channels

>TABLE>

Table 10

Error Procedures

>TABLE>

Table 11

Interrupt Transfer

>TABLE>

Table 12

Sending Data

>TABLE>

Table 13

Receiving Data

>TABLE>

Table 14

Delivery Confirmation

>TABLE>

E.8.2.3. Miscellaneous Features and Options

Table 15

Values of Cause and Diagnostic Codes

>TABLE>

E.8.2.4. Facilities

Table 16

Facilities Sent in CALL REQUEST Packets

>TABLE>

Table 17

Facilities Sent in CALL ACCEPT Packets

>TABLE>

Table 18

Facilities Sent in CLEAR REQUEST Packets

>TABLE>

Table 19

Facilities Received in INCOMING CALL Packets

>TABLE>

Table 20

Facilities Received in CALL CONNECTED Packets

>TABLE>

Table 21

Facilities Received in CLEAR INDICATION Packets

>TABLE>

Table 22

Facilities Received in CLEAR CONFIRMATION Packets

>TABLE>

E.8.2.5. Parameter Values and Ranges

Table 23

Parameter Values and Ranges

>TABLE>

E.8.3. Datalink Layer Requirements

The PRLs given in this section are based on the PICS proforma for ISO/IEC 7776:1994 [Reference 6]. The entries in the "References" column under "Base standard features" of the following tables are references to clauses in that standard.

Table 24

Datalink Protocol

>TABLE>

E.8.4. Physical Layer Requirements

See ISO/IEC TR 10609-9 clause A.4 [Reference 8].

ANNEX F (Informative)

CONFORMANCE TESTING METHODOLOGY

F.1. Introduction

F.1.1. It is important that implementations of this ICD are such that there is a high level of confidence for interoperation between Air Traffic Control Centres (ATCCs) interworking across the interface.

F.1.2. Implementations of the interface are undertaken by member states in a manner that is likely to rely on procurement from various sources. To achieve a high level of confidence that such implementations will interoperate, a common set of conformance test requirements is required to standardise preparation for test, testing and presentation of results.

F.2. Purpose and Scope

F.2.1. This Annex defines requirements for the testing of conformance of implementations of this Eurocontrol Standard of which this Annex is a part.

F.2.2. It identifies mechanisms whereby confidence in the declared interface is established through a process of test to validate the claim.

F.3. Bibliography

The following document is relevant to the testing of implementations of this Eurocontrol Standard Document:

Eurocontrol (Maastricht Upper Area Control (UAC) Systems Division) FDE ICD Part 1 Integration Test Plan Version 1.0, dated 10 May 1996 [Reference 15].

F.4. Development Methods and Practices

F.4.1. Implementations of the ICD can be effected using certain options and versions of the ICD itself. In order to establish the potential for interworking, a Member State implementing the interface must identify which parts of the ICD are supported with a defined statement as to the capability and what limitations, if any, on variable parameters are supported.

F.4.2. Any implementation should be subject to a conformance test as described below.

F.5. Tests

F.5.1. Introduction

F.5.1.1. In order to provide confidence in and support for FDE Interface within an ATCC to the interworking between co-operating FDE applications, it is desirable for each to be tested for conformance to the standards of which this Annex forms a part. Such testing is against the external behaviour of the System Under Test (SUT) and is intended to test for interworking rather than the serviceability of the end system.

F.5.1.2. The results of such testing can serve as evidence in support of claims of conformance made in accordance with Section 5.1 of this part of this Eurocontrol Standard Document. The PICS proformas and PRLs called up by this profile specification can be used as the basis of conformance tests; in addition, international standards (e.g. ISO/IEC 8208 [Reference 7]) may already have abstract test suites defined that can be used in conformance testing.

F.5.1.3. The intention of this document is to provide for a standardised programme of test relying on a standardised test suite, use of which should lead to comparability of test results, wide acceptance of such test results and a minimisation of conformance testing required. The standardised test suite has been developed, in part, by Eurocontrol.

F.5.1.4. Based on Figure 2, the testing of the complete end system takes the form of tests on the lower 3 layers. It is advisable that testing include tests on the FDE application, Status, System and Operator Messages.

F.5.1.5. Each test described below should be conducted in order. The latter test will only be successful if the lower layers are functioning correctly and it is likely that this will be ascertained with the earlier tests.

F.5.1.6. Notwithstanding the above, the testing described in this section is voluntary.

F.5.2. Testing of the Lower Layers (Layers 1-3)

In support of the requirement for inter-operation between any one ATCC and its peers, it is recommended that any testing shall be based on the use of the test plan given in the Eurocontrol (Maastricht UAC Systems Division) FDE ICD Integration Test Plan. Test procedures are to be bilaterally agreed between co-operating ATCCs.

F.5.3. Testing of the Application Layer

A series of bilaterally agreed tests should be agreed and conducted between co-operating ATCCs.

F.5.4. Certification

The results of tests should be recorded and agreed between the co-operating parties.

F.5.5. Notification

Member states should pass details of the results of any tests to Eurocontrol.

ANNEX G (Informative)

ASSIGNMENT OF ATC UNIT IDENTIFIERS

The following table shows the ATC unit identifiers assigned as at April 22nd, 1997. The Eurocontrol can provide information on the current assignment of identifiers. The table also shows in hexadecimal the binary encoding of the identifier as part of the NSAP address encoding defined in Annex C.

Table 1

ATC Unit Identifiers

>TABLE>

ANNEX H (Informative)

GUIDANCE ON RELIABILITY, AVAILABILITY AND SECURITY

H.1. Introduction

It is expected that ATC applications such as OLDI shall make use of interconnected X.25 networks and/or public or private telecommunication services. As a consequence, it is deemed necessary to provide guidance to FDE ICD Part 1 implementations.

H.2. Purpose and Scope

H.2.1. The purpose of this Annex is to give guidance on issues relating to reliability, availability and security.

H.2.2. The scope of this Annex is based on two scenarios. The first scenario is a point-to-point connection over leased line. The second scenario is based within an interconnected X.25 network environment.NOTE

For the second scenario, issues relating to the interconnection of the X25 networks are not considered.

H.2.3. It is assured that implementations are physically protected against intrusion, power failures and other external threats that can affect normal operation.

H.3. Bibliography

The following document is a detailed technical analysis of which this Annex is an overview:

Eurocontrol FDE ICD Part 1: Reliability, Availability and Security - Technical Report [Reference 16].

H.4. Leased Line Implementations

H.4.1. Reliability

To increase service reliability, leased line, PSTN, Integrated Services Digital Network (ISDN) cables must follow physically different paths and linked to different telecommunication operator switches (this must be specified to the telecommunication operator).

H.4.2. Availability

H.4.2.1. Due to long setup times on PSTN which are incompatible with time constraining applications, ISDN should be used as a backup medium.

H.4.2.2. In event of DTE switchover, the standby DTE should generate a DISC frame to accelerate connection re-establishment.

H.4.3. Security

H.4.3.1. When using ISDN as backup medium, the called ISDN terminal adapter (TA) should validate the caller's E.164 address [Reference 18].

H.4.3.2. The calling DTE should comply to ITU-T Recommendation X.32 [Reference 17] by including caller identification and for authentication information.

H.4.4. Configuration Example

Figure H.1

Leased Line Configuration Example

>PIC FILE= "L_2000254EN.023301.EPS">

H.5. Network Implementation

H.5.1. Reliability

To increase service reliability, hosts on a given site should be connected to two DCEs belonging to different network switches (this requirement should be specified to the network operator).

H.5.2. Availability

H.5.2.1. The hunt group facility should be used so as to be able to assign a single X.121 address [Reference 20] to the DCEs located on a given site, thereby optimising network routing and limiting unsuccessful calls.

H.5.2.2. In the event other call mechanisms are implemented resulting in a different called DTE address value in the CALL REQUEST and CALL ACCEPT packets, the calling DTE should be configured so there is no impact on the setting up of the call.

H.5.2.3. In the event of DCE disconnection due to a network failure and a second access to the network is available, call re-establishment should be made via this second access.

H.5.3. Security

Within the scope of this Annex, the Closed User Group (CUG) facility is the only applicable network facility that should be used.

H.6. General Guidance for Leased Line and Network Implementations

H.6.1. Reliability

H.6.1.1. As a full host switchover can be long, it is advantageous to consider the use a front-end processor (FEP) to cater for host failures.

H.6.1.2. An architecture based on an FEP can increase service reliability.NOTE

Inclusion of a transport stack in the profile specification may be developed in the context of a future FDE ICD Part 2 standard.

H.6.2. Availability

When a call is unsuccessful, the calling site should make a second call using the second X.121 address (if available).

H.6.3. Systems Management

H.6.3.1. The use of switches that are automatically toggled by scanning of the interface signals should be used where possible.

H.6.3.2. A local error indication during data transmission can be used to trigger a host switchover.

H.6.3.3. The switchover of a FEP should generate a TC-disconnect to ensure the local host is in the IDLE state.

H.6.3.4. On expiry of the time-outs on the X.25 network or datalink layers, the higher layers should be released.

H.6.3.5. A total FEP failure should generate a TC-disconnect.

H.6.3.6. The management system should poll the Message Transfer Protocol layer (Annex A) and check the state machine to distinguish between a Message Transfer Protocol failure and an application failure.

H.6.4. Configuration Example

Figure H.2

Network Configuration Example

>PIC FILE= "L_2000254EN.023401.EPS">