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

Unde