2000R2082 — EN — 15.06.2002 — 001.001 — 1
This document is meant purely as a documentation tool and the institutions do not assume any liability for its contents
►B COMMISSIONREGULATION(EC)No2082/2000
of6September2000
adopting Eurocontrol standards and amending Directive 97/15/EC, adopting Eurocontrol stan-
dardsandamendingCouncilDirective 93/65/EEC
(OJ L 254, 9.10.2000, p. 1)
Amended by:
Official Journal
No page date
►M1Commission Regulation (EC) No 980/2002 of 4 June 2002 L 150 38 8.6.2002
▼B
COMMISSIONREGULATION(EC)No2082/2000
of6September2000
adoptingEurocontrol standardsandamending 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 theprocurement of air traffic management equipment and systems(
1) and
in particular Article 3 thereof,
Having regard to Commission Directive 97/15/EC of 25 March1997
adopting Eurocontrol standards and amending Council directive 93/65/EEC on the definition and use of compatible technical specificationsfor 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 Eurocontrolstandard for Air Traffic Services Data Exchange Presentation(ADEXP), edition 1.0.
(2)Eurocontrol adopted more recent versions of the two standardsmentioned above, i.e. OLDI edition 2.2 and ADEXP edition 2.0and also a new Eurocontrol standard named Flight Data
Exchange — Interface Control Document (FDE-ICD).
(3)These Eurocontrol standards fall within the scope of Directive93/65/EEC and contribute to the harmonisation of Member
States' air traffic management national systems, particularlyconcerning the transfer of flights between air traffic controlcentres (OLDI), the air traffic flow management (ADEXP) andthe communications between national systems (FDE-ICD).
(4)Editions 2.2 of OLDI and 2.0 of ADEXP supersede previouseditions presently in force according to the provisions ofArticle I of Directive 97/15/EC and therefore that Article has to
be repealed.
(5)The provisions of this Regulation are in accordance with theopinion of the Committee established in accordance with Direc-
tive 93/65/EEC,
HAS ADOPTED THIS REGULATION:
Article 1
In as much as they are necessary for the implementation of an inte-
grated European air traffic management system, the mandatoryelements of Eurocontrol specifications included in the following Euro-control standards documents are adopted in the framework of Directive93/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 tothe present Regulation,2000R2082 — EN — 15.06.2002 — 001.001 — 2
(1) OJ L 187, 29.7.1993, p. 52.
(2) OJ L 95, 10.4.1997, p. 16.
▼B
— the Eurocontrol standard for Flight Data Exchange — Interface
Control Document (FDE-ICD), edition 1.0 (Eurocontrol documentreference 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.2000R2082 — EN — 15.06.2002 — 001.001 — 3
▼B
ANNEX I
ON-LINEDATAINTERCHANGE(OLDI)EDITION2.2
(Eurocontroldocumentreference DPS.ET1.ST06-STD)2000R2082 — EN — 15.06.2002 — 001.001 — 4
▼B
TABLEOFCONTENTS
COPYRIGHT NOTICE
FOREWORD1. INTRODUCTION
1.1. Purpose1.2. Scope
2. REFERENCES3. DEFINITIONS, SYMBOLS AND ABBREVIATIONS
3.1. Definitions3.2. Symbols and Abbreviations
4. GENERAL REQUIREMENTS
4.1. Introduction4.2. Flight Data Processing System Requirements4.2.1. Flight Data Base4.2.2. Operation in Real Time4.2.3. Data Communications Capability4.2.4. Application Functions4.2.5. Human-Machine Interface (HMI)4.2.6. Initiation of Messages4.2.7. Reception of Messages4.3. Updating from Surveillance Data4.4. Recording of OLDI Data4.4.1. Content4.4.2. Facilities4.5. Availability, Reliability, Data Security and Data Integrity4.5.1. Availability4.5.2. Reliability4.5.3. Data Security4.5.4. Data Integrity4.6. Operational Evaluation4.6.1. Evaluation Period4.6.2. Operational Introduction Date
5. MESSAGE CATEGORIES
5.1. General5.1.1. Purpose5.1.2. Message Categories5.2. Transaction Times5.2.1. Transaction Time Conditions5.3. Message Classification and Categorisation2000R2082 — EN — 15.06.2002 — 001.001 — 5
▼B
5.3.1. Message Classification — Mandatory and Complementary
5.3.2. Categorisation of Messages
6. BASIC PROCEDURE — MANDATORY MESSAGES
6.1. General6.1.1. Description of Requirement6.1.2. Implementation6.2. Advance Boundary Information Message (ABI)
6.2.1. Purpose of the ABI Message
6.2.2. Message Contents6.2.3. Rules of Application6.2.4. Acknowledgement of ABI6.2.5. Examples6.3. Activate Message (ACT)
6.3.1. Purpose of the ACT Message
6.3.2. Message Contents6.3.3. Rules of Application6.3.4. Acknowledgement of ACT6.3.5. Examples
6.4. Logical Acknowledgement Message (LAM)
6.4.1. Purpose of the LAM Message6.4.2. Message Contents6.4.3. Rules of Application6.4.4. Acknowledgement of LAM6.4.5. Examples
7. BASIC PROCEDURE — COMPLEMENTARY MESSAGES
7.1. General
7.1.1. Description of Requirement7.1.2. Implementation7.2. Preliminary Activate Message (PAC)7.2.1. Purpose of the PAC Message7.2.2. Message Contents
7.2.3. Rules of Application
7.2.4. Acknowledgement of PAC7.2.5. Examples7.3. Revision Message (REV)7.3.1. Purpose of the REV Message
7.3.2. Message Contents
7.3.3. Rules of Application7.3.4. Acknowledgement of REV7.3.5. Examples2000R2082 — EN — 15.06.2002 — 001.001 — 6
▼B
7.4. Message for the Abrogation of Co-ordination (MAC)
7.4.1. Purpose of the MAC Message7.4.2. Message Contents
7.4.3. Rules of Application
7.4.4. Acknowledgement of MAC7.4.5. Examples7.5. SSR Code Assignment Message (COD)
7.5.1. Purpose of the COD Message
7.5.2. Message Contents7.5.3. Rules of Application
7.5.4. Acknowledgement of COD
7.5.5. Examples7.6. Information Message (INF)7.6.1. Purpose of the INF Message
7.6.2. Message Contents
7.6.3. Rules of Application7.6.4. Acknowledgement of INF
7.6.5. Examples
8. DIALOGUE PROCEDURE — COORDINATION
8.1. General8.1.1. Introduction
8.1.2. The Filter
8.1.3. Message Sequence8.1.4. Simultaneous Message Handling8.1.5. Reject Handling
8.1.6. Operational Reply Time-out
8.1.7. Implementation8.2. Activate Message (ACT)
8.2.1. Purpose of the ACT Message
8.2.2. Message Contents8.2.3. Rules of Application
8.2.4. Acknowledgement of ACT
8.3. Referred Activate Proposal Message (RAP)8.3.1. Purpose of the RAP Message8.3.2. Message Contents
8.3.3. Rules of Application
8.3.4. Acknowledgement of RAP8.3.5. Operational Reply to RAP
8.3.6. Examples
8.4. Revision Message (REV)2000R2082 — EN — 15.06.2002 — 001.001 — 7
▼B
8.4.1. Purpose of the REV Message
8.4.2. Message Contents8.4.3. Rules of Application
8.4.4. Acknowledgement of REV
8.4.5. Operational Reply to REV8.5. Referred Revision Proposal Message (RRV)8.5.1. Purpose of the RRV Message
8.5.2. Message Contents
8.5.3. Rules of Application8.5.4. Acknowledgement of RRV
8.5.5. Operational Reply to RRV
8.5.6. Examples8.6. Stand-by Message (SBY)8.6.1. Purpose of the SBY Message
8.6.2. Message Contents
8.6.3. Rules of Application8.6.4. Acknowledgement of SBY
8.6.5. Examples
8.7. Acceptance Message (ACP)8.7.1. Purpose of the ACP Message
8.7.2. Message Contents
8.7.3. Rules of Application8.7.4. Acknowledgement of ACP8.7.5. Examples
8.8. Co-ordination Message (CDN)
8.8.1. Purpose of the CDN Message8.8.2. Message Contents
8.8.3. Rules of Application
8.8.4. Acknowledgement of CDN8.8.5. Operational Reply to CDN8.8.6. Examples
8.9. Reject Co-ordination Message (RJC)
8.9.1. Purpose of the RJC Message8.9.2. Message Contents
8.9.3. Rules of Application
8.9.4. Acknowledgement of RJC8.9.5. Examples
9. DIALOGUE PROCEDURE — TRANSFER OF COMMUNICATION
9.1. General
9.1.1. Introduction2000R2082 — EN — 15.06.2002 — 001.001 — 8
▼B
9.1.2. Message Sequence
9.1.3. Transfer of Communications9.2. Transfer Initiation Message (TIM)
9.2.1. Purpose of the TIM Message
9.2.2. Message Contents9.2.3. Rules of Application9.2.4. Acknowledgement of TIM
9.2.5. Example
9.3. Supplementary Data Message (SDM)9.3.1. Purpose of the SDM Message
9.3.2. Message Contents
9.3.3. Rules of Application9.3.4. Acknowledgement of SDM9.3.5. Example
9.4. Hand-Over Proposal (HOP)
9.4.1. Purpose of the HOP Message9.4.2. Message Contents
9.4.3. Rules of Application
9.4.4. Acknowledgement of HOP9.4.5. Example
9.5. Request on Frequency Message (ROF)
9.5.1. Purpose of the ROF Message9.5.2. Message Contents9.5.3. Rules of Application
9.5.4. Acknowledgement of ROF
9.5.5. Example9.6. Change of Frequency Message (COF)
9.6.1. Purpose of the COF Message
9.6.2. Message Contents9.6.3. Rules of Application9.6.4. Acknowledgement of COF
9.6.5. Examples
9.7. Manual Assumption of Communications Message (MAS)9.7.1. Purpose of the MAS Message
9.7.2. Message Contents
9.7.3. Rules of Application9.7.4. Acknowledgement of MAS
9.7.5. Example
ANNEX A (NORMATIVE) DATA INSERTION RULES
ANNEX B (NORMATIVE) SPECIAL ROUTE PROCESSING REQUIREMENTS2000R2082 — EN — 15.06.2002 — 001.001 — 9
▼B
ANNEX C (INFORMATIVE) DIALOGUE PROCEDURE (SYSCO LEVEL 1) PHASES —
MESSAGE SEQUENCE2000R2082 — EN — 15.06.2002 — 001.001 — 10
▼B
COPYRIGHTNOTICE
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.2000R2082 — EN — 15.06.2002 — 001.001 — 11
▼B
FOREWORD
1. ResponsibleBody
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. RelationtotheEATCHIPWorkProgramme 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. ApprovalandAmendments
This Standard has been subject to the following approval proce-
dure as detailed in the Directives for Eurocontrol Standardisation:
— Approval by the EATCHIP Operational Requirement and
ATM Data Processing Team (ODT) by correspondence proce-
dure;
— 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 withspecified procedures.
4. EditorialPractices
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
prefixRecommendation .
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. RelationshiptoEdition1oftheEurocontrolStandardforOn
LineDataInterchange
This document supersedes Parts 1 and 2 of Edition 1 of the Euro-
control 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. SignificantChangesfromEdition1
The following are the most significant changes and additions
from Edition 1:
1. Incorporation of the following complementary (non-manda-
tory) messages in respect of the basic procedure:
— Message for the Abrogation of Co-ordination (MAC);2000R2082 — EN — 15.06.2002 — 001.001 — 12
▼B
— 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 Eurocon-
trol Standard Document for ATS Data Exchange Presentation
(ADEXP) is introduced. All messages specified under thebasic procedure and those used during the co-ordination phase
of the dialogue procedure are described using both Interna-
tional 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. RelationshiptoOtherDocuments
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 defini-
tion 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.2000R2082 — EN — 15.06.2002 — 001.001 — 13
▼B
1. INTRODUCTION
1.1. Purpose
1.1.1. Flights which are being provided with an ATC service are trans-
ferred from one ATC unit to the next in a manner designed to
ensure complete safety. In order to accomplishth is 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-ordi-
nated 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 indi-
vidual 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 repla-
cing suchverbal ‘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 withth e 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 prere-
quisite to the use of data interchange for this purpose.
1.2.3. This Standard is applicable between the Member States of Euro-
control to international OLDI facilities between units providing
an area ATC service.
1.2.4. Recommendation It is recommended that European Civil Avia-
tion 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 Docu-
ment, the editions indicated for the referenced documents were
valid.
Any revision of the referenced ICAO Documents shall be imme-
diately 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 Eurocon-
trol Standard Document and the contents of these other
referenced documents, this Eurocontrol Standard Document shall
take precedence.2000R2082 — EN — 15.06.2002 — 001.001 — 14
▼B
2.2. The following documents are referenced in this Standard Docu-
ment:
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,SYMBOLSANDABBREVIATIONS
3.1. Definitions
For the purposes of this Eurocontrol Standard, the following defi-
nitions 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
withadjoining 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 character-
istics, configuration, material, performance, personnel or
procedure, the uniform application of which has been approved
as essential for implementation in ATS systems within Eurocon-
trol Member States. A Eurocontrol Standard must not be in2000R2082 — EN — 15.06.2002 — 001.001 — 15
▼B
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 trans-
mission 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 transfer-
ring 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 acknowl-
edgement message, and its identification in the transferring
system are performed.
3.1.32. Transferof 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 posi-
tion 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. SymbolsandAbbreviations
For the purposes of this Eurocontrol Standard, the following
symbols and abbreviations shall apply.
ABI Advance Boundary Information Message2000R2082 — EN — 15.06.2002 — 001.001 — 16
▼B
ACC Area Control Centre
ACP Accept MessageACT Activate Message
ADEXP ATS Data Exchange Presentation
ATC Air Traffic ControlATM Air Traffic Management
ATS Air Traffic Service
CDN Co-ordination MessageCNL Flight Plan Cancellation
COD SSR Code Assignment Message
COF Change of Frequency MessageCOP Co-ordination Point
DED Directorate of EATCHIP Development, Eurocontrol
EATCHIP European ATC Harmonisation and Integration
Programme
ECAC European Civil Aviation ConferenceETO Estimated Time Over
ETOT Estimated Take-Off Time
EWPD EATCHIP Work Programme DocumentFDPS Flight Data Processing System
FRF Further Route of Flight
HMI Human-Machine InterfaceHOP Handover Proposal Message
ICAO International Civil Aviation Organisation
INF Information MessageLAM Logical Acknowledgement Message
LoA Letter of Agreement
MAC Message for the Abrogation of Co-ordinationMAS Manual Assumption of Communications
NM Nautical Mile
OLDI On-Line Data InterchangeORCAM Originating Region Code Assignment Method
PAC Preliminary Activate Message
RAP Referred Activate Proposal MessageREV Revision Message
RJC Reject Co-ordination Message
ROF Request on Frequency MessageRRV Referred Revision Message
SBY Stand-by Message
SDM Supplementary Data MessageSSR Secondary Surveillance Radar
SYSCO System Supported Co-ordination
TI Transfer InitiationTIM Transfer Initiation Message
TWR/APP Tower (aerodrome control) and ApproachControl
4. GENERALREQUIREMENTS
4.1. Introduction
This section describes the general operational requirements neces-
sary for the implementation of an OLDI facility between ATC
units and the classification and performance requirements of the
different types of message used.2000R2082 — EN — 15.06.2002 — 001.001 — 17
▼B
4.2. FlightDataProcessingSystemRequirements
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 informa-
tion 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 withtimes 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 TheFDPS shouldhave the development poten-
tial 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 reli-
able 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.
NOTEThe 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 rele-
vant 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.2000R2082 — EN — 15.06.2002 — 001.001 — 18
▼B
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 acknowledge-
ment 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 immedi-
ately 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. Eachsystem sh all 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 trans-
mission 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 applica-
tion 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 automati-
cally 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 proces-
sing to the appropriate position(s), as necessary, is assured.
NOTEThe detailed conditions for the generation of an acknowl-
edgement are specified individually for each message.
4.3. UpdatingfromSurveillanceData
Recommendation In order to ensure the accuracy of time esti-
mate data, information derived from the tracking of flights by
radar or other surveillance means should be used to update the
flight plan database.2000R2082 — EN — 15.06.2002 — 001.001 — 19
▼B
4.4. RecordingofOLDIData
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,DataSecurityandDataIntegrity
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 TheOLDIfacility shouldbeavailable24hours
every day.
4.5.1.3. Any scheduled down-time periods (and thus the planned avail-
ability 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 % (equiva-
lent 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
RecommendationData 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 transmis-
sion error per 2 000 messages.
4.6. OperationalEvaluation
4.6.1. Evaluation Period
Eachnew 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 withATC proce-
dures and overall safety prior to its operational implementation.
NOTEA procedure to assist in the evaluation of a new OLDI
facility is available from the OLDI Secretariat, Eurocon-
trol.
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. MESSAGECATEGORIES
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 comple-
mentary;
— assigns message types to categories.2000R2082 — EN — 15.06.2002 — 001.001 — 20
▼B
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. TransactionTimes
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
Message Category 90 % 99,8 %
1 4 sec 10 sec
2 10 sec 25 sec
3 15 sec 45 sec
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 respec-
tively.
5.3. MessageClassificationandCategorisation
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.
NOTEIn 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 trans-
mission, processing shall be included to be able to send such
messages if required by the sending unit and bilaterally agreed
withth e receiving unit.
NOTEComplementary 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 bilat-
erally between ATC units.2000R2082 — EN — 15.06.2002 — 001.001 — 21
▼B
5.3.2. Categorisation of Messages
5.3.2.1. The categorisation of messages for the basic procedure is speci-
fied 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
Message Type Abbreviation Category Transmission Reception
Advance Boundary Infor-
mationABI 3 M M
Activate ACT 2 M M
Revision REV 2 C (1)C (1)
Preliminary Activate PAC 2 C C
Abrogation of Co-ordina-
tionMAC 2 C C
SSR Code Assignment COD 2 C C
Information INF 3 C CLogical Acknowledgement
MessageLAM M M
NOTE
(1) Mandatory for TX and REC when used in a dialogue procedure.
Table 5-3
Dialogue Procedure — Co-ordination Phase Messages
(Additional to Table 5-2)
Message Type Abbreviation Category Transmission Reception
Referred Activate Proposal RAP 2 C M
Referred Revision RRV 2 C M
Co-ordination CDN 2 M M
Stand-by (1) SBY M M
Accept ACP 2 M M
Reject Co-ordination (2) RJC 2 C C
NOTES
(1) See paragraph5.2.1.1 Transaction Time Conditions.
(2) Not used in all airspace configurations.
Table 5-4
Dialogue Procedure — Transfer Phase Messages
Message Type Abbreviation Category Transmission Reception
Transfer Initiation TIM 1 M M
Supplementary Data SDM 1 (1)(1)
Handover Proposal HOP 1 M M
Change of Frequency (2) COF 1 C M2000R2082 — EN — 15.06.2002 — 001.001 — 22
▼B
Message Type Abbreviation Category Transmission Reception
Request on Frequency ROF 1 C M
Manual Assumption (2) MAS 1 C M
NOTES
(1) M when sent from the transferring unit; C when sent from the accepting unit.
(2) Bilaterally agreed procedures shall specify that when the transfer takes place in respect of a
given direction of traffic flow, as a minimum, either the transferring unit shall send a COF
message or the accepting unit shall send a MAS message.
6. BASICPROCEDURE—MANDATORYMESSAGES
6.1. General
6.1.1. Description of Requirement
This section describes the minimum requirement at the applica-
tion 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. AdvanceBoundaryInformationMessage(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,
— type of flight,
— equipment capability and status,— 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 proce-
dures.2000R2082 — EN — 15.06.2002 — 001.001 — 23
▼M1
▼B
▼B
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.
NOTEThe 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 SSRcode 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 associa-
tion 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 resolu-
tion.
6.2.3.3. Time Parameters for Transmission6.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 trans-
mitting a LAM message.
NOTEA 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 acknowl-
edgement 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 esti-
mating BNE VOR at 1221 UTC, flying at FL350 at a true
airspeed of 480 knots, planned to route via UB4 BNE UB4 BPK2000R2082 — EN — 15.06.2002 — 001.001 — 24
▼B
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. I C A O
(ABIE/L001-AMM253/A7012-LMML-BNE/1221F350-EGBB-9/
B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON-80/N-
81/W/EQ Y/NO)
6.2.5.2. A D E X P
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 -FLTTYP N -BEGIN EQCST -EQPT W/
EQ -EQPT Y/NO -END EQCST-ROUTE N0480F390 UB4 BNE
UB4 BPK UB3 HON)
6.3. ActivateMessage(ACT)
6.3.1. Purpose of the ACT Message
The ACT message satisfies the following operational require-
ments:
— Replace the verbal boundary estimate by transmitting automa-
tically 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
withth e 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,
— type of flight,
— equipment capability and status,
— 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. General6.3.3.1.1. One ACT message shall be sent for eligible flights crossing the
boundary except as provided for in paragraph6.3.3.1.10.
6.3.3.1.2. The ACT message shall be generated and transmitted automati-
cally 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 trans-
mitted shall be displayed at the working position responsible for
the co-ordination of the flight prior to the actual transmission.2000R2082 — EN — 15.06.2002 — 001.001 — 25
▼M1
▼B
▼M1
▼B
▼B
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 transmis-
sion 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 transfer-
ring 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-ordina-
tion 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 Unit6.3.3.2.1. The ATC system receiving an ACT message shall attempt asso-
ciation 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.2000R2082 — EN — 15.06.2002 — 001.001 — 26
▼B
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. I C A O
(ACTE/L005-AMM253/A7012-LMML-BNE/1226F350-EGBB-9/
B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON-80/N-
81/W/EQ Y/NO)
6.3.5.2. A D E X P
-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 -FLTTYP N-BEGIN EQCST-
EQPT W/EQ -EQPT Y/NO -END EQCST-ROUTE N0480F390
UB4 BNE UB4 BPK UB3 HON
6.4. LogicalAcknowledgementMessage(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 withth e 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 appro-
priate working position(s).
6.4.2. Message Contents
The LAM message shall contain the following items of data:
— Message Type;
— Message Number;
— Message Reference.
NOTEData insertion rules, formats and field contents are speci-
fied at Annex A.
6.4.3. Rules of Application
6.4.3.1. General6.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 tech-
nical messages to ensure the integrity of data transmissions.
6.4.3.1.4. The LAM message shall be generated and transmitted immedi-
ately so that the transaction time requirement of the message
being acknowledged can be achieved.
6.4.3.1.5. Withexception of ABI messages, th e 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 suchwarnings.2000R2082 — EN — 15.06.2002 — 001.001 — 27
▼M1
▼B
▼B
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. BASICPROCEDURE—COMPLEMENTARYMESSAGES
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 Proce-
dure — 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 ActivateMessage(PAC)
7.2.1. Purpose of the PAC Message
The PAC message satisfies the following operational require-
ments:
— 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/approachcontrol) unit to th e
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).
NOTEData insertion rules, formats and field contents are speci-
fied at Annex A.
7.2.3. Rules of Application
7.2.3.1. General7.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.2000R2082 — EN — 15.06.2002 — 001.001 — 28
▼B
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 transmis-
sion 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 SSRcode 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 Unit7.2.3.2.1. The ATC system receiving a PAC message shall attempt associa-
tion 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
paragraph7.2.3.2.2. above, a COD message sh all be returned in
addition to the LAM.
NOTEAs 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 for2000R2082 — EN — 15.06.2002 — 001.001 — 29
▼B
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 iden-
tifying 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 paragraph7.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 Message7.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 Request7.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. RevisionMessage(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,— aircraft identification,
— departure aerodrome,
— estimate data and/or coordination point,
— destination aerodrome,
— message reference (optional),— SSR mode and code (optional),2000R2082 — EN — 15.06.2002 — 001.001 — 30
▼M1
▼M1
— route (optional),
— equipment capability and status (optional).
NOTE:Data insertion rules, formats and field contents are
specified at Annex A.
7.3.3. Rules of Application
7.3.3.1. General7.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,— equipment capability and status.
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), SSR code or
equipment capability and status.
7.3.3.1.4. Where bilaterally agreed, a REV message shall be sent when
there is any change in the following:
— COP,
— route.
NOTE:Operational rules may require that modifications effected
after ACT be subject to prior coordination 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. I C A O format
All revision messages include field types 3, 7, 13, 14 and 16. 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 field 14,
— a change to the SSR code shall be included as elements (b)
and (c) of field 7,
All other modifications are included in field 22 format after the
initial five fields. The following rules apply:
— fields included in field 22 format can be in any order relative
to eachoth er,
— changes to the COP shall be incorporated as field 14 data in
field 22 format (see Appendix B — Special route processing
requirements),
— route changes shall be incorporated as field 15 data in field 22
format. Rules for the coordination of such changes, including
direct routings, are specified in Annex B Special Route
Processing Requirements,
— equipment Capability and Status; only the capability or
capabilities being changed shall be included. A message chan-
ging a capability that results in the need to include data
concerning an additional capability as specified in Annex A
paragraph A.30 shall include the additional capability.2000R2082 — EN — 15.06.2002 — 001.001 — 31
▼B
▼M1
▼B
▼M1
▼M1
7.3.3.2.2. A D E X P 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,
— the primary field COP shall be included unless a change to
the ETA or transfer level(s) requires the use of primary field
COORDATA. It shall contain the COP through which the
flight is currently co-ordinated or, if the COP is being
amended, the COP through which the flight had previously
been coordinated,
— changes to the COP shall be incorporated using primary field
COORDATA (see Appendix B — Special route processing
requirements). Suchmessages sh all also include primary field
COP as stated above,
— changes to the route shall be incorporated using primary field
ROUTE. Rules for the coordination of such changes,
including direct routings, are specified in Annex B — Special
route processing requirements,
— a change to the SSR Code shall be indicated by the inclusion
of primary field SSRCODE,
— a change to equipment capability and status shall utilise
primary field EQCST; only the capability or capabilities being
changed shall be included. A message changing a capability
that results in the need to include data concerning an addi-
tional capability as specified in Annex A paragraphA.30
shall include the additional capability.
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 Unit7.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 Transmission7.3.3.4.1. The REV message is event driven and shall be transmitted imme-
diately 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 sepa-
rately 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 acknowledge-
ment;
— cannot be associated with a flight plan within the receiving
system, a LAM message shall not be transmitted.2000R2082 — EN — 15.06.2002 — 001.001 — 32
▼B
▼B
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 trans-
ferring ATC unit.
7.3.5. Examples
7.3.5.1. I C A O
(a) (REVE/L002-AMM253-LMML-BNE/1226F310-EGBB)
(b) (REVE/L010-AMM253/A2317-LMML-BNE/1226F310-
EGBB)
(c) (REVE/L019-AMM253-LMML-BNE/1237F350-EGBB-81/
W/NO)
(d) (REVBC/P873-BAF4486-EBMB-NEBUL/2201F250-LERT-
81/W/NO U/EQ)
7.3.5.2. A D E X P
(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
(c) -TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC
L -SEQNUM 019 -ARCID AMM253 -ADEP LMML -COP
BNE -ADES EGBB -BEGIN EQCST -EQPT W/NO -END
EQCST
(d) -TITLE REV -REFDATA -SENDER -FAC BC -RECVR -
FAC P -SEQNUM 873 -ARCID BAF4486 -ADEP EBMB -
COP NEBUL -ADES LERT -BEGIN EQCST -EQPT Y/NO
-EQPT U/EQ -END EQCST
7.4. MessagefortheAbrogationofCo-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).
NOTEData insertion rules, formats and field contents are speci-
fied at Annex A.2000R2082 — EN — 15.06.2002 — 001.001 — 33
▼M1
▼B
▼B
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 abro-
gated.
7.4.3.1.4. Recommendation A MAC message should be sent when the noti-
fication (ABI message)previously effected foraflight iscancelled
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 ornotification is torevert andthe 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 withth e 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.2000R2082 — EN — 15.06.2002 — 001.001 — 34
▼B
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 appro-
priate, 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 suchcases a verbal abrogation of co-ordination sh all 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 Maas-
tricht 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 bothin 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. SSRCodeAssignmentMessage(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 alloca-
tion 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.2000R2082 — EN — 15.06.2002 — 001.001 — 35
▼B
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).
NOTEData insertion rules, formats and field contents are speci-
fied 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 discre-
pancy 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 withth e 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)2000R2082 — EN — 15.06.2002 — 001.001 — 36
▼B
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. InformationMessage(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 suchagencies
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.
NOTEData insertion rules, formats and field contents are speci-
fied 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 capabil-
ities. 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 condi-
tions.
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 appro-
priate position .2000R2082 — EN — 15.06.2002 — 001.001 — 37
▼B
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. DIALOGUEPROCEDURE—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. General8.1.2.1.1. The co-ordination dialogue procedure requires that systems iden-
tify 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 asso-
ciated withth e 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.2000R2082 — EN — 15.06.2002 — 001.001 — 38
▼B
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 withth e 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 condi-
tions 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 trans-
ferring 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 deci-
sion, 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 transfer-
ring 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 trans-
fers 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 bothunits do not simultaneously make proposals on th e 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 witha 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.2000R2082 — EN — 15.06.2002 — 001.001 — 39
▼B
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-ordi-
nation 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 complemen-
tary 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. ActivateMessage(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.2000R2082 — EN — 15.06.2002 — 001.001 — 40
▼B
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 para-
graph 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.
NOTEIf 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 accor-
dance withparagraph6.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-stan-
dard 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 ActivateProposalMessage(RAP)
8.3.1. Purpose of the RAP Message
The RAP message satisfies the following operational require-
ments, in addition to those specified for the ACT message in
paragraph6.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.2000R2082 — EN — 15.06.2002 — 001.001 — 41
▼B
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 option-
ally 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 condi-
tions:
— 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 trans-
mitted 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 transmis-
sion of the RAP message.
8.3.3.2. Processing in the Receiving Unit8.3.3.2.1. The ATC system receiving a RAP message shall attempt associa-
tion 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 posi-
tion 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 trans-
mission of an SBY message.2000R2082 — EN — 15.06.2002 — 001.001 — 42
▼B
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. Acceptance8.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 bothof th e 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.
NOTEWith 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. RevisionMessage(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 torefer 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 paragraph7.3.2.
8.4.3. Rules of Application
8.4.3.1. General8.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
paragraph7.3.3.1 for fligh ts withstandard 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 paragraph7.3.3.2000R2082 — EN — 15.06.2002 — 001.001 — 43
▼B
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-stan-
dard 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. Acknowledgement8.4.4.1.1. If the REV message is to be acknowledged, it shall be acknowl-
edged 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 bothof th e 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 RevisionProposalMessage(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 (paragraph7.3.2) and may optionally include th e
following data element:
— reason, indicating manual referral (only available in ADEXP
format).2000R2082 — EN — 15.06.2002 — 001.001 — 44
▼B
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 eachrevision, if eith er:
— 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 trans-
mission 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 EGBB2000R2082 — EN — 15.06.2002 — 001.001 — 45
▼B
8.6. Stand-byMessage(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.
NOTEData insertion rules, formats and field contents are speci-
fied at Annex A.
8.6.3. Rules of Application
8.6.3.1. General
The SBY message shall be generated and transmitted automati-
cally 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. AcceptanceMessage(ACP)
8.7.1. Purpose of the ACP Message
The ACP message satisfies the following operational require-
ments 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.2000R2082 — EN — 15.06.2002 — 001.001 — 46
▼B
NOTEData insertion rules, formats and field contents are speci-
fied 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 Unit8.7.3.2.1. The ATC system receiving an ACP message shall attempt asso-
ciation 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. Acknowledgement8.7.4.1.1. A LAM shall not be returned where the ACP is used as an auto-
matic 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-ordinationMessage(CDN)
8.8.1. Purpose of the CDN Message
The CDN message satisfies the following operational require-
ments:
— 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 condi-
tions by the accepting controller to the transferring controller.2000R2082 — EN — 15.06.2002 — 001.001 — 47
▼B
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;
NOTEThe 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.
NOTEData insertion rules, formats and field contents are speci-
fied at Annex A.
8.8.3. Rules of Application
8.8.3.1. General8.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.
NOTEThis 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 condi-
tions.
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 acknowl-
edgement nor an operational reply shall be returned.
NOTETheeffect ofthisisthat whentwo messagescross,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 bothof th e 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 Unit8.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.2000R2082 — EN — 15.06.2002 — 001.001 — 48
▼B
8.8.3.2.2. If the CDN cannot be associated, or a discrepancy is found that
inhibits correct processing of the message, no SBY shall be
returned.
8.8.4. Acknowledgement of CDN
8.8.4.1. Acknowledgement
Under the conditions specified above, the CDN message shall be
acknowledged by the generation and transmission of an SBY
message.
8.8.4.2. No Acknowledgement Cases
If no SBY message is received as an acknowledgement for a
CDN message, a warning shall be displayed at the ATC position
responsible for the co-ordination of the flight.
8.8.5. Operational Reply to CDN
The controller may either accept or reject the transfer conditions
proposed in a CDN message.
8.8.5.1. Acceptance
When the transferring controller elects to accept the proposed
transfer conditions, an ACP message shall be returned.
8.8.5.2. Recommendation When the transferring controller elects to
reject the proposed transfer conditions, an RJC message should
be sent (explicit rejection).
NOTEThe proposed co-ordination is implicitly rejected if no
acceptance has been received by the time that the CDN
message times-out.
8.8.6. Examples
8.8.6.1. ICAO
(CDNL/D041D/L025 -EIN636 -EIDW -LIFFY/1638F270F110A -
EBBR)
8.8.6.2. ADEXP
-TITLE CDN -REFDATA -SENDER -FAC L -RECVR -FAC D -
SEQNUM 041 -MSGREF -SENDER -FAC D -RECVR -FAC L -
SEQNUM 025 -ARCID EIN636 -ADEP EIDW -ADES EBBR -
PROPFL -TFL F270 -SFL F110A
8.9. RejectCo-ordinationMessage(RJC)
8.9.1. Purpose of the RJC Message
The RJC message indicates the rejection by a controller at one
unit of the transfer conditions proposed by the controller at the
other unit in one of the following messages:
— RAP;
— RRV;
— CDN;
— ACT and REV, if either is found to be non-standard.
The RJC message can only be used in direct response to one of
the above messages.
8.9.2. Message Contents
The RJC message shall contain the following items of data:
— Message Type;
— Message Number;— Message Reference.
NOTEData insertion rules, formats and field contents are speci-
fied at Annex A.
8.9.3. Rules of Application
8.9.3.1. General
8.9.3.1.1. The RJC shall be sent as required in response to a RAP, RRV,
CDN message or to a ACT or REV message found to be non-
standard at the accepting unit.2000R2082 — EN — 15.06.2002 — 001.001 — 49
▼B
8.9.3.1.2. The RJC message terminates the system dialogue and any
previously agreed co-ordination remains valid.
8.9.3.1.3. Recommendation Following the reception of an RJC message a
new co-ordination sequence should be initiated, reflecting the
telephone co-ordination where applicable.
8.9.3.2. Processing in the Receiving Unit
8.9.3.2.1. If a corresponding message to which the RJC message refers is
found;
— the rejection shall be indicated at the ATC position respon-
sible for the co-ordination of the relevant flight; and
— a LAM shall be returned in acknowledgement.
8.9.3.2.2. If no suchmessage is found to be awaiting reply, or a discre-
pancy is present in the message which prevents processing, no
acknowledgement shall be returned.
8.9.4. Acknowledgement of RJC
8.9.4.1. Acknowledgement
The RJC message shall be acknowledged by the generation and
transmission of a LAM message.
8.9.4.2. No Acknowledgement Cases
If no LAM message is received as an acknowledgement for an
RJC message, a warning shall be displayed at the ATC position
responsible for the co-ordination of the flights.
8.9.5. Examples
8.9.5.1. ICAO
(RJCMC/E746E/MC324)
8.9.5.2. ADEXP
-TITLE RJC -REFDATA -SENDER -FAC MC -RECVR -FAC E
-SEQNUM 746 -MSGREF -SENDER -FAC E -RECVR -FAC
MC -SEQNUM 324
9. DIALOGUE PROCEDURE — TRANSFER OF COMMUNI-
CATION
9.1. General
9.1.1. Introduction
9.1.1.1. This section of the Standard describes the facilities and messages
that support the radar hand-over aspect of the transfer of control
procedure. They shall be implemented where bilaterally agreed.
9.1.1.2. Transfer of Communication facilities shall not be implemented
unless the unit is utilising either the co-ordination facilities
described in Section 6 (Basic Procedure — Mandatory Messages)
or those in Section 8 (Dialogue Procedure — Co-ordination).
9.1.1.3. The messages described in this section of the document are avail-
able only in ADEXP format and it is not planned that they be
made available in ICAO format.
9.1.2. Message Sequence
9.1.2.1. Transfer of Communication message exchange, other than the
Supplementary Data Message (SDM), shall not take place unless
co-ordination is complete, i.e. an ACT or RAP dialogue has been
completed by a LAM or ACP.
9.1.2.2. An acknowledgement shall not be returned whilst co-ordination is
outstanding.
9.1.3. Transfer of Communications
9.1.3.1. The method of signifying the actual change of communication of
flights shall be bilaterally agreed between the two units
concerned.
9.1.3.2. The conditions shall be one or both of the following:
— the transferring unit sends a Change Of Frequency message
(COF);2000R2082 — EN — 15.06.2002 — 001.001 — 50
▼B
— the accepting unit sends a Manual Assumption of Communi-
cation message (MAS);
9.1.3.3. The method shall be agreed between the two units for each traffic
flow.
NOTEAlternative methods may be used for different flows, e.g.
one unit may generate COF messages for flights leaving
its airspace and MAS messages for flights entering its
airspace. In such a case it would not be necessary for
the other unit to enter any messages to signify transfer
of communication.
9.2. TransferInitiationMessage(TIM)
9.2.1. Purpose of the TIM Message
The purpose of the TIM is to:
— signify the Transfer Initiation (TI) event (the end of the co-
ordination phase and the start of the transfer phase);
— simultaneously forward executive control data from the trans-
ferring to the accepting unit.
9.2.2. Message Contents
The TIM message shall consist of the following items of data:
— Mandatory data — the message shall contain:
— Message Type;
— Message Number;
— Aircraft Identification;
— Available data — the message shall also contain any of the
following, if available:
— Cleared Flight Level;
— Assigned Heading or Direct Clearance;
— Assigned Speed;
— Assigned Rate of Climb/Descent;
— Optional data — the message may also contain:
— Position.
NOTEData insertion rules, formats and field contents are speci-
fied at Annex A.
9.2.3. Rules of Application
9.2.3.1. General
9.2.3.1.1. The TIM message shall be generated and transmitted by the
transferring unit to the accepting unit without human intervention
at a bilaterally agreed time/distance of the flight from the
boundary.
9.2.3.1.2. A TIM message shall also be sent automatically when the
Request On Frequency message (ROF) is received by the trans-
ferring unit.
9.2.3.1.3. A TIM shall not be sent before the flight has been co-ordinated.9.2.3.1.4. The TIM message shall contain the most recent data available in
the system.
9.2.3.2. Time Parameters for Transmission
9.2.3.2.1. The TIM generation parameter shall be a Variable System Para-
meter which may be changed, based on the provisions of the
LoAs.
9.2.3.2.2. Recommendation The TIM generation system parameter should
be defined separately for each of the COPs.
9.2.3.2.3. The co-ordination partners shall include the TIM generation para-
meters in their LoA.
9.2.3.2.4. The system parameter triggering the TIM message may be related
to the calculated ground speed of the aircraft. However, initiation
of a TIM message shall always commence before the current
flight plan position is closer to COP than a minimum distance
specified bilaterally.2000R2082 — EN — 15.06.2002 — 001.001 — 51
▼B
9.2.3.2.5. The specified system parameter for TIM transmission shall allow
sufficient time for verbal co-ordination before the hand-over.
9.2.3.3. Processing in the Receiving Unit9.2.3.3.1. The data received in a TIM shall be made available to the
accepting controller.
9.2.4. Acknowledgement of TIM
9.2.4.1. Acknowledgement
If the TIM message:
— can be unambiguously associated with a flight plan, it shall be
acknowledged by the generation and transmission of a LAM
message;
— cannot be unambiguously associated witha fligh t plan, no
acknowledgement shall be sent.
9.2.4.2. No Acknowledgement Cases
If no LAM message is received as an acknowledgement for an
TIM message, a warning shall be displayed at the appropriate
position.
9.2.5. Example
-TITLE TIM -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 029 -ARCID AMM253
9.3. SupplementaryDataMessage(SDM)
9.3.1. Purpose of the SDM Message
9.3.1.1. General
9.3.1.1.1. The primary purpose of the SDM is to transmit control data and
changes thereto from the transferring unit to the accepting unit,
provided that it has been bilaterally agreed that the changes do
not need to be acknowledged by the accepting controller.
9.3.1.1.2. The SDM message may also be used by the accepting unit to
notify the transferring unit of the radio telephony frequency to
which the flight is to be transferred.
9.3.2. Message Contents
9.3.2.1. Messages from the Transferring Unit
The SDM message shall consist of the following items of data:
— Mandatory data — the message shall contain:
— Message Type;
— Message Number;— Aircraft Identification;
— Additional data — the message shall also contain one or more
of the following:
— Assigned Heading or Direct Clearance;
— Assigned Speed;— Assigned Rate of Climb/Descent;— Cleared Flight Level.
9.3.2.2. Messages from the Accepting Unit
The SDM shall contain the following data:
— Message Type;
— Message Number;— Aircraft Identification;
— Frequency.
NOTEData insertion rules, formats and field contents are speci-
fied at Annex A.2000R2082 — EN — 15.06.2002 — 001.001 — 52
▼B
9.3.3. Rules of Application
9.3.3.1. Messages from the Transferring Unit
9.3.3.1.1. SDM messages shall be transmitted after the initiation of the
transfer phase (see TIM, paragraph 9.2) following any change to
the following items:
— cleared flight level;
— assigned speed;— assigned rate of climb/descent;
— assigned heading; or
— issue or change of a clearance for the flight to proceed direct
to a specified point.
NOTEThe HOP message is required to be used when approval
by the accepting controller is required prior to the
transfer of communication.
9.3.3.1.2. The message shall contain only the fields which have changed.
9.3.3.1.3. SDM messages containing the data described in 9.3.3.1.1 shall be
transmitted before TI, if bilaterally agreed.
9.3.3.1.4. Suchmessages sh all commence at a bilaterally agreed time rela-
tive to TI, provided that there is data for which there is a value
available in the system.
9.3.3.2. Messages from the Accepting Unit
9.3.3.2.1. SDM messages may be transmitted to indicate the frequency on
which the flight is to contact the accepting unit.
NOTEUnits may agree bilaterally to send other information.
Such transfer is not defined in, and therefore, not part
of, this Standard.
9.3.3.2.2. SDM messages from the accepting unit shall be transmitted
during the co-ordination phase if bilaterally agreed.
9.3.3.3. Processing in the Receiving Unit
9.3.3.3.1. The ATC system receiving an SDM message shall attempt asso-
ciation with the corresponding flight plan.
9.3.3.3.2. If a corresponding flight plan in the co-ordinated state is found:
— a LAM shall be returned; and
— the operational contents of the SDM message shall be made
available to the appropriate controller.
9.3.3.3.3. If a corresponding flight plan cannot be found, or a discrepancy is
found that inhibits correct processing of the message:
— no LAM shall be returned; and
— a warning shall be output at an appropriate position.
9.3.4. Acknowledgement of SDM
9.3.4.1. Acknowledgement
The SDM message shall be acknowledged by the generation and
transmission of a LAM message.
9.3.4.2. No Acknowledgement Cases
If no LAM message is received as an acknowledgement for an
SDM message, a warning shall be displayed at an appropriate
position.
9.3.5. Example
-TITLE SDM -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 028 -ARCID AMM253 -AHEAD 290
9.4. Hand-OverProposal(HOP)
9.4.1. Purpose of the HOP Message
The purpose of the HOP Message is:
— for the transferring controller to draw the attention of the
accepting controller to a specific flight for handover purposes;
— for the transferring controller to propose the flight for hand-
over to the accepting controller when it is required to do so;2000R2082 — EN — 15.06.2002 — 001.001 — 53
▼B
— to forward modifications to the executive control data which
require the approval of the accepting controller, as bilaterally
agreed.
It is not necessary to utilise the HOP for all flights; it is used at
the discretion of the transferring controller.
NOTEWith respect to paragraph c) above, the SDM is used to
forward modifications to executive control data which do
not require the approval of the accepting controller.
9.4.2. Message Contents
The HOP message shall consist of the following items of data:
— Mandatory data — the message shall contain:
— Message Type;
— Message Number;— Aircraft Identification;
— Available data — the message shall also contain any of the
following, if available:
— Cleared Flight Level;
— Assigned Heading/Direct Clearance;
— Assigned Speed;
— Assigned Rate of Climb/Descent;
— Optional data — the message may also contain:
— Position.
NOTEData insertion rules, formats and field contents are speci-
fied at Annex A.
9.4.3. Rules of Application
9.4.3.1. General9.4.3.1.1. The HOP message, when used, shall be manually initiated by the
transferring controller.
9.4.3.1.2. The message shall include any flight data described in paragraph
9.4.2 above which has changed from that previously transmitted.
9.4.3.1.3. If a HOP message is sent before TI, the Transfer phase shall be
initiated.
NOTEA Transfer Initiation Message (TIM) is not required in
addition to the HOP.
9.4.3.1.4. The earliest time or distance before the COP or boundary at
which a HOP may be sent shall be bilaterally agreed.
9.4.3.1.5. Recommendation The time/distance should be specified sepa-
rately for each COP.
9.4.3.2. Processing in the Receiving Unit
9.4.3.2.1. The ATC system receiving a HOP message shall attempt associa-
tion with the corresponding flight plan.
9.4.3.2.2. The flight data received in the message shall be displayed imme-
diately to the accepting controller.
9.4.3.2.3. If the accepting controller accepts the flight under the conditions
proposed in the HOP, a ROF may be sent in response to the
transferring unit. When bilaterally agreed an ACP may be sent
as a reply to a HOP.
9.4.3.2.4. If the accepting controller is unable to accept the flight, the
transfer shall be agreed verbally.
NOTEDue to the urgency of the handover procedure, system
support in monitoring the return of the ROF (or ACP) is
not required by this Standard; it is assumed that the
transferring controller will be well aware of the absence
of a response from the accepting controller and will take
action as necessary. However, this Standard does not
prevent a warning being provided to the transferring
controller if it is considered operationally necessary.
9.4.3.2.5. As soon as a ROF (or ACP) has been received, the HOP message
data shall become operationally binding to both of the ATC units.2000R2082 — EN — 15.06.2002 — 001.001 — 54
▼B
9.4.4. Acknowledgement of HOP
9.4.4.1. Acknowledgement
If it can be associated with a flight plan, the HOP message shall
be acknowledged automatically by a LAM.
9.4.4.2. No Acknowledgement Cases
If no LAM message is received as an acknowledgement for a
HOP message, a warning shall be displayed at the appropriate
position.
9.4.5. Example
-TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM253 -CFL F190 -ASPEED N0420 -
RATE D25 -DCT BEN STJ
9.5. RequestonFrequencyMessage(ROF)
9.5.1. Purpose of the ROF Message
The ROF is sent by the accepting unit to the transferring unit,
when required, requesting the transferring controller to instruct
the aircraft to change to the frequency of the accepting controller.
The message may be used:
— in reply to a HOP to signify the acceptance of the flight under
the proposed conditions;
— to request the early transfer of the flight.
9.5.2. Message Contents
The ROF message shall consists of the following items of data:
— Mandatory data — the message shall contain:
— Message Type;
— Message Number;— Aircraft Identification;
— Optional data — the message may also contain:
— Frequency.
NOTEData insertion rules, formats and field contents are speci-
fied at Annex A.
9.5.3. Rules of Application
9.5.3.1. General9.5.3.1.1. The ROF message shall be manually initiated by the accepting
controller.
9.5.3.1.2. The accepting controller may trigger a ROF, either:
— when the accepting controller requires to have the aircraft
early on frequency;
— as a reply to a HOP message.
9.5.3.2. Processing in the Receiving Unit9.5.3.2.1. The ATC system receiving an ROF message shall attempt asso-
ciation with the corresponding flight plan.
9.5.3.2.2. The reception of the ROF shall be indicated to the transferring
controller without delay.
9.5.3.2.3. If the flight is not in the Transfer phase, the Transfer phase shall
be initiated and a TIM message shall be transmitted.
9.5.4. Acknowledgement of ROF
9.5.4.1. Acknowledgement9.5.4.1.1. If the ROF message can be unambiguously associated with a
flight plan, it shall be acknowledged by the generation and trans-
mission of a LAM message.
9.5.4.1.2. If the ROF message cannot be unambiguously associated with a
flight plan, no acknowledgement shall be sent.2000R2082 — EN — 15.06.2002 — 001.001 — 55
▼B
9.5.4.2. No Acknowledgement Cases
If no LAM message is received as an acknowledgement for an
ROF message, a warning shall be displayed at the appropriate
ATC position.
9.5.5. Example
-TITLE ROF -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM253
9.6. ChangeofFrequencyMessage(COF)
9.6.1. Purpose of the COF Message
9.6.1.1. General9.6.1.1.1. The COF is sent by the transferring unit to the accepting unit, to
indicate that the flight has been instructed to contact the
accepting controller.
9.6.1.1.2. The message may include the facility for the transferring
controller to release the flight from the agreed transfer conditions
when it has established radio communication with the accepting
controller.
9.6.2. Message Contents
The COF message shall consist of the following items of data:
— Mandatory data — the message shall contain:
— Message Type;
— Message Number;— Aircraft Identification;
— Available data — the message shall also contain any of the
following, if available:
— Release Indication;
— Frequency;— Cleared Flight Level;— Assigned Heading or Direct Clearance;— Assigned Speed;— Assigned Rate of Climb/Descent;
— Optional data — the message may also contain:
— Position.
NOTEData insertion rules, formats and field contents are speci-
fied at Annex A.
9.6.3. Rules of Application
9.6.3.1. General
9.6.3.1.1. The COF message shall be manually initiated by the transferring
controller.
9.6.3.1.2. The use of the COF message is mandatory if, by bilateral agree-
ment, the MAS message is not used.
9.6.3.1.3. If a COF message is sent before TI, the Transfer phase shall be
initiated.
NOTEA Transfer Initiation Message (TIM) is not required in
addition to the COF.
9.6.3.2. Processing in the Receiving Unit
9.6.3.2.1. The ATC system receiving a COF message shall attempt associa-
tion with the corresponding flight plan.
9.6.3.2.2. The reception of the COF shall be indicated to the accepting
controller without delay.
9.6.4. Acknowledgement of COF
9.6.4.1. Acknowledgement
9.6.4.1.1. If the COF message can be unambiguously associated with a
flight plan, it shall be acknowledged by the generation and trans-
mission of a LAM message.
9.6.4.1.2. If the COF message cannot be unambiguously associated with a
flight plan, no acknowledgement shall be sent.2000R2082 — EN — 15.06.2002 — 001.001 — 56
▼B
9.6.4.2. No Acknowledgement Cases
If no LAM message is received as an acknowledgement for a
COF message, a warning shall be displayed at the appropriate
ATC position.
9.6.5. Examples
-TITLE COF -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM253
9.7. ManualAssumptionofCommunicationsMessage(MAS)
9.7.1. Purpose of the MAS Message
The MAS is sent by the accepting unit to the transferring unit
indicating that two-way radio contact has been established with
the flight.
9.7.2. Message Contents
The MAS message shall contain the following items of data:
— Message Type;
— Message Number;— Aircraft Identification.
NOTEData insertion rules, formats and field contents are speci-
fied at Annex A.
9.7.3. Rules of Application
9.7.3.1. General
9.7.3.1.1. The MAS message shall be manually initiated by the accepting
controller.
9.7.3.1.2. The use of the MAS message is mandatory if, by bilateral agree-
ment, the COF message is not used.
9.7.3.2. Processing in the Receiving Unit
9.7.3.2.1. The ATC system receiving a MAS message shall attempt associa-
tion with the corresponding flight plan.
9.7.3.2.2. The fact that the MAS has been received shall be presented
immediately to the controller.
9.7.4. Acknowledgement of MAS
9.7.4.1. Acknowledgement9.7.4.1.1. If the MAS message can be unambiguously associated with a
flight plan, it shall be acknowledged by the generation and trans-
mission of a LAM message.
9.7.4.1.2. If the MAS message cannot be unambiguously associated with a
flight plan, no acknowledgement shall be sent.
9.7.4.2. No Acknowledgement Cases
If no LAM message is received as an acknowledgement for an
MAS message, a warning shall be displayed at the appropriate
ATC position, as required.
9.7.5. Example
-TITLE MAS -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM2532000R2082 — EN — 15.06.2002 — 001.001 — 57
▼B
ANNEX A (Normative)
DATAINSERTIONRULES
CONTENTS
A.1. Purpose
A.2. Generic Message FormatsA.3. Message Type
A.4. Message Number
A.5. Message ReferenceA.6. Aircraft Identification
A.7. SSR Mode and Code
A.8. Departure AerodromeA.9. Estimate Data
A.10. Co-ordination Point
A.11. Destination AerodromeA.12. Aircraft Number and Type
A.13. Route
A.14. Other Flight Plan DataA.15. Co-ordination Status and Reason
A.16. Assigned Heading (ADEXP only)
A.17. Assigned Speed (ADEXP only)A.18. Assigned Rate of Climb/Descent (ADEXP only)
A.19. Direct Clearance (ADEXP only)
A.20. Direct Routing RequestA.21. Position (ADEXP only)
A.22. Release Indication (ADEXP only)
A.23. FrequencyA.24. Reason (ADEXP only)
A.25. Cleared Flight Level (ADEXP only)
A.26. Transfer Flight Level (ADEXP only)A.27. Estimated Take-Off Time
A.28. Reference Message Type
A.29. Type of flight
A.30. Equipment capability and status
A.1.Purpose
This Annex describes the general rules for the insertion of data in
the messages described in this Standard. These rules apply to all
messages except where other alternatives or exceptions to these
rules are specifically stated in the Rules of Application for a
specific message.
A.2.Generic MessageFormats
A.2.1. All messages described in the following sections may be transmitted
using ICAO format:
6 Basic Procedure — Mandatory Messages;
7 Basic Procedure — Complementary Messages;
8 Dialogue Procedure — Co-ordination.2000R2082 — EN — 15.06.2002 — 001.001 — 58
▼M1
▼B
▼B
A.2.2. ICAO message field formats are specified in the Procedures for Air
Navigation Services — Rules of the Air and Air Traffic Control
(Document 4444). In messages where they occur, the following
ICAO Field types shall be transmitted before any other Field types
in the following order: 3, 7, 13, 14, and 16. As they are in Field
type 22 format, the order of other ICAO Field types is not impor-
tant, other than that they do not precede the Field types listed above.
A.2.2.a In some instances a pseudo ICAO field type number is used where a
suitable ICAO field does not exist. Suchnumbers contain two digit
values equal to or greater than 80.
A.2.3. All messages described in this document may be transmitted using
Eurocontrol ADEXP format. The contents, structure, and usage of
ADEXP data fields shall be in accordance with Reference 2.
NOTES1.Only the Primary ADEXP data fields are listed in this Annex,
except where associated Sub-fields require specific comment.
The ADEXP Standard lists all optional and mandatory Sub-fields
required within each Primary field.
2.Messages described in Section 9, Dialogue Procedure —
Transfer of Communication, are described only in ADEXP
format.
A.3.MessageType
The message type shall be the abbreviation for the message as
described in the following list:
ABI: Advance Boundary Information.
ACP: Acceptance.
ACT: Activate.
CDN: Co-ordination.
COD: SSR Code Assignment.
COF: Change of Frequency.
HOP: Hand-Over Proposal.
INF: Information.
LAM: Logical Acknowledgement Message.
MAC: Message for Abrogation of Co-ordination.
MAS: Manual Assumption of Communications.
PAC: Preliminary Activation.
RAP: Referred Activate Proposal.
REV: Revision.
RJC: Reject Co-ordination.
ROF: Request on Frequency.
RRV: Referred Revision Proposal.
SBY: Stand-by.
SDM: Supplementary Data Message.
TIM: Transfer Initiation Message.
A.3.1. ICAO
Field type 3, element (a).
A.3.2. ADEXP
Primary field ‘title’.
A.4.MessageNumber
The message number data includes the identifiers assigned to the
transmitting and receiving units and the message sequence number.
The message sequence number progresses sequentially from 001 to
000 (representing 1000), thence repeats from 001 for all messages
sent to the same addressee, regardless of the type of message.2000R2082 — EN — 15.06.2002 — 001.001 — 59
▼M1
▼B
▼B
A.4.1. ICAO
Field type 3, element (b).
A.4.2. ADEXP
Primary field ‘refdata’.
Sub-field ‘fac’, within sub-fields ‘sender’ and ‘recvr’, shall contain
the identifiers assigned to the ATC units. These identifiers shall be
not greater than eight characters in length.
Sub-field ‘seqnum’ shall contain the sequence number.
A.5.MessageReference
A.5.1. ICAO
Field type 3, element (c) (called ‘reference data’ in ICAO
document 4444).
The content of element (c) shall be that of Field type 3, element (b),
of the OLDI message referred to.
A.5.2. ADEXP
Primary field ‘msgref’.The values of Sub-fields ‘sender’, ‘recvr’, and ‘seqnum’, within
Primary field ‘msgref’, shall be those of the same Sub-fields within
Primary field ‘refdata’ of the OLDI message referred to.
A.6.Aircraft Identification
A.6.1. ICAO
Field type 7, element (a).
A.6.2. ADEXP
Primary field ‘arcid’.
A.7.SSRModeandCode
Either:
1. if known, the SSR mode/code on which the receiving unit can
expect the aircraft to respond at the transfer of control point;
or
2. an indicator that the SSR code is being requested from the
receiving unit.
A.7.1. ICAO
Field type 7, elements (b) and (c).If no SSR code is assigned or the mode/code is not known,
elements (b) and (c) shall be omitted.
When requesting an SSR code/mode, elements b) and c) shall
contain the value ‘A9999’.
A.7.2. ADEXP
Primary field ‘ssrcode’.If no valid SSR code is assigned or the mode/code is not known, the
field shall be omitted.
When requesting an SSR code/mode via the PAC message, primary
field ‘ssrcode’ shall contain the indicator ‘REQ’.
A.8.DepartureAerodrome
A.8.1. ICAO
Field type 13, element (a).2000R2082 — EN — 15.06.2002 — 001.001 — 60
▼B
A.8.2. ADEXP
Primary field ‘adep’.
A.9.EstimateData
A.9.1. General
A.9.1.1. Estimate data shall include the COP, time at the COP and transfer
level.
A.9.1.2. The co-ordination point shall be defined as either a known reference
point, a range and bearing from a known reference point, or a lati-
tude and longitude.
A.9.1.3. The cleared (transfer) level shall correspond to the proposed transfer
conditions.
A.9.1.4.Recommendation For climbing or descending flights, the estimate
data should also contain supplementary crossing data and crossing
conditions.
A.9.1.5. If used, the supplementary crossing data shall contain the supple-
mentary crossing level at the transfer of control point. The crossing
conditions shall be:
— Letter 'A'; — if the flight will be at or above the level in the
supplementary crossing data; or
— Letter 'B'; — if the flight will be at or below the level in the
supplementary crossing data.
A.9.2. ICAO
Field type 14.
A.9.3. ADEXP
Primary field ‘coordata’.Subfield ‘ptid’ within Primary field ‘coordata’ shall contain either:
— a known reference point; or
— a bearing and distance from a known reference point, as defined
in the same message by Primary field ‘REF’ or ‘GEO’.
A.10.Co-ordinationPoint
A.10.1. General
A.10.1.1. The co-ordination point referred to by the transferring and receiving
ATC units for the purposes of the transfer concerned.
A.10.1.2. The co-ordination point shall be defined as either a known reference
point, a range and bearing from a known reference point, or a lati-
tude and longitude.
A.10.2. ICAO
Field 14, element (a).
A.10.3. ADEXP
Primary field ‘cop’ containing:
— a known reference point; or
— a bearing and distance from a known reference point, as defined
in the same message by Primary field ‘REF’ or ‘GEO’.
A.11.DestinationAerodrome
A.11.1. ICAO
Field 16, element (a).
A.11.2. ADEXP
Primary field ‘ades’.2000R2082 — EN — 15.06.2002 — 001.001 — 61
▼B
A.12.Aircraft NumberandType
Aircraft number and type shall contain the type of aircraft. The
number of aircraft shall be included in the case of formation flights.
A.12.1. ICAO
Field type 9 in field type 22 format. Element c of field type 9 shall
contain either the wake turbulence category appropriate to the type
of aircraft or the letter ‘Z’.
A.12.2. ADEXP
Primary field ‘arctyp’. In addition, if there is more than one aircraft
in the flight, Primary field ‘nbarc’.
A.13.Route
Bothformats support th e route description as defined for ICAO
messages which requires as the first element speed and requested
flight level or altitude information. After the speed level group, the
route data will include as a minimum that specified in the following
paragraph. Further route data may be inserted after item c) if avail-
able. See also Annex B ‘Special Route Processing Requirements’
for insertion rules for route data.
A.13.1. Content
A.13.1.1. Flights Proceeding via a Defined COP
— the route element before the COP (ATS route, SID identifier,
DCT or significant point);
— the COP;
— the route element after the COP (ATS route or significant point).
A.13.1.2. Flights Proceeding Off ATS Route
— the point from which the flight is proceeding on the direct route
segment;
— the element ‘DCT’;— the point to which the flight is proceeding on the direct route
segment.
A.13.2. Format
A.13.2.1. ICAO
Field type 15, in field type 22 format.
A.13.2.2. ADEXP
Primary field ‘route’.
A.14. This field allows the option of including in specified messages flight
plan data not normally included as part of the coordination proce-
dure and not described elsewhere in this Appendix. The inclusion
of the following items as described in Reference 1, Appendix 2,
Field types 8 and 18 are permitted:
— flight rules,
— registration markings,
— name of the operator,
— reason for special handling by ATS,— type,
— performance,
— name of departure, destination, alternate aerodromes— plain language remarks.
A.14.1. ICAO
Field type 8, element (a) Flight rules in field type 22 format.2000R2082 — EN — 15.06.2002 — 001.001 — 62
▼M1
▼M1
One or more of the following field type 18 elements in field type 22
format:
REG, OPR, STS, TYP, PER, DEP, DEST, ALTN, RALT, RMK.
A.14.2. ADEXP
Primary fields: ‘fltrul’, ‘depz’, ‘destz’, ‘opr’, ‘per’, ‘reg’, ‘rmk’,
‘altrnt1’, ‘altrnt2’, ‘sts’, and ‘typz’.
A.15.Co-ordinationStatusandReason
Co-ordination status and Reason shall include the following
elements:
— a three letter indicator confirming the new status of the system
flight plan, to be one of the following:
— INI, when the system flight plan is to be in an initial state,
i.e. no notification message received;
— NTF, when the system flight plan is to be in a notified
status;
— CRD, when the system flight plan is to be in co-ordinated
status, i.e. basic ACT received or initial co-ordination
dialogue completed withconditions agreed.
— a three letter indicator specifying the reason for the status to be
one of the following:
— TFL, if the reason is a change of transfer level;
— RTE, if the reason is a change of route;— HLD, to indicate that the flight is holding for an indefinite
period and will be subject to a further message;
— DLY, to indicate that the departure is delayed;— CAN, if the reason is a cancellation;— CSN, for a change of callsign;— OTH, for any other reason or if the reason is unknown.
A.15.1. ICAO
A.15.1.1. The co-ordination status and reason shall be in the Field type 18
format.
A.15.1.2. The co-ordination status and reason shall include the following
elements as a ten character group:
— STA followed by an oblique stroke;
— the indicator to confirm the new status of the notification/co-
ordination;
— the indicator specifying the reason.
A.15.2. ADEXP
Primary field ‘cstat’.Auxiliary items ‘coordstatusident’ and ‘coordstatusreason’ shall
contain the new status and reason as specified above respectively.
A.16.AssignedHeading (ADEXP only)
Primary field ‘ahead’ shall contain either:
— the heading assigned to a flight, expressed in degrees;
or
— if no heading is assigned, the indicator ‘ZZZ’, e.g. when an
SDM message is used to indicate that a previously assigned
heading no longer applies.
A.17.AssignedSpeed (ADEXP only)
Primary field ‘aspeed’ shall contain either:
— the speed assigned to a flight, expressed in knots, mach number,
or kilometres/hour;
or
— if no speed is assigned, the indicator ‘ZZZ’, e.g. when an SDM
message is used to indicate that a previously assigned speed no
longer applies.2000R2082 — EN — 15.06.2002 — 001.001 — 63
▼B
▼B
A.18.AssignedRateofClimb/Descent (ADEXP only)
Primary field ‘rate’ shall contain:
— the climb or descent rate assigned to a flight, expressed in
hundreds of feet per minute;
or
— if no rate of climb/descent is assigned, the indicator ‘ZZZ’ in the
digit portion of the field, e.g. when an SDM message is used to
indicate that a previously assigned rate of climb/descent no
longer applies.
A.19.DirectClearance (ADEXP only)
A direct route, not defined as an ATS route, between two points.
The points can be defined as either a known reference point or arange and bearing from a reference point. All endpoint designators
used shall be bilaterally agreed, i.e. known to both systems.
Primary field ‘DCT’ containing:
— the point at which the deviation has or will commence, defined
as one of:
— a known reference point;
or
— a range and bearing from a known reference point, as
defined in the same message by Primary field ‘REF’;
or
— the value ‘ZZZ’ if the sending unit does not require to desig-
nate the deviation point.
— the point situated on the original flight plan route to which the
aircraft has been or will be cleared, defined as:
— a known reference point;
or
— a range and bearing from a known reference point, as
defined in the same message by Primary field ‘REF’.
A.20.DirectRoutingRequest
Request for a direct route, not defined as an ATS route, between
two points. The points can be defined as either a known reference
point or a range and bearing from a reference point.
All endpoint designators used shall be bilaterally agreed, i.e. known
to bothsystems.
A.20.1. ICAO
Field type 15, excluding the initial speed/level group, in field 22
format.
It shall contain:
— the point at which the deviation is requested to commence,
defined as one of:
— a known reference point;
or
— a range and bearing from a known reference point;
or
— the value ‘ZZZ’ if a direct routing is being requested by the
receiving ATC unit.
— the abbreviation ‘DCT’,— followed by the point situated on the original flight plan route to
which the aircraft is requested to be cleared, defined as:
— a known reference point;
or
— a range and bearing from a known reference point.
A.20.2. ADEXP
Primary field ‘DCT’ containing:
— the point at which the deviation is requested to commence,
defined as one of:
— a known reference point;2000R2082 — EN — 15.06.2002 — 001.001 — 64
▼B
or
— a range and bearing from a known reference point, as
defined in the same message by Primary field ‘REF’;
or
— the value ‘ZZZ’ if a direct routing is being requested by the
receiving ATC unit but the precise point at which it would
commence is not known.
— the point situated on the original flight plan route to which the
aircraft is requested to be cleared, defined as:
— a known reference point;
or
— a range and bearing from a known reference point, as
defined in the same message by Primary field ‘REF’.
A.21.Position (ADEXP only)
A.21.1. General
A.21.1.1. The current position of the flight expressed in either geographic co-
ordinates or by bearing and distance from a designated point.
A.21.1.2. Primary field ‘ref’ or ‘geo’ shall define the current horizontal loca-
tion of the aircraft. Points used for range and bearing purposes in
primary field ‘ref’ shall be bilaterally agreed, i.e. known to both
systems. Primary field ‘position’ shall contain the subfield ‘ptid’
which refers to the defined reference or geographic point. If time
information is to be included, either sub-field ‘to’ (hhmm) or ‘sto’
(hhmmss) is to be used, as bilaterally agreed.
A.22.ReleaseIndication (ADEXP only)
Primary field ‘release’ shall contain one of the following:
— C, if the flight is released for climb;
— D, if the flight is released for descent;
— T, if the flight is released for turns;
— F, if the flight is fully released for all actions.
A.23.Frequency
A.23.1. ICAO
Field type 18 shall include the following elements in field 22
format:
— FRQ, followed by an oblique stroke;
— 6 digits indicating the frequency, expressed in MHz to three
decimal places.
A.23.2. ADEXP
Primary field ‘freq’.
A.24.Reason(ADEXP only)
Primary field ‘reason’, containing the value ‘MANUAL’ for manu-
ally referred messages.
A.25.ClearedFlightLevel (ADEXP only)
Primary field ‘cfl’.
A.26.ProposedTransferFlightLevel (ADEXP only)
Primary field ‘propfl’.
A.27.EstimatedTake-OffTime
A.27.1. ICAO
Field type 13 element (b).
A.27.2. ADEXP
Primary field ‘etot’.2000R2082 — EN — 15.06.2002 — 001.001 — 65
▼B
A.28.Reference MessageType
The field contains the message type as specified in paragraph A.1 of
this Annex.
A.28.1. ICAO
Field type 18 in field type 22 format. The element indicator shall be
‘MSG’.
A.28.2. ADEXP
Primary field ‘msgtyp’.
A.29.Typeofflight
This item shall be as filed in the flight plan or equivalent data origi-
nating from an alternative source. The letter X shall be inserted if
the type of flight is omitted in the flight plan or it is not known
for any other reason.
A.29.1. ICAO
The type of flight shall be inserted as a single letter in field type 22
format utilising the pseudo field type number 80.
A.29.2. ADEXP
Primary field ‘flttyp’.
A.30.Equipmentcapabilityandstatus
This item indicates the capability and status of equipment that is
either a pre-requisite for flight in certain airspaces or on specifiedroutes or has a significant effect on the provision of ATC service.
The presence of a capability is identified in the flight plan but may
be found to be incorrect or to have changed during the flight. The
equipment capability and status specifies the current status.
The status of the following items shall be included:
— RVSM capability,
— 8.33 kHz RTF equipage.
The status of the following shall be included for State flights as
specified in the type of flight in the flight plan for which 8.33 kHz
RTF equipment is not known to be available for use:
— UHF equipage.
A.30.1. ICAO
The data shall be inserted in field type 22 format utilising the
pseudo field number 81.
Two elements shall be inserted for each capability:
— the equipment capability expressed as a single letter as specified
in field type 10 ‘Equipment’ in the ICAO flight plan (see
Appendix 3 of Reference 1), followed immediately by,
— element separator — oblique stroke (/), followed immediately
by,
— status expressed as two letters.
The status shall be expressed by the use of following indicators as
applicable to the flight:
(a) EQ meaning the flight is equipped and the equipment is avail-
able for use by the flight;
(b) NO meaning the flight is not equipped or for any reason the
equipment cannot be used by the flight;
(c) UN meaning compliance withth e capability is unknown.
The first capability group shall be inserted directly after the oblique
stroke following the field number. Subsequent groups shall be sepa-
rated by a space character. The order of equipment capabilities is
not significant.2000R2082 — EN — 15.06.2002 — 001.001 — 66
▼M1
▼M1
A.30.2. ADEXP
Primary field ‘EQCST’2000R2082 — EN — 15.06.2002 — 001.001 — 67
▼B
ANNEX B (Normative)
SPECIALROUTEPROCESSINGREQUIREMENTS
B.1.Introduction
B.1.1. General
B.1.1.1. This Annex describes the rules and data insertion requirements in
the following cases, when permitted:
— a flight routes on a direct track, off route, across the boundary
as the result of a direct route segment filed in the flight plan;
— after transmission of the ABI or ACT message, a flight is re-
routed via either:
— a different ATS route;
— a direct track to rejoin the original route at a later point.
B.1.1.2. With respect to the re-routing of flights (paragraph B.1.1.1), the
data exchange described in this Annex supports the modification
of the route of flight as held in both systems by the use of notifica-
tion and co-ordination messages.
B.2.ApplicationofMessages
B.2.1. Basic Rules for Direct Routings
B.2.1.1. Conditions for the use of OLDI for the co-ordination of flights on
direct routings shall be agreed bilaterally.
B.2.1.2. The data required for the notification and co-ordination of flights
on direct routings is contained in the co-ordination point (estimate
data (ICAO format) and co-ordination data (ADEXP format)) and
route in the applicable messages.
B.2.2. Direct Route Filed
When the route indicates that the flight will cross the boundary on
a direct track, the direct route segment and the resultant COP will
be included in the ABI message(s). This COP is included in the
subsequent ACT or RAP message.
The COP and route data shall be formatted as described in para-
graphB.3.2.
B.2.3. Re-routings after ABI and before ACT Transmission
A new ABI message shall be sent with data corresponding to the
new route.
B.2.4. Re-routing after ACT transmission
B.2.4.1. A REV message shall be used to indicate re-routings after the ACT
message has been sent until a bilaterally agreed time before the
ETO at the COP previously co-ordinated.
NOTEA REV message is only used where the accepting unit does
not change as the result of the modification. If it does
change, a MAC message must be sent to the original
accepting unit or the co-ordination verbally cancelled.
B.2.4.2. The message shall contain the following data elements:
— Co-ordination point (previous COP, for reference purposes);
— Estimate data;
— Route.
B.2.4.3. ICAO format messages shall contain the following fields:
3 Message type and number; message reference if bilaterally
agreed;
7 Aircraft identification. Elements b and c shall not be included
unless a revision o the SSR code is being co-ordinated simul-
taneously;
13 Departure aerodrome;2000R2082 — EN — 15.06.2002 — 001.001 — 68
▼B
14 Element a only, containing the previous COP for reference
purposes;
16 Destination;22 Field 14 containing the estimate data for the new boundary
crossing conditions in field 22 format;
22 Field 15 containing the new route in field 22 format.
B.2.4.4. ADEXP format messages shall include, in addition to the message
type and number, aircraft identification, departure aerodrome, desti-
nation and, if bilaterally agreed, the message reference number:
— the previous COP in the COP field;
— the new co-ordination conditions in the COORDATA field;
— the new route in the ROUTE field.
B.2.4.5. Route revisions sent as part of the dialogue procedure shall be sent
as RRV messages unless bilaterally agreed to be considered ‘stan-
dard’.
B.3.FieldContents
B.3.1. ATS Routes
For flights which re-route via an alternative ATS Route, the esti-
mate and route fields are formatted as for ABI and ACT messages.
B.3.2. Direct Routes
B.3.2.1. The co-ordination point in the estimate data shall be the point of
boundary crossing expressed as a bearing and distance from a
reporting point. Such points shall be bilaterally agreed. Where the
distance is zero or a flight will pass within a bilaterally agreed
distance from such a point, only the identifier of the point shall be
included.
B.3.2.2. When bilaterally agreed, the co-ordination point for a flight on a
direct route may be expressed by reference to latitude/longitude.
B.3.2.3. The route shall contain:
— the point situated on the original route from which the aircraft is
to route direct; where a flight is routed direct from ‘present
position’, the point may be expressed as a bearing and distance
from a reporting point. When bilaterally agreed, the point may
be expressed by reference to latitude/longitude;
— the abbreviation ‘DCT’;
— the point to which the aircraft is to proceed directly;— the remainder of the further route of flight (FRF), if known to
the sending system.
B.4.Examples
B.4.1. Direct Routes
B.4.1.1. ABI and ACT Messages
B.4.1.1.1. The flight (identification Jetset 253) is to cross the boundary on a
direct track from Point A (PTA), to Point C (PTC) after which it
will follow ATS route UA134. The system determines a COP of
bearing 350, distance 22 NM from Point B (PTB).2000R2082 — EN — 15.06.2002 — 001.001 — 69
▼B
The following ABI message is sent:
— ICAO
(ABIE/L003-AMM253/A0701-LMML-PTB350022/1440F350-
EGBB-9/B757/M-15/N0490F390 PTA DCT PTC UA134)
— ADEXP
-TITLE ABI -REFDATA -SENDER -FAC E -RECVR -FAC L
-SEQNUM 003 -ARCID AMM253 -SSRCODE A0701 -ADEP
LMML-COORDATA -PTID REF01 -TO 1440 -TFL F350 -
ADES EGBB-ARCTYP B757-REF-REFID REF01 -PTID PTB
-BRNG 350 -DSTNC 022 -ROUTE N0490F390 PTA DCT
PTC UA134
B.4.1.1.2. The ACT message has the same format as the ABI message except
that the route of flight is optional.
B.4.1.2. REV Message
Flight HZT2051 was previously the subject of the following ACT
message (or ADEXP equivalent):
(ACTQW/FG455-HZT2051/A3347-HECA-WSS/1838F310-EHBK-
9/B737/M
The flight is then routed from 40 NM west of point RQA direct to
MYY. The closest point to the boundary crossing is TDS from2000R2082 — EN — 15.06.2002 — 001.001 — 70
▼B
which the distance to the actual crossing point is 26 NM at bearing
240 degrees. The following revision message is sent:
(REVQW/FG464-HZT2051-HECA-WSS-EHBK-14/TDS240026/
1842F310-15/N0458F310 RQA270040 DCT MYY)
The ADEXP equivalent of the message is:
-TITLE REV -REFDATA -SENDER -FAC QW -RECVR -FAC FG
-SEQNUM 464 -ARCID HZT2051 -ADEP HECA -COP WSS -
ADES EHBK -COORDATA -PTID REF01 -TO 1842 -TFL F310
-REF -REFID REF01 -PTID TDS -BRNG 240 -DSTNC 026 -
ROUTE N0458F310 RQA270040 DCT MYY
A subsequent revision message would indicate TDS240026 as the
COP.
B.4.2. Re-route via ATS Routes after ACT Transmission
B.4.2.1. ACT Message
Flight GKP217 is planned to route via co-ordination point EMT.
The following ACT is transmitted:
(ACTK/G206-GKP217/A2332-EGNX-EMT/1211F270-DTTA-9/
FK28/M)
The flight subsequently re-routes via ATS route UM247 within the
sending centre's airspace to new co-ordination point XAT following2000R2082 — EN — 15.06.2002 — 001.001 — 71
▼B
which it is to follow ATS route UJ124. The accepting centre
remains the same. The following revision message is sent:
(REVK/G214-GKP217-EGNX-EMT-DTTA-14/XAT/1225F270-15/
N0430F290 UM247 XAT UJ124)
The flight is then cleared to FL290 resulting in the following
message (containing the new COP):
(REVK/G233-GKP217-EGNX-XAT/1225F290-DTTA)
B.4.2.2. ADEXP Equivalents
The ADEXP equivalents of the two revision messages are as
follows:
a. -TITLE REV -REFDATA -SENDER -FAC K -RECVR -FAC G
-SEQNUM 214 -ARCID GKP217 -ADEP EGNX -COP EMT -
ADES DTTA -COORDATA -PTID AT -TO 1225 -TFL F270 -
ROUTE N0430F290 UM247 XAT UJ124
b. -TITLE REV -REFDATA -SENDER -FAC K -RECVR -FAC G
-SEQNUM 233 -ARCID GKP217 -ADEP EGNX -COORDATA
-PTID XAT -TO 1225 -TFL F290 -ADES DTTA2000R2082 — EN — 15.06.2002 — 001.001 — 72
▼B
ANNEX C (Informative)
DIALOGUEPROCEDURE(SYSCOLEVEL1)PHASES—MESSAGESEQUENCE
MessageSequence
2000R2082 — EN — 15.06.2002 — 001.001 — 73
▼B
ANNEX II
AIR TRAFFIC SERVICES DATA EXCHANGE PRESENTATION
(ADEXP)EDITION2.0
(Eurocontroldocumentreference DPS.ET1.ST09-STD)2000R2082 — EN — 15.06.2002 — 001.001 — 74
▼B
TABLEOFCONTENTS
COPYRIGHT NOTICE
FOREWORD1. SCOPE2. REFERENCES3. DEFINITIONS, SYMBOLS AND ABBREVIATIONS
3.1. Notation3.2. Definitions3.3. Construction3.4. Conventions3.5. Operators3.6. Abbreviations
4. ADEXP PRINCIPLES
4.1. Textual, Human Readable Format4.2. Identified and Retrievable Fields4.3. Unrecognised Fields
5. ADEXP SYNTAX RULES
5.1. Lexical Elements5.2. Fields
6. NORMALISED DESCRIPTION OF ADEXP MESSAGES
6.1. Introduction6.2. Auxiliary Terms6.3. Definition of Primary Fields6.4. Definition of Subfields6.5. Group of Messages
ANNEX A (NORMATIVE) FIELD DEFINITIONS
ANNEX B (NORMATIVE) CENTRAL INDEX OF ADEXP MESSAGE TITLESANNEX C (NORMATIVE) CENTRAL INDEX OF RESERVED MESSAGE TITLESANNEX D (NORMATIVE) CENTRAL INDEX OF RESERVED FIELDANNEX E (INFORMATIVE) INTRODUCTION OF MESSAGE GROUPSANNEX F (INFORMATIVE) EXAMPLES OF ADEXP MESSAGE FORMATANNEX G (INFORMATIVE) FUTURE DEVELOPMENTS2000R2082 — EN — 15.06.2002 — 001.001 — 75
▼B
COPYRIGHTNOTICE
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.2000R2082 — EN — 15.06.2002 — 001.001 — 76
▼B
FOREWORD
1. ResponsibleBody
This Standard has been developed and is maintained by the User
Requirements Section of the Central Flow Management Unit
(CFMU) of the European Organisation for the Safety of Air Navi-
gation (Eurocontrol).
2. EATCHIPWorkProgramme Document
This Standard has been produced as a deliverable of the
EATCHIP Work Programme Document (EWPD), Data Proces-
sing Systems Domain (DPS), Executive Task 09.
3. ApprovaloftheStandard
3.1. This Standard is adopted in accordance with the procedures
outlined in the Directives for Eurocontrol Standardisation,
Ref. 000-2-93, Edition 1.0.
3.2. The provisions of this Standard became effective after adoption
of edition 1.0 by the Permanent Commission of Eurocontrol in
1995 and had a date of application with effect from
1st. December 1997.
4. TechnicalCorrigendaandAmendments
This Standard is kept under review to ascertain required amend-
ments or technical corrigenda. The procedure for the maintenance
of this Standard is laid down in Annex H of the Directives for the
Uniform Drafting and Presentation of Eurocontrol Standard
Documents.
Amendments or additions affecting the basic principles or
grammar of the ADEXP format shall only be made following
the formal review procedure as provided in the Directives for
the Uniform Drafting and Presentation of Eurocontrol Standard
Documents.
Amendments or additions to this Standard shall be proposed in
writing to: CFMU Users Requirements Section (ADEXP), Euro-
control Agency.
5. EditorialConventions
5.1. The format of this Standard complies with the Directives for the
Uniform Drafting and Presentation of Eurocontrol Standard
Documents, there are however some departures from the Direc-
tives. The minor formatting exemptions from the Directives are
to avoid confusion with the ATS Data Exchange Presentation
(ADEXP) notation.
5.2. The following notation has been used to indicate the status of
eachstatement:
— Normative Elements use the operative verb ‘shall’ and have
been printed in light faced roman text;
—Recommended Elements use the operative verb ‘should’ and
have been printed in light faced italics, the status being indi-
cated by the prefix; Recommendation .
6. RelationshiptootherStandardDocuments
This Standard is related to:
Eurocontrol Standard Document for On-Line Data Interchange
(OLDI)
7. StatusofAnnexestothisStandard
There are 6 Annexes to this Directive, the status of each being
defined as follows:
Annex A Normative
Annex B NormativeAnnex C NormativeAnnex D NormativeAnnex E Informative2000R2082 — EN — 15.06.2002 — 001.001 — 77
▼B
Annex F Informative
Annex G Informative.
8. Languageused
The English language has been used for the original text of this
Standard.2000R2082 — EN — 15.06.2002 — 001.001 — 78
▼B
1. SCOPE
1.1. ADEXP is a format, not a protocol. No restrictions are imposed
on the transmission media or protocols to be used, other than
that of the character set.
1.2. ADEXP provides a format for use primarily in on-line, computer
to computer message exchange.
1.3. This document defines the principles and syntax rules of the
ADEXP format. It provides this definition in terms of a compre-
hensive definition of the ADEXP fields.
1.4. The ADEXP format has been specified for use within the
following areas of message exchange (for document reference
information see Section 2, page 3):
— Flight Planning: exchange of flight plan data and associated
messages between the Integrated Initial Flight Plan Processing
System (IFPS), Air Traffic Services (ATS) and Aircraft
Operators (AO). (Document Ref. 3)
— Air Traffic Flow Management (ATFM): exchange of
messages between the Tactical System (TACT) of the
CFMU, AO and ATS. (Document Ref. 5)
— Air Traffic Control Co-ordination: exchange of tactical co-
ordination messages between Air Traffic Control Units
(ATCU). (Document Ref. 6)
— Airspace Management: exchange of data between National
ATS Units, the CFMU and AO, concerning airspace avail-
ability. (Document Ref. 7)
— Civil / Military Co-ordination: messages concerning civil/
military flight data and airspace crossing messages. (Docu-
ment Ref. 7).
1.5. Detailed specifications concerning the usage and content of the
messages within each of the above groups shall be found in the
referenced documents.
2. REFERENCES
2.1. The following documents and standards contain provisions which,
through reference in this text, constitute provisions of this Euro-
control Standard Document.
At the time of publication of this Eurocontrol Standard Docu-
ment, the editions indicated for the referenced documents and
standards were valid.
Any revision of the referenced International Civil Aviation Orga-
nisation (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 Eurocon-
trol Standard Document and the contents of these other
referenced documents, this Eurocontrol Standard Document shall
take precedence.
2.2. At the time of publication, the documents listed below are those
that are referenced from this Standard however users are invited
to check the usage and message field composition tables in the
latest editions of these documents.
1. ICAO Chicago Convention Annex 10 Volume I, edition dated
November 1985;
2. ICAO Chicago Convention Annex 10 Volume II, edition dated
July 1995;
3. IFPS and RPL Dictionary of Messages, edition 1.0, dated
March1998;
4. ‘Rules of the Air and Air Traffic Services’, PANS-RAC
Doc 4444, edition dated November 1985 (including Amend-
ment No 6 dated November 1995);
5. Guide To ATFM Message Exchange Eurocontrol Document
Ref. TACT/USD/MSGGUID, edition 6.0, effective March
1998,2000R2082 — EN — 15.06.2002 — 001.001 — 79
▼B
6. Eurocontrol Standard for On-Line Data Interchange,
edition 2.0, dated October 1996.
7. Functional Specifications for System Support to Airspace Data
Distribution and Civil Military Co-ordination, edition 1.0,
dated May 1996.
3. DEFINITIONS,SYMBOLSANDABBREVIATIONS
3.1. Notation
The notation used to define the syntax is termed Backus Naur
Form (BNF). BNF defines a set of rules which determines a class
of character strings. In this case, the class of character strings is
the set of messages which can be called a syntactically valid
ADEXP message.
3.2. Definitions
For the purposes of this Eurocontrol Standard document, the
following definitions shall apply:
Token: A character or set of characters which can be ‘extracted’
by a lexical analyser due to the presence of separators.
Symbol: Any ‘term’ which appears in a BNF rule but which is not
a character.
Terminal Symbol : A symbol which is represented in terms of a
sequence of characters.
Non-Terminal Symbol : A symbol which is represented by one or
more terminal symbols.
NOTEA non-terminal symbol may also be represented as a
mixture of terminal and non-terminal symbols.
3.3. Construction
3.3.1. BNF consists of a set of rules or constructs of the form:
symbol::= expressionNOTES1)The ‘::=’ notation should be read as ‘can be replaced by’.
2)The ‘symbol’ is classed as non-terminal.
3)The ‘expression’ part contains terminal and non-terminal
symbols.
3.3.2. Terminal symbols have a direct representation as a sequence of
characters which can be identified as a token by a lexical
analyser, using the presence of separators.
3.4. Conventions
For the purposes of this Eurocontrol Standard document, the
following conventions shall apply:
—Terminal symbols are in upper case.
NOTEBy convention, the NIL terminal symbol stands for ‘no
terminal symbol’ .
It is used in choices as in the following example:
a::= b (c | NIL) where a can be replaced by (b
followed by c) or by b only.
—Non-Terminal symbols (e.g. the left hand side of a grammar
production) are in lower case.
—Characters and String Literals appearing inside rules are
respectively enclosed in quotes (') or double quotes (").
Examples1) HYPHEN::= '–'
2) title::= '–' ”TITLE” titleid
It may be required, for some data modelling applications, to
distinguishbetween terminal and non-terminal symbols by means
other than the use of upper and lower case lettering.2000R2082 — EN — 15.06.2002 — 001.001 — 80
▼B
Whenever it is required to explicitly distinguish between terminal
and non-terminal symbols, other than by the use of upper and
lower case lettering, it is recommended to use the addition of a
suffix as follows: ‘_at’ for an Auxiliary term, ‘_pf’ for a Primary
field and ‘_sf’ for a Subfield.
3.5. Operators
For the purposes of this Eurocontrol Standard document, the
following operators shall apply:
Optional: When some symbols can legally appear or not appear
at some point in the grammar. The optional symbols are enclosed
in square brackets ‘[’ and ‘]’.
Closure: When a group of symbols may appear zero or more
times. The symbols are enclosed in curly brackets ‘{’ and ‘}’. If
a number is specified before the ‘{’ it gives the minimum number
of times that the group of symbols may appear. If a number is
specified after the ‘}’ it gives the maximum number of times
that the group of symbols may appear.
Choice:When a number of alternative symbols may appear at
some point in the grammar. Choice is represented by ‘|’.
Concatenation: Representation of symbols that follow sequen-
tially, even though one or more separators may come in the
middle. There is no explicit representation of this. They are two
types:
—Strict Concatenation: at the lexical level, rules may involve
concatenation of terminals indicating that they strictly follow
each other (no separator in the middle), in this case the ‘!’
symbol shall be used.
Example datetime:: = date ! timehhmm
e.g.”9912251200” meaning 25thDecember 1999, at 12h 00.
—Loose Concatenation: the allowed presence of separators
between terminals. The representation of Loose Concatenation
within a rule may be either Implicit or Explicit
Examples
1) Implicit:
dct::= '–' ”DCT” point point
2) Explicit
dct::= '–'!{SEP}!”DCT”!1{SEP}!point!1{SEP}!point
e.g. ”-DCT NTM RMS”.
NOTES
1)Concatenation shall always takes precedence over choice.
Parenthesis ‘(’ and ‘)’ areused toalter the expression evalua-
tion order.
Example a::= B C | D is equivalent
to:a::= (B C) | D
and NOT to: a::= B (C | D)
2)In all rules, the allowed presence of separators between the
symbols will be left implicit, in order to preserve readability .
Recommendation When there isariskofconfusiondue toprece-
dence between the above mentioned operators, it is recommended
to use the parenthesis, in order to clarify the desired evaluation
order.
3.6. Abbreviations
For the purposes of this Eurocontrol Standard Document, the
following abbreviations shall apply:
ACH ATC Flight Plan Amendment Message
ADEG ATS Data Exchange GroupADEXP ATS Data Exchange Presentation2000R2082 — EN — 15.06.2002 — 001.001 — 81
▼B
AFIL Air-Filed Flight Plan
AFP ATC Flight Plan Proposal
AFTN Aeronautical Fixed Telecommunication Network
ANM ATFM Notification MessageAO Aircraft Operator(s)APL ATC Flight Plan
ATC Air Traffic Control
ATCU Air Traffic Control Unit(s)ATFM Air Traffic Flow Management
ATS Air Traffic Services
BNF Backus Naur Form
CASA Computer Assisted Slot Allocation
CIDIN Common ICAO Data Interchange NetworkCFL Cleared Flight LevelCFMU Central Flow Management Unit
CMTP Common Medium-Term Plan
CNL Cancellation MessageCTOT Calculated Take-Off Time
DPS Data Processing Systems Domain
ECAC European Civil Aviation Conference
EFL Estimated Flight Level
EOBT Estimated Off-Block TimeETO Estimated Time Over
Eurocontrol European Organisation for the Safety of Air Navi-
gation
EWPD EATCHIP Work Programme Document
FIR Flight Information Region
FIW Flight Plan Input WorkstationFMP Flow Management Position
FNM Flight Notification Message
FPL Flight Plan Message (ICAO format)
GAT General Air Traffic
IA International Alphabet
IAFP Individual ATC Flight Plan Proposal
ICAO International Civil Aviation Organisation
IFPD Individual Flight Plan DataIFPS Integrated Initial Flight Plan Processing SystemIFPU IFPS Unit
IFR Instrument Flight Rules
ISO International Standards OrganisationITA International TelegraphAlph abet
LAM Logical Acknowledgement Message
LRM Logical Rejection Message
MAC Co-ordination Abrogation Message
MFS Message from Shanwick
OAT Operational Air Traffic
OLDI On-Line Data Interchange
RFL Requested Flight Level
RFP Replacement Flight Plan
RFPD Repetitive Flight Plan DataRPL Repetitive Flight PlanRVR Runway Visual Range
SFL Supplementary Flight Level
SRD Software Requirements Document
SSR Secondary Surveillance Radar
TACT Tactical System of the CFMU
TOS Traffic Orientation Scheme
UIR Upper Information Region2000R2082 — EN — 15.06.2002 — 001.001 — 82
▼B
VFR Visual Flight Rules
4. ADEXPPRINCIPLES
4.1. Textual,HumanReadableFormat
4.1.1. The ADEXP format is a textual format, based on characters.
4.1.2. The ADEXP messages remain readable to a human operator
which enables better tuning, or operational issues, to be
addressed.
4.1.3. A textual format is also more open and understandable.
4.2. IdentifiedandRetrievable Fields
4.2.1. A message in ADEXP format shall be composed of fields.
4.2.2. Fields shall be delimited by a special start-of-field character, the
hyphen character (‘-’) and identified by specific keywords.
NOTEIt should be noted that certain fields (those syntactically
defined as containing the lexical item ‘CHARACTER’)
may legally contain a ‘-’ character as part of the field
content.
4.2.3. This approach improves the extensibility and robustness of the
format. (If a field is absent or incorrect, it can be skipped, and
the remaining part of the message can still be interpreted. (See
section 4.3).
4.2.4. As another consequence, the order of fields in a message shall not
be relevant to determine its legality, except for the first field
(mandatory title field) which determines the allowed fields.
4.2.5. Fields may be basic or compound.
4.2.6. The constituent parts of compound fields are called subfields, and
are defined by the presence of keywords, delimited by the a start-
of-field character.
4.2.7. Basic fields are fields which do not contain subfields.4.2.8. The basic or compound fields composing the first level of defini-
tion of a message are called its primary fields.
4.2.9. All lower level constituents are by definition subfields, which in
turn, may be basic or compound.
4.2.10. Compound fields are of two kinds, structured fields or list fields.4.2.11. Structured fields have a pre-defined content made exclusively of
subfields. The order of subfields in a structured field is NOT
significant.
4.2.12. List fields are introduced by the BEGIN keyword and terminated
by the END keyword. Between these, repeating occurrences of a
same subfield or combination of subfields may take place. The
order of the occurrences inside a list field is semantically signifi-
cant.
4.2.13. In the following, the term ‘field’ will be used generically to mean
primary and/or subfields, except when explicitly qualified other-
wise.
4.2.14. Fields in a message may be optional or mandatory, as defined by
their syntax.
4.3. UnrecognisedFields
4.3.1. If an unknown field appears in a message, it shall be ignored.
4.3.2. In other words, if the system which analyses the message does
not recognise a keyword, all the text up to the next known
Primary Field, which is not within a List Field, will be ignored.
4.3.3. Depending on the message title, the ignored field may or may not
cause a rejection of the message being parsed.
NOTEIt should be noted that although ADEXP is designed to
provide this type of flexibility, it is at the discretion of2000R2082 — EN — 15.06.2002 — 001.001 — 83
▼B
those responsible for defining the interface requirements,
to indicate, for each message, how the system should
react to an unrecognised field.
4.3.4. If the unknown field is a list field, (this has been found due to the
-BEGIN keyword), then all its contents (up to the corresponding -
END keyword) are ignored.
4.3.5. In order to avoid any ambiguity during the recovery that follows
skipping an unrecognised field, it is required that a keyword
introduces either a primary field, or a subfield.
4.3.6. This allows the definition of two kinds of keywords:
— Primary keywords;
— Sub-keywords.
4.3.7. Once it is defined as being of one kind, a keyword shall not be
further re-used in another group of messages as the other kind,
with the one exception when it is inside a list field. It is possible
to have inner occurrences of a primary keyword anywhere within
a list field without creating ambiguity, since the presence of the
BEGIN keyword indicates we may consider the inner occurrence
as a subfield.
Examples (of use of keyword types)
1)Primary Field
-RFL F330
2)Sub-Field : always within a ‘Compound Field’
-GEO -GEOID 01 -LATTD 520000N -LONGTD 0150000W
where -GEO is a primary compound field and -GEOID, -
LATTD and LONGTD are all sub-fields.
3)List Field
-BEGIN RTEPTS -PT -PTID CMB -ETO 9305091430 -RFL
F370 -PT -PTID
…
-END RTEPTS
where ‘-BEGIN’ is the list field indicator and ‘RTEPTS’ is a
primary field.
NOTE‘RFL’ is defined as a primary field. Inclusion within a list
field is the only occasion when a primary field may be
used as a subfield. (See Example 3 above)
5. ADEXPSYNTAXRULES
5.1. LexicalElements
5.1.1. Character Set
5.1.1.1. The character set to be used for the exchange of messages in
ADEXP format shall be International Alphabet Number 5 (IA-5)
as defined in Reference 1.
5.1.1.2. The ADEXP format is designed as a computer to computer
exchange format which may be transmitted on different computer
networks or on dedicated computer-computer links. In addition, a
requirement exists to be able to exchange some ADEXP
messages, typically Flight Planning and ATFM related, on the
Aeronautical Fixed Telecommunication Network (AFTN).
5.1.1.3. Messages which may be required to be transmitted via AFTN
shall have their character set restricted to those characters that
have a direct correlation between International Telegraph
Alphabet Number 2 (ITA-2) and IA-5, as defined in Reference 1.
NOTEBesides graphic characters and format effectors as
defined below, the ITA-2 character set defines ‘signals’
(like perforated tape, for instance). They are not part of
the allowed character set for ADEXP messages.2000R2082 — EN — 15.06.2002 — 001.001 — 84
▼B
5.1.1.4. The characters which are permitted for use within ADEXP
messages which may be transmitted via AFTN, are the graphic
characters and the format effectors as defined below:
Graphic Characters
a) upper case letters (A to Z)
b) digits (0 to 9)
c) special graphic characters, as follows:
1) space character ‘ ’
2) open bracket ‘(’3) close bracket ‘)’4) hyphen ‘-’
5) question mark ‘?’
6) colon ‘:’7) full stop ‘.’8) comma ‘,’9) apostrophe ‘'’
10) equal sign ‘=’11) plus sign ‘+’
12) oblique ‘/’
Format Effectors
a) Carriage-Return
b) Line-Feed
5.1.2. Basic Lexical Items
The following basic lexical items are defined for use in this
specification:
— ALPHA::='A'|'B'|'C'|'D'|'E'|'F'|'G'|'H'|'I'|'J'|'K'|'L'|'M'|'N'|'O'|'P'|'Q'|'-
R'|'S'| 'T'|'U'|'V'|'W'|'X'|'Y'|'Z'
— DIGIT ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
— ALPHANUM ::= ALPHA | DIGIT
— SPACE ::= ' '
— HYPHEN ::= '–'
— FEF ::= Carriage_return | Line_Feed— SEP ::= 1{ SPACE | FEF }
— SPECIAL ::= SPACE | '(' | ')' | '?' | ':' | '.' | ',' | ''' | '=' | '+' | '/'
— CHARACTER ::= ALPHA | DIGIT | SPECIAL | FEF |
HYPHEN
— LIM_CHAR ::= ALPHA | DIGIT | SPECIAL | FEF
— START-OF-FIELD ::= HYPHEN
NOTELIM_CHARrepresents any allowed character except
HYPHENwhich isreserved toindicate the start ofafield.
On the contrary, CHARACTER represents any allowed
element of the character set.
5.1.3. Lines, Separators and Delimiters
5.1.3.1. The division into lines of the text of a message shall have no
syntactic effect.
5.1.3.2. A separator can be a space character or format effector.5.1.3.3. Fields shall be delineated only by the presence of a start-of-field
character followed by a keyword.
5.1.3.4. Hence the whole message could legally be on one line.5.1.4. Signed Values
5.1.4.1. It may be required to indicate a numeric value as being negative.
5.1.4.2. Fields which are required to indicate a negative value shall,
within their syntax definition, explicitly indicate the value as
being a ‘signed value’ i.e. as being either positive or negative. A
field which has not been so defined may not represent a negative
value.2000R2082 — EN — 15.06.2002 — 001.001 — 85
▼B
5.1.4.3. A ‘signed value’ shall always be preceded by either the letter ‘N’
meaning negative or ‘P’ meaning positive. A zero value may be
preceded by either ‘N’ or ‘P’.
5.1.4.4. The syntax of a field which allows a ‘signed value’ shall be as
follows:
‘-' “KEYWORD” (“P” | “N”) ! 1{DIGIT}
Example: A field called ‘NUMBER’ which may contain a nega-
tive value of one to eight digits would be defined as:
‘-' “NUMBER” (“P” | “N”) ! 1{DIGIT}8
Therefore: -NUMBER P5 — value of ‘number’ is +5
-NUMBER N5 — value of ‘number’ is –5
-NUMBER 5 — invalid syntax, either a ‘P’ or
a ‘N’ must be present
5.1.5. Keywords
5.1.5.1. A keyword is any sequence of upper case letters or digits. It
introduces a field only when it is preceded by a start-of-field
character (‘-’).
keyword::= 1{ ALPHANUM }
5.1.5.2. Keywords shall comply with the following syntax:
'–'!{SEP}!”KEYWORD”!1{SEP}! <subfield/s or contained
value>
i.e. a keyword shall be separated from it's ‘start-of-field character’
by zero or more separators. It shall be followed immediately by
one or more separators, followed by the relevant subfield/s or
contained value.
NOTEIt is important to note that a keyword and its preceding
start-of-field character may be separated by any number
of separators, including none.
Examples (The following sequences all validly introduce a field)
1) -TITLE IFPL
2) - TITLE IFPL
3) - TITLE IFPL
4) -
TITLE IFPL
5.1.5.3. Recommendation It is a recommended practice to avoid the use
of a separator between the start-of-field character ‘-’ and the
subsequent keyword.
NOTE
1) In the examples above, the first occurrence is the recom-
mended choice.
2) It is also important to note that a keyword must be immedi-
ately followed by at least one separator.
5.1.5.4. Throughout the document the concatenation of items separated by
at least one separator is implicitly represented by the notation of
‘Loose Concatenation’ (see 3.5).
NOTEAs will be explained later, keywords also introduce list
fields when they are preceded by the BEGIN keyword.
5.1.5.5. Keywords shall be as short as possible while remaining semanti-
cally meaningful.
5.1.5.6. The pre-defined keywords of the ADEXP format which are listed
below shall not be redefined or used with a different role, in
specific usages of the format:
TITLE: identifies a category of messages and defines the
corresponding set of allowed primary fields;
BEGIN: identifies the beginning of a list field;
END: identifies the end of a list field;COMMENT: identifies a COMMENT field.2000R2082 — EN — 15.06.2002 — 001.001 — 86
▼B
5.1.5.7. In order to avoid ambiguity (duplicate use of a same keyword
withdifferent meanings) or redundancy (different keywords with
the same meaning), a Central Definition Table of Primary Fields
(i.e. primary keywords) is maintained in this Standard at Annex A
(A3) and a Central Definition Table of Subfields (i.e. sub-
keywords) is also maintained at Annex A (A4).
5.2. Fields
5.2.1. Field Syntax
field::= basic_field | structured_field | list_field
basic_field::= '–' keyword contained_values
contained_values::= {CHARACTER}list_field::= '–' ”BEGIN” keyword {subfields} '–' ”END” keywordstructured_field::= '–' keyword field_1 field_2 ….field_nNOTE As will be seen, in the case of list fields, the keyword is
not preceded directly with‘-’ but withth e ‘-’‘BEGIN’
construct.
5.2.2. Message Composition in Terms of Fields
5.2.2.1. The first field of an ADEXP message shall always be a TITLE
field (i.e. a field introduced by the TITLE keyword).
5.2.2.2. The remaining contents of a message in terms of its primary
fields, shall be defined by its TITLE.
5.2.2.3. The syntax of messages corresponding to a given TITLE shall be
defined by the fields it contains (defined by their keywords):
— The name and allowed content of its primary fields;
— The name and allowed content of its subfields.
5.2.3. Basic Fields
5.2.3.1. The syntax of basic field shall be as follows:
basic_field::= '–' keyword contained_values
5.2.3.2. ‘Contained_values’ defines the text which provides the value of
the field, and may not introduce any subfield.
Example rule arctyp::= '–' ”ARCTYP” (icaoaircrafttype |
”ZZZZ”)
NOTE1) An explicit equivalent rule of which being:
arctyp::= '–'!{SEP}!”ARCTYP”!1{SEP}!(icaoaircrafttype |
”ZZZZ”).
2) An example portion of a message is::
”-ARCTYP ZZZZ”.
5.2.3.3. Recommendation Where there are more than two contained
values within a basic field and there is, in addition, the need to
express ‘choice’ or ‘option’ amongst the values, it is recom-
mended to make the field a structured field and to include the
contained values within subfields.
5.2.4. List Fields
5.2.4.1. The syntax of list fields shall be as follows:
list_field::='–' ”BEGIN” keyword { subfields } '–' ”END”
keyword
5.2.4.2. The ‘subfields’ may be any combination of subfields, the occur-
rence of which may appear zero or more times inside the list
field.
5.2.4.3. The list of subfields contained in a given list field shall form an
ordered set (the order of subfields is significant).
Example rule addr::= '–' ”BEGIN” ”ADDR” { fac } '–' ”END”
”ADDR”2000R2082 — EN — 15.06.2002 — 001.001 — 87
▼B
NOTE
1) This example shows that an ‘addr’ field is a list field
containing 0 or more occurrences of a ‘fac’ subfield (an ATS
facility).
2) An example portion of a message showing ADDR as a list
field containing FAC subfields is:
-BEGIN ADDR -FAC LLEVZPZX -FAC LFFFZQZX -END
ADDR.
3) An example portion of a message showing a combination of
subfields is:
xxx::= '–' ”BEGIN” ”XXX” { yyy | zzz } '–' ”END” ”XXX”.
5.2.5. Structured Fields
5.2.5.1. The syntax of structured fields shall be as follows:
structured_field::= '–' keyword field_1 field_2…field_n
5.2.5.2. The allowed contained subfields in a given structured field shall
depend only on the structured field itself.
5.2.5.3. The order of appearance of subfields in a structured field shall
not be significant, which allows for easy future extensions (by
adding new contained subfields).
Examplerule pt::= '–' ”PT” ptid [fl] [eto]
NOTES
1) This defines the ‘pt’ field as a structured field containing a
point (‘ptid’ subfield), optionally followed by a calculated
flight level (‘fl’ subfield), optionally followed by an estimated
time over the point (‘eto’ subfield).
2) An example occurrence of that field may be for instance:
”-PT -PTID RMS -FL F250 -ETO 921225120000”.
5.2.5.4. Recommendation Wherever it is felt that the contents of a field
might evolve in the future, it is desirable to make it a structured
field. This will allow progressive extensions of its subfields.On
the contrary, a basic field may be simpler or more familiar to
use, but it imposes a fixed sequence of elements (values) with
very reduced extension possibilities.
5.2.6. The COMMENT Field
5.2.6.1. The comment field introduces an area of free text where all avail-
able characters except the start-of-field character (‘-’) can be
used, and which extends to the next field.
comment::= '–' ”COMMENT” { LIM_CHAR }
Example COMMENT THIS IS THE BEGINNING OF A FREE
ROUTE TEXT AREA
5.2.7. The TITLE Field
5.2.7.1. The first field of an ADEXP message shall always be a title field.
The syntax of which shall be as follows:
title::= '–' ”TITLE” 1{ ALPHA }10
5.2.7.2. The possible values of the title field consist of the set of ADEXP
message titles, as listed in Annex B of this Standard.
Example -TITLE IFPL
6. NORMALISEDDESCRIPTIONOFADEXPMESSAGES
6.1. Introduction
6.1.1. The following paragraphs define how the ADEXP format of
different categories of messages shall be described in a normal-
ised way, in the frame of the present Standard.
6.1.2. The Normalised description involves:
— Definition of auxiliary terms;
— Definition of eachindividual primary field's syntax and
semantic;2000R2082 — EN — 15.06.2002 — 001.001 — 88
▼B
— Definition of eachindividual subfield's syntax and semantic;
— Definition of eachgroup of messages withreference to th eir
defining documentation.
6.1.3. This Standard does not provide the detail concerning the field
composition and data insertion rules for eachmessage title.
6.1.4. Reference should be made to the defining documentation (Inter-
face Specification) which is applicable to the relevant message
group (See section 6.5.7).
6.1.5. Defining documentation should provide, in a normalised manner,
the following information for each message title:
— a list of compulsory primary fields;
— a list of optional primary fields;— the data insertion rules for each field, and in particular, the
rules concerning the use of subfields defined as optional
within this Standard;
— the rules concerning recovery following the detection of an
unrecognised field.
6.1.6. The fields currently defined and agreed throughout Eurocontrol
member states for use within the different categories of messages
which have been defined for use using ADEXP, are those
provided in Annex A of this document.
6.1.7. A field shall not be used for a purpose other than that specified in
it's semantic description.
6.1.8. A central index of reserved fields is provided at Annex D.
‘Reserved fields’ have not been agreed for use within the
currently defined ADEXP messages. Typically they are fields
which have been foreseen for possible future use, or they are
used locally within national systems. The purpose of including
them in this Standard is to assist in ensuring the uniqueness of
field titles and avoidance of unnecessary redundancy.
6.2. AuxiliaryTerms
6.2.1. In order to provide a readable definition of fields, it is often
useful to introduce auxiliary terms in the grammar description.
6.2.2. Auxiliary terms do not introduce a field or subfield and hence,
are not associated witha particular keyword. However, th ey may
appear in the definition of more than one field, or subfield, or
auxiliary. For instance an auxiliary term like ‘date’ may be used
in the definition of many fields.
6.2.3. All necessary auxiliary terms shall be introduced in alphabetical
order and are defined in Annex A (A2) of this Standard.
6.2.4. The description may be presented in a table as follows, sorted in alphabetical order:
Auxiliary
TermSyntax SemanticUsed in
Primary
FieldUsed in
SubfieldUsed
in
Auxili-
ary
adexpmsg { CHARACTER } Free text
conforming to
the syntax
described for
an ADEXP
message.ifpdlong
rfpdlong
preproctxt
postproctxt
aidequip-
ment( ('N' | 'S') ! [
equipmentcode ] ) |
equipmentcodeRadio commu-
nication, navi-
gation and
approachaid
equipment.ceqpt
aircraftid 1{ ALPHANUM
}7Aircraft Identi-
fication.arcid
arcidk
arcidoldprevarcid2000R2082 — EN — 15.06.2002 — 001.001 — 89
▼B
6.3. DefinitionofPrimary Fields
6.3.1. All primary fields used in ADEXP messages shall conform to the
syntax and semantics as expressed in Annex A (A3) of this Stan-
dard.
6.3.2. The syntax of each field will be given first, then its semantic in
plain clear and unambiguous terms.
6.3.3. The syntax of fields will be expressed using the BNF notation as
introduced in section 3 of this Standard.
6.3.4. The description may be presented in a table as follows, sorted in alphabetical order,
where:
— The first column represents the left part of a BNF rule (i.e. that part of the rule at
the left of the ‘::=’ symbol) and the third column represents its right part.
— The second column (Kind) indicates if a field is basic (‘b’) or compound (‘c’).
Primary Field Kind Syntax Semantic
eobt b '–' ”EOBT” timehhmm Estimated Off-Block Time
6.4. DefinitionofSubfields
6.4.1. All subfields used in ADEXP messages shall conform to the
syntax and semantics expressed in Annex A (A4) of this Stan-
dard.
6.4.2. Additionally, for cross-reference purposes, the primary fields
inside which a given subfield appears are identified.
6.4.3. A subfield may also be a subfield of other subfields, therefore a
cross-reference to these subfields is also given.
6.4.4. The description may be presented in a table as follows, sorted in alphabetical order:
Subfield Kind Syntax SemanticUsed in
Primary FieldUsed in
Subfield
brng b '–' ”BRNG”
refbearingBearing of a
point from a
navigation aid
(in magnetic
degrees)ref
6.5. GroupofMessages
6.5.1. The operational categories (groups) of messages which have been
defined for use using the ADEXP format are introduced in
Annex E of this Standard.
6.5.2. The groups are defined in terms of the operational nature of the
messages being exchanged and are often characterised by the
systems concerned.
6.5.3. Reference to the defining documentation shall be made for each
group of messages.
6.5.4. No title value already used for a group of messages shall be
reused for another group with a different meaning.
6.5.5. A central index of message titles shall be maintained in Annex B
of this Standard.
6.5.6. A reference to the related group is given for each message title
listed in the central index of message titles. Reference to the
defining documentation for eachmessage title is th erefore
provided via the message group.
6.5.7. A central index of reserved message titles is also provided at
Annex C. ‘Reserved’ message titles have not been agreed for
use within the currently defined groups of messages using
ADEXP. Typically they are messages which have been foreseen
for possible future use within one of the defined groups, or they
are used locally within national systems. The purpose of
including them in this Standard is to assist in ensuring the2000R2082 — EN — 15.06.2002 — 001.001 — 90
▼B
uniqueness of message titles and avoidance of unnecessary redun-
dancy.2000R2082 — EN — 15.06.2002 — 001.001 — 91
▼B
ANNEX A (Normative)
ADEXPFIELDDEFINITIONS
A.1.Introduction
This Annex provides a listing of all the fields; Auxiliary Terms, Primary
Fields and Sub-Fields which have been defined for use in ADEXP.
A.2.ADEXPAuxiliaryTerms
Auxiliary Term Syntax SemanticUsed in
Primary
FieldUsed in
SubfieldUsed in
Auxiliary
adexpmsg { CHARACTER } Free text
conforming to the
syntax described for
an ADEXP
message.ifpdlong
rfpdlong
preproct-
xt
post-
proctxt
aidequipment ( ('N' | 'S') ! [
equipmentcode ] ) |
equipmentcodeRadio communica-
tion, navigation and
approachaid equip-
ment.ceqpt
aircraftid 2{ ALPHANUM }7 Aircraft Identifica-
tion.arcid
arcidk
arcidold
prevarci-
d
aircraf-
tidwldcrd1{ ALPHANUM |
'+' | '?' }7Wildcard form of
aircraftid to be used
in Query messages:
‘?’ replaces one
character
‘+’ replaces any
number of charac-
ters.arcidk
atsroute 2 {ALPHANUM} 7 The designator of
an ATS route.atsrt refatsrte
century 2{DIGIT}2 Two first digits of a
century.fulldate
coorstatusident 3 {ALPHA} 3 An indicator of the
co-ordination status
of a flight.statid
coorstatus-
reason3 {ALPHA} 7 The reason for noti-
fying a change in
the co-ordination
status.statreas-
on
country 2{ALPHA}2 The two letter
ICAO designator of
a country.refatsrte
datalink 1 {'S' | 'H' | 'V' | 'M'
}4The ICAO desig-
nator of the datalink
capability.
May contain any of
the values: S, H, V
or M in any order
but without repeti-
tion.dat2000R2082 — EN — 15.06.2002 — 001.001 — 92
▼B
Auxiliary Term Syntax SemanticUsed in
Primary
FieldUsed in
SubfieldUsed in
Auxiliary
date year ! month! day A date indication in
the format,
YYMMDD.
e.g. 930424 = 24th.
April 1993.ada
add
aobd
cobd
ctod
eobd
eobdk
eobdold
etod
fstday
iobd
lstday
neweobd
valfrom
valfromk
valfro-
mold
validity-
date
valuntil
valuntilk
valunti-
loldeto datetime
datetime date ! timehhmm A ‘date’ term as
described above and
immediately
followed by the
time in the format,
HHMM.
e.g.
9304240930=0930Z
on the 24th. April
1993.origindt
datewldcrd 1{ DIGIT | '+' | '?'
)6A ‘date’ term which
may be wild carded.valfromk
valuntilk
day ('0' | '1' | '2' | '3') !
DIGITA two digit number
which may contain
the digits from 00
to 31.endtime
filtim
starttimeendreg
from
startreg
untildate
fulldate
emergradio 1 {'U' | 'V' | 'E' } 3 Indicator of the type
of emergency radio
equipment on board
the aircraft. May be
one or more of the
defined characters
in any order but
without repetition.splr
eqptcode 1 {ALPHANUM} 2 Code which identi-
fies an equipment
capability. May be
identical to equip-
ment codeeqpt
eqptstatus 2 {ALPHA} 2 Two letter status
value describing the
status of the aircraft
capability.eqpt
equipmentcode 1 {(‘A' | ‘B' | ‘C' |
‘D' | ‘E' | ‘F' | ‘G' |
‘H' | ‘I' | ‘J' | ‘K' |
‘L' | ‘M' | ‘O' | ‘P' |
‘Q' | ‘R' | ‘T' | ‘U' |
‘V' | ‘W' | ‘X' | ‘Y' |
‘Z' )} 24A valid ICAO code
letter to indicate the
equipment carried.
May be one or more
of the defined char-
acters in any order
but without repeti-
tion.aidequip-
ment
errorcode 1{DIGIT}4 Error message code
number.error2000R2082 — EN — 15.06.2002 — 001.001 — 93
▼M1
▼B
▼B
Auxiliary Term Syntax SemanticUsed in
Primary
FieldUsed in
SubfieldUsed in
Auxiliary
fieldid 1{ ALPHANUM } Valid ADEXP field
name (i.e.
keyword).errfield
ifpsmod
firindicator 4{ ALPHA }4 An ICAO desig-
nator of an FIR.eetfir
flightlevel ('F' | 'A') ! 3{
DIGIT }3 | ('S' |
'M') ! 4{ DIGIT } 4A flight level
expressed either as;
‘F’ or ‘A’ followed
by three digits or,
‘S’ or ‘M’ followed
by four digits.rfl crfl1
crfl2
efl
fl
tfl
sfl
ptrfl
flightplanstatus 'EMER' | 'HUM' |
'HOSP' | 'SAR' |
'HEAD' | 'STATE'The reason for
special treatment as
indicated in Field
18 element ‘STS/’.
EMER = Emer-
gency
HUM = Humani-
tarian flight
HOSP = Hospital
flight
SAR = Searchand
Rescue
HEAD = Head of
State
STATE = State
flightsts
flightrule 'I' | 'V' | 'Y' | 'Z' The flight rule indi-
cator of a flight.fltrul
flighttype 'S' | 'N' | 'G' | 'M' |
'X'The type of flight as
indicated by the
ICAO designator
used.flttyp
flighttypechg 'OAT' | 'GAT' The indication
provided in the
route of flight of a
change in the type
of flight to ‘OAT’
or ‘GAT’.chgrul ptrulchg
fulldate century ! year !
month! dayA date indication in
the format
CCYYMMDD
eg. 19970801 = 1st.
Aug. 1997fulldate-
time
fulldatetime fulldate ! timehhmm A date, as described
in ‘fulldate', and
immediately
followed by the
time in the format
HHMM
e.g.
199708010930=09-
30 hours on 1st.
Aug. 1997mesval-
period
geoname "GEO" !
2{DIGIT}2The identification
given to a geogra-
phical position
expressed in latitude
and longitude.geoid
heading 3{DIGIT}3 A three digit
number in the range
001 to 360.ahead2000R2082 — EN — 15.06.2002 — 001.001 — 94
▼B
Auxiliary Term Syntax SemanticUsed in
Primary
FieldUsed in
SubfieldUsed in
Auxiliary
icaoaerodrome 4{ ALPHA }4 A four letter ICAO
designator for an
aerodrome.adarr
adep
adepk
adepold
ades
adesk
adesold
altrnt1
altrnt2adid
icaoaerodro-
mewldcrd1{ ALPHA | '+' | '?'
}4Wildcard form of
icaoaerodrome, to
be used in Query
messages:
‘?’ replaces one
character
‘+’ replaces any
number of charac-
ters.adepk
adesk
icaoaircrafttype ALPHA ! 1{
ALPHANUM }3An ICAO desig-
nator of an aircrafttype.arctyp
icaomsg { CHARACTER } An ICAO message.
(conforming to the
syntax described in
Ref. {4})msgtxt
ifpuid 1{ ALPHANUM } The identifier of an
IFPS Unit.ifpuresp
latitudelong 6{ DIGIT }6 A latitude expressed
as six digits.lattd
latitudeside 'N' | 'S' An indicator for
‘North’ or ‘South’
latitude.lattd
lifejackets 1 {'L' | 'F' | 'U' | 'V'}
4The ICAO indicator
of the type of life-
jackets carried.
May be one or more
of the defined char-
acters in any order
but without repeti-
tion.splj
longitudelong 7{ DIGIT }7 A longitude
expressed as seven
digits.longtd
longitudeside 'E' | 'W' An indicator for
‘East’ or ‘West’
longitude.longtd
machnumber 'M' ! 3{ DIGIT }3 The Mach number. mach
aspeedcrmach
ptmach
modifind 1{ALPHANUM} Indication of the
type of modification
made to a field.ifpsmod
month('0' | '1' ) ! DIGIT Month , expressed as
a two digit number.date
fulldate
numdays ('0' | '1') ! ('0' | '2') !
('0' | '3') ! ('0' | '4') !
('0' | '5') ! ('0' | '6') !
('0' | '7')The indication of
the days of the
week on which a
RPL is active.days
daysk
daysold
numdayswldcrd 1{ DIGIT | '+' | '?'
}7The indication of
the days of the
week on which a
RPL is active.
Wildcard characters
may also be used.daysk2000R2082 — EN — 15.06.2002 — 001.001 — 95
▼B
Auxiliary Term Syntax SemanticUsed in
Primary
FieldUsed in
SubfieldUsed in
Auxiliary
originatorid 1{ ALPHANUM
}10Identifier of the
originator of a
message.orgnid
qrorgn
point 2{ ALPHANUM }5 The designator of a
significant point.
May be a published
point, a geogra-
phical point, a
reference point or a
point given artifi-
cially suchas a ‘re-
named’ point
(RENxx).atsrt
chgrul
cop
dct
eetpt
mach
rfl
speed
sid
starptid
refatsrte
refbearing 3{ DIGIT }3 Reference Bearing
value.brng
refname "REF" ! 2{DIGIT}2 The identifier given
to a point expressed
by bearing and
distance from a
published pointrefid
regulid 1{ ALPHANUM
}20The identification of
an ATFM regula-
tion concerning a
flight.regul regid
renameid "REN" !
2{DIGIT}2Identifier of a re-
named point.renid
rrteid 1{ ALPHANUM}
20The identifier of a
re-routing.rrteref
rtf 6{DIGIT}6 A radio frequency
expressed in MHz
to three decimal
places.freq
rulechg VFR' | 'IFR' The indicators used
in the route of a
flight to indicate a
change in the flight
rules.chgrul ptrulchg
seconds ( '0' | '1' | '2' | '3' | '4'
| '5' ) ! DIGITSeconds.
Two digits from
‘00’ to ‘59’.eto
sto
spd ('K' | 'N') ! 4{
DIGIT }4Speed.
Expressed as either
‘K’ or ‘N’ followed
by four digits.aspeed
speedcrspeed
ptspeed
ssrequipment 1 {ALPHA} 2 The ICAO desig-
nator of the SSR
equipment carried
and optionally, indi-
cation of a data link
capability.seqpt
stayidentifier STAY' ! ( ‘1' | ‘2' |
‘3' | ‘4' | ‘5' | ‘6' | ‘7'
| ‘8' | ‘9' )Designator of a
‘stay’ period, a
period of ‘special
activity’ within the
route of a flight.ptstay
stayident
survivaleqpt 1 {'P' | 'D' | 'M' | 'J'
}4The ICAO desig-
nator of the survival
equipment carried.
May be one or more
of the defined char-
acters in any order
but without repeti-
tion.spls2000R2082 — EN — 15.06.2002 — 001.001 — 96
▼B
Auxiliary Term Syntax SemanticUsed in
Primary
FieldUsed in
SubfieldUsed in
Auxiliary
text20 1{ LIM_CHAR }20 Text made of 1 to
20 characters,
excluding the
hyphen character.altnz
com
depz
destz
nav
per
sts
typz
timehhmm ( '0' | '1' | '2' ) !
DIGIT ! ( '0' | '1' |
'2' | '3' | '4' | '5' ) !
DIGITTime, expressed in
hours (2 digits 00-
23) and minutes (2
digits 00-59). May
be the time of day
or a duration.aobt
ata
atd
atot
cobt
ctot
delay
endtime
eobt
eobtk
eobtold
etot
filtim
iobt
minli-
neup
newctot
neweobt
newptot
ptot
rejctot
respby
starttime
taxitimecto
endreg
eto
from
ptstay
startreg
sto
time
to
untildatetime
fulldate-
time
timehhmm_e-
lapsedDIGIT ! DIGIT !
('0' | '1' | '2' | '3' | '4' |
'5' ) ! DIGITAn unlimited
number of hours
and minutes, used
for durations.ttleet
eetfir
eetpt
sple
timewldcrd 1{ DIGIT | '+' | '?'
}4Wild card form of a
timehhmm.eobtk
titleid 1{ ALPHA }10 A valid ADEXP
message title. (see
Annex B)msgtyp
orgmsg
title
waketurbcat 'H' | 'M' | 'L' The ICAO wake
turbulence category
designator.wktrc
year 2{ DIGIT }2 Two last digits of a
year.date
fulldate
A.3.ADEXPPrimary Fields
ADEXP
Primary
FieldKind Syntax Semantic
ad c '–' "AD" adid [(fl | flblock)] [eto]
[to] [cto] [sto] [ptstay] [ptrfl]
[ptrulchg] [(ptspeed | ptmach)]The designator of an aerodrome. In
cases where the aerodrome forms
part of the route description addi-
tional routing information may be
provided.
ada b '–' "ADA" date Actual date of arrival.
adarr b -' "ADARR" (icaoaerodrome |
'ZZZZ')Actual aerodrome of arrival.
adarrz b '–' "ADARRZ" text20 Name of actual aerodrome of
arrival if no ICAO location indi-
cator exists.
add b '–' "ADD" date Actual date of departure.2000R2082 — EN — 15.06.2002 — 001.001 — 97
▼B
ADEXP
Primary
FieldKind Syntax Semantic
addr c '- "BEGIN" "ADDR" 1 { fac } '–'
"END" "ADDR"List of addressees.
adep b '–' "ADEP" (icaoaerodrome |
'AFIL' | 'ZZZZ')ICAO location indicator of the
aerodrome of departure or the indi-
cation ‘AFIL’ meaning an air-filed
flight plan or ‘ZZZZ’ when no
ICAO location indicator is assigned
to the aerodrome of departure.
adepk b '–' "ADEPK" (icaoaerodrome |
'AFIL' | 'ZZZZ' | icaoaerodro-
mewldcrd)Aerodrome of departure used as
database key in a query, may be
wild-carded.
May contain an ICAO location
indicator or the indication ‘AFIL’
meaning an air-filed flight plan or
‘ZZZZ’ when no ICAO location
indicator is assigned to the aero-
drome of departure or a combina-
tion of alphabetic and wildcard
characters.
adepold b '–' "ADEPOLD" (icaoaerodrome |
'AFIL' | 'ZZZZ')The ‘previous’ aerodrome of
departure. May contain the ICAO
location indicator or the indication
‘AFIL’ meaning an air-filed flight
plan or ‘ZZZZ’ when no ICAO
location indicator is assigned to the
aerodrome of departure.
ades b '–' "ADES" (icaoaerodrome |
'ZZZZ')The ICAO location indicator of the
aerodrome of destination or
‘ZZZZ’ when no ICAO location
indicator is assigned to the aero-
drome of destination.
adesk b '–' "ADESK" (icaoaerodrome |
'ZZZZ' | icaoaerodromewldcrd)The aerodrome of destination used
as database key in a query, may be
wild-carded.
May contain an ICAO location
indicator or ‘ZZZZ’ when no ICAO
location indicator has been
assigned to the aerodrome of desti-
nation or a combination of alpha-
betic and wildcard characters.
adesold b '–' "ADESOLD" (icaoaerodrome |
'ZZZZ')The ‘previous’ aerodrome of desti-
nation. May contain the ICAO
location indicator or ‘ZZZZ’ when
no ICAO location indicator has
been assigned to the aerodrome of
destination.
adexptxt c '–' "ADEXPTXT" (preproctxt |
postproctxt)Contains an ADEXP message.
afildata c '–' "AFILDATA" ptid fl eto Estimate data for an air-filed flight
plan.
A point identification, the joining
flight level and the estimate date-
time at the point.
NOTE: The flight level indicated is
the level at which the flight has
been cleared to join controlled
airspace over the point indicated. It
need not be the same as the RFL.
ahead b '–' "AHEAD" (heading | "ZZZ") The heading assigned to a flight,
expressed in degrees
Must be a three digit numeric or
the value ‘ZZZ’ indicating that no
heading is assigned.
altnz b '–' "ALTNZ" text20 Name of alternate aerodrome if no
ICAO location exists.2000R2082 — EN — 15.06.2002 — 001.001 — 98
▼B
ADEXP
Primary
FieldKind Syntax Semantic
altrnt1 b '–' "ALTRNT1" (icaoaerodrome |
'ZZZZ')The ICAO location indicator of the
first alternate aerodrome of desti-
nation or the indicator ‘ZZZZ’
when no ICAO location indicator
has been assigned to the aero-
drome.
altrnt2 b '–' "ALTRNT2" (icaoaerodrome |
'ZZZZ')The ICAO location indicator of the
second alternate aerodrome of
destination or the indicator ‘ZZZZ’
when no ICAO location indicator
has been assigned to the aero-
drome.
aobd b '–' "AOBD" date Actual Off_Block Date.
aobt b '–' "AOBT" timehhmm Actual Off_Block Time.arcid b '–' "ARCID" aircraftid Aircraft Identification.
May be the registration marking of
the aircraft, or the ICAO designator
of the aircraft operator followed by
the flight identifier.
arcidk b '–' "ARCIDK" (aircraftid | aircraf-
tidwldcrd)Aircraft Identification used as data-
base key in a query; may be wild-
carded.
Must be a combination of alphanu-
meric and wild-card characters up
to maximum 7 characters in total.
arcidold b '–' ARCIDOLD aircraftid The ‘previous’ aircraft id. Where
the aircraft id. is to be amended,
the new value will be given in
‘ARCID’.
arctyp b '–' "ARCTYP" (icaoaircrafttype |
"ZZZZ")Type of aircraft (ICAO identifica-
tion of the type) or ZZZZ.
aspeed b '–' "ASPEED" (spd | machnumber
| "ZZZ")The currently assigned speed of the
flight, in kilometres per hour, knots
or Machnumber.
Must be ‘M’ followed by three
digits, ‘K‘ or ‘N’ followed by four
digits or ‘ZZZ’ indicating that no
speed restriction is assigned.
ata b '–' "ATA" timehhmm Actual time of arrival.
atd b '–' "ATD" timehhmm Actual time of departure.atot b '–' "ATOT" timehhmm Actual Time of Take-offatsrt b '–' "ATSRT" atsroute point point ATS route designator and identi-
fiers of first and last points.
cassaddr c '–' "BEGIN" "CASSADDR" { fac
} '–' "END" "CASSADDR"Addresses to which ATFM
messages should be addressed.
ceqpt b '–' "CEQPT" aidequipment Radio communication, navigation
and approachaid equipment (as
ICAO field 10).
cfl c '–' "CFL" fl [ptid] Cleared Flight Level. The flight
level currently assigned by ATC to
the pilot (flight level number).
chgrul b '–' "CHGRUL" ( rulechg | flight-
typechg | rulechg flighttypechg )
pointIndication of a change in either the
‘flight rules’ (VFR/IFR) or the
‘type of flight’ (OAT/GAT) or both
together with the point at which the
change occurs.
cobd b '–' "COBD" date Calculated Off-Block Date.
cobt b '–' "COBT" timehhmm Calculated Off-Block Time.
com b '–' "COM" text20 Communication equipment (as
ICAO field 18 COM/).
comment b '–' "COMMENT" 1 { LIM_CHAR
}A general comment in free text
without hyphen.2000R2082 — EN — 15.06.2002 — 001.001 — 99
▼B
ADEXP
Primary
FieldKind Syntax Semantic
condid b '–' "CONDID" 1 {LIM_CHAR}
30Identification of an ‘exceptional
condition’ raised in the context of
ATFM.
coordata c '–' "COORDATA" ptid (to | sto)
tfl [sfl]The transfer conditions of a flight.
A point id., the flight level and
estimated time at that point and
optional supplementary flight level
information.
cop b '–' "COP" point A co-ordination point identifier,
either a coded designator of a point
or a name given artificially
(GEOxx, RENxx or REFxx).
crsclimb c '–' "CRSCLIMB" ptid (crspeed |
crmach) crfl1 crfl2Indication of a cruiseclimb. Giving
the point at which the climb will
begin, speed or machno. and th e
two levels indicating the flight
level band to be occupied during
the climb. The second level may be
‘PLUS’ where the upper level is
unknown.
cstat c '–' "CSTAT" statid [statreason] An indicator confirming the new
co-ordination status of a flight and,
optionally, the reason for the
change.
ctod b '–' "CTOD" date Calculated Take-Off Date.ctot b '–' "CTOT" timehhmm Calculated Take-Off Time (CTOT):
reference time of an ATFM Slot.
dat b '–' "DAT" datalink Indication of the datalink capability
carried by the aircraft.
days b '–' "DAYS" numdays Days of operation for a repetitive
flight plan (1234567 where 1 is for
Monday, 2 for Tuesday, …, with0
in columns of non-operation).
daysk b '–' "DAYSK" (numdays |
numdayswldcrd)Days of operation for a repetitive
flight plan, used as database key in
a query message, may be wild-
carded.
daysold b '–' "DAYSOLD" numdays The ‘previous’ days of operation.
Used as a database key. Where the
days of operation of an RPL are to
be amended, the new values will be
given in ‘DAYS’.
dct b '–' "DCT" point point Indicates a direct route between
two points.
The points may either be a valid
ICAO designator of a point or a
point appearing in a GEO, REN or
REF field of the form GEOxx,
RENxx or REFxx.
delay b '–' "DELAY" timehhmm A period of time representing a
delay. The nature of the delay i.e.
delay to a flight, processing delay,
etc. is dependant upon its context.
depz b '–' "DEPZ" text20 Name of departure aerodrome if no
ICAO location indicator exists.
desc b '–' "DESC" 1 {LIM_CHAR} Description of a condition or entity
which is of relevance to the content
of the message.
destz b '–' "DESTZ" text20 Name of destination aerodrome if
no ICAO location indicator exists.
eetfir b '–' "EETFIR" firindicator time-
hhmm_elapsedFIR identification and the accumu-
lated elapsed time (in hours and
minutes) to the FIR boundary.2000R2082 — EN — 15.06.2002 — 001.001 — 100
▼B
ADEXP
Primary
FieldKind Syntax Semantic
eetlat c '–' "EETLAT" lattd time Indication of an elapsed time to a
position given by latitude only.
eetlong c '–' "EETLONG" longtd time Indication of an elapsed time to a
position given by longitude only.
eetpt b '–' "EETPT" point timehhmm_e-
lapsedPoint identifier and the accumu-
lated elapsed time to the point.
endtime b '–' "ENDTIME" day ! timehhmm The time at which a period of time
ends.
entrydata c '–' "ENTRYDATA" (ptid |
airspdes | (ptid airspdes)) [fl]
[ptrfl] [(ptspeed | ptmach)]
[ptfltrul] [ptmilrul]The flight plan data which is
applicable to a flight at the point
given or at the entry of the flight
into the airspace concerned. One or
bothof th e fields; ‘ptid’, ‘airspdes’,
must be present.
eobd b '–' "EOBD" date Estimated Off-Block Date.
eobdk b '–' "EOBDK" date Estimated Off-Block Date used as
database key in a query, may be
wildcarded.
Must be a combination of digits
and wild-card characters, up to
maximum 6 characters in total.
eobdold b '–' "EOBDOLD" date The ‘previous’ estimated off block
date. Used as a database key.
Where the estimated off block date
is to be amended, the new value
will be given in ‘EOBD’.
eobt b '–' "EOBT" timehhmm Estimated Off-Block Time (EOBT)
eobtk b '–' "EOBTK" (timehhmm |
timewldcrd)Estimated Off-Block Time used as
database key in a query, may be
wildcarded.
eobtold b '–' "EOBTOLD" timehhmm The ‘previous’ estimated off block
time. Used as a database key.
Where the estimated off block date
is to be amended, the new value
will be given in ‘EOBT’.
eqcst b '–' "BEGIN" "EQCST" 1 {eqpt}
'–' "END" "EQCST"List of equipment capability codes
eachfollowed by a status value
which specifies the current status of
the capability
errfield b '–' "ERRFIELD" fieldid ADEXP name of erroneous field(s).
error b '–' "ERROR" [errorcode] 1{
LIM_CHAR }Error message text. May optionally
contain an error identification code.
estdata c '–' "ESTDATA" ptid eto fl [sfl] Estimate data. A point id., the esti-
mated flight level (flight level
number) and the estimate date-time
at this point followed optionally by
the supplementary flight level
(flight level number followed by
the indicator A or B).
etod b '–' "ETOD" date Estimated Take-Off Date.
etot b '–' "ETOT timehhmm Estimated Take-Off Time.
extaddr c '–'"EXTADDR" num | { fac } |
(num {fac})Addresses which are provided in
addition to those which are deter-
mined automatically i.e. ‘extra
addresses’. May contain only the
number of addresses or the actual
addresses or both.
filrte b '–' "FILRTE" {LIM_CHAR} The route exactly as filed i.e.
without any processing.2000R2082 — EN — 15.06.2002 — 001.001 — 101
▼M1
▼B
▼B
ADEXP
Primary
FieldKind Syntax Semantic
filtim b '–' "FILTIM" day ! timehhmm Day-time group specifying when
the message was filed for transmis-
sion.
flband c '–' "FLBAND" fl fl A flight level band defining the
airspace vertically, inclusive of the
flight levels given.
fltrul b '–' "FLTRUL" flightrule Flight rule, as ICAO field 8.flttyp b '–' "FLTTYP" flighttype Type of flight, as ICAO field 8.
fmp b '–' "FMP" 4{ ALPHA }4 Identifier of a ‘Flow Management
Position’.
fmplist c '–' "BEGIN" "FMPLIST" fmp
reglist
'–' "END" "FMPLIST"List of FMPs and their associated
ATFM regulations.
freq b '–' "FREQ" rtf Radio frequency.
fstday b '–' "FSTDAY" date First day of operation for a repeti-
tive flight plan. This is used to give
the actual first day from which
flight plans will be generated from
a RPL (see valfrom field) or the
first day on which an amendment
to an RPL is effective.
furthrte b '–' "FURTHRTE" {LIM_CHAR} The further routing of a flight. For
use within messages containing
estimate data to indicate the further
routing of the flight following the
estimate point. It may contain only
the next point or the complete
further routing until the destination.
geo c '–' "GEO" geoid lattd longtd Point along a route defined by lati-
tude and longitude and given in the
flight plan, as GEOxx (where xx is
a sequence number).
ifp b '–' "IFP" 1{ALPHA} Indication of known errors within a
FPL.
ifpdlist c '–' "BEGIN" "IFPDLIST" 1 {
ifpdlong } '–' "END" "IFPDLIST"List of complete IFPDs matching
the database key given in a query
message.
Contains a list of complete infor-
mation for eachindividual fligh t
which matches given query keys.
ifpdslist c '–' "BEGIN" "IFPDSLIST" 1 {
ifpdsum } '–' "END" "IFPDS-
LIST"List of ifpdsum matching the data-
base key given in a query message.
Contains a list of summarised
information for eachindividual
flight which matches given query
keys.
ifplid b '–' "IFPLID" ALPHA ALPHA {
DIGIT }8A unique flight plan identifier,
assigned by the IFPS.
ifpsmod b '–' "IFPSMOD" fieldid modifind An indication given by IFPS of
those fields which have been
modified, and the nature of the
modification.
ifpuresp b '–' "IFPURESP" ifpuid Identifier of the IFPU which is
responsible for a query. It must
process the query and answer to it.2000R2082 — EN — 15.06.2002 — 001.001 — 102
▼B
ADEXP
Primary
FieldKind Syntax Semantic
ignore c '–' "BEGIN" "IGNORE" { (condi-
tion | condition ptid ptid) }'-'
"END" "IGNORE"Indication of conditions which have
been ‘ignored’ or by-passed in the
processing of the message
concerned. An ‘ignored’ condition
may be limited to a specific portion
of the route delimited by the route
points given. A condition may, forexample, be a time restriction
(route access condition), flight
level restriction or TOS violation.
iobd b '–' "IOBD" date The ‘Initial’ Off Block Date — the
‘off-block date’ as given in the
FPL and updated by flight plan
associated messages (DLA, CHG,
etc.). This is the reference date
used for accessing the flight plan in
the database and is the only ‘off-
block date’ known by the
concerned ATS units.
Note: The IOBD is not affected by
changes requested or notified
through the exchange of ATFM
messages.
iobt b '–' "IOBT" timehhmm The ‘Initial’ Off Block Time - the
‘off-block time’ as given in the
FPL and updated by flight plan
associated messages (DLA, CHG,
etc.). This is the reference time
used for accessing the flight plan in
the database and is the only ‘off-
block time’ known by the
concerned ATS units.
Note: The IOBT is not affected by
changes requested or notified
through the exchange of ATFM
messages.
lacdr c '–' "BEGIN" "LACDR" { airroute
} '–' "END" "LACDR"List of Active Conditional Routes.
latsa c '–' "BEGIN" "LATSA" { airspace
} '–' "END" "LATSA"List of Active Temporary Segre-
gated Areas.
lcatsrte c '–' "BEGIN" "LCATSRTE" {
airroute } '–' "END"
"LCATSRTE"List of Closed ATS Routes.
lfir c '–' "BEGIN" "LFIR" 1{ fir ( lacdr
| ( lacdr lcatsrte latsa lrar lrca) ) }
'–' "END" "LFIR"List of FIRs, including the name of
the region followed by either the
list of Available Conditional
Routes or the lists of Available
Conditional Routes, Closed ATS
Routes, Active Temporary Segre-
gated Areas, Reduced Airspace
Restrictions and Reduced Co-ordi-
nation Airspaces.
lrar c '–' "BEGIN" "LRAR" { airspace }
'–' "END" "LRAR"List of Reduced Airspace Restric-
tions.
lrca c '–' "BEGIN" "LRCA" { airspace }
'–' "END" "LRCA"List of Reduced Co-ordination
Areas.
lstday b '–' "LSTDAY" date Last day of operation for a repeti-
tive flight plan. This is used to give
the actual last day from which
flight plans will be generated from
a RPL (see valuntil field) or the
last day on which an amendment to
an RPL is effective
=> Must be a date between
VALFROM and VALUNTIL.2000R2082 — EN — 15.06.2002 — 001.001 — 103
▼B
ADEXP
Primary
FieldKind Syntax Semantic
mach b '–' "MACH" machnumber [ point ] Mach number, in hundredths of a
unit and optionally the point at
which the change is requested.
mesval-
periodb '–' "MESVALPERIOD" fulldate-
time fulldatetimeThe validity period of a message,
inclusive of the times given.
minlineup b '–' "MINLINEUP" timehhmm The minimum time required for a
flight, which has declared itself
ready to depart, to get from it's
present holding position to
airborne.
modifnb b '–' "MODIFNB" 1{ DIGIT }3 Number of modifications that were
necessary to correct an original
message.
msgref c '–' "MSGREF" sender recvr
seqnumReference data for associated,
previously transmitted messages.
msgsum c '–' "BEGIN" "MSGSUM" { [arcid]
[adep] [ades] [eobt] [eobd] [orgn]
[days] [valfrom] [valuntil] }
'–' "END" MSGSUM"Contains a summary of a message.
Note: Must contain one or more*
of the fields arcid, adep, ades, eobt
and orgn but without repetition.
* one or more of the fields may
have been missing or garbled in
received message
msgtxt b '–' "MSGTXT" icaomsg Contains a complete ICAO
message.
msgtyp b '–' "MSGTYP" titleid Contains the title of the referenced
or copied message.
May be any valid ADEXP message
title (see Annex B).
nav b '–' "NAV" text20 Significant navigation equipment,
as ICAO field 18 NAV/.
nbarc b '–' "NBARC" 1{ DIGIT }2 Number of aircraft if more than
one.
nbrfpd b '–' "NBRFPD" 1{ DIGIT }3 Number of flight plan data
matching a query.
Must be between 0 and 999.
newctot b '–' "NEWCTOT" timehhmm A new Calculated Take-Off Time,
as updated by TACT.
newend-
timeb '–' "NEWENDTIME" day !
timehhmmA new time at which a period of
time ends.
neweobd b '–' "NEWEOBD" date A new Estimated Off-Block Date.neweobt b '–' "NEWEOBT" timehhmm A new Estimated Off-Block Time.newptot b '–' "NEWPTOT" timehhmm A new Provisional Take-Off Time.newrte b '–' "NEWRTE" { LIM_CHAR } A new route between the same
aerodromes of departure and arrival
as in the original message.
newstart-
timeb -' NEWSTARTTIME day !
timehhmmA new time at which a period of
time starts.
oldmsg b '–' "OLDMSG" { CHARACTER } A complete original message,
exactly (and in the same format) as
it was received.
opr b '–' "OPR" 1 { LIM_CHAR } Name of the company or agency
operating the flight, as ICAO Field
18 element OPR/.
orgmsg b '–' "ORGMSG" titleid The ADEXP Title of an erroneous
message, as it was received by
TACT.
orgn b '–' "ORGN" 1{LIM_CHAR}30 The address of the originator of a
message.
orgnid b '–' "ORGNID" originatorid The designator of an addressee
having originated a message.2000R2082 — EN — 15.06.2002 — 001.001 — 104
▼B
ADEXP
Primary
FieldKind Syntax Semantic
orgrte b '–' "ORGRTE" { LIM_CHAR } Original route between the aero-
dromes of departure and arrival.
origin c '–' "ORIGIN" networktype | fac |
(networktype fac)Information concerning the origi-
nator of a message. May include
the type of network used or the
address concerned or both.
origindt b '–' "ORIGINDT" datetime Date and time of receipt of original
message by the IFPS.
Note: This is not the filing time of
the message.
Format is YYMMDDHHMM.
part c '–' "PART" num lastnum Identification of the part of the
message identified by the title,
filing time and validity period.
per b '–' "PER" text20 Aircraft performance data, as
ICAO field 18 PER/.
position c '–' "POSITION" (adid | ptid)[(to |
sto)] [fl] [cto]The position of an aircraft given as
either a point or an aerodrome with
optional time and flight level
information.
prevarcid b '–' "PREVARCID" aircraftid The previous callsign used.prevssrcode b '–' "PREVSSRCODE" ALPHA !
4{ '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7'
}4SSR Mode and Code used by the
flight immediately prior to the SSR
Mode and Code given in field ‘-
SSRCODE’.
propfl c '–' "PROPFL" tfl [sfl] A flight level proposed by an
accepting unit for the transfer of a
flight.
ptot b '–' "PTOT" timehhmm Provisional Take-Off Time. Provi-
sional reference time for an ATFM
slot.
qrorgn b '–' "QRORGN" originatorid Identifier of the originator of the
Query.
ralt b '–' "RALT" 1 {LIM_CHAR} 40 Name of en-route alternate aero-
drome/s.
rate b '–' "RATE" ((("C" | "D")!
2{DIGIT}2 ) | "ZZZ" )Rate of change: the climb or
descent rate assigned to an aircraft,
expressed in hundreds of feet per
minute.
=> Must be ‘C’ indicating a climb
rate, or ‘D’ indicating a descent
rate, followed by a two digit
number indicating the assigned rate
in hundreds of feet per minute.
Alternatively the designator ‘ZZZ’
may be used to indicate that there
is no assigned rate of climb or
descent.
ratepdlst c '–' "BEGIN" "RATEPDLST" 1
{rateperiod} '–' "END"
"RATEPDLST"List of time periods and their
respective flow rates for an ATFM
condition.
reason b '–' "REASON" 4{ALPHA}12 Reason for either rejection of a
message or cancellation of a slot by
TACT.
Information in support of the
message dependent on its context.
ref c '–' "REF" refid ptid brng distnc Point along a route which is
defined in terms of magnetic
bearing and distance from another
point and is given the designator
REFxx.
refdata c '–' "REFDATA" [sender] [recvr]
seqnumReference data for message being
transmitted.2000R2082 — EN — 15.06.2002 — 001.001 — 105
▼B
ADEXP
Primary
FieldKind Syntax Semantic
reg b '–' "REG" 1{ LIM_CHAR }7 Registration markings, as ICAO
field 18 REG/.
regloc b '–' "REGLOC" 1 {LIM_CHAR}
15Reference location for an ATFM
Regulation.
regul b '–' "REGUL" regulid Identifier of a Regulation
concerning a flight.
rejctot b '–' "REJCTOT" timehhmm Rejected Calculated Take-Off
Time: negative response to a Slot
Improvement Proposal.
release b '–' "RELEASE" 1{ALPHA}1 An indication that the flight is
released by the transferring
controller to the receiving
controller.
C = released for climb
D = released for descent
T = released for turns
F = released for all actions
rename c '–' "RENAME" renid ptid Indication of a temporary, new
name given to a ‘significant point’
which appears more than once in
the route description in order to
avoid confusion. This temporary
name is applied only for the
purpose of clarity in the represen-
tation of the route and does not
imply an actual modification of the
real identification of the point .
respby b '–' "RESPBY" timehhmm Respond By: time by which a
response to a Slot Improvement
Proposal has to be made.
rfl b '–' "RFL" flightlevel [point] Requested flight level (in flight
level number, tens of meters or
hundreds of feet) and optionally the
point at which a change of RFL is
required.
rfp b '–' "RFP" "Q" ( '1' | '2' | '3' | '4' | '5'
| '6' | '7' | '8' | '9' )Replacement Flight Plan (RFP)
indicator.
Must be ‘Q’ followed by a digit (1
- 9).
rfpdlist c '–' "BEGIN" "RFPDLIST" {
rfpdlong } '–' "END"
"RFPDLIST"List of complete RFPDs matching
the database keys given in a Query.
rfpdslist c '–' "BEGIN" "RFPDSLIST" {
rfpdsum } '–' "END"
"RFPDSLIST"List of rfpdsum (RFPD summarised
information) matching the database
keys given in a Query.
rif b '–' "RIF 4{LIM_CHAR} Revised route subject to clearance
in flight and terminating with the
ICAO designator of the revised
aerodrome of destination.
rmk b '–' "RMK" 1{ LIM_CHAR } Plain language remarks, as ICAO
field 18 RMK/.
route b '–' "ROUTE" {LIM_CHAR} Complete ICAO Field 15 informa-
tion containing speed, RFL and
route (conforming to the syntax
given in Ref. 4).
rrtefrom c '–' "RRTEFROM" tfvid refloc
flowlst flblockDescription of a traffic flow which
is to be re-routed.
rrteref b '–' "RRTEREF" rrteid Re-Route Reference.
rrteto c '–' "RRTETO" tfvid refloc flowlst
flblockDescription of a traffic flow to
which traffic is to be re-routed.
rtepts c '–' "BEGIN" "RTEPTS" { pt [ad]}
'–' "END" "RTEPTS"List of route points. May also
contain an aerodrome identifier.2000R2082 — EN — 15.06.2002 — 001.001 — 106
▼B
ADEXP
Primary
FieldKind Syntax Semantic
rvr b '–' "RVR" 1{ DIGIT }3 Runway Visual Range (RVR).
Operating minima when special
meteorological conditions exist.
Expressed in meters.
rvrcond c '–' "BEGIN" "RVRCOND" 1
{rvrperiod} '–' "END"
"RVRCOND"List of time periods and their
applicable RVR limits.
rvrperiod c '–' "RVRPERIOD" from until
rvrlimitThe period of time within which
the RVR limit provided is applic-
able.
sector b '–' "SECTOR" 1{ ALPHANUM
}8Identification of an ATC sector.
sel b '–' "SEL" 4{ ALPHA }5 SELCAL code as ICAO Feld 18
element ‘SEL/’.
sendto c '–' "BEGIN""SENDTO" {unit} '–'
"END""SENDTO"List of air navigation units which
are to be sent a message
seqpt b '–' "SEQPT" ssrequipment Surveillance equipment, as ICAO
Field 10.
sid b '–' "SID" point ! 1{DIGIT}1 !
0{ALPHA}1Identifier of a Standard Instrument
Departure procedure.
speed b '–' "SPEED" spd [ point ] True airspeed (in kilometres per
hours or knots) and optionally, the
point at which a change of airspeed
is requested.
spla b '–' "SPLA" 1{ LIM_CHAR }50 Colour of markings on aircraft, as
ICAO Field 19 element ‘A/’.
spladdr c '–' "BEGIN" "SPLADDR" { fac }
'–' "END" "SPLADDR"Contact data, where flight plan
Supplementary information may be
obtained.
splc b '–' "SPLC" 1{ LIM_CHAR }50 Name of pilot in command, as
ICAO Field 19 element ‘C/’.
spldcap b '–' "SPLDCAP" 1{ DIGIT }3 Dinghies total capacity, as ICAO
Field 19 element ‘D/’.
spldcol b '–' "SPLDCOL" 1{ LIM_CHAR
}50Dinghies colour, as ICAO Field 19
element ‘D/’.
spldcov b '–' "SPLDCOV" ('T' | 'F') Dinghies: indication if they are
covered, as ICAO Field 19 element
‘D/’.
T = True (=> ‘C’ in ICAO)
F = False, not covered.
spldnb b '–' "SPLDNB" 1{ DIGIT }2 Dinghies: number, as ICAO field
19 element ‘D/’.
sple b '–' "SPLE" timehhmm_elapsed Fuel endurance, as ICAO Field 19
element ‘E/’.
splj b '–' "SPLJ" lifejackets Life jackets, as ICAO Feld 19
element ‘J/’.
spln b '–' "SPLN" 1{ LIM_CHAR } Any other survival equipment and
useful remarks, as ICAO Field 19
element ‘N/’.
splp b '–' "SPLP" 1{DIGIT}3 Persons on board, as ICAO Field
19 element ‘P/’.
splr b '–' "SPLR" emergradio Emergency radio equipment, as
ICAO Field 19 element ‘R/’.
spls b '–' "SPLS" survivaleqpt Survival equipment, as ICAO Field
19 element ‘S/’.
src b '–' "SRC" ("RPL" | "FPL" |
"AFIL" | "MFS" | "FNM" | "AFP"
| "RQP" | "RQS" | NIL )Indication of the data source.
Contents depend on the TITLE
field.2000R2082 — EN — 15.06.2002 — 001.001 — 107
▼B
ADEXP
Primary
FieldKind Syntax Semantic
ssrcode b '–' "SSRCODE" ('A' ! 4{ '0' | '1' |
'2' | '3' | '4' | '5' | '6' | '7' }4 | "REQ"
)Either;
- SSR mode and code, as ICAO
field 7 elements b and c.
or
- the letters ‘REQ’ meaning that
the code is requested.
star b '–' "STAR" point ! 1{DIGIT}1 !
0{ALPHA}1Identification of a Standard Arrival
procedure.
starttime b '–' "STARTTIME" day !
timehhmmTime at which a period of time
begins.
stay c '–' "STAY" stayident time ((adid
adid) | (ptid ptid) (adid | ptid) |
(ptid adid)) [ptspeed] [ptrfl]Indication in the route of flight of a
period of ‘special activity’ when
the aircraft will ‘stay’ in the area
defined by the points and/or aero-
dromes given for the length of time
indicated, i.e. training, mid-air re-
fuelling, photographic mission etc.
NOTE: The order in which the
points and/or aerodromes are given
is significant
stayinfo c '–' "STAYINFO" stayident remark Information concerning the type of
activity (training, photographic
mission, etc.) to be performed
during a ‘stay’ period in the route
of a flight.
sts b '–' "STS" ( "PROTECTED" |
flightplanstatus | 1{LIM_CHAR} )Reason for special handling, as
ICAO field 18 STS/. Can be either
‘PROTECTED’ to indicate sensi-
tive handling or one of the recog-
nised labels, EMER, HOSP, etc. or
free text.
taxitime b '–' "TAXITIME" timehhmm The difference in time between the
'off blocks time' and the ‘take-off
time’. The times referred to may be
actual or estimated depending upon
the context.
tfcvol b '–' "TFCVOL" 1 {ALPHANUM}
15Identification of a ‘traffic volume’.
tfv c '–' "TFCVOL" tfvid refloc flowlst
flblockDescription of a traffic volume.
title b '–' "TITLE" titleid Message title.
ttleet b '–' "TTLEET" timehhmm_elapsed Total estimated elapsed time in
hours and minutes.
typz b '–' "TYPZ" text20 Type of aircraft when no ICAO
code exists.
unit c '–' "UNIT" unitid [addrinfo] Information concerning an ‘air
navigation unit’ i.e. an ATC unit,
an aircraft operator or flight plan
originator. Contains the identifica-
tion of the unit and optionally
address data.
valfrom b '–' "VALFROM" date First date from which the flight is
scheduled to operate (in year,
monthand day).
valfromk b '–' "VALFROMK" ( date |
datewldcrd )First date from which the flight is
scheduled to operate, used as data-
base key in a query, may be wild-
carded.
Must be a valid date or a combina-
tion of a valid date and wild-card
characters.2000R2082 — EN — 15.06.2002 — 001.001 — 108
▼B
ADEXP
Primary
FieldKind Syntax Semantic
valfromold b '–' "VALFROMOLD" date The ‘previous’‘valfrom’ date. Used
as a database key. Where the start
of validity date is to be amended,
the new value will be given in
‘VALFROM’.
validitydate b '–' "VALIDITYDATE" date Date of validity.
valuntil b '–' "VALUNTIL" date Last date from which the flight is
scheduled to operate (in year,
monthand day).
valuntilk b '–' "VALUNTILK" ( date |
datewldcrd )Last date from which the flight is
scheduled to operate, used as data-
base key in a Query, may be wild-
carded.
Must be a valid date or a combina-
tion of a valid date and wild-card
characters.
valuntilold b '–' "VALUNTILOLD" date The ‘previous’‘valuntil’ date. Used
as a database key. Where the end
of validity date is to be amended,
the new value will be given in
‘VALUNTIL’.
wktrc b '–' "WKTRC" waketurbcat Wake turbulence category.
A.4.ADEXPSubfields
Subfield Kind Syntax SemanticUsed in
Primary
FieldUsed in
Subfield
addrinfo c '-' "ADDRINFO"
networktype facAddress information unit
adid b '-' "ADID" icaoaero-
drome | 'ZZZZ'The designator of an
aerodrome. May
contain the ICAO
location indicator or
the characters
‘ZZZZ’ where no
location indicator has
been assigned.ad
position
stay
airroute c '-' "AIRROUTE"
[num] refatsrte
flblock valperiod
[remark]Description of all or
part of an ATS route
during a specified
period.lacdr
lcatsrte
airspace c '-' "AIRSPACE"
[num] airspdes
flblock valperiod
respunit [remark]Description of all or
part of an airspace
during a specified
period.latsa
lrar
lrca
airspdes b '-' "AIRSPDES" 3 {
ALPHANUM }12Designates an
airspace other than an
ATS route.entrydata airspace
brng b '-' "BRNG"
refbearingBearing of a point
from a navigation aid
in degrees magnetic.ref
condition b '-' "CONDITION" 2
{ALPHA} 20Type of condition or
restriction e.g. TOS,
FL restriction.ignore
crfl1 b '-' "CRFL1" fligh-
tlevelThe lower limit of
the flight level band
within which a cruise
climb is requested.crsclimb ptcrsclimb2000R2082 — EN — 15.06.2002 — 001.001 — 109
▼B
Subfield Kind Syntax SemanticUsed in
Primary
FieldUsed in
Subfield
crfl2 b '-' "CRFL2" (fligh-
tlevel | "PLUS")The upper limit of
the flight level band
within which a cruise
climb is requested.
‘PLUS’ where the
upper limit is
unknown.crsclimb ptcrsclimb
crmachb '-' "CRMACH"
machnumberThe Mach No. main-
tained during a cruise
climb.crsclimb ptcrsclimb
crspeed b '-' "CRSPEED" spd The speed to be
maintained during a
cruise climb.crsclimb ptcrsclimb
cto b '-' "CTO" timehhmm Calculated Time
Over a point.ad
positionpt
distnc b '-' "DISTNC" 1{
DIGIT }3Distance of a point
from a navigation aid
in nautical miles.
Must be 1 to 3 digits,
possibly withleading
zeroes.ref
efl b '-' "EFL" flightlevel Estimated flight
level.Reserved
for future
use.
endreg b '-' "ENDREG" day!ti-
mehhmmThe time at which an
ATFM Regulation
finishes.exccond
regulation
eqpt b '-' "EQPT" eqptcode !
/! eqptstatusEquipment capability
code followed by a
status value which
specifies the current
status of the
capabilityeqcst
eto b '-' "ETO" date !
timehhmm ! secondsEstimated Time Over
a point, in year,
month, day, hours,
minutes and seconds.ad
afildata
estdata
positionpt
exccond c '-' "EXCCOND"
regnum refloc
regreason startreg
endreg [flblock]
[rvrlimit] [remark]An ‘exceptional
condition’ raised in
the context of ATFM
e.g. fog at an aero-
drome.reglist
fac b '-' "FAC" 1{
LIM_CHAR }30Address data. addr
cassaddr
extaddr
origin
spladdraddrinfo
recvr
sender
fir b '-' "FIR" 7{ ALPHA
}7Designates a FIR or
UIR.lfir
fl b '-' " FL" flightlevel A generic flight level
field.
May be a ‘SFL’,
‘EFL’, ‘CFL’, ‘RFL’,
etc. depending on its
context.ad
afildata
cfl
entrydata
estdata
flband
positionflblock
pt2000R2082 — EN — 15.06.2002 — 001.001 — 110
▼M1
▼B
▼B
Subfield Kind Syntax SemanticUsed in
Primary
FieldUsed in
Subfield
flblock c '-' "FLBLOCK" fl fl A flight level block
defining an airspace
vertically, inclusive
of the flight levels
given. A block
defined as below or
above a flight levelshall be expressed
respectively as from
flight level 000 to the
specified level or as
from the specified
level to flight level
999.ad
rrteto
rrtefrom
tfvairspace
airroute
pt
regulation
exccond
flow c '-' "FLOW" frompos
[via1] [via2] topos
[via3] [via4] flowroleDescription of a
‘flow’ giving the
source area, option-
ally the routes or
points to be over-
flown from the
source area, the
destination area and
optionally the routes
or points to be over-
flown to the destina-
tion area.flowlst
flowlst c '-' "BEGIN"
"FLOWLST" 1
{flow} '-' "END"
"FLOWLST"List of traffic flows. rrteto
rrtefrom
tfv
flowrate b '-' "FLOWRATE"
3{LIM_CHAR}7The ‘rate’ which is
imposed by an
ATFM Regulation.rateperiod
flowrole b '-' "FLOWROLE"
'EX' | 'IE' | 'EM' | 'IN'An indication of the
‘role’ of a flow.
EX = excluded
IE = included
exempted
EM = exempted
IN = includedflow
from b '-' "FROM" day!ti-
mehhmmThe time from which
a period of time
begins.rvrperiod rateperiod
frompos b '-' "FROMPOS" 1
{ALPHANUM} 15A position from
which a route, a route
portion, a ‘path’ or a
flow begins.
May be a region, an
aerodrome or a
significant point.flow
geoid b '-' "GEOID" geoname Identifier of a
geographical point
made of ‘GEO’
followed by a
sequence number
(example: ‘GEO12’).geo
ifpdlong c '-' "BEGIN" "IFPD-
LONG" adexpmsg '-'
"END" "IFPDLONG"Complete information
concerning an indivi-
dual flight plan.ifpdlist
ifpdsum c '-' "IFPDSUM" arcid
adep ades eobt orgnSummary information
concerning an indivi-
dual flight plan. It
contains the arcid,
adep, ades, eobt and
orgn fields.ifpdslist2000R2082 — EN — 15.06.2002 — 001.001 — 111
▼B
Subfield Kind Syntax SemanticUsed in
Primary
FieldUsed in
Subfield
lastnum b '-' "LASTNUM"
3{DIGIT}3A three digit number
indicating the end of
a sequence.
lattd b '-' "LATTD" latitude-
long ! latitudesideLatitude in degrees,
minutes, seconds and
direction (Northor
South).eetlat
geo
longtd b '-' "LONGTD" longi-
tudelong ! longitude-
sideLongitude in degrees,
minutes, seconds and
direction (East or
West).eetlong
geo
network-
typeb '-' "NETWORK-
TYPE"
2{ALPHANUM}10Indication of the type
of network used for a
message exchange.origin addrinfo
num b '-' "NUM"
3{DIGIT}3A three digit number. extaddr
partairspace
airroute
penrate b '-' "PENRATE"
3{LIM_CHAR}7The ‘pending rate’,
used for ATFM
purposes.rateperiod
postproctxt b '-' "POSTPROCTXT"
adexpmsgContains a complete
ADEXP message
after it has been
processed.adexptxt
preproctxt b '-' "PREPROCTXT"
adexpmsgContains a complete
ADEXP message
prior to it being
processed i.e. as it
was received.adexptxt
pt c '-' "PT" ptid [(fl |
flblock)] [sfl] [eto]
[to] [cto] [sto] [ptrte]
[ptstay] [ptrfl]
[ptrulchg] [(ptspeed |
ptmach)] [ptcrsclimb]Point along a route.
=> Contains a point
identification and
optionally;
- a flight level or
flight level block,
- a supplementary
flight level,
- a time reference(s),
- a cruise climb
- a routing indication
- an indication of a
period of ‘special
activity’, i.e. that the
flight will ‘stay’ in
the area for a period
of time
Change in:
- RFL, flight rules,
speed/MachNo.rtepts
ptcrsclimb c '-' "PTCRSCLIMB"
(crspeed | crmach)
crfl1 crfl2Indication in the
route of a flight of a
cruiseclimb. Giving
the speed or mach
no. followed by the
two levels indicating
the flight level band
to be occupied during
the climb. The
second level may be
‘PLUS’ where the
upper level is
unknown.pt
ptfltrul b '-' "PTFLTRUL"
'VFR' | 'IFR'An indication of the
flight rules which are
applicable at the
point concerned.entrydata2000R2082 — EN — 15.06.2002 — 001.001 — 112
▼B
Subfield Kind Syntax SemanticUsed in
Primary
FieldUsed in
Subfield
ptid b '-' "PTID" point Point identification,
either coded desig-
nator or a name given
artificially (GEOxx,
REFxx or RENxx).afildata
cfl
coordata
crsclimb
entrydata
estdata
ignore
position
ref
rename
staypt
ptmachb '-' "PTMACH" mach -
numberMachnumber, in
hundredths of a unit,
associated to a point
on the route.ad
entrydatapt
ptmilrul b '-' "PTMILRUL"
'OAT' | 'GAT'An indication of the
‘military’ flight rules
which are applicable
at the point
concerned.entrydata
ptrfl b '-' "PTRFL" fligh-
tlevelRequested flight
level, associated to a
point on the route.ad
entrydatapt
ptrte b '-' "PTRTE"
2{LIM_CHAR}The route of flight
following the point
indicated. May be the
complete route to the
destination aero-
drome or simply the
routing element to
the next point.pt
ptrulchg b '-' "PTRULCHG"
rulechg | flightty-
pechg | rulechg
flighttypechgIndication of a
change in either the
‘flight rules’ (VFR/
IFR) or the ‘type of
flight’ (OAT/GAT)
or bothand asso-
ciated to a point on
the route.ad pt
ptspeed b '-' "PTSPEED" spd True airspeed (in
kilometres per hours
or knots) associated
to a point on the
route.ad
entrydatapt
ptstay b '-' "PTSTAY" stayi-
dentifier timehhmmIndication within the
filed route of flight of
a period of ‘special
activity’ when the
aircraft will ‘stay’ in
the area defined for
the length of timegiven, i.e. training,
mid-air re-fuelling,
etc.ad pt
rateperiod c '-' "RATEPERIOD"
from until flowrate
penrateA period of time
during which the
given flow rates are
applicable for an
ATFM Regulation.ratepdlst regcond
recvr b '-' "RECVR" fac The receiver of the
referenced message.msgref
refdata2000R2082 — EN — 15.06.2002 — 001.001 — 113
▼B
Subfield Kind Syntax SemanticUsed in
Primary
FieldUsed in
Subfield
refatsrte b '-' "REFATSRTE"
atsroute point
[country] point
[country]ATS route designator
and identifiers of first
and last points. The
points listed may be
ICAO identifiers or
artificially given
GEOxx, RENxx or
REFxx points. The
identifier of the
country within which
the point is located
may optionally be
included.
The end points must
be consistent withth e
route information.airroute
refid b '-' "REFID" refname Identifier of a refer-
ence point made of
‘REF’ followed by a
sequence number
(example: ‘REF02’).ref
refloc b '-' "REFLOC"
1{LIM_CHAR}15Reference location of
an ATFM Regula-
tion.rrteto
rrtefrom
tfvexccond
regulation
regcond c '-' "BEGIN"
"REGCOND" {rate-
period} '-' "END"
"REGCOND"List of time periods
and their respective
flow rates for a parti-
cular regulation.regulation
regdesc b '-' "REGDESC"
1{LIM_CHAR}Description of an
ATFM Regulation.regulation
regid b '-' "REGID" regulid Identification of a
flow management
‘Regulation’.regulation
reglist c '-' "BEGIN"
"REGLIST" regula-
tion [exccond] '-'
"END" "REGLIST"List of ‘Regulations’
for flow management
purposes.fmplist
regnum b '-' "REGNUM"
3{DIGIT}3 ! "/" !
2{DIGIT}2A reference number
for an ATFM ‘Regu-
lation’. Provides a
unique reference
followed by a
validity indication.exccond
regulation
regreason b '-' "REGREASON" 4
{ALPHA} 12The reason for an
ATFM Regulation.exccond
regulation
regulation c '-' "REGULATION"
regnum regid regdesc
refloc startreg endreg
[flblock] [remark]
[tfvid] [regreason]
[regcond]A ‘Regulation’
imposed for flow
management
purposes.reglist
remark b '-' "REMARK"
1{LIM_CHAR}A remark about the
item, the description
of which this field is
a part.stayinfo airspace
airroute
exccond
regulation
renid b '-' "RENID" renameid Identifier given to a
point which is
repeated in the route
description.rename
respunit b '-' "RESPUNIT"
12{ALPHA}12The responsible ATC
Unit.airspace
rfpdlong c '-' "BEGIN"
"RFPDLONG"
{adexpmsg} '-'
"END"
"RFPDLONG"Complete information
concerning a repeti-
tive flight plan.rfpdlist2000R2082 — EN — 15.06.2002 — 001.001 — 114
▼B
Subfield Kind Syntax SemanticUsed in
Primary
FieldUsed in
Subfield
rfpdsum c '-' "RFPDSUM" arcid
adep ades eobt orgn
days valfrom valuntilSummary of the
information
concerning a repeti-
tive flight plan. It
contains the arcid,
adep, ades, eobt,
orgn, days, valfrom
and valuntil fields.rfpdslist
rvrlimit b '-' "RVRLIMIT"
3{DIGIT}3Runway Visual
Range: operating
minima when special
meteorological condi-
tions exist. Expressed
in meters.rvrperiod exccond
sender b '-' "SENDER" fac The sender of the
referenced message.msgref
refdata
seqnum b '-' "SEQNUM"
3{DIGIT}3The serial number of
the message being
sent (a 3 digit
number unique to the
sender/receiver
combination).msgref
refdata
sfl b '-' SFL flightlevel !
('A'|'B')Supplementary flight
level. The flight level
at or above which or,
at or below which a
flight has been or
will be co-ordinated
to cross one point.
Consists of a flight
level number and a
crossing condition
(either ‘A’ if the
aircraft will cross the
point at or above the
level, or ‘B’ if the
aircraft will cross the
point at or below the
level).coordata
estdata
propflpt
startreg b '-' "STARTREG"
day!timehhmmThe time at which an
ATFM Regulation
becomes effective.exccond
regulation
statid b '-' "STATID" coorsta-
tusidentThe indicator of the
co-ordination state of
a flight.cstat
statreason b '-' "STATREASON"
coorstatusreasonThe reason for a
change in the co-
ordination status of a
flight.cstat
stayident b '-' "STAYIDENT"
stayidentifierIdentification of a
period of ‘special
activity’ or a ‘stay’
within the route of a
flight.stay
stayinfo
sto b '-' "STO" timehhmm
! secondsA generic time field
which may contain
the time for a point
or for an aerodrome.
The time may be an
estimated, calculated
or actual time
depending upon its
context.ad
coordata
positionpt2000R2082 — EN — 15.06.2002 — 001.001 — 115
▼B
Subfield Kind Syntax SemanticUsed in
Primary
FieldUsed in
Subfield
tfl b '-' "TFL" flightlevel Transfer Flight Level.
The flight level at
which a flight has
been or will be co-
ordinated to cross
one point (flight level
number), if in level
flight, or the cleared
level to which it is
proceeding if
climbing or
descending at the
boundary point.coordata
propfl
tfvid b '-' "TFVID"
1{ALPHANUM}15Identification of a
‘traffic volume’.rrteto
rrtefrom
tfvregulation
time b '-' "TIME" timehhmm A time indication.
May be an actual
time or a period of
time, depending upon
the message context.stay
to b '-' "TO" timehhmm ‘Time Over/Off’. A
generic time field
which may contain
the time for a point
or for an aerodrome.
The time may be an
estimated, calculated
or actual time
depending upon its
context.position
coordatapt
topos b '-' "TOPOS" 1
{ALPHANUM} 15A position to which a
route, a route portion,
a ‘path’ or a flow
extends.
May be a region, an
aerodrome or a
significant point.flow
unitid b '-' "UNITID" 2{
ALPHANUM}10Identification of an
air navigation unit
i.e. an ATC unit,
aircraft operator or
flight plan originator.unit
until b '-' "UNTIL" day!ti-
mehhmmThe time at which a
period of time ends.rvrperiod rateperiod
valperiod b '-' "VALPERIOD"
fulldatetime fulldate-
timeA validity period,
inclusive of the times
given.airroute
airspace
via1 b '-' "VIA1" 1
{ALPHANUM} 15A point, an ATS
route or an airspace
which is either on or
is required to be on
the route of flight.
When it is required to
indicate more than
one this field will
contain the first in
the sequence.flow
via2 b '-' "VIA2" 1
{ALPHANUM} 15A point, an ATS
route or an airspace
which is either on or
is required to be on
the route of flight.
When it is required to
indicate more than
one this field will
contain the second in
the sequence.flow2000R2082 — EN — 15.06.2002 — 001.001 — 116
▼B
Subfield Kind Syntax SemanticUsed in
Primary
FieldUsed in
Subfield
via3 b '-' "VIA3" 1
{ALPHANUM} 15A point, an ATS
route or an airspace
which is either on or
is required to be on
the route of flight.
When it is required to
indicate more than
one this field will
contain the third in
the sequence.flow
via4 b '-' "VIA4" 1
{ALPHANUM} 15A point, an ATS
route or an airspace
which is either on or
is required to be on
the route of flight.
When it is required to
indicate more than
one this field will
contain the fourth in
the sequence.flow2000R2082 — EN — 15.06.2002 — 001.001 — 117
▼B
ANNEX B (Normative)
CENTRALINDEXOFADEXPMESSAGETITLES
Title DefinitionIntroduced in
Section
ABI Advance Boundary Information Message E.3
ACK Acknowledge Message E.1ACP Acceptance Message E.5
ACT Activation Message E.3
AUP Airspace Use Plan Message E.4BFD Basic Flight Data Message E.5
CDN Co-ordination Message E.3
CFD Change to Flight Data Message E.5CNLCOND ATFM Exceptional Condition Cancellation Message E.2.3
CNLREG ATFM Regulation Cancellation Message E.2.3
COD SSR Code Assignment Message E.3COF Change of Frequency Message E.3CRAM Conditional Route Availability Message E.4
DES De-Suspension Message E.2.2
ERR Error Message E.2.2EXCOND ATFM Exceptional Condition Notification Message E.2.3
FCM Flight Confirmation Message E.2.2
FLS Flight Suspension Message E.2.2FSA First System Activation Message E.2.3
HOP Hand-Over Proposal Message E.3
IACH Individual ATC Modification Message E.1IAFP Individual ATC Flight Plan Proposal Message E.1
IAPL Individual ATC Flight Plan Message E.1
IARR Individual Arrival Message E.1ICHG Individual Modification Message E.1
ICNL Individual Cancellation Message E.1
IDEP Individual Departure Message E.1IDLA Individual Delay Message E.1IFPL Individual Flight Plan Message E.1
INF Information Message E.3
IRPL Individual Repetitive Flight Plan E.1IRQS Individual Request Supplementary Flight Plan E.1
ISPL Individual Supplementary Flight Plan E.1
LAM Logical Acknowledgement Message E.3, E.5LRM Logical Rejection Message E.3
MAC Message for Abrogation of Co-ordination E.3
MAN Manual Processing Pending Message E.1MAS Manual Assumption of Communications Message E.3
MODCOND ATFM Exceptional Condition Modification Message E.2.3
MODREG ATFM Regulation Modification Message E.2.3MRA Mandatory Route Activation Message E.2.3MRCNL Mandatory Route Cancellation Message E.2.3
MRMOD Mandatory Route Modification Message E.2.3
NEWREG New ATFM Regulation Notification Message E.2.32000R2082 — EN — 15.06.2002 — 001.001 — 118
▼B
Title DefinitionIntroduced in
Section
NTA No Traffic Accepted Message E.2.3
NTACNL No Traffic Accepted Cancellation Message E.2.3
NTAMOD No Traffic Accepted Modification Message E.2.3
OLRA Off-Load Route Activation Message E.2.3
OLRCNL Off-Load Route Cancellation Message E.2.3OLRMOD Off-Load Route Modification Message E.2.3
PAC Preliminary Activation Message E.3
RAP Referred Activate Proposal Message E.3
RCHG Repetitive Flight Plan Data Modification Message E.1
RCNL Repetitive Flight Plan Data Cancellation Message E.1
RDY Ready Message E.2.2
REJ Rejection Message E.1
REV Revision Message E.3
RJC Reject Co-ordination Message E.5
RJT Re-Routing Rejection Message E.2.2
ROF Request On Frequency Message E.3
RRP Re-Routing Proposal Message E.2.2
RRV Referred Revision Proposal Message E.3
SAM Slot Allocation Message E.2.2
SBY Stand-by Message E.3
SDM Supplementary Data Message E.3
SIP Slot Improvement Proposal Message E.2.2
SLC Slot Requirement Cancellation Message E.2.2
SMM Slot Missed Message E.2.2
SPA Slot Proposal Acceptance Message E.2.2
SRJ Slot Proposal Rejection Message E.2.2SRM Slot Revision Message E.2.2
SRR Slot Revision Request Message E.2.2
TIM Transfer Initiation Message E.3
UUP Updated Airspace Use Plan Message E.4
XAP Crossing Alternate Proposal Message E.5
XCM Crossing Cancellation Message E.5
XIN Crossing Intention Notification Message E.5
XRQ Crossing Request Message E.52000R2082 — EN — 15.06.2002 — 001.001 — 119
▼B
ANNEX C (Normative)
CENTRALINDEXOFRESERVEDMESSAGETITLES
C.1.Introduction
This annex contains a central index of reserved message titles which
have not yet been defined for use in ADEXP. Their inclusion in this
annex indicates that they have either been foreseen for future use or
that they are already in use but their usage is limited to within local
systems.
C.2.Purpose
The purpose of providing a listing of titles which have not yet been
formally adopted for use within this ADEXP Standard is to prevent, in
so far as possible, either the creation of redundancy whenever a new title
is required for a particular purpose or the creation of a title which is
already in use within a local system.
C.3.ReservedMessageTitles
Reserved Title Message Type Reserved by
ACTARR Activation Message for an Arrival FRANCE
ACTDEP Activation Message for a Departure FRANCE
ADMFPL ADMAR2000 Flight Plan Message GERMANY
ADMFPT ADMAR2000 Flight Plan Termination Message GERMANY
ADMFPU ADMAR2000 Flight Plan Update Message GERMANYANM ATFM Notification Message CFMU
ANSWERCT Response Message (Terminal Control System) FRANCE
ANSWM Response Message (ODS) FRANCE
ANSXFPLCT Response Message FRANCE
ATT Landing Message FRANCE
BEGINPROC Begin Processing Message FRANCE
BEGPROC Controller Working Position Initialisation Procedure
Message (ODS)FRANCE
BEGPROCCT Controller Working Position Initialisation Message
(Terminal Control System)FRANCE
CDA Departure Cleanance Message (ARINC 623) FRANCE
CDAFTX Departure Clearance (ARINC 620) FRANCE
CHGDEP Modification message for a Departure flight FRANCE
CLD Departure Clearance (ARINC 623) FRANCE
CLDFTX Departure Clearance (ARINC620) FRANCE
CNLARR Cancellation of an Arrival FRANCE
CNLCOND Cancellation of Exceptional Condition CFMU
CNLDEP Cancellation of a Departure FRANCE
CNLREG Cancellation of an ATFM Regulation CFMU
CONFEND End Message to a change of Operational Configuration FRANCE
CONFIDM Operational Configuration Message (ODS) FRANCE
CONFIDMCT Operational Configuration Message (Terminal Control
System)FRANCE
DEC Take-Off Message FRANCE
DOUBM Duplication Flight Plan Message FRANCE
DRT Modification of Destination Message FRANCE
EATARR Update of Estimated Arrival Time Message FRANCE
ENDPROC Controller Working Position Initialisation Procedure
Last Message (ODS)FRANCE2000R2082 — EN — 15.06.2002 — 001.001 — 120
▼B
Reserved Title Message Type Reserved by
ENDPROCCT Controller Working Position Initialisation Procedure
Last Message (Terminal Control System)FRANCE
EVLARR Pre-Activation Message for Arrival FRANCE
EVLDEP Pre-Activation Message for Departure FRANCE
EXCOND Activation of an Exceptional Condition CFMUFICM Flight Data Creation Message FRANCEFLXVIVO ‘Flexible Track’ Description Display Message FRANCE
FPCLOSE Flight Plan Data Close Message (ODS) FRANCE
FPCLOSECT Flight Plan Data Close Message (Terminal Control
System)FRANCE
FPCLOSED Duplication of Flight Plan Data Close Message (ODS) FRANCE
FPCRD Activation of Flight Plan Message (ODS) FRANCEFPCRDCT Activation of Flight Plan Message (Terminal Control
System)FRANCE
FPCRDD Duplication of Flight Plan Data Activation Message
(ODS)FRANCE
FPCRE Creation of Flight Plan Message (ODS) FRANCE
FPCRECT Creation of Flight Plan Message (Terminal Control
System)FRANCE
FPINI Pre-Activation of Flight Plan Message (ODS) FRANCE
FPINICT Pre-Activation of Flight Plan Message (Terminal
Control System)FRANCE
FPINID Duplication of Pre-Activation of Flight Plan Message FRANCE
FPNTF Pre-Activation of Flight Plan Message (ODS) FRANCE
FPNTFD Duplication of Pre-Activation of Flight Plan Message
(ODS)FRANCE
FPRDU Flight Data Information Message for a Non-Concerned
Sector (ODS)FRANCE
FPRDUCT Flight Data Information Message for a non-concerned
Sector (Terminal Control System)FRANCE
FSM Departure Clearance System Message (ARINC 623) FRANCE
FSMFTX Departure Clearance System Message (ARINC 620) FRANCEFSR Flight Suspension Request Message CFMU
IACHD Individual ATC Modification Message GERMANY
ICHGD Individual Modification Message GERMANYIDEPD Individual Departure Message GERMANYIDLAD Individual Delay Message GERMANYIFPDQ Individual Flight Plan Data Query Message CFMU
IFPDQR Individual Flight Plan Data Query Reply Message CFMU
IFPDSQ Individual Flight Plan Data Summary Query Message CFMUIFPDSQR Individual Flight Plan Data Summary Query Reply
MessageCFMU
IFPLD Individual Flight Plan GERMANY
INFOM Information Message FRANCEIRQS Individual Request for Supplementary Information
MessageCFMU
ISPL Individual Supplementary Flight Plan Message CFMU
LGR Flight Plan Message List FRANCELISTFP Flight Plan Message List (ODS) FRANCE
LISTFPCT Flight Plan Message List (Terminal Control System) FRANCE
LOGON Identification of Flight Plan Message FRANCEMAJVIVO Daily Movements Message FRANCE2000R2082 — EN — 15.06.2002 — 001.001 — 121
▼B
Reserved Title Message Type Reserved by
MCOM Co-ordination Message FRANCE
MODCOND Modification of an Exceptional Condition CFMU
MODREG Modification of an ATFM Regulation CFMU
MRA Activation of a Mandatory Route CFMU
MRCNL Cancellation of a Mandatory Route CFMU
MRMOD Modification of a Mandatory Route CFMUMRR Mandatory Re-Routing Message CFMU
MVTVIVO Movements Information Message FRANCE
NEWREG Activation of an ATFM Regulation CFMU
NTA Activation of a ‘Not Allowed’ Traffic Flow CFMU
NTACNL Cancellation of a ‘Not Allowed’ Traffic Flow CFMU
NTAMOD Modification of a ‘Not Allowed’ Traffic Flow CFMU
OCLM Oceanic Clearance Message FRANCE
OCLMD Duplication of Oceanic Clearance Message FRANCE
OLRA Activation of an Off-Load Route CFMUOLRCNL Cancellation of an Off-Load Route CFMU
OLRMOD Modification of an Off-Load Route CFMU
PAMAER Runway Application Message FRANCE
PAMARB ‘On-Stand ‘Confirmation Message FRANCE
PAMARRANN Cancellation of Parking Allocation for an Arrival FRANCE
PAMARRCRE Allocation of Parking Position for an Arrival FRANCE
PAMARRPST Modification of Parking Allocation for an Arrival FRANCEPAMDAPARB Parking Message for Arrival Aircraft FRANCE
PAMDAPCRE Allocation of a Parking Position FRANCE
PAMDEPANN Cancellation of Parking Allocation for a Departure FRANCE
PAMDEPCRE Parking Allocation for a Departure FRANCE
PAMDEPPST Modification of Parking Allocation for a Departure FRANCE
PAMDRB ‘Off-Stand' Confirmation Message FRANCE
QTAARR Return to Original ‘Created’ Status for an Arrival FRANCE
QTADEP Return to Original ‘Created’ Status for a Departure FRANCE
RCD Request Departure Clearance Message (AIRINC 623) FRANCERCDFTX Request Departure Clearance Message (AIRINC 620) FRANCE
REVARR Revision Message for an Arrival FRANCE
RFPDQ Repetitive Flight Plan Data Query Message CFMU
RFPDQR Repetitive Flight Plan Data Query Reply Message CFMU
RFPDSQ Repetitive Flight Plan Data Summary Query Message CFMU
RFPDSQR Repetitive Flight Plan Data Summary Query Reply
MessageCFMU
RIEM Flight Data Information Message FRANCE
RMG Missed ApproachMessage FRANCE
RRA Re-Routing Acceptance Message CFMU
RREC Repetitive Flight Plan Recovery Message CFMU
RRN Re-Routing Notification Message CFMU
RSUS Repetitive Flight Plan Suspension Message CFMU
RWYCHGCT Runway Configuration Message FRANCE
TRACT Request for Flight Plan Activation (ODS) FRANCE
TRACTCT Request for Flight Plan Activation (Terminal Control
System)FRANCE
TRCNL Request for Flight Plan Cancellation (ODS) FRANCE2000R2082 — EN — 15.06.2002 — 001.001 — 122
▼B
Reserved Title Message Type Reserved by
TRCNLCT Request for Flight Plan Cancellation (Terminal Control
System)FRANCE
TRCOR Request for Manual Correlation FRANCE
TRDECOR Request for Manual De-Correlation FRANCE
TRFIC Request for Creation of Flight Plan Data (ODS) FRANCE
TRFICCT Request for Creation of Flight Plan Data (Terminal
Control System)FRANCE
TRFLRQT Request Flight Level Message FRANCE
TRMOD Request for Flight Plan Modification (ODS) FRANCE
TRMODCT Request for Flight Plan Modification (Terminal Control
System)FRANCE
TRMODH Request for Time Modification FRANCE
TRMODHD Request for Time Modification for Delayed Flight FRANCE
TRMVT Co-ordination Request for Exiting Flight (ODS) FRANCE
TRMVTCT Co-ordination Request for Exiting Flight (Terminal
Control System)FRANCE
TRPOINT Specific Flight Data Request Message FRANCE
TRRET Request for Revision of Flight Plan to ‘Created’ Status
(ODS)FRANCE
TRRETCT Request for Revision of Flight Plan to ‘Created’ Status
(Terminal Control System)FRANCE
TRRIP Request for Display of Flight Data Information (ODS) FRANCE
TRRIPCT Request for Display of Flight Data Information (Term-
inal Control System)FRANCE
TRRQT Flight Plan Request (ODS) FRANCE
TRRQTCT Flight Plan Request (Terminal Control System) FRANCETRSHRQT Request for SHOOT Action FRANCE
TRSTAR Controller Working Position Initialisation Request
(ODS)FRANCE
TRSTARCT Controller Working Position Initialisation Request
(Terminal Control System)FRANCE
TRTRP Transfer Position Message FRANCE
UNKFP Suppression of Flight Plan Message (ODS) FRANCE
UNKFPCT Suppression of Flight Plan Message (Terminal Control
System)FRANCE2000R2082 — EN — 15.06.2002 — 001.001 — 123
▼B
ANNEX D (Normative)
CENTRALINDEXOFRESERVEDFIELDS
D.1.Introduction
This annex contains a central index of reserved fields, Primary, Subfield
and Auxiliary Terms, which have not yet been defined for use in
ADEXP. Their inclusion in this annex indicates that they have either
been foreseen for future use or that they are already in use but their
usage is limited to within local systems.
D.2.Purpose
The purpose of providing a listing of fields which have not yet been
formally adopted for use within this ADEXP Standard is to prevent, in
so far as possible, either the creation of redundancy whenever a new
field is required for a particular purpose or the creation of a keyword
which is already in use within a local system.
D.3.ReservedAuxiliaryTerms
Reserved
Auxiliary
TermSyntax SemanticUsed in
Primary FieldUsed in
SubfieldUsed in
auxilary
centreidentifi-
cation1{ALPHA}4 Centre identifica-
tion.ctsrc
ripsrcctripectdest
contextfdpsid 'opepal' | 'opesos' |
'evalpal' | 'tsto-
pepal' |'tstopesos'Mode of opera-
tion of an FDPS
application.
(Operational,
Test, etc.)ctxtfdps
contextphi-
diasid'ope'|'eva-
l1'|'EVAL2'
|('TST'!1{DIGI-
T}1)Specific to the
French systemctxtpos
coordpoints ('E'!('S'!('X'!('O'|-
NIL)
|NIL)|NIL)
|'S'!('X'!('O'|NIL)|-
NIL)
|'X'!('O'|NIL)|NIL)
|'O'Entry point for
the control posi-
tion (‘E’).
Exit point for the
control position
(‘S’),
XFL point (X),
OCL point (O)coorpt
eoidentifica-
tion1{ALPHANU-
M}6Identification of
an ‘operational
entity’eosrc eoid
fl3 'F' ! 3{DIGIT}3 Flightlevel
expressed in
hundred of feet.autfl1
autfl2
curfl
flightten-
dancy'U'|'D'|'S' Projected
tendency of the
flight profile.
U for UPD for DownS for Stableetrfl
trfl
fpcentrestate 'CREE'|'EVEIL'|
'EVLCRT'|'AC-
TIVE'|
'TERM'Flight plan status
within an ACC.fpctst2000R2082 — EN — 15.06.2002 — 001.001 — 124
▼B
Reserved
Auxiliary
TermSyntax SemanticUsed in
Primary FieldUsed in
SubfieldUsed in
auxilary
latitude 4{ DIGIT }4 A latitude
expressed as four
digitsReserved for
future use
latitudeshort 2{ DIGIT }2 A latitude
expressed as two
digits.Reserved for
future use
longitude 5{ DIGIT }5 A longitude
expressed as five
digits.Reserved for
future use
longitude-
short3{ DIGIT }3 A longitude
expressed as three
digits.Reserved for
future use
pointcautra 1{ALPHANU-
M}5Specific to the
French systemfirstpid pointid
ptcid
ptid
positioniden-
tification1{ALPHANU-
M}6Working position
actual or logicalposid
qfuid (‘0'|'1'|'2'|'3')!1{
DIGIT }1!(‘L'|'C'
|'R'|NIL)QFU for a
runway.
L = LeftC = Centre
R = Rightqfu qful
secidentifica-
tion1{ALPHANU-
M}2Sector identifica-
tion.secdest
secsrcsecid
sendin-
greason'INI'|'NTF'|'ACT'|
'MOD'|'MVT'|'MVTSEC'|'-
COORAUTO'|'-
MODHD'|
'CNL'|'RADAR'|'-
INIT'|
'RQT'|'TRF'|'RIP'|
'CONF'|'END'|'Q-
TA'|
'ESLSA'|'OCM'|
'DMER'|'TRFSE-
C'|
'COLLAT'|'SHR-
QT'|
'POINT'|'FLRQT'|
'PKG'Reason for
sending flight
plan data.event
starreason 'TOTAL' The type of initi-
alisation of a
position with
flight plan datastreason
temperature ("N" | "P") !
2{DIGIT}2Temperature
expressed in
degrees Celsius
(00-99) withth e
indication of the
sign (Negative or
Positive)temp
updatereason ('T'!('R'|NIL)|'R') Type of update
last made to a
flight data.O-
perator Transac-
tion (‘T’). Radar
update (‘R’).udpt2000R2082 — EN — 15.06.2002 — 001.001 — 125
▼B
D.4.ReservedPrimaryFields
Reserved
Primary
FieldKind Syntax Semantic
aabd b '-' "AABD" date Actual arrival on-block date
aabt b '-' "AABT" timehhmm Actual arrival on-block time
acnf c '-' "ACNF" ad rcnf [qfulist] Runway configuration
aobd b '-' "AOBD" date Actual off-block date
aobt b '-' "AOBT" timehhmm Actual off-block time
apptyp b '-' "APPTYP" 1{ALPHANUM}1 Approach type of the flight (1 digit,
values: 1, 2, 3)
arcidao b '-' "ARCIDAO"
1{ALPHANUM}11Aircraft identification used by
aircraft operators
arcidatc b '-' "ARCIDATC" 8{DIGIT}8 Locally unique aircraft identifica-
tion number used by ATC
atis b '-' "ATIS" 1{ALPHA}1 Automatic Terminal Information
Service indicator.
autfl1 b '-' "AUTFL1" fl3 Authorised flight level 1
autfl2 b '-' "AUTFL2" fl3 Authorised flight level 2
automsg c '-' "AUTOMSG" (sendt ptcid flb
pflt)|'NO'Provides the data which is to be
transmitted in a co-ordination
message: sending time, exit point,
flight level over exit point, planed
flight level and information
concerning whether the level is in
accordance withagreements.
avail b '-' "AVAIL" 'YES'|'NO' Indication as to whether a sector is
permitted or not to modify a flight
plan data.
bkrow b '-' "BKROW" 1{DIGIT}2 The position of a point of reference
in a list of route points.
bkt b '-' "BKT" datetime Time over the reference point for a
transaction.
codetr b '-' "CODETR" 'YES'|'NO' Indication whether the ssrcode
should be transmitted (or not) to
the pilot by the control position
confid b '-' "CONFID" 1{DIGIT}5 Operational configuration identifi-
cation (sectors|positions).
confl c '-' "BEGIN" "CONFL"
1{eopos}
'-' "END" "CONFL"List of sectors/positions associa-
tions for an en-route centre.
crspd b '-' "CRSPD" 1{DIGIT}4 Cruise speed in knots
ctripe b '-' "CTRIPE" centreidentification Name of the receiving centre for a
transaction
ctrow b '-' "CTROW" 1{DIGIT}1 The position of a centre in a list of
centres.
ctsrc b '-' "CTSRC" centreidentification Identification of sending centre
ctxtct b '-' "CTXTCT" 'OPE' | 'TST' Mode of operation of Terminal
Control System.
ctxtfdps b '-' "CTXTFDPS" contextfdpsid Mode of operation of an FPDS
ctxtpos b '-' "CTXTPOS" contextphidiasid Mode of operation for ODS
curfl b '-' "CURFL" fl3 Current flight levelcurpos c '-' "CURPOS" ptid | (lattd longtd) Current position
curpost b '-' "CURPOST" datetime Date and time at current position
curptt b '-' "CURPTT" datetime Date and time of overflight of
current point
curptx b '-' "CURPTX" 1{DIGIT}2 Numbered position of current point
in a list of route points.2000R2082 — EN — 15.06.2002 — 001.001 — 126
▼B
Reserved
Primary
FieldKind Syntax Semantic
dcatcid b '-' "DCATCID" icaoaerodrome Aerodrome responsible for depar-
ture clearance when given by FDPS
to the aircraft via datalink.
dcbtxt b '-' "DCBTXT" 'PDC REQUEST
RECEIVED'|'PDC REQUEST
UNKNOWN' | 'PDC REQUEST
IGNORED' | 'ACK'Basic text for ARINC 623 depar-
ture clearance messages. ‘ACK’ for
acknowledgement message.
dcbtxtftx b '-' "DCBTXTFTX" 'PDC
REQUEST RECEIVED'|'PDC
REQUEST UNKNOWN' | 'PDC
REQUEST IGNORED' | 'ACK'Basic text for ARINC 620 depar-
ture clearance messages. ‘ACK’ for
acknowledgement message.
dccar b '-' "DCCAR" 'DMER'|'COL-
LAT'|'NO'Departure clearance status for a
flight.
dcid b '-' "DCID" 1{DIGIT}3 System number for departure clear-
ance.
dcmtyp b '-' "DCMTYP" 1{ALPHA}3 Departure clearance message type.dcref b '-' "DCREF" 1{ALPHANUM}5 Context reference for a departure
clearance.
dcrmk b '-' "DCRMK" 1{LIM_CHAR}80 Remark for a departure clearance.
dcs1txt b '-' "DCS1TXT"
'REQUEST BEING PROCESSED'
| 'REQUEST ALREADY
RECEIVED' | 'FLIGHT PLAN
NOT HELD' | 'ERROR IN
MESSAGE'.Supplementary text for the Depar-
ture Clearance System Message
(ARINC 623).
dcs2txt b '-' "DCS2TXT" 'STANDBY'|
'REVERT TO VOICE PROCE-
DURE'Second Supplementary text for the
Departure Clearance message
(ARINC 623).
dcdt b '-' "DCDT" datetime ! seconds Day, hours, minutes, seconds for
the departure clearance.
delcode b '-' “DELCODE”
1{ALPHANUM}20Reason for a delay
dfdpsid b '-' "DFDPSID datetime ! seconds Data of Flight Data Processing
System Identification
doubid b '-' "DOUBID" 1{ALPHANUM}2 Identification of a ‘duplicate’
entity.
ecurptt b '-' "ECURPTT" datetime Estimated time of overflight of
current point
eda b '-' "EDA" date Estimated date of arrivalelastptt b '-' "ELASTPTT" datetime Estimated time of overflight of last
point of the route
endhldt b '-' "ENDHLDT" datetime Holding pattern ending time.
entrnb b '-' "ENTRNB" '1' | '2' | '3' | '4' | '5' |
'6' | '7' | '8' | '9' | '10' | '11' | '12' |
'13' | '14' | '15'Number of occurrences of a flight
plan within a centre.
entryt b '-' "ENTRYT" datetime Entry time for the position.
enxtptt b '-' "ENXTPTT" datetime Estimated time of overflight of
next point (not given if current
point is the last point).
eobdt b '-' "EOBDT" datetime Date and estimated off-block time.eosrc b '-' "EOSRC" eoidentification Operational ‘entity’ identificationespfl b '-' "ESPFL" flightlevel Supplementary transfer flight level
for the preceding control position.
eta b '-' "ETA" timehhmm Estimated time of arrival.etrfl b '-' "ETRFL" flightlevel|flightten-
dancyEntry Flight Level or flight profile
tendency.
event b '-' "EVENT" sendingreason Triggering event for FDPS.firstpid b '-' "FIRSTPID" pointcautra Specific to the French system2000R2082 — EN — 15.06.2002 — 001.001 — 127
▼B
Reserved
Primary
FieldKind Syntax Semantic
flbk b '-' "FLBK" flightlevel Flight level of the last transaction
reference point for an activated
flight, or modified level for refer-
ence point for a transaction.
fpbaseid b '-' "FPBASEID" datetime!seconds Flight Plan Data Base Identification
fpctst b '-' "FPCTST" fpcentrestate Flight Plan Status within a Centre.
fpkwl c '-' "BEGIN" "FPKWL"
1{fpident}300 '-' "END"
"FPKWL"List of the known but not yet
transferred flight plans for a posi-
tion.
fplcat b '-' "FPLCAT" "T" | "E" | "S" | "I" Flight category:
T = overflight
E = inbound
S = outbound
I = internal.
fplist c '-' "BEGIN" "FPLIST"
1{fpsum}50
'-' "END" "FPLIST"List of Flight plan information for
a callsign.
fpllist c '-' BEGIN "FPLLIST" fpllgr
'-' "END"List of flight plans fields
fplnb b '-' "FPLNB" 1{DIGIT}1 Number of flight plans
from 0 to 5
fplstat b '-' "FPLSTAT" "T" | "C" Flight status:
T = terminated
C = active.
fprmk b '-' "FPRMK" 1{LIM_CHAR}8 Initial flight plan remarks.
fpsrc b '-' "FPSRC" ("FICTOT"|"FI-
CEVL"|"FICMOD"|FICABI"|"FI-
CACT"“|FIC-
PAC"|'FPL"|"RPL"|"NKW")Flight Plan source.
fpunkl c '-' "BEGIN" "FPUNKL"
1{fpident}300 '-' "END"
"FPUNKL"List of ‘unknown’ flight plans.
freetxt c '-' "BEGIN" "FREETXT" 1{txt}3
'-' "FREETXT"Free text message.
ftxid b '-' "FLXID" 1{ALPHANUM}14 Flex-track identity.
ftxname b '-' "FLXNAME"
1{ALPHANUM}4Flex-track name.
ftxnum b '-' "FLXNUM" 1{DIGIT}2 Flex-track generation number.
grspd b '-' "GRSPD" 1{DIGIT}4 Ground speed in knots.
hldbkrw b -' "HLDBKRW" 1{DIGIT}2 Number position of a reference
point for an holding pattern in a list
of route points.
icing b '-' "ICING" 1{ALPHA}8 Icing.
‘TRACE’ or ‘LIGHT’ or
‘MODERATE’ or ‘SEVERE’.
indstip b '-' "INDSTIP" 'STIP' Specific to the French system
initid b '-' "INITID" 1{DIGIT}1 Initialisation number.
interid b '-' "INTERID"
'V'!2{DIGIT}2!'R'!2{DIGIT}2FDPS/ODS or FDPS/Terminal
system interface identifier.
lalglist c '-' BEGIN "LALGLIST" lalg
'-' END "LALGLIST"List of latitude and longitude of
points in the route.
lang b '-' "LANG" '?' Conversational language indicator.
‘?’ = the language is not usual in
the company
lastradt b '-' "LASTRADT" datetime Last update time given by radar
information.
lights b '-' "LIGHTS" 1{ALPHANUM}1 Lights code.2000R2082 — EN — 15.06.2002 — 001.001 — 128
▼B
Reserved
Primary
FieldKind Syntax Semantic
maint b '-' "MAINT" 'YES'|'NO' Indication whether the data infor-
mation for a control position is
continually maintained or not.
modea b '-' "MODEA"
'A'!4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'}4SSR Mode A .information
modec b '-' "MODEC" flightlevel SSR Mode C information
msgbody b '-' "MSGBODY" 1{CHAR-
ACTER}Contains a character string which is
identical to the body of the equiva-
lent and existing non-ADEXP
message.
msgct b '-' "MSGCT" datetime ! seconds Time stamp of the message in the
format: Day, hours, minutes,
seconds.
nat b '-' "NAT" 1{ALPHA}1 Identification of a NorthAtlantic
track .
nfc b '-' "NFC" 3{DIGIT}3 ! '.' !
3{DIGIT}3Next frequency contact.
nxtfir b '-' "NXTFIR" icaoaerodrome Next FIR to be contacted
nxtpos c '-' "NXTPOS" ptid | (lattd longtd) Next position.
nxtpost b '-' "NXTPOST" datetime Time over the next position.
oclfl b '-' "OCLFL" flightlevel Oceanic Clearance Limit (OCL)
flight level.
oprfl b '-' "OPRFL" flightlevel Request Flight Level modified by
an operator.
oprmk c '-' "BEGIN" "OPRMK"
1{rmktxt}2 '-' "END" "OPRMK"List of Operator remarks.
oprmkct b '-' "OPRMKCT"
1{LIM_CHAR}20Operator remarks.
oriented b '-' "ORIENTED" 'YES'|'NO' Oriented flight or not.
pfl b '-' "PFL" flightlevel Planned Flight Level (PFL).
pistcoord c '-' "PISTCOORD" xpist ypist
vxpist vypistRadar track coordinates and speed
vector coordinates.
pistid b '-' "PISTID" 1{DIGIT}4 Radar track identification.
pkarr c '-' "PKARR" [pka] [pkc] pkatt Parking position for an arriving
flight
pkdep b '-' "PKDEP" 1{ALPHANUM}3 Parking position for a departing
flight.
plnid b '-' "PLNID" 4{DIGIT}4 Flight Plan identificationplnold b '-' "PLNOLD" 4{DIGIT}4 Old Fight Plan identification
posst b '-' "POSST" 'MAE'|'MPS'|'-
MAS'|'MPSA'|'MPSLATE'|'NO'Co-ordination movement State for
the position:
Accepted Movement for the Entry
(MAE) or for the exit (MAS) or
Proposed Movement for the Exit
(MPS) or Proposed Movement Exit
Alarm (MPSA) or position not yet
movement co-ordinated (NO).
ptnb b '-' "PTNB" 1{DIGIT}2 Number of points in the route.
qfu b '-' "QFU" qfuid Runway in use (QFU) identifica-
tion.
quebec b '-' "QUEBEC" 'YES'|'NO' Quebec flight or not.
radioid b '-' "RADIOID"
1{ALPHANUM}20Radio identification.
reqid b '-' "REQID" 1{DIGIT}5 Number of a request.
reqtyp b '-' "REQTYP" ('STPV' | 'STIP') Flight plan request type.2000R2082 — EN — 15.06.2002 — 001.001 — 129
▼B
Reserved
Primary
FieldKind Syntax Semantic
ripel c '-' "BEGIN" "RIPEL"
1{destid}12
'-' "END" "RIPEL"List of entities to receive flight
plan data
ripsrc b '-' "RIPSRC" centreidentification Identification of the centre respon-
sible for initiating the transmission
of flight plan data.
rstid b '-' "RSTID" '1'|'2'|'3'|'4'|'5' IFPS transaction number in a flight
plan request.
rte c '-' "BEGIN" "RTE"
1{ptc}22
'-' "END" "RTE"List of the CAUTRA points of
undirected route.
rtetr c '-' "BEGIN" "RTETR" 1{ptpro}22
'-' "END" "RTETR"List of route points for certain
transactions.
scnf c '-' "BEGIN" "SCNF"
1{acnf}3
'-' "END" "SCNF"List of aerodrome configurations.
secdest b '-' "SECDEST" secidentification Receiving sector identifier.
seclist c '-' "BEGIN" "SECLIST" 1{sec}30
'-' "END" "SECLIST"Global List of sectors.
seclistct c '-' "BEGIN" "SECLISTCT"
1{secct}30
'-' "END" "SECLISTCT"Global List of the sectors.
secsrc b '-' "SECSRC" secidentification Originating sector identifier.
spfl b '-' "SPFL" flightlevel Supplementary Flight Level.
ssrcodes c '-' "SSRCODES" (code1 code2) |
code | codep)Transmitted SSR code.
stamp b '-' "STAMP" 3{DIGIT}3 !
timehhmmStamp identification.
streason b '-' "STREASON" starreason Reason for an initialisation request
issued from a working position.
strid b '-' "STRID" 1{DIGIT} RDPS identifier.
temp b '-' "TEMP" temperature Temperature
terminal b '-' "TERMINAL"
1{ALPHANUM}2Name of the terminal.
translist c '-' "BEGIN" "TRANSLIST"
1 {transid}
'-' "END" "TRANSLIST"List of possible transactions for the
control position and for the flight
plan specified.
trfl b '-' "TRFL" flightlevel | flightten-
dancyTransfer Flight Level or tendency
information about a flight profile
turb b '-' "TURB" 1{ALPHA}8 Turbulence = LIGHT or
MODERATE or SEVERE
validend b '-' "VALIDEND" datetime End time of display.
validst b '-' "VALIDST" datetime Start time of display.
visi b '-' "VISI" 1{ALPHANUM}20 Visibility.
wddir b '-' "WDDIR" 1{DIGIT}3 Wind direction expressed in
degrees from 0 to 359.
wdspd b '-' "WDSPD" 1{DIGIT}3 Wind speed expressed in knots.
xfl b '-' "XFL" flightlevel Exit Flight Level (XFL).
xfpltxt b '-' "XFPLTXT" 1{CHARACTER |
ASCII_SUP} 768Response message to a flight plan
request.2000R2082 — EN — 15.06.2002 — 001.001 — 130
▼B
D.5.ReservedSubfields
Reserved
SubfieldsKind Syntax SemanticUsed in
Primary
FieldUsed in
Subfield
act C '-' "BEGIN" "ACT"
1{fieldid}20
'-' "END" "ACT"Flight plan fields
which are modifiable
at the time of activa-
tion of a flight.transid
bkchg C '-' "BKCHG" flimp
flmin flmaxImplicit FL,
minimum FL and
maximum FL for the
reference point for a
transaction. The FL is
generic, may be RFL,
PFL, etc.fieldid
bktchg c '-' "BKTCHG"
delta1 delta2The value (+/-) by
which a time modifi-
cation for a point is
permitted.fieldid
cflchg c '-' "CFLCHG" flimp
flmin flmaxImplicit Cleared
Flight Level (CFL),
minimum CFL and
maximum CFL for
the reference point
for a transaction.fieldid
code b '-' "CODE"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4SSR mode and allo-
cated code.ssrcodes
codep b '-' "CODEP"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-7'}4SSR mode and code
which is available for
use.ssrcodes
code1 b '-' "CODE1"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4SSR mode and code
previously allocated.ssrcodes
code2 b '-' "CODE2"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4SSR mode and code
which has been
reserved for use and
is therefore not avail-
able.ssrcodes
coorpt b '-' "COORPT" coor-
dpointsCharacteristic of co-
ordination point:
Initial, Exit, OCL,
XFLptc
ctdest b '-' "CTDEST"
centreidentificationReceiving centre
(ACC)destid
delta1 b '-' "DELTA1"
('0'|'1'|'2'|'3'|'4'|'5')!DI-
GITTime interval for the
calculation of a
minimum time.bktchg
delta2 b '-' "DELTA2"
('0'|'1'|'2'|'3'|'4'|'5')!DI-
GITTime interval for the
calculation of a
maximum time.bktchg
deltsp1 b '-' "DELTSP1"
1{DIGIT}4Speed interval for the
calculation of a
minimum speed.spdchg
deltsp2 b '-' "DELTSP2"
1{DIGIT}4Speed interval for the
calculation of a
maximum speed.spdchg
destid c '-' "DESTID" ctdest
secripATC Centre and list
of sectors to whom
flight plan data is to
be sentripel2000R2082 — EN — 15.06.2002 — 001.001 — 131
▼B
Reserved
SubfieldsKind Syntax SemanticUsed in
Primary
FieldUsed in
Subfield
edto b '-' "EDTO" dateti-
me|"WT"Estimated time over a
point in year, month,
day, hours, minutes
or indicator ‘point
without time’‘WT’.ptc
ptpro
eoid b '-' "EOID" eoidentifi-
cationOperational ‘entity’
name.eolist
eolist c '-' "BEGIN"
"EOLIST" 1{eoid}
'-' "END" "EOLIST"List of operational
entities associated to
a control position.eopos
eopos c '-' "EOPOS" posid
[eolist]Control position
name and list of
operational entities
associated to this
position.confl
fieldid c '-' "FIELDID"
'TYPA'|'ADES'|'R-
TE'|'ADEP'|'CODE'|'-
LANG'|'BK'|spdchg|r-
flchg|cflchg|pflchg|tf-
lchg|sflchg|xflchg|bk-
chg|bktchg|'QFU'|'PK-
DEP'|'SID'|'NFC'|'A-
TIS'|'DCRM-
K'|'OPRMK'Identification of
modifiable fields for
a transaction.act
mod
mvt
ret
modh
flb b '-' "FLB" flightlevel Calculated flightlevel
at exit co-ordination
point which may be
transmitted in the
automatic co-ordina-
tion message to the
next centre.automsg
flimp b '-' "FLIMP" fligh-
tlevelImplicit flight level. bkchg
rflchg
pflchg
cflchg
tflchg
sflchg
flmax b '-' "FLMAX" fligh-
tlevelMaximum flight
level.bkchg
rflchg
pflchg
cflchg
tflchg
sflchg
xflchg
flmin b '-' "FLMIN" fligh-
tlevelMinimum flight
level.bkchg
rflchg
pflchg
cflchg
tflchg
sflchg
xflchg
fpident c '-' "FPIDENT" plnid
stamp ctrow entrnbFlight plan identifica-
tion in a message.fpunkl
fpkwl
fpllgr c '-' "FPLLGR" arci-
datc arcid adep ades
eobd eobt‘Summary’ flight
plan data.fpllist
fpsum c '-' "FPSUM" plnid
eobdt adep ades
ctrow firstpidFlight plan identifica-
tion.fplist
lalg c '-' "LALG" lattd
longtdLatitude and longi-
tude of eachpoint in
the routelaglist
mod c '-' "BEGIN" "MOD"
1{fieldid}20
'-' "END" "MOD"List of fields which
are modifiable after
activation.transid2000R2082 — EN — 15.06.2002 — 001.001 — 132
▼B
Reserved
SubfieldsKind Syntax SemanticUsed in
Primary
FieldUsed in
Subfield
modhc '-' "BEGIN"
"MODH" 1{fieldid}2
'-' "END" "MODH"List of fields which
are modifiable in a
time update transac-
tion after activation.transid
mvt c '-' "BEGIN" "MVT"
1{fieldid}2
'-' "END" "MVT"List of fields which
are modifiable in a
manually triggered
co-ordination
between sectorstransid
pflchg c '-' "PFLCHG" flimp
flmin flmaxImplicit, minimum
and maximum level
for modification of
PFL.fieldid
pflt b '-' "PFLT" flightle-
vel!('NA'|NIL)Planned flightlevel
which will be trans-mitted in the auto-
matic co-ordination
message to the next
centre. Plus an indi-
cation whether the
level is in accordance
withth e applicable
operational agree-
ments.
NA = Not according
agreement.automsg
pka b '-' "PKA"
1{ALPHANUM}3Reserved parking
position, not yet allo-
cated.pkarr
pkatt b '-' "PKATT" 'YES' |
'NO'Indicator that the
aircraft is waiting for
a parking position.pkarr
pkc b '-' "PKC"
1{ALPHANUM}3Allocated parking
position.pkarr
pointid b '-' "POINTID" point-
cautraSpecific to the
French system.ptpro
posid b '-' "POSID" positioni-
dentificationControl position
name.eopos
ptc c '-' "PTC" ptcid edto
[fl] [view] [udpt]
[traj] [coorpt] [ref]Characteristics of a
route point.rte
ptcid b '-' "PTICD" pointcau-
tra|geonameSpecific to the
French system.automsg ptc
ptpro c '-' "PTPRO" pointid
[edto] [fl] [traj]Description of
proposed route
points.rtetr
qful c '-' "QFUL" qfuid Valid QFU for a
given runway on an
aerodrome.qfulist
qfulist c '-' BEGIN"
"QFULIST"
1{qful}8
'-' "END"
"QFULIST"List of valid QFUs
for an aerodrome.acnf
rcnf b '-' "RCNF"
1{ALPHA}5General take-off and
landing direction for
an aerodrome. (East,
West, etc.)acnf
ref c '-' "REF" (refi-
d|ref1id)Characteristics of a
reference point for a
transaction.ptc2000R2082 — EN — 15.06.2002 — 001.001 — 133
▼B
Reserved
SubfieldsKind Syntax SemanticUsed in
Primary
FieldUsed in
Subfield
refid b '-' "REFID"
'REF'!2{DIGIT}2Identification of a
possible reference
point for a transac-
tion.ref
ref1id b '-' "REF1ID"
'REF'!2{DIGIT}2Identification of the
most probable refer-
ence point for a
transaction.ref
regulid1 b '-' "REGULID1"
1{ALPHANUM}5Regulation informa-
tion specific to the
Frenchsystems.regul
regulid2 b '-' "REGULID2"
1{ALPHANUM}5Regulation informa-
tion specific to the
Frenchsystems.regul
regult b '-' "REGULT" date-
timeRegulation informa-
tion specific to the
Frenchsystems.regul
ret c '-' "BEGIN" "RET"
1{fieldid}1
'-' "END" "RET"List of fields which
are modifiable in a
transaction to return
the flight plan data to
it's previous status.transid
rflchg c '-' "RFLCHG" flimp
flmin flmaxImplicit, minimum
and maximum level
for the modification
of the RFL.fieldid
rmktxt b '-' "RMKTXT"
1{LIM_CHAR}20Text of a controller
remark.oprmk
sec c '-' "SEC" secid
[seccar]Identification and
characteristics of
ACC sectors to
whom flight plan
data is to be sent.seclist secrip
seccar b '-' "SECCAR"
('F'!('L'!('M'!('D'|NI-
L)|NIL)|NIL)|NIL)
|('L'! ('M'!('D'|NIL)|-
NIL)|NIL)
|('M'!('D'|NIL)|NIL)
|'D'Characteristic of an
ACC sector:
-First sector (‘F’)
-Last sector (‘L’)
-Accepted for Entry
(‘M’)
-source sector for
‘duplication’ (‘D’)sec
seccarct b '-' "SECCARCT"
('F'!('L'!('M'!('V'/
NIL)/NIL)/NIL)/NIL)
/('L'! ('M'!('V'/NIL)/
NIL)/NIL)
/('M'!('V'/NIL)/NIL)
/'V'Characteristic of a
Terminal Area sector:
-First sector (‘F’)
-Last sector (‘L’)
-Accepted for
Entry(‘M’)secct
secct c '-' "SECCT" secid
[seccarct]Identification and
characteristics of
Terminal Area
sectors.seclistct
secid b '-' "SECID" seciden-
tificationSector identification. secct
sec
secrip c '-' "BEGIN"
"SECRIP" 1{sec}40
'-' "END" "SECRIP"List of receiving
entities (sectors or
departure/arrival
control entities) to
whom flight plan
data is to be sent.destid
sendt b '-' "SENDT" datetime Time for sending co-
ordination message.automsg2000R2082 — EN — 15.06.2002 — 001.001 — 134
▼B
Reserved
SubfieldsKind Syntax SemanticUsed in
Primary
FieldUsed in
Subfield
sflchg c '-' "SFLCHG" flimp
flmin flmaxImplicit, minimum
and maximum level
for modification of
Supplementary Flight
Level (SFL)fieldid
spdchg c '-' "SPDCHG" deltsp1
deltsp2Lower an upper
speed intervals for
the modification of
the flight plan speed
during a transaction.fieldid
tflchg c '-' "TFLCHG" flimp
flmin flmaxImplicit, minimum
and maximum level
for modification of
Transfer Flight Level
(TFL).fieldid
traj b '-' "TRAJ"
('S'!'M')|'S'|'M'|'T'|
('S'!'M'!'A')|('S'!'A')|
('M'!'A')|'A'Characteristics of a
point in relation to
the trajectory of a
flight:
S = Splitpoint
M = Mergepoint
T = Abeam point
A = STAR pointptc
ptpro
transid b '-' " TRANSID" (act |
mod | mvt | ret |
modh| 'CNL' | 'RIP')
| 'NO'Identification of
possible transaction
for the control posi-
tion for this flight
plan or ‘NO’ indi-
cator meaning trans-
action not possible.translist
txt b '-' "TXT"
1{LIM_CHAR}80Free text. freetxt
udpt b '-' "UDPT" updater-
easonLast update brought
by operator and/or by
radar information.ptc
view b '-' "VIEW"
('V'|'VNX')Indication of ‘view-
able’ nature of a
point.
V = viewable
VNX = not viewable
(artificial point)ptc
vxpist b '-' "VXPIST" ALPHA
1{DIGIT}5
ALPHA:= P|N
P:= Positif
N:= NegativeX coordinate of the
speed vector of a
radar position.pistcoord
vypist b '-' "VYPIST" ALPHA
1{DIGIT}5
ALPHA:= P|N
P:= Positif
N:= NegativeY coordinate of the
speed vector of a
radar position.pistcoord
xflchg c '-' "XFLCHG" flmin
flmaxMinimum and
maximum level for
modification of an
Exit Flight Level
(XFL).fieldid
xpist b '-' "XPIST" 'P'|'N'
1{DIGIT}6
P:= Positif
N:= NegativeX coordinate of a
radar position.pistcoord
ypist b '-' "YPIST" 'P'|'N'
1{DIGIT}6
ALPHA:= P/N
P:= Positif
N:= NegativeY coordinate of a
radar position.pistcoord2000R2082 — EN — 15.06.2002 — 001.001 — 135
▼B
ANNEX E (Informative)
INTRODUCTIONOFMESSAGEGROUPS
INTRODUCTION
This Annex provides an introduction to the different groups or categories of
messages which can be exchanged in ADEXP. A complete listing of all ADEXP
message titles is given in Annex B.
NOTE For the exact conditions, rules of application and field usage, particu-
larly the use of optional fields, reference should be made to the
relevant documentation (e.g. Interface Specification document) of the
systems concerned.
E.1.FlightPlanMessages
E.1.1.Introduction
Messages within this category are exchanged primarily between the
AO, IFPS and the relevant ATS Units.
E.1.2.Definition of Message Titles
Message titles within this category are:ACK, IACH, IAFP, IAPL, IARR, ICHG, ICNL, IDEP, IDLA, IFPL,
IRPL, IRQP, MAN, RCHG, RCNL, REJ.
All defining material for these messages is held within Document
Ref. 3
E.1.3.Primary Fields Composition
Detailed definition of message content, data insertion rules and the
use of compulsory and optional fields can be found in Document
Ref. 3.
Example
Flight Plan Message-TITLE IFPL
-BEGIN ADDR -FAC CFMUTACT -FAC EGZYTTFO -FAC
EGZYTTTE -FAC EGTTZGZP
-FAC EGKKZPZI -FAC LFFBTEST -FAC LESCYFPX -FAC
LPPCIFPS -FAC LPPTYWYA
-FAC LPAMYWYA -FAC LPAMYCYX -FAC LPPTIFPS-END ADDR
-ADEP EGKK -ADES LPPT -ARCID AZX752 -ARCTYP BA11 -
CEQPT S
-EOBD 980305 -EOBT 1130 -FILTIM 041530 -IFPLID AA00463686
-ORGNID AZXRPLO
-SEQPT C -SRC RPL -WKTRC M -TTLEET 0230 -RFL F330 -
SPEED N0400 -FLTRUL I
-FLTTYP S-ROUTE N0400F330 SAM UR41 ORTAC UR1 QPR UR107 AVS
UG41 FTM
-BEGIN RTEPTS-PT -PTID EGKK -FL F000 -ETO 980305113000-PT -PTID SAM -FL F196 -ETO 980305114012
-PT -PTID ASPEN -FL F288 -ETO 980305114658
-PT -PTID ORTAC -FL F311 -ETO 980305114959-PT -PTID GUR -FL F330 -ETO 980305115617
-PT -PTID AKEMI -FL F330 -ETO 980305120118
-PT -PTID LARSI -FL F330 -ETO 980305120626-PT -PTID QPR -FL F330 -ETO 980305121236-PT -PTID ERWAN -FL F330 -ETO 9803051231522000R2082 — EN — 15.06.2002 — 001.001 — 136
▼B
-PT -PTID LOTEE -FL F330 -ETO 980305124401
-PT -PTID AVS -FL F330 -ETO 980305125357-PT -PTID KORET -FL F330 -ETO 980305130137-PT -PTID BARKO -FL F330 -ETO 980305130734-PT -PTID CANAR -FL F330 -ETO 980305131544-PT -PTID VIS -FL F330 -ETO 980305132220
-PT -PTID FTM -FL F234 -ETO 980305133230
-PT -PTID LPPT -FL F000 -ETO 980305134529-END RTEPTS-ATSRT UR41 SAM ORTAC -ATSRT UR1 ORTAC QPR -ATSRT
UR107 QPR AVS
-ATSRT UG41 AVS FTM
E.2.AirTrafficFlowManagementMessages
E.2.1.Introduction
Messages within this category are exchanged primarily between the
TACT system of the Eurocontrol CFMU, Aircraft Operators and
ATS Units.
E.2.2.Computer Assisted Slot Allocation Messages (CASA)
Message titles within this category are:
DES, ERR, FCM, FLS, RDY, RJT, RRP, SAM, SIP, SLC, SMM,
SPA, SRJ, SRM, SRR.
E.2.2.1. Definition of Message Titles
All defining material for these messages is held within Document
Ref. 5
E.2.2.2. Primary Fields Composition
Detailed definition of message content, data insertion rules and the
use of compulsory and optional fields can be found in Document
Ref. 5.
Example
-TITLE SAM -ARCID AMC101 -ADEP EGLL -ADES LMML -
EOBD 980324 -EOBT 0945
-CTOT 010 -REGUL UZZU11 -TAXITIME 0020
E.2.3.Information Messages
Message titles within this category are:FSA
E.2.3.1. Definition of Message Titles
Defining material for this message will be available in Document
Ref. 5
E.2.3.2. Primary Fields Composition
Definition of message content, data insertion rules and the use of
compulsory and optional fields will be found in Document Ref. 5.
Example
First System Activation Message-TITLE FSA -ARCID EIN636 -ADEP EIDW -ADES EBBR -POSI-
TION -PTID LIFFY -TO 1646
E.3.ATCCo-ordinationMessages
E.3.1.Introduction
Co-ordination Messages are used to automate operational co-ordina-
tion and the exchange of information between ATC units. The2000R2082 — EN — 15.06.2002 — 001.001 — 137
▼B
messages ensure the timely delivery of operational information
related to co-ordination through standardised data extraction and
transmission capabilities.
E.3.2.Definition of Message Titles
Message titles within this category are:ABI, ACT, CDN, COD, COF, HOP, INF, LAM, LRM, MAC, MAS,
PAC, RAP, REV, ROF, RRV, SBY, SDM, TIM.
All defining material for these messages is held within Document
Ref. 6
E.3.3.Primary Fields Composition
All defining material for these messages is held within Document
Ref. 6.
Examples
Hand-Over Proposal Message-TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM253
-CFL F190 -ASPEED N0420 -RATE D25 -DCT BEN STN
Activate Message
-TITLE ACT -REFDATA -SENDER -FAC E -RECVR -FAC L -
SEQNUM 005 -ARCID AMM253
-SSRCODE A7041 -ADEP LMML -COORDATA -PTID BNE -TO
1226 -TFL F350
-ADES EGBB -ARCTYP B757 -ROUTE N0480F390 UB4 BNE UB4
BPK UB3 HON
E.4.AirspaceManagementMessages
E.4.1.Introduction
Messages used in the of co-ordination of airspace management. These
messages cover the management of the environment in which the
traffic is moving: the permanent and conditional routes, temporary
segregated areas, danger and prohibited areas, etc.
E.4.2.Definition of Message Titles
Message titles within this category are:AUP, CRAM, UUP.All defining material for these messages is held within Document
Ref.7.
E.4.3.Primary Fields Composition
All defining material for these messages is held within Document
Ref. 7.
Example:
Conditional Route Availability Message-TITLE CRAM -PART -NUM 001 -LASTNUM 010
-FILTIME 281353 -MESVALPERIOD 199803290600
1998703300600
-BEGIN LACDR
-AIRROUTE -NUM 001 -REFATSRTE UA23 ELVAR LP BEJ LP-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803290600
199803300600
-AIRROUTE -NUM 002 -REFATSRTE UA44 ESP LP BEJ LP
-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803290600
199803290730
-AIRROUTE -NUM 003 -REFATSRTE UA44 ESP LP BEJ LP
-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803291830
1998033006002000R2082 — EN — 15.06.2002 — 001.001 — 138
▼B
-AIRROUTE -NUM 004 -REFATSRTE A44 ESP LP BEJ LP
-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803290600
199803290730
-AIRROUTE -NUM 005 -REFATSRTE A44 ESP LP BEJ LP
-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803291830
199803300600
-AIRROUTE -NUM 006 -REFATSRTE A44 BEJ LP ROSAL LP
-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803292030
199803300530
-AIRROUTE -NUM 007 -REFATSRTE UA57 FFM ED DIK EL-FLBLOCK -FL F250 -FL F450 -VALPERIOD 199803290700
199803291330
-END LACDR
E.5.Civil/Military Co-ordinationMessages
E.5.1.Introduction
Messages used in the co-ordination of flight data and airspace
crossing requests between civil and military ATS units.
E.5.2.Definition of Message Titles
Message titles within this category are:
ACP, BFD, CFD, LAM, RJC, XAP, XCM, XIN, XRQ.All defining material for these messages is held within Document
Ref. 7.
E.5.3.Primary Fields Composition
All defining material for these messages is held within Document
Ref. 7.
Example:
Crossing Clearance Request Message-TITLE XRQ -REFDATA -SENDER -FAC EBSZZXZQ -RECVR -
FAC EBBUZXZQ
-SEQNUM 012 -ARCID DEUCE22 -SSRCODE A1240 -ARCTYP
F111 -SECTOR SOUTH
-BEGIN RTEPTS
-PT -PTID GEO01 -TO 1630 -FL F250-PT -PTID GEO02 -TO 1631 -FL250
-END RTEPTS
-GEO -GEOID GEO01 -LATTD 500000N -LONGTD 0051000E-GEO -GEOID GEO02 -LATTD 500000N -LONGTD 0051500E
Acceptance Message
-TITLE ACP -REFDATA -SENDER -FAC EBBUZXZQ -RECVR -
FAC EBSZZXZQ
-SEQNUM 014 -MSGREF -SENDER -FAC EBSZZXZQ -RECVR -
FAC EBBUZXZQ
-SEQNUM 0122000R2082 — EN — 15.06.2002 — 001.001 — 139
▼B
ANNEX F (Informative)
EXAMPLESOFADEXPMESSAGEFORMAT
The following examples are provided as a demonstration of the ADEXP format,
not as an example of message content. The message used is an IFPL and
although correct at the time of publication, accuracy of field composition etc.
is not guaranteed.
The EXAMPLE 1 below has been presented in a manner which makes it easily
readable. This has been achieved through the use of carriage returns, line feeds,
indents etc. Such a layout however does not form part of the ADEXP format
rules.
Presentation of a message is therefore at the discretion of the receiving system.
The examples provided as EXAMPLE 2 and EXAMPLE 3 are both valid repre-
sentations of the same message as that in EXAMPLE 1.
EXAMPLE 1
-TITLE IFPL
-BEGIN ADDR
-FAC CFMUTACT
-FAC LFFFSTIP
-FAC EDFFZRZL-FAC EDZZZQZA-FAC EDUUZQZA-FAC LOVVZQZX-FAC LHBPZEZX
-FAC LYBAZQZX
-FAC LWSSZQZX-FAC LGTSZAZX-END ADDR
-ADEP EDDF
-ADES LGTS
-ARCID DLH3728
-ARCTYP B73A
-CEQPT SDMRY-EOBD 980517
-EOBT 0715
-FILTIM 170421-IFPLID AA05966101
-ORGNID DLHAOCC
-ORIGIN -NETWORKTYPE SITA -FAC FRAOXLH
-REG DABHM
-SEL KMGJ-SRC FPL
-FLTTYP S
-WKTRC M
-TTLEET 0210
-RFL F330-SPEED N0417
-FLTRUL I
-SEQPT C-ROUTE N0417F330 NDG3D NDG UW70 MUN UB103 UNKEN UT23
BABIT UR26
SAVIN UG18 BUI UB1 TALAS2000R2082 — EN — 15.06.2002 — 001.001 — 140
▼B
-ALTRNT1 LBSF
-EETFIR EDUU 0014-EETFIR LOVV 0035
-EETFIR LJLA 0054
-EETFIR LHCC 0057
-EETFIR LYBA 0113
-EETFIR LWSS 0148-EETFIR LGGG 0159
-BEGIN RTEPTS
-PT -PTID EDDF -FL F000 -ETO 980317071500
-PT -PTID NDG -FL F311 -ETO 9803173414-PT -PTID RIDER -FL F327 -ETO 980317073726
-PT -PTID MAH -FL F330 -ETO 980317074130
-PT -PTID MUN -FL F330 -ETO 980317074449-PT -PTID CHIEM -FL F330 -ETO 980317074754
-PT -PTID UNKEN -FL F330 -ETO 980317075109
-PT -PTID GRZ -FL F330 -ETO 9803170080830
-PT -PTID DIMLO -FL F330 -ETO 980317081443
-PT -PTID BABIT -FL F330 -ETO 980317083107-PT -PTID SAVIN -FL F330 -ETO 980317083613
-PT -PTID UPIVO -FL F330 -ETO 980317084054
-PT -PTID KLENA -FL F330 -ETO 980317084204
-PT -PTID VAL -FL F330 -ETO 980317084629
-PT -PTID KAVOR -FL F330 -ETO 980317085329-PT -PTID BUI -FL F330 -ETO 980317090135
-PT -PTID SARAX -FL F330 -ETO 980317090650
-PT -PTID PEP -FL F312 -ETO 980317091414-PT -PTID TALAS -FL F241 -ETO 980317091746
-PT -PTID LGTS -FL F000 -ETO 980317093138
-END RTEPTS
-SID NDG3D
-ATSRT UW70 NDG MUN
-ATSRT UB103 MUN UNKEN-ATSRT UT23 UNKEN BABIT
-ATSRT UR26 BABIT SAVIN
-ATSRT UG18 SAVIN BUI
-ATSRT UB1 BUI TALAS
EXAMPLE 2
-TITLE IFPL -BEGIN ADDR -FAC CFMUTACT -FAC LFFFSTIP -FAC
EDFFZRZL -FAC EDZZZQZA -FAC EDUUZQZA -FAC LOVVZQZX -FAC
LHBPZEZX -FAC LYBAZQZX -FAC LWSSZQZX -FAC LGTSZAZX -END
ADDR -ADEP EDDF -ADES LGTS -ARCID DLH3728 -ARCTYP B73A -
CEQPT SDMR -EOBD 980517 -EOBT 0715 -FILTIM 170421 -IFPLID
AA05966101 -ORGNID DLHAOCC -ORIGIN -NETWORKTYPE SITA -FAC
FRAOXLH -REG DABHM -SEL KMGJ -SRC FPL -FLTTYP S -WKTRC M
-TTLEET 0210 -RFL F330 -SPEED N0417 -FLTRUL I -SEQPT C -ROUTE
N0417F330 NDG3D NDG UW70 MUN UB103 UNKEN UT23 BABIT UR26
SAVIN UG18 BUI UB1 TALAS -ALTRNT1 LBSF -EETFIR EDUU 0014 -
EETFIR LOVV 0035 -EETFIR LJLA 0054 -EETFIR LHCC 0057 -EETFIR
LYBA 0113 -EETFIR LWSS 0148 -EETFIR LGGG 0159 -BEGIN RTEPTS -
PT -PTID EDDF -FL F000 -ETO 980317071500 -PT -PTID NDG -FL F311 -
ETO 9803173414 -PT -PTID RIDER -FL F327 -ETO 980317073726 -PT -PTID
MAH -FL F330 -ETO 980317074130 -PT -PTID MUN -FL F330 -ETO
980317074449 -PT -PTID CHIEM -FL F330 -ETO 980317074754 -PT -PTID
UNKEN -FL F330 -ETO 980317075109 -PT -PTID GRZ -FL F330 -ETO
9803170080830 -PT -PTID DIMLO -FL F330 -ETO 980317081443 -PT -PTID
BABIT -FL F330 -ETO 980317083107 -PT -PTID SAVIN -FL F330 -ETO
980317083613 -PT -PTID UPIVO -FL F330 -ETO 980317084054 -PT -PTID
KLENA -FL F330 -ETO 980317084204 -PT -PTID VAL -FL F330 -ETO
980317084629 -PT -PTID KAVOR -FL F330 -ETO 980317085329 -PT -PTID
BUI -FL F330 -ETO 980317090135 -PT -PTID SARAX -FL F330 -ETO2000R2082 — EN — 15.06.2002 — 001.001 — 141
▼B
980317090650 -PT -PTID PEP -FL F312 -ETO 980317091414 -PT -PTID
TALAS -FL F241 -ETO 980317091746 -PT -PTID LGTS -FL F000 -ETO
980317093138 -END RTEPTS -SID NDG3D -ATSRT UW70 NDG MUN -
ATSRT UB103 MUN UNKEN -ATSRT UT23 UNKEN BABIT -ATSRT
UR26 BABIT SAVIN -ATSRT UG18 SAVIN BUI -ATSRT UB1 BUI TALAS
EXAMPLE 3
-TITLE IFPL-BEGIN ADDR-FAC CFMUTACT-FAC LFFFSTIPFAC
EDFFZRZL-FAC EDZZZQZA-FAC EDUUZQZA-FAC LOVVZQZX-FAC
LHBPZEZX-FAC LYBAZQZX-FAC LWSSZQZX-FAC LGTSZAZX-END
ADDR-ADEP EDDF-ADES LGTS-ARCID DLH3728-ARCTYP B73A-CEQPT
SDMR-EOBD 980517-EOBT 0715-FILTIM 170421-IFPLID AA05986101-
ORGNID DLHAOCC-ORIGIN-NETWORKTYPE SITA-FAC FRAOXLH-REG
DABHM-SEL KMGJ-SRC FPL-FLTTYP S-WKTRC M-TTLEET 0210-RFL
F330-SPEED N0417-FLTRUL I-SEQPT C-ROUTE N0417F330 NDG3D NDG
UW70 MUN UB103 UNKEN UT23 BABIT UR26 SAVIN UG18 BUI UB1
TALAS-ALTRNT1 LBSF-EETFIR EDUU 0014-EETFIR LOVV 0035-EETFIR
LJLA 0054-EETFIR LHCC 0057-EETFIR LYBA 0113-EETFIR LWSS 0148-
EETFIR LGGG 0159-BEGIN RTEPTS-PT-PTID EDDF-FL F000-ETO
980317071500-PT-PTID NDG-FL F311-ETO 9803173414-PT-PTID RIDER-FL
F327-ETO 980317073726-PT-PTID MAH-FL F330-ETO 980317074130-PT
PTID MUN-FL F330-ETO 980317074449-PT-PTID CHIEM-FL F330-ETO
980317074754-PT-PTID UNKENFL F330-ETO 980317075109-PT-PTID GRZ-
FL F330-ETO 9803170080830-PT-PTID DIMLO-FL F330-ETO 980317081443-
PT-PTID BABIT-FL F330-ETO 980317083107-PT-PTID SAVIN-FL F330-ETO
98031708361-PT-PTID UPIVO-FL F330-ETO 980317084054-PT-PTID
KLENA-FL F330-ETO 980317084204-PT-PTID VAL-FL F330-ETO
980317084629-PT-PTID KAVOR-FL F330-ETO 980317085329-PT-PTID BUI-
FL F330-ETO 980317090135-PT-PTID SARAX-FL F330-ETO 980317090650-
PT-PTID PEP-FL F312-ETO 980317091414-PT-PTID TALAS-FL F241-ETO
980317091746-PT-PTID LGTS-FL F000-ETO 980317093138-END RTEPTS-
SID NDG3D-ATSRT UW70 NDG MUN-ATSRT UB103 MUN UNKEN-
ATSRT UT23 UNKEN BABIT-ATSRT UR26 BABIT SAVIN-ATSRT UG18
SAVIN BUI-ATSRT UB1 BUI TALAS2000R2082 — EN — 15.06.2002 — 001.001 — 142
▼B
ANNEX G (Informative)
FUTUREDEVELOPMENTS
G.1.Introduction
This annex is intended to provide an indication of the proposed future
development of ADEXP and the reasons and objectives behind the devel-
opment.
G.2.Objectives
One of the most important objectives during the development of ADEXP
was the requirement to develop a format which would enable a receiving
system to successfully ‘ignore’ or ‘skip’ an unknown or unrecognised
field without necessarily having to invalidate the message being
processed. This implementation can allow the addition of a new field
within a message without the requirement to have all receiving systems
modified in advance followed by a very carefully co-ordinated ‘switch-
over’. The enormous flexibility that this can provide is one of the advan-
tages of the ADEXP format.
This objective is achieved in the current standard through the use of pre-
defined primary and sub-fields, introduced by unique keywords. A
lexical analyser or parser which does not ‘recognise’ a keyword is
required to ignore all the text up to the next known Primary Field, which
is not within a List Field. Recovery is therefore achieved at the level of
primary fields.
Current and future development in the definition of new messages indi-
cate that in certain areas a greater level of complexity is required, where
third and even fourth level nesting of fields is needed. (The Conditional
Route Allocation Message (CRAM) is a current example of this require-
ment). ADEXP today provides the ability to build a message with any
level of nesting. However, the ability to recover from an unrecognised
subfield, which occurs at perhaps the third or fourth level of nesting,
without the chance of misinterpretation of data or of having to invalidate
the message, does not exist. The proposed modifications required of the
ADEXP format are designed to ensure that a lexical analyser or parser is
able, at all times, to determine where it is within the structure of a
message or individual field and in so doing, to enable recovery to take
place at any level of nesting without the danger of misinterpretation of
data.
G.3.Proposal
In order to achieve the objective of recovery at any level within a
message it is necessary for the lexical analyser to be able to determine
the end, as well as the start, of a field. The current format allows only
the determination of the start of a field using the ‘-’ character.
It will be proposed, in a future release of ADEXP, to introduce the use of
parenthesis to indicate respectively the start and end of a field. The
current use of the ‘-’ character to introduce the start of field would be
replaced by the ‘(’ character. The end of field, which is not explicitly
indicated today, would be indicated in future by the ‘)’ character. Thefollowing examples are intended to demonstrate the principle.
Examples
Current Format Proposed Format
Example of Basic Field: -RFL F330 (RFL F330)Example of Compound Field: -CRSCLIMB
-PTID DUB
-CRSPEED M084-CRFL1 F370-CRFL2 F430(CRSCLIMB
(PTID DUB)
(CRSPEED M084)(CRFL1 F370)(CRFL2 F430))2000R2082 — EN — 15.06.2002 — 001.001 — 143
▼B
ANNEX III
FLIGHT DATA EXCHANGE — INTERFACE CONTROL DOCUMENT
(FDE-ICD),EDITION1.0
(Eurocontroldocumentreference COM.ET1.ST12-STD)2000R2082 — EN — 15.06.2002 — 001.001 — 144
▼B
TABLEOFCONTENTS
COPYRIGHT NOTICE
FOREWORD1. INTRODUCTION2. SCOPE3. REFERENCES
3.1. Introduction3.2. References
4. DEFINITIONS, SYMBOLS AND ABBREVIATIONS
4.1. Definitions4.2. Symbols and Abbreviations4.3. Notations
5. TECHNICAL OVERVIEW
5.1. Protocol Stack5.2. Structure of the Profile5.3. Relation to Previous Versions of the Specification
6. PROFILE REQUIREMENTS
6.1. Conformance Requirements6.2. Upper-layer Requirements6.3. Lower-layer Requirements6.3.1. Transport Layer Requirements6.3.2. Network Layer Requirements6.3.3. Datalink Layer Requirements6.3.4. Physical Layer Requirements
7. TEST METHODSANNEX A (NORMATIVE) MESSAGE TRANSFER PROTOCOL
A.1. IntroductionA.2. Service ImplementedA.3. Service AssumedA.4. Protocol SpecificationA.4.1. IntroductionA.4.2. Types of DataA.4.3. Association EstablishmentA.4.4. Data TransferA.4.5. Orderly Association ReleaseA.4.6. Association Re-establishmentA.4.7. Association IntegrityA.4.8. Disorderly Association ReleaseA.4.9. Recovery From Failure2000R2082 — EN — 15.06.2002 — 001.001 — 145
▼B
A.4.10. Message Formats
A.5. Protocol State Transition TablesA.5.1. Introduction
A.5.2. State Definitions
A.5.3. Possible EventsA.5.4. TimersA.5.5. State Transition TableA.5.6. State Transition Diagram
ANNEX B (NORMATIVE) MESSAGE HEADER PROTOCOL
B.1. IntroductionB.2. Service ImplementedB.3. Service AssumedB.4. Protocol SpecificationB.4.1. Connection EstablishmentB.4.2. Avoidance of Redundant Network ConnectionsB.4.3. Connection ReleaseB.4.4. Data Transfer
ANNEX C (NORMATIVE) NETWORK PROTOCOL
C.1. IntroductionC.2. Service ProvidedC.3. Service AssumedC.4. NSAP AddressingC.4.1. IntroductionC.4.2. NSAP Address StructureC.4.3. Assignment of ATC Unit Identifiers and SelectorsC.5. Protocol SpecificationC.5.1. OverviewC.5.2. Address EncodingC.5.3. Encoding of the User Data Field
C.5.4. Treatment of Addresses in INCOMING CALL Packets
C.5.5. Data Transfer
ANNEX D (NORMATIVE) PROFILE-SPECIFIC PICS PROFORMAS
D.1. Introduction
D.2. Instructions for Completing the PICS Proformas
D.2.1. General Structure of the PICS ProformasD.2.2. Additional InformationD.2.3. Exception InformationD.2.4. Conditional ItemsD.3. PICS Proforma for the Message Transfer ProtocolD.3.1. Abbreviations and Special Symbols2000R2082 — EN — 15.06.2002 — 001.001 — 146
▼B
D.3.2. Identification
D.3.3. Protocol ImplementationD.4. PICS Proforma for the Message Header ProtocolD.4.1. Abbreviations and Special SymbolsD.4.2. IdentificationD.4.3. Protocol ImplementationD.5. PICS Proforma for the Network Protocol
D.5.1. Abbreviations and Special Symbols
D.5.2. IdentificationD.5.3. Protocol Implementation
ANNEX E (NORMATIVE) PROFILE REQUIREMENTS LIST
E.1. IntroductionE.2. The Role of the PRL and PICS Proformas
E.3. Notation
E.4. Instructions for Completing the PICS ProformasE.5. ReferencesE.6. Conformance StatementE.6.1. Conformance OverviewE.6.2. Dynamic Conformance Requirements4E.7. Upper Layer RequirementsE.8. Lower Layer RequirementsE.8.1. Transport Layer Requirements
E.8.2. Network Layer Requirements
E.8.3. Datalink Layer RequirementsE.8.4. Physical Layer Requirements10
ANNEX F (INFORMATIVE) CONFORMANCE TESTING METHODOLOGY
F.1. IntroductionF.2. Purpose and ScopeF.3. Bibliography
F.4. Development Methods and Practices
F.5. TestsF.5.1. IntroductionF.5.2. Testing of the Lower Layers (Layers 1 — 3)F.5.3. Testing of the Application LayerF.5.4. CertificationF.5.5. Notification
ANNEX G (INFORMATIVE) ASSIGNMENT OF ATC UNIT IDENTIFIERS
ANNEX H (INFORMATIVE) GUIDANCE ON RELIABILITY, AVAILABILITY AND SECURITY
H.1. Introduction2000R2082 — EN — 15.06.2002 — 001.001 — 147
▼B
H.2. Purpose and Scope
H.3. BibliographyH.4. Leased Line Implementations
H.4.1. Reliability
H.4.2. AvailabilityH.4.3. SecurityH.4.4. Configuration ExampleH.5. Network ImplementationH.5.1. ReliabilityH.5.2. AvailabilityH.5.3. SecurityH.6. General Guidance for Leased Line and Network ImplementationsH.6.1. ReliabilityH.6.2. AvailabilityH.6.3. Systems ManagementH.6.4. Configuration Example2000R2082 — EN — 15.06.2002 — 001.001 — 148
▼B
COPYRIGHTNOTICE
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.2000R2082 — EN — 15.06.2002 — 001.001 — 149
▼B
FOREWORD
1. ResponsibleBody
This Standard Document has been prepared by and is maintained
by the Flight Plan related Data Exchange (FPDE) Task Force of
the European Organisation for the Safety of Air Navigation
(Eurocontrol).
2. EATCHIPWorkProgramme Document
This Standard relates to the EATCHIP Work Programme Docu-
ment (EWPD), Communications Domain, Executive Task 01,
Specialist Task 12
3. ApprovaloftheStandard
3.1. This Standard is adopted in accordance with the procedures
outlined in the Directives for Eurocontrol Standardisation Ref.
000-2-93.
3.2. This Standard becomes effective upon adoption by the Permanent
Commission of Eurocontrol and supersedes Eurocontrol Standard
for On-Line Data Interchange (OLDI), Edition 1, Part 3: TECH-
NICAL REQUIREMENTS (Short Term Interface Control
Document) Ref. 001-3-92.
4. TechnicalCorrigendaandAmendments
This Standard is kept under review to ascertain required amend-
ments or technical corrigenda. The procedure for the maintenance
of this Standard is laid down in Annex H of the Directives for the
Uniform Drafting and Presentation of Eurocontrol Standard
Documents Ref. 000-1-92.
5. EditorialConventions
5.1. The format of this Standard complies with the Directives for the
Uniform Drafting and Presentation of Eurocontrol Standard
Documents.
5.2. The following notation has been used to indicate the status of
eachstatement:
— Normative statements use the operative verb ‘shall’ and have
been printed in light faced roman text;
—Recommended statements use the operative verb ‘should’ and
have been printed in light faced italics, the status being indi-
cated by the prefix Recommendation .
5.3. Any other information which is considered essential to the under-
standing of a particular indent will be integrated within the text as
a NOTE. A note is considered to be informative only, therefore
does not contain specifications and is placed immediately after
the indent to which it refers.
5.4. Exceptionally, in order to present the Profile Requirements Lists
(PRLs) in Annex E in a suitable format, some tables are not
indented and are not continued over several pages.
6. RelationshiptootherStandardDocuments
6.1. This Eurocontrol Standard Document supersedes the OLDI Short
Term Interface Control Document (ST-ICD), Part 3, Edition 1 of
the OLDI Eurocontrol Standard [Reference 13].
6.2. This Eurocontrol Standard Document is the first part in a
expected series of Eurocontrol Standard Interface Control Docu-
ments (ICDs) for Flight Data Exchange.
7. StatusofAnnexestothisStandard
The Annexes to this Standard have the following status:
— Annex A — Normative
— Annex B — Normative
— Annex C — Normative— Annex D — Normative.— Annex E — Normative2000R2082 — EN — 15.06.2002 — 001.001 — 150
▼B
— Annex F — Informative
— Annex G — Informative
— Annex H — Informative
8. LanguageUsed
The English language has been used for the original text of this
Standard.2000R2082 — EN — 15.06.2002 — 001.001 — 151
▼B
1. INTRODUCTION
This Eurocontrol Standard is based on the Short Term Interface
Control Document developed by the former OLDI Technical
Sub-Group which was tasked with defining new interface stan-
dards for the future operation of OLDI between Area Control
Centres.
Earlier OLDI links were based on proprietary protocols suchas
INTERCAUTRA or Datenübertragungs- und Verteilungssystem
(DÜV), which run over dedicated point-to-point circuits or
limited networks, and require the use of specialised hardware
and software.
For the larger number of new links planned, it was felt to be
desirable to move towards a network-based architecture and the
adoption of international telecommunications standards, enabling
links to be implemented in a more cost-effective manner, by
reducing the number of connections at each Centre and allowing
the use of standard ‘off the shelf’ hardware and software.
This Eurocontrol Standard formalises and extends the Short Term
ICD. The ST-ICD has been rewritten to give a more rigorous
specification that will improve interoperability and, in addition,
is suitable to form the basis of future ICDs to meet the evolving
requirements for Flight Data Exchange (FDE), including wider
use of shared networks and the introduction of new lower layer
standards. This Eurocontrol Standard provides a minimum set of
functionalities that can be supported by existing OLDI implemen-
tations withminimal modifications, using eith er point-to-point
links or Comité Consultatif des Téléphones et Télégraphes
(CCITT) Recommendation X.25, 1980 or later, packet-switched
networks. For procurement, more possibilities can be specified.
This ICD does not prevent agreements on a bilateral basis to go
further.
Installations wishing to run other application protocols in addition
to, or in place of the one described in this document may either
apply for amendment of the present protocol, or separate their
protocol using different virtual circuits.
2. SCOPE
2.1. This Eurocontrol Standard Document specifies a data communi-
cations interface for the exchange of flight-related data messages
between Area Control Centres (ACCs). It is presented in the form
of an Open Systems Interconnection (OSI) profile as defined in
International Organisation for Standardisation/International Elec-
trotechnical Commission (ISO/IEC) Technical Report (TR)
10000-2 [Reference 3]. The profile covers both lower layers (T-
profile) and upper layers (A-profile).
2.2. This Eurocontrol Standard Document is applicable to the
following scenarios:
— support of OLDI as described in Eurocontrol Standard
No. 001-92 Edition 1;
— support of transmission of OLDI application messages from
ACCs to the Central Flow Management Unit (CFMU)
systems.
2.3. The Standard is applicable for connection using either:
— leased line point-to-point circuits, or
— Public Switched Telephone Network (PSTN) point-to-point
circuits, or
— packet-switched data networks, or interconnected packet-
switched data networks, that provide an interface conforming
to CCITT Recommendation X.25, 1980 or later.
NOTES
1. The arrangement between Flight Plan Processing Systems
(FPPSs) is represented in Figure 1.
2. Figure 1 doesnot illustrate potential backup connections, such
as PSTN, for which guidance is given in Annex H.2000R2082 — EN — 15.06.2002 — 001.001 — 152
▼B
Figure 1
Interface Arrangement
2.4. Detailed security aspects of the specified data communications
interface are not mandated by this Standard. However, a basic
provision is specified in Annex and further guidance may be
found in Annex H of this Eurocontrol Standard.
3. REFERENCES
3.1. Introduction
The following documents and standards contain provisions which,
through reference in this text, constitute provisions of this Euro-
control Standard.
At the time of publication of this Eurocontrol Standard, the
editions indicated for the referenced documents and standards
were valid.
Any revision of the referenced International Civil Aviation Orga-
nisation (ICAO) Documents shall be immediately taken into
account to revise this Eurocontrol Standard.
Revisions of the other referenced documents shall not form part
of the provisions of this Eurocontrol Standard until they are
formally reviewed and incorporated into this Eurocontrol Stan-
dard Document.
In case of conflict between the requirements of this Eurocontrol
Standard Document and the contents of these other referenced
documents, this Eurocontrol Standard shall take precedence.
3.2. References
1. ITU-T Recommendation X.25 (1993) (Rev. 1), Interface
between data terminal equipment (DTE) and data circuit-
terminating equipment (DCE) for terminals operating in the
packet mode and connected to public data networks by dedi-
cated circuit.
2. ISO/IEC TR 10000-1:1992, Information technology —
Framework and taxonomy of International Standardized
Profiles: — Part 1: Framework (2nd edition).
3. ISO/IEC TR 10000-2:1994, Information technology —
Framework and taxonomy of International Standardized
Profiles — Part 2: Principles and Taxonomy for OSI Profiles
(3rd edition).
4. ITU-T Recommendation X.21 (1992) (Rev. 1), Interface
between data terminal equipment (DTE) and data circuit-
terminating equipment (DCE) for synchronous operation on
public data networks.2000R2082 — EN — 15.06.2002 — 001.001 — 153
▼B
5. CCITT Recommendation X.21bis (1988), Use on public data
networks of data terminal equipment (DTE) which is
designed for interfacing to synchronous V-Series modems.
6. ISO/IEC 7776:1994, Information technology — Telecommu-
nications and information exchange between systems —
High-level data link control procedures — Description of
the X.25 LAPB-compatible DTE Data Link procedures (2nd
edition).
7. ISO/IEC 8208:1993, Information Technology — Data
communications — X.25 Packet Layer Protocol for Data
Terminal Equipment (3rd edition).
8. ISO/IEC ISP 10609-9:1992, Information technology — Inter-
national Standardized Profiles TB, TC, TD and TE —
Connection-mode Transport Service over Connection-mode
Network Service — Part 9: Subnetwork-type dependent
requirements for Network Layer, Data Link Layer and
Physical Layer concerning permanent access to a packet-
switched data network using virtual calls.
9. ISO/IEC 7498-1:1994, Information technology — Open
Systems Interconnection — Basic Reference Model: The
Basic Model (2nd edition).
10. ISO/IEC 8348:1993, Information technology — Open
Systems Interconnection — Network Service Definition (1st
edition).
11. ISO/IEC 8072:1994, Information technology — Open
Systems Interconnection — Transport service definition (2nd
edition).
12. ISO/IEC 8878:1992, Information Technology — Telecommu-
nications and information exchange between systems — Use
of X.25 to provide the OSI connection-mode Network
Service (2nd edition).
13. Eurocontrol Standard for On-Line Data Interchange (OLDI),
No. 001-92, Edition 1, 1992.
14. ISO/IEC 9646-1:1994, Information technology — Open
Systems Interconnection — Conformance testing metho-
dology and framework — Part 1: General concepts (2nd
edition).
15. Eurocontrol (Maastricht Upper Area Control (UAC) Systems
Division) FDE ICD Part 1 Integration Test Plan Version 1.0,
dated 10 May 1996.
16. Eurocontrol FDE ICD Part 1 — Reliability, Availability and
Security — Technical Report version 1.0, dated 20 April
1997.
17. ITU-T Recommendation X.32 (1993) (Rev. 1), Interface
between DTE and DCE for terminals operating in the packet
mode and accessing a packet switched public data through a
public switched telephone network or an integrated services
digital network or a circuit switched public data network.
18. ITU-T Recommendation E.164 (1991) (Rev. 1), Numbering
plan for the ISDN era.
19. ITU-T Recommendation X.75 (1993) (Rev. 1), Packet-
switched signalling system between public network providing
data transmission service.
20. ITU-T Recommendation X.121 (1993), International
numbering plan for public data networks.
4. DEFINITIONS,SYMBOLSANDABBREVIATIONS
4.1. Definitions
4.1.1. For the purposes of this Eurocontrol Standard Document, the
following definitions shall apply:
4.1.2. Profile: A set of one or more base standards, and, where applic-
able, the identification of chosen classes, subsets, options and
parameters of those base standards, necessary for accomplishing
a particular function [Reference 2].
4.1.3. Profile Requirements List (PRL) : The profile requirements are
expressed in the form of conformance requirements and are
arranged in a tabular list format [Reference 2].2000R2082 — EN — 15.06.2002 — 001.001 — 154
▼B
4.1.4. T-profile: Transport Profile providing a Connection mode Trans-
port Service [Reference 3].
4.1.5. A-profile: Application Profile requiring a Connection-mode
Transport Service [Reference 3].
4.1.6. Protocol Implementation Conformance Statement (PICS) :A
statement made by the supplier of an OSI system, stating which
capabilities have been implemented, for a given OSI protocol
[Reference 14].
4.2. SymbolsandAbbreviations
For the purpose of this Eurocontrol Standard Document, the
following symbols and abbreviations are used:
ACC Area Control Centre
AFI Authority and Format Identifier
ASCII American Standard Code for Information
Interchange
ATC Air Traffic ControlATCC Air Traffic Control Centre
CAUTRA Coordinateur Automatique du Trafic Aérien
CCITT Comité consultatif international télégra-
phique et téléphonique (now ITU-T)
CFMU Central Flow Management UnitCUG Closed User Group
DCE Data Circuit-terminating Equipment
DCTS Digital Communications Terminal SystemDSP Domain Specific PartDTE Data Terminal EquipmentDÜV Datenübertragungs- und Verteilungssystem
FDE Flight Data Exchange
FEP Front-End Processor
FPDE Flight Plan related Data ExchangeFPPS Flight Plan Processing System
ICAO International Civil Aviation Organisation
ICD Interface Control DocumentIDI Initial Domain IdentifierIDP Initial Domain Part
IEC International Electrotechnical Commission
INTERCAUTRA Inter-CAUTRA protocolISO International Organization for Standardiza-
tion
ITU-T International Telecommunication Union —
Telecommunication Standardization Sector
ISDN Integrated Services Digital Network
LAPB Link Access Procedure Balanced
LSB Least Significant Bit
M, m Mandatory
MSB Most Significant BitMT Message Transfer
NA Not Applicable
NS Network ServiceNSAP Network Service Access Point
NSDU Network Service Data Unit
O, O.<n> Optional, where <n> is a numeral for refer-
encing
o, o.<n> Optional, where <n> is a numeral for refer-
encing
OLDI On-Line Data InterchangeOSI Open Systems Interconnection
PICS Protocol Implementation Conformance
Statement
PLP Packet Layer Protocol2000R2082 — EN — 15.06.2002 — 001.001 — 155
▼B
PRL Profile Requirements List
PSTN Public Switched Telephone Network
ST-ICD Short Term Interface Control Document
SUT System Under Test
T<x> Timer (where <x> is a single or double
letter for referencing)
TA Terminal AdaptorTSDU Transport Service Data UnitTPDU Transport Protocol Data Unit
TR ISO Technical Report
X Prohibited
x Excluded<item>: Conditional Item (dependent on the value of
item)
4.3. Notations
4.3.1. For the purpose of this Eurocontrol Standard Document, binary
values or a sequence of bits are denoted in hexadecimal using
the notation 'd'H, where the letter d stands for a digit or a
sequence of hexadecimal digits.
4.3.2. For the purpose of this Eurocontrol Standard Document, the hexa-
decimal representation of a bit sequence is formed by taking 4
bits at a time from the most significant bit (MSB) to the least
significant bit (LSB).
NOTEUnless otherwise specified in the referred international
Standards, a sequence of bits is transmitted from MSB to
LSB.
4.3.3. For the purpose of this Eurocontrol Standard Document, the
status of the support for features of a base standard, or this Euro-
control Standard, shall be shown in upper case (e.g. M, O, O.<n>,
X). The exact meaning of each status symbol is described in the
Annexes of this Eurocontrol Standard prior to their use.
4.3.4. For the purpose of defining the FDE ICD Part 1 profile in this
Eurocontrol Standard Document, the status of the support for
features of a base standard or this Eurocontrol Standard, shall be
shown in lower case (e.g. m, o, o.<n>, x).
NOTEThe result is a further refinement of the features of the
base standards that areconditional, optional, or value
dependent (see E.3.1).
5. TECHNICALOVERVIEW
5.1. Protocol Stack
NOTEThe protocol stack for the profile of this Eurocontrol
Standard is illustrated in Figure 2. The figure places the
protocols in the framework of the OSI Basic Reference
Model [Reference 9] by aligning the stack with the corre-
sponding OSI layers. However, the protocol stack is a
specification for pre-OSI systems and it does not support
the many functions that are allowed in the OSI protocols
of the corresponding OSI layers.2000R2082 — EN — 15.06.2002 — 001.001 — 156
▼B
Figure 2
Profile Protocol Stack
5.2. StructureoftheProfile
NOTES1. AsshowninFigure 2,the profile stack combinesseveral lower
layer protocols, of which only the X.25 Packet Layer Protocol
(PLP) [Reference 1]and itssupporting protocols, X.21 [Refer-
ence 4] and X.21bis [Reference 5], are defined in existing
ISO/IEC and International Telecommunication Union-Tele-
communication Standardization Sector (ITU-T) standards. The
other higher layer protocols are defined in Annexes (Annexes
A, B and C) in this Eurocontrol Standard Document.
2. Conformance requirements for the profile can refer to these
specifications on an equal footing with external standards
and are stated in Section 6. The detailed requirements are
stated using the tabular format of PRLs (Annex E) and PICS
proformas (proformas for protocols defined in the Annexes
are given in Annex D). The use of these PRLs and PICS
proformas in development and/or procurement is explained in
Annex E.
5.3. RelationtoPreviousVersionsoftheSpecification
NOTES1. This profile is based on the ST-ICD developed by the former
OLDI Technical Sub-Group. The protocols and packet formats
defined in this Eurocontrol Standard Document are a compa-
tible subset of those of the ST-ICD with the exception that this
Eurocontrol Standard makes more detailed requirements on
the use of the X.25 PLP, includes mandatory support of the
M-bit and corrects the inconsistent specification of the
Authority and Format Identifier (AFI) value in the Network
Service Access Point (NSAP) address.
2. The main change in the style of this Eurocontrol Standard
Document relates to the structure of the ICD specification.
The Message Transfer Protocol (Annex A) is separated from
the supporting T-profile. This will facilitate the use of other
T-profiles as this becomes necessary to support evolving FDE
requirements.
3. Those parts of the ST-ICD specification dealing with control
of X.25 virtual circuits and delimiting application messages2000R2082 — EN — 15.06.2002 — 001.001 — 157
▼B
are now found in the Message Header Protocol (Annex B),
which constitutes a minimal transport layer for FDE.
6. PROFILEREQUIREMENTS
6.1. ConformanceRequirements
6.1.1. An implementation claiming conformance to this specification
shall meet the requirements laid down in sections 6.2 and 6.3
below.
6.1.2. A claim of conformance shall be supported by a Profile Imple-
mentation Conformance Statement as described in and Annex D
and Annex E.
6.2. Upper-layerRequirements
6.2.1. A conforming implementation shall satisfy the requirements of
the base standard, given at Annex A.
6.2.2. A conforming implementation shall satisfy the constraints given
in the Profile Requirements List at Annex E.7.
6.3. Lower-layerRequirements
6.3.1. Transport Layer Requirements
6.3.1.1. A conforming implementation shall satisfy the requirements of
the base standard, given at Annex B.
6.3.1.2. A conforming implementation shall satisfy the constraints given
in the Profile Requirements List at Annex E.8.1.
6.3.1.3. A conforming implementation shall satisfy the requirement of
supporting Transport Service Data Unit (TSDU) sizes of up to
and including 4 097 octets.
NOTEThe first octet of the TSDU corresponds to a field of the
Message Header (see and A.4.10, B.4.4), leaving a
maximum of 4096 octets for user data.
6.3.2. Network Layer Requirements
6.3.2.1. A conforming implementation shall satisfy the requirements of
ISO/IEC 8208 [Reference 7] in accordance withth e protocol
mapping given at Annex C.
6.3.2.2. A conforming implementation shall satisfy the constraints given
in the Profile Requirements List at Annex E.8.2.
6.3.2.3. A conforming implementation shall, if data terminal equipment
(DTE)-DTE operation is supported, be capable of configuring by
system management mechanisms the choice of DTE or data
circuit-terminating equipment (DCE) role for the DTE-DTE
operation.
6.3.2.4. A conforming implementation shall, in either role defined by
6.3.2.3, be capable of initiating a connection according to the
specification of Annex C i.e. the protocol is totally symmetric.
NOTESome existing implementations based on the ST-ICD, may
not be able to initiate network connections according to
the protocol of Annex C.
6.3.2.5. A conforming implementation shall agree for a period of time to
the facility of Non-standard Default Packet Sizes, with the value
256 for bothdirections of transmission.
6.3.2.6. A conforming implementation shall use NSAP addresses as
defined in Annex C.
6.3.2.7. A conforming implementation shall set the D-bit to 0 in CALL
REQUEST, CALL ACCEPTED and DATA packets.
NOTESetting D=0 in CALL REQUEST and CALL ACCEPTED
packets has the effect of not using Delivery Confirmation.
6.3.3. Datalink Layer Requirements
6.3.3.1. A conforming implementation shall satisfy the conformance
requirements of ISO/IEC 7776 [Reference 6] for the Link Access
Protocol Balanced (LAPB) Single Link Protocol.2000R2082 — EN — 15.06.2002 — 001.001 — 158
▼B
6.3.3.2. A conforming implementation shall also satisfy the constraints
given in the Profile Requirements List at Annex E.8.3.
6.3.4. Physical Layer Requirements
A conforming implementation shall satisfy the conformance
requirements of ISO/IEC ISP 10609-9 clause 7 [Reference 8].
7. TESTMETHODS
NOTES
1. An approach to conformance testing of implementations of this
specification is outlined in Annex F.
2. The use of the PRLs and PICS proformas provided with this
specification to document conformance is outlined in Annex E.2000R2082 — EN — 15.06.2002 — 001.001 — 159
▼B
ANNEX A (Normative)
MESSAGETRANSFERPROTOCOL
A.1.Introduction
This specification defines a protocol to implement a simple message
transfer service for applications that require flight data exchange.
A.2.Service Implemented
The Message Transfer (MT) protocol implements the following
unconfirmed services:
MT-Associate : establishan application message transfer association;
MT-Data: transfer an application message consisting of American
Standard Code for Information Interchange (ASCII) characters;
MT-Abort : terminate an application message transfer association.
A.3.Service Assumed
This Message Transfer protocol assumes a subset of the Connection-
mode Transport Service as defined in ISO/IEC 8072 [Reference 11],
such as that offered by the protocol defined in of this Eurocontrol
Standard.
A.4.Protocol Specification
A.4.1. Introduction
In the following text, only the operation of one application initiated
Message Transfer association is described. Further associations may
be supported on the same network interface, by repeating these
procedures for eachunderlying transport connection.
A.4.2. Types of Data
This Annex identifies four types of application messages that are
equivalent to those defined in Eurocontrol Standard No 001-3-92
Edition 1:
System Messages: These messages shall be used for link monitoring
(HEARTBEAT message) and application control (STARTUP and
SHUTDOWN messages).
Operational Messages: These messages shall be linked to a specific
operational context and are defined in the Eurocontrol Standards
and Documents that make use of this Standard for data interchange.
Eurocontrol Standard Document for On-Line Data Interchange
defines operational messages suchas th e Activation (ACT),
Advanced Boundary Information (ABI), Logical Acknowledgement
(LAM) messages.
Operator Messages: These messages shall contain free text. Their
use shall be bilaterally agreed. For example, they may be used to
exchange test information or to inform the other side about operator
actions.
Status Messages: The use and the contents of these messages shall
be bilaterally agreed. For example, they may be used to exchange
system management information.
NOTES
1. The use of System messages is part of the operation of this
protocol and their format is specified in paragraph A.4.10.3 of
this Annex.
2. The use and format of Status messages are subject to bilateral
agreement, and are not further specified in this Eurocontrol
Standard.
3. The state of the protocol determines which types of messagescan
be transmitted, as specified in the following paragraphs.
A.4.3. Association Establishment
A.4.3.1. The protocol is initially in the IDLE state.2000R2082 — EN — 15.06.2002 — 001.001 — 160
▼B
A.4.3.2. The MT-Associate-Request primitive is executed to establish an
application association and bring the protocol into the DATA_-
READY state. The primitive has to be invoked by both the local
and remote applications.
A.4.3.3. It is first necessary to establishan underlying transport connection,
following the T-connect primitive procedures described in Annex B
paragraph B.4.1, after which the protocol enters the READY state.
At this stage only System messages (and possibly, by bilateral
agreement, Operator messages) can be transferred. To transfer a
System or Operator message, the sender uses the T-Data primitive
(see B.4.4), withth e message as parameter.
A.4.3.4. A STARTUP message (system message) shall then be transmitted,
timer Tr (see A.4.7) shall be started, and the protocol enters the
ASSOCIATION_PENDING state. If timer Tr expires while the
protocol is still in this state, the STARTUP message shall be
retransmitted and the timer shall be restarted.
NOTEThe protocol will remain in the ASSOCIATION_PENDING
state until a STARTUP message is received. Continuous
time-outs of the Tr timer could be signalled locally.
A.4.3.5. Receipt of the STARTUP message shall cause the following
actions:
— in the ASSOCIATION_PENDING state, a further STARTUP
message is transmitted, the protocol enters the DATA_READY
state and the MT-Associate-Indication primitive is signalled;
— in any other state, the message is ignored.
A.4.3.6. Receipt of the STARTUP message in state ASSOCIATION_-
PENDING corresponds to either:
— the remote application issued a MT-Associate-Request primitive
and its Message Transfer protocol has entered the ASSOCIA-
TION_PENDING state, or
— the remote Message Transfer protocol is responding to a
previously received STARTUP message and has entered the
DATA_READY State.
NOTEThis uncertainty occurs because the same message is used
for STARTUP and for response to STARTUP. As a result,
the Message Transfer protocol that first entered the DATA_-
READY state will receive a further STARTUP message. As
specified in A.4.3.5, this STARTUP message is ignored.
A.4.3.7. Once STARTUP messages have been exchanged, the association is
established and all the identified types of messages can be trans-
ferred (DATA_READY state).
A.4.4. Data Transfer
Other types of messages are transferred in the same way as System
messages, using the T-Data service, with the message as parameter.
This corresponds to the MT-Data-Request and the MT-Data-Indica-
tion service primitives.
NOTEEach message is sent as a single TSDU: there is no conca-
tenation or segmentation of messages at this level.
A.4.5. Orderly Association Release
A.4.5.1. The Message Transfer association between two applications can be
cleared by either one. This corresponds to the MT-Abort-Request
service primitive.
A.4.5.2. The following actions shall be taken:
— in the DATA_READY state, a SHUTDOWN message (system
message) shall be transmitted, timers Tr and Ts shall be stopped,
and the transport connection shall be released;
— in the ASSOCIATION_PENDING state, a SHUTDOWN
message (system message) shall be transmitted, timer Tr shall
be stopped, and the transport connection shall be released;
— in the READY state the transport connection shall be released;
— otherwise no action is taken.
NOTEThe SHUTDOWN message is not an early warning — the
association is terminated immediately. There is no confirma-
tion of this message from the other side.2000R2082 — EN — 15.06.2002 — 001.001 — 161
▼B
A.4.5.3. Receipt of a SHUTDOWN message shall cause the following
actions:
— in the DATA_READY state, timer Ts (see A.4.7) shall be
stopped, MT-Abort-Indication is signalled and the interface
enters the ASSOCIATION_PENDING state without sending a
STARTUP message;
— in any other state, no action is taken.
A.4.6. Association Re-establishment
The application which initiated the clearing of the association has
the responsibility, when it is ready, for re-establishing the applica-
tion association and any lower levels (if necessary).
NOTEIf the clearing of the association has resulted in the release
of the underlying network connection, the association estab-
lishment procedure specified in paragraph A.4.3 must be
followed.
A.4.7. Association Integrity
A.4.7.1. The integrity of the association between two applications is
provided by the idle heartbeat facility.
A.4.7.2. On entering the DATA_READY state and on transmitting any type
of message on the transport connection, a configurable timer Ts
shall be (re)started. If the timer Ts expires in the DATA_READY
state, a HEARTBEAT message (System message) shall be trans-
mitted (and the timer shall be restarted).
A.4.7.3. Similarly, on entering the DATA_READY state and on receiving
any message except a STARTUP message on the connection, a
configurable timer Tr shall be (re)started. If the timer Tr expires in
the DATA_READY state, MT-Abort-Indication is signalled, the
transmission of all messages is stopped, timer Ts is stopped and
the timer Tr is restarted. The interface is in the ASSOCIATION_-
PENDING state.
NOTEThe applications will recover and resynchronise through the
exchange of STARTUP messages (see A.4.3).
A.4.8. Disorderly Association Release
A.4.8.1. There can be an abnormal association release if:
— the transport connection fails (e.g. line failure, protocol error),
— one of the two applications or systems fails (this could be due to
hardware or software failure; in some cases, the underlying
transport connection can still be working).
NOTEFollowing the definition of the transport procotol in
Annex B, there is no end-to-end transport connection. As a
result, failure of the transport connection is a direct result
of the network connection failure.
A.4.8.2. An application or system failure can be detected by the expiry of a
time-out for the receipt of an expected HEARTBEAT message (see
A.4.7) from this application.
A.4.9. Recovery From Failure
A.4.9.1. Two cases have to be considered:
— after a transport connection failure;
— after an application failure.
A.4.9.2. In both cases, the re-establishment involves the normal association
establishment procedure (see A.4.3), including exchange of
STARTUP messages.
NOTEIn the event of a failure at the application level that does
not cause the underlying connection to be released, the
failed system may transmit a SHUTDOWN message (i.e.
L_shutdown invoked either manually or as part of the appli-
cation logic) before attempting to restart the link. This will
curtail the remote application's time-out Tr and may result
in a quicker recovery with less chance of lost data.2000R2082 — EN — 15.06.2002 — 001.001 — 162
▼B
A.4.10. Message Formats
A.4.10.1. General Message Structure
All messages consist of an integer type field (‘TYP’) from the range
1…63 followed by the message body. The ‘TYP’ field is encoded in
one octet as an ASCII character by adding '40'H to the binary repre-
sentation of the field (e.g. the value 3 is encoded as '43'H, character
‘C’). The message body consists of ASCII characters encoded one
per octet. This gives the following format:
TYP Message Body
octet 1 octet 2 … octet n
A.4.10.2. Message Body Length
Message bodies of lengthup to and including 4 096 octets sh all be
supported.
A.4.10.3. System Message Formats
System messages are coded withTYP = 4, encoded as '44'H. Th e
message body consists of a two octets, coded as follows:
— STARTUP message: '3031'H (ASCII digits "01");
— SHUTDOWN message: '3030'H (ASCII digits "00");
— HEARTBEAT message: '3033'H (ASCII digits "03").
A.4.10.4. Other Message Formats
Field TYP defines the message type, encoded as described above:
— value 1 (encoded as '41'H) Operational messages;
— value 2 (encoded as '42'H) Operator messages;
— value 5 (encoded as '45'H) Status messages.
NOTES
1. The format of the message body for Status messages is beyond
the scope of this Eurocontrol Standard Document.
2. The format for Operational messages is specified in Eurocontrol
Standards and Documents that define messaging applications
such as On-Line Data Interchange [Reference 13].
3. Operator messages consist of printable ASCII text. If these
messages are supported, a user interface must be provided to
display received messages and to allow the composition of
messages for transmission.
A.5.Protocol StateTransitionTables
A.5.1. Introduction
The state tables given below are the definitive specification of the
protocol. In case of discrepancy with the main text above, the speci-fication below shall prevail.
NOTEThe notation used to describe states, events, timers and
actions are based on the ST-ICD. However, the following
definitions and resulting actions have been reviewed and
may differ from the ST-ICD.2000R2082 — EN — 15.06.2002 — 001.001 — 163
▼B
A.5.2. State Definitions
Table 1
State Definitions
State State Description Additional State Information
state 0 IDLE No transport connection
state 1 READY Transport connection established,
local user down, remote user down
state 2 ASSOCIATION_-
PENDINGTransport connection established,
local user up, remote user down
state 3 DATA_READY Local user up, remote user up
A.5.3. Possible Events
Table 2
Possible Events
Event Description Additional State Information
L_data Indication that data (Operational, Operator, or Status message) is
to be sent from the local to the remote user (MT-Data Request
primitive)
L_shutdown A command is given to stop the local user (MT-Abort Request)
L_startup A command is given to start the local user (MT-Associate
Request)
R_data Indicates that data has been received from the remote user (T-Data
Indication, TYP ≠‘System’)
R_heartbeat A HEARTBEAT message is received from the remote user (T-
Data Indication, TYP = ‘System’, Message code = HEARTBEAT)
R_shutdown A SHUTDOWN message is received from the remote user (T-
Data Indication, TYP = ‘System’, Message code = SHUTDOWN)
R_startup A STARTUP message is received from the remote user (T-Data
Indication, TYP = ‘System’, Message code = STARTUP)
Ts_timeout Expiry of timer Ts
Tr_timeout Expiry of timer Tr
TC_disconnect A Transport connection release indication has been received (T-
Disconnect Indication)
TC_setup Event (e.g. explicit command, application request) which causes a
T-Connect Request primitive
A.5.4. Timers
Table 3
Timers
Timer Timer information
Tr Time-out when a HEARTBEAT or a data message is expected
Ts Time-out for sending a HEARTBEAT to the remote user
The value of these timers shall be such that Tr = 2Ts + transit time.
NOTETypical values of these timers are: Ts = 30s, Tr = 70s.2000R2082 — EN — 15.06.2002 — 001.001 — 164
▼B
A.5.5. State Transition Table
Table 4
State Transitions
State Event Actions to be Taken New State
state 0 TC_setup The transport layer attempts to set
up the lower layer connection(s)
between the local and remote
users; when the connection has
been successfully established, the
user is notified (1)state 1
TC_disconnect The system takes appropriate
actions but remains in state 0state 0
L_data Ignored state 0
L_shutdown
L_startup
Tr_timeout
Ts_timeout
R_data Ignore (event should not happen) state 0
R_heartbeat
R_shutdown
R_startup
state 1 L_startup The local user sends a STARTUP
message to the remote user, timer
Tr is started (2)state 2
R_startup The local user receives a
STARTUP message from the
remote user, this STARTUP
message is ignored since an
L_startup event has not occurredstate 1
L_data Ignored state 1
R_data
R_heartbeat
R_shutdown
TC_setup
Tr_timeout Ignored state 1
Ts_timeout
L_shutdown The transport connection is cleared state 0TC_disconnect The local user is notified that the
transport connection is discon-
nected (e.g. due to an error or aremote shutdown)state 02000R2082 — EN — 15.06.2002 — 001.001 — 165
▼B
State Event Actions to be Taken New State
state 2 R_startup The local user receives a
STARTUP message from the
remote user; timers Tr and Ts are
started; the local user is notified
that data can be sent on the asso-
ciation and the reception of the
STARTUP message is explicitly
notified by replying withanoth er
STARTUP message (3)state 3
Tr_timeout The local user retransmits a
STARTUP message if it did not
receive a STARTUP message from
the remote user within a specified
time period Tr, timer Tr is
restartedstate 2
L_startup Ignored state 2
L_data
R_data
R_heartbeat
R_shutdown
Ts_timeout
TC_setup
L_shutdown The local user is directed to shut
down the association: a SHUT-
DOWN message is transmitted,
timer Tr is stopped and the trans-
port connection is releasedstate 0
TC_disconnect The local user is notified that the
transport connection is discon-
nected (e.g. due to an error), timer
Tr is stopped and the association isabortedstate 02000R2082 — EN — 15.06.2002 — 001.001 — 166
▼B
State Event Actions to be Taken New State
state 3 L_data Timer Ts is restarted state 3
R_data Timer Tr is restarted state 3
R_heartbeat
R_startup If a STARTUP message is
received from the remote user, it is
considered as an acknowledgement
of a previously sent STARTUP
message; timer Tr is not restartedstate 3
Ts_timeout A HEARTBEAT message is sent
and timer Ts is restartedstate 3
L_startup Ignored state 3 (4)
TC_setup
R_shutdown Timer Ts is stopped; MT-Abort-
Indication is signalled to the local
userstate 2
Tr_timeout Timer Ts is stopped. MT-Abort-
Indication is signalled to the local
user; timer Tr is restartedstate 2
L_shutdown A SHUTDOWN message is trans-
mitted; timers Tr and Ts are
stopped and the transport connec-
tion is releasedstate 0
TC_disconnect The local user is notified that the
transport connection is discon-
nected (e.g. due to an error);
timers Tr and Ts are stopped and
the association is abortedstate 0
NOTES
(1) When entering state 0, it may be considered to automatically generate the TC_setup event.
(2) Only when entering state 1 via an automatically generated TC_setup event as described in state 0,
then the L_startup event may be automatically generated.
(3) This method guarantees that a received STARTUP message from a remote user is always
acknowledged by a STARTUP message.
(4) Some existing implementations, pre-dating this Eurocontrol Standard Document, may treat this
event as TC_disconnect, i.e. returning to state 0.2000R2082 — EN — 15.06.2002 — 001.001 — 167
▼B
A.5.6. State Transition Diagram
NOTEThe protocol is described in Figure A.1 in the form of a
state transition diagram. The diagram is only informative:
in case of conflict between the diagram and the state tables
above, the latter shall take precedence.
Figure A.1
Message Transfer Protocol: State Transition Diagram2000R2082 — EN — 15.06.2002 — 001.001 — 168
▼B
ANNEX B (Normative)
MESSAGEHEADERPROTOCOL
B.1.Introduction
This Annex defines the Message Header protocol, a minimal trans-
port protocol to be used for applications suchas OLDI.
B.2.ServiceImplemented
B.2.1. The Message Header protocol corresponds to a subset of the Connec-
tion-mode transport Service, as defined in ISO/IEC 8072
[Reference 11], comprising the following service primitives.
T-Connect: establisha transport connection for an application
T-Data:transfer ASCII data
T-Disconnect: terminate the transport connection of an application
B.2.2. The service does not support multiplexing, error recovery, or segmen-
tation and reassembly.
B.3.ServiceAssumed
The protocol assumes a reliable basic network service as provided by
the X.25 Packet Layer Protocol.
NOTEOnly a single transport connection is supported on each
network connection.
B.4.ProtocolSpecification
B.4.1.Connection Establishment
The T-Connect primitive shall be implemented by using the N-
Connect service of the underlying network service. There is a direct
mapping between the two sets of (request, indication) primitives.
Alternatively, an existing network connection may be used (e.g. one
established by system management mechanisms).
Recommendations1. In the latter case above the network connection should be reset
before use. The N-Connect primitive may be reissued automati-
cally if no response has been received within a certain time.
2. If this automatic retry is implemented, retries should be attempted
approximately every 15s.
B.4.2.Avoidance of Redundant Network Connections
If an N-Connect-Request primitive is outstanding (i.e. no corre-
sponding N-Connect-Confirm or N-Disconnect primitive has been
signalled) and an N-Connect-Indication is signalled, then the
incoming network establishment attempt shall be rejected or cleared,
by responding withan N-Disconnect-Request primitive, only wh en
bothth e following conditions apply:
— the calling NSAP address of the N-Connect-Indication is the same
as the called NSAP address of the outstanding N-Connect-
Request;
— the calling NSAP address of the outstanding N-Connect-Request
is greater than the called NSAP address of the outstanding N-
Connect-Request, the comparison being made on the bit strings
formed by the preferred binary encoding of each NSAP address,
as defined in ISO/IEC 8348 Annex A [Reference 10] (a string
shall be considered greater than any of its proper initial
substrings, e.g. '8800'H > '88'H).
B.4.3.Connection Release
B.4.3.1. Connection release shall use the N-Disconnect and N-Reset service
primitives of the underlying network service.
B.4.3.2. To implement a T-Disconnect-Request, an N-Disconnect-Request
shall be signalled. Alternatively, if the establishment of network2000R2082 — EN — 15.06.2002 — 001.001 — 169
▼B
connections using N-Connect primitives is not supported, the network
connection shall not be explicitly released.
Recommendation In the latter case, above the network connection
should be reset.
B.4.3.3. A T-Disconnect-Indication shall be signalled on the receipt of either
of the following network service primitives on a network connection
corresponding to a wholly or partly established transport connection:
— N-Disconnect-Indication;
— N-Reset-Indication.
B.4.4.Data Transfer
B.4.4.1. The T-Data primitive shall be implemented by using the N-Data
primitive of the underlying network service. There is a direct
mapping between the two sets of (request, indication) primitives.
The mapping uses a Transport Protocol Data Unit (TPDU) which is
transferred by the network service.
B.4.4.2. The TPDU shall have the following format, transmitted from left to
right, whereby the message structure defined in A.4.10.1 is to be
inserted in the data(1), data(2)…data(n) fields.
STX LENG ADEST DEST AEMM EMM data(1) ADRdata(2)…
data(n)ETX
'02'H '48'H '40'H '40'H '40'H '40'H '40'H '03'H
NOTES
1. This header is defined so as to be identical to that used in the
INTERCAUTRA procedure defined for ACT message exchange
between CAUTRA Paris, the 9020D system of the London Air
Traffic Control Centre and Digital Communications Terminal
System (DCTS) Maastricht/Karlsruhe, when carrying the message
formats defined in ; in this case the field ‘data(1)’ corresponds to
the TYP field.
2. The use of the fields ADEST, DEST, AEMM, EMM, and ADRwith
values other than '40'H is beyond the scope of this Eurocontrol
Standard Document, but may be subject to bilateral agreement.
B.4.4.3. The T-Data service shall be restricted to the transfer of printable
ASCII character data. In particular, none of the data octets shall
have the value '03'H (the character ETX).
B.4.4.4. A conforming implementation shall satisfy the requirement of
supporting Network Service Data Unit (NSDU) sizes of up to and
including 4105 octets.
B.4.4.5. A conforming implementation shall prohibit concatenation of
multiple TSDUs into a single NSDU.
B.4.4.6. A conforming implementation shall prohibit segmentation of a single
TSDU into multiple NSDU's.2000R2082 — EN — 15.06.2002 — 001.001 — 170
▼B
ANNEX C (Normative)
NETWORKPROTOCOL
C.1.Introduction
This Annex specifies a basic Network Protocol using the X.25 packet
layer protocol, for use in bothpoint-to-point and packet-switch ed
network environments, to support the transfer of flight data. The
protocol subset is compatible withth at defined in versions of
[Reference 1] from the 1980 edition on.
C.2.ServiceProvided
C.2.1. The protocol implements the connection-mode OSI Network Service
as defined in ISO/IEC 8348 [Reference 10], withth e following
exceptions.
— NSAP addresses are restricted to the form defined in ;
— there is no facility for establishing agreement between the
Network Service (NS) users and the NS provider on the quality
of service associated witha network connection;
— transfer of NS-User-Data during network connection establish-
ment and release is not supported except for provisions
described in C.5.3.
C.2.2. The following NS provider-options are not offered:
— Receipt Confirmation;
— Expedited Data Transfer.
C.3.ServiceAssumed
The protocol assumes the provision of an OSI Datalink Service, such
as that offered by ISO/IEC 7776 (LAPB) [Reference 6].
C.4.NSAPAddressing
C.4.1.Introduction
C.4.1.1. The structure of the NSAP addresses follows that defined in ISO/IEC
8348 Annex A [Reference 10], as illustrated below.
C.4.1.2. The components of the NSAP address are defined below:
IDP: Initial Domain Part, comprising the AFI and IDI fields
AFI: Authority and Format Identifier, and
IDI: Initial Domain Identifier
DSP: Domain Specific Part
C.4.2.NSAP Address Structure
C.4.2.1. For the purpose of this Eurocontrol Standard Document, the address
components shall be limited to the following form.
C.4.2.2. The AFI value 48 shall be used, indicating a Local format IDI with
decimal abstract syntax.
C.4.2.3. The IDI is null, following the Local format.C.4.2.4. The DSP shall consist of 2 pairs of decimal digits, as follows:
— the first pair is an Air Traffic Control (ATC) unit identifier,
which identifies an ATC system and thus indirectly a location;
— the second pair is an ATC unit selector, which may be used to
identify a particular end point within an ATC unit.2000R2082 — EN — 15.06.2002 — 001.001 — 171
▼B
C.4.2.5. The resulting NSAP address structure is illustrated below.
AFI DSP
48 ATC unit identifier ATC unit selector
C.4.3.Assignment of ATC Unit Identifiers and Selectors
C.4.3.1. Assignment of unique ATC unit identifiers to eachATC system will
be the responsibility of Eurocontrol, while ATC unit selectors will be
assigned by the relevant authority within the ATC Administration or
Organisation.
C.4.3.2. The allocation of ATC unit identifiers at the time of preparing this
Standard is shown in
C.5.ProtocolSpecification
C.5.1.Overview
The protocol is based on the Subnetwork-Dependent Convergence
Protocol for X.25(1980) defined in of ISO/IEC 8878 [Reference 12],
withth e following differences:
— the Fast Select user facility is not used; however, the encoding
defined in Annex A of ISO/IEC 8878 [Reference 12] for use
withth e extended format User Data field available withth e Fast
Select facility is used here with the basic format User Data field
in CALL REQUEST and INCOMING CALL packets, since
restrictions on the allowed network service parameters ensure
that the encoded information fits into 16 octets;
— of the network service parameters for which encodings are
defined in ISO/IEC 8878 [Reference 12], only the called and
calling NSAP addresses (and only in the form defined in ) are
sent in the CALL REQUEST packet;
— the User Data field is not used in the CALL ACCEPTED, CALL
CONNECTED, CLEAR REQUEST, or CLEAR INDICATION
packets;
— the alternative procedures for network connection establishment
and release are not used;
— receipt confirmation using the D-bit is not supported.
NOTEThe first three of these restrictions ensure that all information
which will be transmitted between two DTEs will respect the
limitations of the User Data field in X.25 (1980) PLP.
C.5.2.Address Encoding
The calling and called NSAP addresses shall be encoded using the
preferred binary encoding defined in ISO/IEC 8348 Annex A
[Reference 10].
C.5.3.Encoding of the User Data Field
C.5.3.1. As a result of the requirements stated above, the User Data field in
CALL REQUEST and INCOMING CALL packets shall be encoded
as illustrated below. All 16 octets shall be transmitted.
Table 1
User Data Field Encoding
Field DescriptionHighOrder Semi-
OctetLow Order Semi-Octet
Octet 0: Protocol identity bin(1000) bin(0100)
Octet 1: Message code type bin(0010) bin(0000)
Octet 2: Message code value (N CR) bin(0000) bin(0001)Octet 3: Parameter type = Called NSAP bin(1100) bin(1001)
Octet 4: Parameter lengthbin(0000) bin(0110)
Octet 5: Parameter value (1st octet) = AFI
valuebin(0100) bin(1000)2000R2082 — EN — 15.06.2002 — 001.001 — 172
▼B
Field DescriptionHighOrder Semi-
OctetLow Order Semi-Octet
Octet 6: Parameter value (2nd octet) =
ATC unit identifierhigh order digit low order digit
Octet 7: Parameter value (3rd octet) = ATC
unit selectorhigh order digit low order digit
Octet 8: Parameter type = Calling NSAP bin(1100) bin(1011)
Octet 9: Parameter lengthbin(0000) bin(0110)
Octet 10: Parameter value (1st octet) = AFI
valuebin(0100) bin(1000)
Octet 11: Parameter value (2nd octet) =
ATC unit identifierhigh order digit low order digit
Octet 12: Parameter value (3rd octet) =
ATC unit selectorhigh order digit low order digit
Octet 13: Reserved for future use bin(0000) bin(0000)
Octet 14: Reserved for future use bin(0000) bin(0000)
Octet 15: Reserved for future use bin(0000) bin(0000)
C.5.3.2. Other parameters described in ISO/IEC 8878 [Reference 12] shall not
be used.
C.5.4.Treatment of Addresses in INCOMING CALL Packets
C.5.4.1. DTE Adresses
The calling DTE address in an INCOMING CALL packet shall be
validated against a local list of valid remote DTE addresses for the
system. If an invalid address is detected, the call shall be cleared.
NOTES
1. The called DTE address, if present, in an INCOMING CALL
packet, if present, may optionally also be validated against a list
(typically ofoneitem)ofvalid local DTEaddressesforthe system.
2. In some instances the DTE address of a unit may differ in value
and/or length when the unit is acting as the calling or called
system. Therefore, particular attention must be given to this issue
when specifying orimplementing the DTEaddressvalidation func-
tionality
C.5.4.2. NSAP Adresses
The calling NSAP address encoded as described above in an
INCOMING CALL packet shall be validated against a local list of
valid remote NSAP addresses for the system. If an invalid address
should be detected, the call shall be cleared.
NOTEThe called NSAP address may optionally also be validated
against a list of (typically of one item) valid local NSAP
addresses for the system.
C.5.5.Data Transfer
C.5.5.1. As described in ISO/IEC 8878 Annex A.5.3 [Reference 12], NSDUs
are transferred in the User Data field of a DATA packet.
NOTEAs a consequence, it is prohibited to transmit more than one
user message, such as an OLDI message, per X.25 packet or
M-bit sequence.
C.5.5.2. NSDUs longer than the maximum User Data allowed for the virtual
circuit shall be segmented and transmitted in the User Data fields of a
sequence of DATA packets where all except the last shall have both
maximum lengthand th e M-bit set (i.e. a More-bit-sequence).
C.5.5.3. On reception, the User Data fields of a More-bit-sequence shall be
reassembled in order to form the received NSDU.2000R2082 — EN — 15.06.2002 — 001.001 — 173
▼B
ANNEX D (Normative)
PROFILE-SPECIFICPICSPROFORMAS
D.1.Introduction
D.1.1. The supplier of a protocol implementation which is claimed to
conform to the specifications in Annexes A-C shall complete the
following PICS proformas.
NOTECopyright release for PICS proformas: users of this Eurocon-
trol Standard Document may freely reproduce the PICS
proformas in this Annex so that it can be used for the
intended purpose and may further publish the completed
PICS.
D.1.2. A completed PICS proforma is the PICS for the implementation in
question. The PICS is a statement of which capabilities and options
of the protocol have been implemented.
D.1.3. The PICS can have a number of uses, including use:
— by the protocol implementor, as a check-list to reduce the risk of
failure to conform to the standard through oversight;
— by the supplier and acquirer, or potential acquirer, of the imple-
mentation, as a detailed indication of the capabilities of the
implementation, stated relative to the common basis for under-
standing provided by the standard PICS proforma;
— by the user, or potential user, of the implementation, as a basis
for initially checking the possibility of interworking with another
implementation (note that, while interworking can never be guar-
anteed, failure to interwork can often be predicted from
incompatible PICSs);
— by a protocol tester, as the basis for selecting appropriate tests
against which to assess the claim for conformance of the imple-
mentation.
D.2.InstructionsforCompletingthePICSProformas
D.2.1.General Structure of the PICS Proformas
D.2.1.1. The Implementation Identification and Protocol Summary is the first
part of eachPICS proforma and sh all be completed as indicated with
the information necessary to identify fully both the supplier and the
implementation.
D.2.1.2. The main part of the PICS proforma is a fixed-format questionnaire.
Answers to the questionnaire items shall be provided in the rightmost
column, either by simply marking an answer to indicate a restricted
choice (usually Yes or No), or by entering a value or a set or range
of values.
NOTES1. Each item is identified by a unique item reference in the first
column; the second column contains the question to be answered;
the third column contains the reference or references to the mate-
rial that specifies the item in this Eurocontrol Standard. The
remaining columns record the status of the item (whether support
is mandatory, optional, prohibited or conditional) and provide
space for the answers: see also below.
2. A supplier may also provide, or be required to provide, further
information categorised as either Additional Information or
Exception Information. When present, each kind of further infor-
mation is to be provided in a further subclause of items labelled
A<i> or X<i> respectively for cross-referencing purposes, where
<i> is any unambiguous identification for the item (e.g. simply a
numeral): there are no other restrictions on its format and presen-
tation.
D.2.1.3. A completed PICS proforma, including any Additional Information
and Exception Information, shall be referred to as the Protocol Imple-mentation Conformance Statement for the implementation in
question.
NOTEWhere an implementation is capable of being configured in
more than one way, a single PICS may be able to describe2000R2082 — EN — 15.06.2002 — 001.001 — 174
▼B
all such configurations. However, the supplier has the choice
of providing more than one PICS, each covering some subset
of the implementation's configuration capabilities, in case
that makes for easier and clearer presentation of the infor-
mation.
D.2.2.Additional Information
Items of Additional Information allow a supplier to provide further
information intended to assist the interpretation of the PICS.
NOTES
1. It is not intended or expected that a large quantity will be
supplied, and a PICS can be considered complete without any
such information. Examples might be an outline of the ways in
which a (single) implementation can be set up to operate in a
variety of environments and configurations; or a brief rationale
(based perhaps upon specific application needs) for the exclusion
of features which, although optional, are nonetheless commonly
present in implementations of this protocol.
2. References to items of Additional Information may be entered next
to any answer in the questionnaire, and may be included in items
of Exception Information.
D.2.3.Exception Information
D.2.3.1. It may occasionally happen that a supplier will wish to answer an
item with mandatory or prohibited status (after any conditions have
been applied) in a way that conflicts with the indicated requirement.
No pre-printed answer will be found in the Support column for this:
instead, the supplier shall write the missing answer into the Support
column, together with an X<i> reference to an item of Exception
Information.
D.2.3.2. The supplier shall provide the appropriate rationale in the Exception
item itself.
D.2.3.3. An implementation for which an Exception item is required in this
way does not conform to this specification.
NOTEA possible reason for the situation described above is that a
defect in the standard has been reported, a correction forwhich is expected to change the requirement not met by the
implementation.
D.2.4.Conditional Items
D.2.4.1. Individual conditional items are indicated by a conditional symbol of
the form ‘<item>: 
’ in the Status column, where ‘<item>’ is an
item reference that appears in the first column of the table for some
other item, and ‘
’ is a status symbol, M, O, O.<n> or X.
NOTEA PICS proforma may contain a number of conditional items.
These are items for which both the applicability of the item
itself, and its status if it does apply (mandatory, optional or
prohibited) are dependent upon whether or not certain other
items are supported.
D.2.4.2. If the item referenced by the conditional symbol is marked as
supported, the conditional item is applicable, and its status is given
by ‘
’: the support column shall be completed in the usual way.
Otherwise, the conditional item is not relevant and the Not Applic-
able (NA) answer shall be marked.
D.2.4.3. Eachitem wh ose reference is used in a conditional symbol is indi-
cated by an asterisk in the Item column.
D.3.PICSProforma fortheMessageTransferProtocol
D.3.1.Abbreviations and Special Symbols
D.3.1.1. Status Symbols
M: Mandatory
O: Optional2000R2082 — EN — 15.06.2002 — 001.001 — 175
▼B
D.3.1.2. Item References
Items in the PICS proforma are identified by mnemonic item refer-
ences. PICS items dealing withrelated functions are identified by
item references sharing the same initial letter or letter-pair (in capi-
tals). There follows a list of those initials, in the order in which the
groups of items occur in the PICS proforma.
— MTsy, MTop, MTst, Mtor message types
— MAE, MAR, MCI, MDT,
MAVprocedures
— MEsu, MEsd, MEhb, Mety encodings
— MNmsg message size
— Ts, Tr timers
D.3.2.Identification
2000R2082 — EN — 15.06.2002 — 001.001 — 176
▼B
D.3.3.Protocol Implementation
D.4.PICSProforma fortheMessageHeaderProtocol
D.4.1.Abbreviations and Special Symbols
D.4.1.1. Status Symbols
M mandatory
O optionalO.<n> optional, but support of at least one of the group of
options labelled by the same numeral <n> is required
X prohibited<item> conditional-item symbol, dependent upon the support
marked for <item> (see D.2.4)
D.4.1.2. Abbreviations
NA not applicable
D.4.1.3. Item References
Items in the PICS proforma are identified by mnemonic item refer-
ences. PICS items dealing withrelated functions are identified by
item references sharing the same initial letter or letter-pair (in capi-2000R2082 — EN — 15.06.2002 — 001.001 — 177
▼B
tals). There follows a list of those initials, in the order in which the
groups of items occur in the PICS proforma.
— IHC1, IHC2, IHC3, IHC4,
IHCCconnection establishment
— IHR1, IHR2 connection release
— IHT1, IHTx data transfer— Tcr timer
D.4.2.Identification
2000R2082 — EN — 15.06.2002 — 001.001 — 178
▼B
D.4.3.Protocol Implementation
D.5.PICSProforma fortheNetworkProtocol
D.5.1.Abbreviations and Special Symbols
D.5.1.1. Status Symbols
M mandatory
O optional
D.5.1.2. Item References
Items in the PICS proforma are identified by mnemonic item refer-
ences. PICS items dealing withrelated functions are identified by
item references sharing the same initial letter or letter-pair (in capi-
tals). There follows a list of those initials, in the order in which the
groups of items occur in the PICS proforma.
— SNDCP1 protocol ID field2000R2082 — EN — 15.06.2002 — 001.001 — 179
▼B
— NCRdae, NCRgae, NCCx,
NDRxparameters in protocol messages
— NCD1, NCD2, NCN1, NCN2 validation of addresses
— NDT data transfer
D.5.2.Identification
D.5.3.Protocol Implementation
2000R2082 — EN — 15.06.2002 — 001.001 — 180
▼B
ANNEX E (Normative)
PROFILEREQUIREMENTSLIST
E.1.Introduction
E.1.1. This Annex provides the PRL for the FDE ICD profile defined in this
Eurocontrol Standard Document. The Implementation Conformance
Statement for an implementation claiming conformance to this profile
shall be generated in accordance with the instructions given below.
NOTEThe proformas in this Annex are based on those accompa-
nying the referenced base standards.
E.1.2. A conforming implementation shall satisfy the mandatory confor-
mance requirements of the base standards referenced in this profile.
E.2.TheRoleofthePRLandPICSProformas
The status of this section (E.2) is informative: it does not constitute a
provision of this Part of this Eurocontrol Standard.
— The objective of presenting the conformance requirements in the
tabular form of the PRL and PICS proformas is to provide a
check-list of the features which must or may be implemented.
The underlying concepts are defined and described in ISO/IEC
9646-1 [Reference 14] (ITU-T Recommendation X.290 is equiva-
lent) and ISO/IEC TR 10000-1 [Reference 2].
— A profile combines and selects the options of several base stan-
dards in order to fulfil a specific information processing
function. Each base standard has a PICS proforma, listing the
requirements of the standard. The PRL comprises the subset of
the base standard PICS proforma items that are constrained by
the profile, together with the specific profile requirements; it
defines answers required on the base standard PICS proformas to
conform with the profile. In addition, the PRL will contain PICS-type items which are specific to the profile (at the least, there will
be a item testing whether all the required PICS proformas have
been correctly completed); these items must be completed
together with the base standard PICS proformas. The completed
proformas together constitute the profile Implementation Confor-
mance Statement (ICS).
— Following the methodology of ISO/IEC TR 10000-1
[Reference 2], a claim of conformance to a profile has to be
supported by PICS proformas completed in accordance withth e
PRL. The use of this material will depend on the procurement
approachfor an FDE ICD implementation.
— Several possible approaches to an FDE implementation can be
imagined:
— In-house implementation by a National Administration or
Organisation: the PRL should be used as the basis of the
requirements specification and acceptance test specification
for the implementation; the completed ICS should be
produced as part of the acceptance procedure.
— Implementation of the profile by a contractor: the material
will be used and produced as for an in-house implementation,
but the contractor should provide the ICS and the need for this
must be a contractual requirement.
— Implementation of the profile by a contractor as part of a turn-
key or system integration contract: the material will be used
and produced as for an in-house implementation, but the
contractor must be required to do this internally as well as
providing the completed ICS. Conformance to the profile
ensures, for instance, that a supplier working for two adminis-
trations cannot introduce its proprietary protocols to meet the
FDE requirement and thus helps to give control to the
contracting administrations.
— Integration of off-the-shelf products into a profile implementa-
tion in any of the previous cases: the supplier of a product
should be required to provide those PICS proformas relevant
to the product completed in accordance with the PRL given
here and to warrant the conformance of the product with the
applicable profile requirements; this PICS can then be
forwarded as part of the profile ICS.2000R2082 — EN — 15.06.2002 — 001.001 — 181
▼B
— Following implementation, the ICS should be maintained as part
of the documentation of the implementation; it can be used to
predict interoperability withoth er administrations, and to identify
changes that may be needed in moving to different protocols.
E.3.Notation
E.3.1. The following notations from ISO/IEC TR 10000-1 [Reference 2] are
used in the PRL to indicate the status of features:
m: mandatory
o: optional
-: not applicable (i.e. logically impossible in the scope of the
profile)
x: excluded
NOTES
1. Two-character combinations may be used, in which case the first
character refers to the static (implementation) status, and the
second to the dynamic (use); thus ‘mo’ means ‘mandatory to be
implemented, optional to be used’.
2. The ‘o.<n>’ notation is used to show a set of selectable options
(i.e. at least one of the set must be implemented) with the same
identifier n.
3. A feature marked ‘x’ may nonetheless be part of an implementa-
tion so long as it is not used when the implementation is
operating in conformance with the profile.
4. Use of features marked ‘x’ would require bilateral agreement. In
this event, the status of the features should be revised as they may
be of interest to other implementations.
E.3.2. The following predicate notation is used:
<predicate>:: introduces a group of items, all of which are condi-
tional on <predicate> (the extent of the group is shown by the
layout).
<predicate>: introduces a single item which is conditional on <predi-
cate>.
NOTEIn each case, the predicate may be the identifier of a profile
feature, or a boolean combination of predicates (‘ ¬’ is the
symbol for logical negation).
E.3.3. Base standard requirements are shown using the equivalent notations
in upper case (i.e. M, O, O.<n>, X).
E.4.InstructionsforCompletingthePICSProformas
E.4.1. To provide the profile ICS, the PICS proformas for the referenced
base standards shall be completed, together with the additional
profile-related PICS items provided in this Annex.
E.4.2. Where this profile refines the features of the base standards, the
requirements expressed in this PRL shall be applied (as indicated in
PRL items witha ‘Profile features’ column) to constrain th e allow-
able responses in the base standard PICS proformas.
E.4.3. Where this profile makes additional requirements, the response
column for such items shall be completed. In this column, each
response shall either be selected from the indicated set of responses,
or comprise a parameter value or values or range of values as
requested.
E.4.4. If a mandatory requirement is not satisfied, exception information
must be supplied, by entering a reference X<i>, where <i> is a
unique identifier, to an accompanying rationale for the non-compli-
ance.
NOTEA possible reason for such an exception is compliance with a
pending defect report on a provision of the profile; if the
defect report is accepted, the implementation will then be
conformant.2000R2082 — EN — 15.06.2002 — 001.001 — 182
▼B
E.5.References
E.5.1. This profile references the following protocol specifications:
— Message Transfer Protocol (Annex A to this Eurocontrol Standard
Document);
— Message Header Protocol (Annex B to this Eurocontrol Standard
Document);
— Connection-mode Network Protocol using ISO/IEC 8208 (Annex
C to this Eurocontrol Standard Document);
— ISO/IEC 7776 [Reference 6];— Physical Layer Standards called up by ITU-T Recommendation
X.25 (1993) clause 1 [Reference 1].
E.5.2. As there are no explicit PICS proformas for the relevant Physical
Layer Standards, the interim physical layer PICS proformas in ISO/
IEC ISP 10609-9 clause A.4 [Reference 8] shall be used.
E.6.ConformanceStatement
E.6.1.Conformance Overview
2000R2082 — EN — 15.06.2002 — 001.001 — 183
▼B
E.6.2.Dynamic Conformance Requirements
E.7.UpperLayerRequirements
Table 3
Message Transfer Protocol
Base Standard Features Profile Features
Item Message Transfer Protocol References Status References Status
MTst — status messages A.4.2 O ox
MTor — operator messages A.4.2 O ox
E.8.LowerLayerRequirements
E.8.1.Transport Layer Requirements
Table 4
Message Header Protocol
Base Standard Features Profile Features
Item Message Header Protocol References Status References Status
IHTx Use of the fields
ADEST, DEST,
AEMM, EMM and
ADR withvalues oth er
than '40'HB.4.4 O ox
E.8.2.Network Layer Requirements
The PRLs given in this section are based on the PICS proforma for
ISO/IEC 8208:1993 [Reference 7]. The entries in the ‘References’
column under ‘Base standard features’ of the following tables are
references to clauses in that standard.2000R2082 — EN — 15.06.2002 — 001.001 — 184
▼B
E.8.2.1. General DTE Characteristics
Table 5
General DTE Characteristics
Base Standard Features Profile Features
ItemGeneral DTE Characteris-
ticsReferences Status References Status
Service supported:
Vs — virtual call O.1 m
Vp — permanent virtual
circuitO.1 x
Environments
supported:3, 3.2
Ec/3 — DTE/DCE(1993) O.2 6.3.2 o.2
Ec/8 — DTE/DCE(1988) O.2 6.3.2 o.2
Ec/4 — DTE/DCE(1984) O.2 6.3.2 o.2
Ec/0 — DTE/DCE(1980) O.2 6.3.2 o.2
Et/t — DTE/DTE in fixed
role as DTEO.2 6.3.2 o.2
Et/c — DTE/DTE in fixed
role as DCEVs: O.2 6.3.2 o.2
Et/d — DTE/DTE with
dynamic role selection4.5 Vs: O.2 x
Packet sequence
numbering supported:
M8 — Modulo 8 13.2, 12.1.1,
Table 3O.3 m
M128 — Modulo 128 13.2, 12.1.1,
Table 3O.3 x
Reference Number
optional user facility
supported, for alterna-
tive Logical Channel
Identifier assignment:13.29, 13.29.1,
13.29.2, 13.29.3,
13.29.4, Fig 31
RNa — without reversion to
use of logical
channel ranges13.29.2.1 Et:O
¬Et:Xx
RNb — withpossible rever-
sion to use logical
channel ranges13.29.2.1 Et:O
¬Et:Xx
E.8.2.2. Procedures, Packet Types and Packet Formats
Table 6
Packet Layer Functions Independent of Logical Channels
Base Standard Features Profile Features
ItemPacket Layer Functions
Independent of Logical
ChannelsReferences Status References Status
Are the following
packet layer functions
supported:
Z2s Sending diagnostic
packet12.7, Table 24 Et:O
¬Et:Xx2000R2082 — EN — 15.06.2002 — 001.001 — 185
▼B
Base Standard Features Profile Features
ItemPacket Layer Functions
Independent of Logical
ChannelsReferences Status References Status
Z4i Initiating On-line
Facility Registration:13.1, 13.1.1.1,
13.1.1.3,
13.1.1.4Oo x
— send REGISTRA-
TION REQUEST12.9.1
— receive REGIS-
TRATION CONFIR-
MATION12.9.2, Table 10
Z4r Responding to On-line
Facility Registration:13.1, 13.1.1.1,
13.1.1.4Et:O –
— receive REGIS-
TRATION REQUEST12.9.1
— send REGISTRA-
TION CONFIRMA-
TION12.9.2, Table 10
Table 7
Call Setup
Base Standard Features Profile Features
Item Call Setup References Status References Status
Are outgoing Virtual
Calls supported:5.2.1, 5.2.5,
Table 33
S1a — Fast Select, no
restriction on
response?5.2.4, 13.16 O x
S1b — Fast Select with
restricted response?13.16 O x
S1c — non-Fast Select? 5.2.4 O m
SP1b CALL REQUEST,
basic format12.2.3.1 S1c:M
S1ab: O.4m
SP1e send CALL
REQUEST, extended
format12.2.3.1,
12.2.3.2S1ab: O.4 x
SP2b receive CALL
CONNECTED, basic
format12.2.4.1 S1ac:M m
SP2e receive CALL
CONNECTED,
extended format12.2.4.1,
12.2.4.2S1a:M –
Is alternative addres-
sing supported for
outgoing Virtual Calls:13.28
— using A = 1 and
expanded Address
Block format?13.28.2.1,
12.2.1.2Ec/3:O
¬Ec/3:Xx
— using the Called
Address Extension
Facility?13.28.2.2. Ec/3:O
¬Ec/3:Xx
Are incoming Virtual
Calls supported:5.2.2, 5.2.5,
Table 33
S2a — Fast Select with
acceptance possible?5.2.3, 13.17 O –
S2b — Fast Select, always
cleared?13.17 O m2000R2082 — EN — 15.06.2002 — 001.001 — 186
▼B
Base Standard Features Profile Features
Item Call Setup References Status References Status
S2c — non-Fast Select
withacceptance
possible?5.2.3 O m
S2d — non-Fast Select,
always cleared?5.2.3 O x
SP3b receive INCOMING
CALL, basic format12.2.3.1 S2:M m
SP3e receive INCOMING
CALL, extended
format12.2.3.1,
12.2.3.2S2ab:M
S2axc:
O.5–
SP4b send CALL
ACCEPTED, basic
format12.2.4.1 S2c:M
S2axc:
O.5m
SP4e send CALL
ACCEPTED, extended
format12.2.4.1,
12.2.4.2S2axc:
O.5
S2anc:O–
Is D-bit negotiation
supported:
DN1 — for outgoing Virtual
Calls6.3 S1ac:O m
DN2 — for incoming
Virtual Calls6.3 S1ac:O m
NOTE The D-bit shall always be negociated to 0.
Table 8
Call Clearing
Base Standard Features Profile Features
Item Call Clearing References Status References Status
Is call clearing
supported, for:5.5.4, Table 33
C1 — response to indica-
tion of clearing5.5.2 O m
C2a — aborting an
outgoing Virtual Call
attempt?5.4, 5.5.1, 5.5.3 S1:O o
C2b — rejecting an
incoming Virtual Call?5.3, 5.5.1, 5.5.3 S2bd:M
S2acxbd:
Om
C2c — originating clearing
of an established
Virtual Call?5.5.1, 5.5.3 O o
CP1b receive CLEAR INDI-
CATION, basic format12.2.5.1 Cany:M m
CP1e receive CLEAR INDI-
CATION, extended
format12.2.5.1,
12.2.5.2Cany:M –
CP2b send CLEAR
CONFIRMATION,
basic format12.2.6.1 C1:M m
CP2e send CLEAR
CONFIRMATION,
extended format12.2.6.1,
12.2.6.2C1rn:M x
CP3b send CLEAR
REQUEST, basic
format12.2.5.1 C2a:M
C2bcxa:
O.6m2000R2082 — EN — 15.06.2002 — 001.001 — 187
▼B
Base Standard Features Profile Features
Item Call Clearing References Status References Status
CP3e send CLEAR
REQUEST, extended
format12.2.5.1,12.2.5.2 C2bcxa:
O.6
C2axbc:
Xx
CP4b receive CLEAR
CONFIRMATION,
basic format12.2.6.1 C2:M m
CP4e receive CLEAR
CONFIRMATION,
extended format12.2.6.1,
12.2.6.2C2rnci:M –
Table 9
Resetting of Logical Channels
Base Standard Features Profile Features
ItemResetting of Logical Chan-
nelsReferences Status References Status
Is resetting supported: 8, 8.4, Table 34
RSi — as initiator? 8.1, 8.3 O mm
send RESET
REQUEST12.5.1
receive RESET
CONFIRMATION/
INDICATION12.5.2, 12.5.1
RSr — as responder? 8.2 O mm
receive RESET INDI-
CATION12.5.1
send RESET CONFIR-
MATION12.5.2
Table 10
Error Procedures
Base Standard Features Profile Features
ItemError Procedures (Virtual
Call Service)References Status References Status
Is ERROR-C proce-
dure:5.2.1, 5.4, 8.1,
Table 33
W1a — clear the Virtual
Call?O.7 m
W1b — restart the packet
layer?O.7 x
Is ERROR-R proce-
dure for virtual calls:6.3, 6.4, 6.6,
6.8.1, 6.8.2,
7.1.3, 7.1.4, 8.2,
11.2.1, 13.4.1,
Tables 34-36
W2sc — restart the packet
layer?O.8 x2000R2082 — EN — 15.06.2002 — 001.001 — 188
▼B
Table 11
Interrupt Transfer
Base Standard Features Profile Features
Item Interrupt Transfer References Status References Status
Is Is sending interrupts
supported?6.8, 6.8.1, 6.8.3,
Table 35Oo x
— send INTERRUPT
REQUEST12.3.2
receive INTERRUPT
CONFIRMATION12.3.3
Ir Is receiving interrupts
supported?6.8, 6.8.2, 6.8.3
Table 35O–
— receive INTER-
RUPT INDICATION12.3.2
— send INTERRUPT
CONFIRMATION12.3.3
Table 12
Sending Data
Base Standard Features Profile Features
Item Sending Data References Status References Status
DS1 Is sending of DATA
packets supported?6, 6.1, 7.1.1,
7.1.2, 7.1.3,
12.3.1Om m
Are the following
supported:
DS2 — send-window rota-
tion on receiving
updated P(R) values?7.1, 7.1.2, 7.1.3 O mm
DS4a — sending M = 0 in
DATA packets?6.4, 6.5, 6.7 M mo.9
DS4b — sending M = 1 in
DATA packets?6.4, 6.5, 6.7 O mo.9
DS5a — sending Q = 0 in
DATA packets?6.6 O.10 mm
DS5b — sending Q = 1 in
DATA packets?6.6 O.10 ox
DS6 — responding to
packet retransmission
requests (received
REJECT packets)?13.4.2 12.8 Et:O –
— Window Rotation
Timer procedure:
DS7a — ERROR-R action
on expiry11.2.1(a) O ox
DS7b — packet retransmis-
sion on expiry11.2.1(b) Et:O
¬Et:Xox
DS8 — discard of over-
lengthflow control
packets (instead of
ERROR-R)?Table 36 Note 2 O ox2000R2082 — EN — 15.06.2002 — 001.001 — 189
▼B
Table 13
Receiving Data
Base Standard Features Profile Features
Item Receiving Data References Status References Status
DR1 Is receiving of DATA
packets supported?6, 6.1, 6.2, 7.1.1,
7.1.2, 7.1.3,
12.3.1Om m
Are the following
supported:
DR2 — receive-window
rotation by sending
updated P(R)values?7.1.2, 7.1.3 O mm
DR3 — flow control by
sending RECEIVE
NOT READY and
RECEIVE READY?7.1.5, 7.1.6,
12.4.1, 12.4.2Om m
DR4b — receiving M = 1 in
DATA packets?6.4, 6.5, 6.7 O mm
DR5a — receiving Q = 0 in
DATA packets?6.6 O.11 mm
DR5b — receiving Q = 1 in
DATA packets?6.6 O.11 –
DR6 — requesting packet
retransmission by
sending REJECT
packets?13.4.1, 12.8 O ox
— recovery from
receipt of DATApackets containing
invalid P(S), by:
DR7a — ERROR-R action? 11.3(a) O.12 mm
DR7b — requesting packet
retransmission?11.3(b) O.12 ox
DR7c — ignoring the packet
and waiting for a
correct retransmitted
packet?11.3(c) O.12 ox
— recovery from
receipt of DATA
packets withinvalid
User Data field, by:
DR8a — ERROR-R action? 11.3(a) O.13 mm
DR8b — requesting packet
retransmission?11.3(b) O.13 ox
DR8c — ignoring the packet
and waiting for a
correct retransmitted
packet?11.3(c) O.13 ox
DR9 — Window Status
Transmission Timer
procedure?11.2.2 O ox
Table 14
Delivery Confirmation
Base Standard Features Profile Features
Item Delivery Confirmation References Status References Status
DC Is Delivery Confirma-
tion supported?6.3, 6.5, 6.7,
7.1.4Ox2000R2082 — EN — 15.06.2002 — 001.001 — 190
▼B
E.8.2.3. Miscellaneous Features and Options
Table 15
Values of Cause and Diagnostic Codes
Base Standard Features Status
ItemValues of Cause and Diag-
nostic CodesReferencesProfile
FeaturesReferences Status
In RESTART
REQUEST packets
sent:12.6.1.1,
12.6.1.2, Tables
24-25
Y1d — Cause = 128,
private diagnostic
codesO.14 ox
In RESTART INDI-
CATION packets
received:12.6.1.1, Table
9, 12.6.1.2
Y2b — Cause not 0 or 128,
any diagnostic code
valueEC:M
¬EC:Om
In CLEAR REQUEST
packets sent:12.2.3.1.1,
12.2.3.1.2,
Tables 24-25
Y3d — Cause = 128,
private diagnostic
codesO.15 ox
In CLEAR INDICA-
TION packets
received:12.2.3.1.1, Table
7, 12.2.3.1.2,
Y4b — Cause not 0 or 128,
any diagnostic code
valueEC:M
¬EC:Om
In RESET REQUEST
packets sent:12.5.1.1,
12.5.1.2, Tables
24-25
Y5d — Cause = 128,
private diagnostic
codesO.16 ox
In RESET INDICA-
TION packets
received:12.5.1.1, Table
8, 12.5.1.2
Y6b — Cause not 0 or 128,
any diagnostic code
valueEC:M
¬EC:Om
E.8.2.4. Facilities
Table 16
Facilities Sent in CALL REQUEST Packets
Base Standard Features Profile Features
ItemFacilities Sent in CALL
REQUEST PacketsReferences Status References Status
FS1pi Flow Control Para-
meter Negotiation,
packet size13.12, 15.2.2.1.1 O x
FS1wi Flow Control Para-
meter Negotiation,
window size13.12, 15.2.2.1.2 O x
FS2ib Basic Throughput
Class Negotiation13.13,
15.2.2.2.1, Table
20aOx2000R2082 — EN — 15.06.2002 — 001.001 — 191
▼B
Base Standard Features Profile Features
ItemFacilities Sent in CALL
REQUEST PacketsReferences Status References Status
FS2ie Extended Throughput
Class Negotiation13.13,
15.2.2.2.2, Table
20bOx
FS3b Closed User Group
Selection, basic format13.14.6,
15.2.2.3.1Oo
FS3e Closed User Group
Selection, extended
format13.14.6,
15.2.2.3.2Ox
FS4b Closed User Group
WithOutgoing Access
Selection, basic format13.14.7,
15.2.2.4.1Ox
FS4e Closed User Group
WithOutgoing Access
Selection, extended
format13.14.7,
15.2.2.4.2Ox
FS5 Bilateral Closed User
Group Selection13.15, 15.2.2.5 O x
FS6a Fast Select 13.16, 15.2.2.6 O x
FS6b Reverse Charging 13.18, 15.2.2.6 O x
FS6c ICRD Status Selection 13.25.4.2,
15.2.2.6Ox
FS7i Network User Identifi-
cation13.21, 13.21.3,
15.2.2.7Ox
FS8i Charging Information,
requesting service13.22, 15.2.2.8.1 O x
FS9b RPOA selection, basic
format13.23, 13.23.2,
15.2.2.9.1Ox
FS9e RPOA selection,
extended format13.23, 13.23.2,
15.2.2.9.2Ox
FS12 Transit Delay Selection
and Indication13.27, 15.2.2.13 O x
FS99i Local non-X.25 facil-
ities, following Facility
Marker15.1, Table 18 O x
FS98i Remote non-X.25
facilities, following
Facility Marker15.1, Table 18 O x
FS20i Facility Marker,
CCITT-specified DTE
facilities15.1 O x
FS21i Calling Address Exten-
sion14.1, 15.3.2.1 x
FS22i Called Address Exten-
sion14.2, 15.3.2.2 x
FS23ib Minimum Throughput
Class Negotiation,
basic format14.3, 15.3.2.3.1,
Table 20aOx
FS23ie Minimum Throughput
Class Negotiation,
extended format14.3, 15.3.2.3.2,
Table 20bO
FS24i End-to-end Transit
Delay Negotiation14.4, 15.3.2.4 O x
FS25i Expedited Data Nego-
tiation14.7, 15.3.2.7 O x
FS26i Priority 14.5, 15.3.2.5 O x
FS27i Protection 14.6, 15.3.2.6 O x2000R2082 — EN — 15.06.2002 — 001.001 — 192
▼B
Table 17
Facilities Sent in CALL ACCEPT Packets
Base Standard Features Profile Features
ItemFacilities Sent in CALL
ACCEPT PacketsReferences Status References Status
FS1pr Flow Control Para-
meter Negotiation,
packet size13.12,
15.2.2.1.1, Table
13Ox
FS1wr Flow Control Para-
meter Negotiation,
window size13.12,
15.2.2.1.2, Table
13Ox
FS2rb Basic Throughput
Class Negotiation13.13,
15.2.2.2.1, Table
20aOx
FS2re Extended Throughput
Class Negotiation13.13,
15.2.2.2.2, Table
20bOx
FS7r Network User Identifi-
cation13.21, 13.21.3
15.2.2.7Ox
FS8r Charging Information,
requesting service13.22, 15.2.2.8.1 O x
FS10r Called Line Address
Modified Notification13.26, 15.2.2.12 O x
FS99r Local non-X.25 facil-
ities, following Facility
Marker15.1, Table 18 O x
FS98r Remote non-X.25
facilities, following
Facility Marker15.1, Table 18 O x
FS20r Facility Marker,
CCITT-specified DTE
facilities15.1 O x
FS22r Called Address Exten-
sion14.2, 15.3.2.2 O x
FS24r End-to-end Transit
Delay Negotiation14.4, 15.3.2.4 O x
FS25r Expedited Data Nego-
tiation14.7, 15.3.2.7 O x
FS26r Priority 14.5, 15.3.2.5 O x
FS27r Protection 14.6, 15.3.2.6 O x
Table 18
Facilities Sent in CLEAR REQUEST Packets
Base Standard Features Profile Features
ItemFacilities Sent in CLEAR
REQUEST PacketsReferences Status References Status
FS10d Called Line Address
Modified Notification13.26, 15.2.2.12 O x
FS13 Call Deflection Selec-
tion13.25.2.2,
15.2.2.10Ox
FS99d Local non-X.25 facil-
ities, following Facility
Marker15.1, Table 18 O x
FS98d Remote non-X.25
facilities, following
Facility Marker15.1, Table 18 O x
FS20d Facility Marker,
CCITT-specified DTE
facilities15.1 O x2000R2082 — EN — 15.06.2002 — 001.001 — 193
▼B
Base Standard Features Profile Features
ItemFacilities Sent in CLEAR
REQUEST PacketsReferences Status References Status
FS22d Called Address Exten-
sion14.2, 15.3.2.2 O x
Table 19
Facilities Received in INCOMING CALL Packets
Base Standard Features Profile Features
ItemFacilities Received in
INCOMING CALL PacketsReferences Status References Status
FR1pi Flow Control Para-
meter Negotiation,
packet size13.12, 15.2.2.1.1 O x
FR1wi Flow Control Para-
meter Negotiation,
window size13.12, 15.2.2.1.2 O x
FR2ib Basic Throughput
Class Negotiation13.13, 15.2.2.2.1
Table, 20aOx
FR2ie Extended Throughput
Class Negotiation13.13, 15.2.2.2.2
Table, 20bOx
FR3b Closed User Group
Selection, basic format13.14.6,
15.2.2.3.1Oo
FR3e Closed User Group
Selection, extended
format13.14.6,
15.2.2.3.2Ox
FR4b Closed User Group
WithOutgoing Access
Selection, basic format13.4.7,
15.2.2.4.1Ox
FR4e Closed User Group
WithOutgoing Access
Selection, extended
format13.4.7,
15.2.2.4.2Ox
FR5 Bilateral Closed User
Group Selection13.15, 15.2.2.5 O x
FR6a Fast Select 13.16, 13.17,
15.2.2.6Ox
FR6b Reverse Charging 13.18, 13.19,
15.2.2.6Ox
FR11 Call Redirection or
Call Deflection Notifi-
cation13.25.3,
15.2.2.11Ox
FR12i Transit Delay Selection
and Indication13.27, 15.2.2.13 O x
FR99i Local non-X.25 facil-
ities, following Facility
Marker15.1, Table 18 O x
FR20i Facility Marker,
CCITT-specified DTE
facilities15.1 O x
FR21 Calling Address Exten-
sion14.1, 15.3.2.1 x
FR22i Called Address Exten-
sion14.2, 15.3.2.2 x
FR23b Minimum Throughput
Class Negotiation,
basic format14.3, 15.3.2.3.1,
Table 20aOx
FR23e Minimum Throughput
Class Negotiation,
extended format14.3, 15.3.2.3.2,
Table 20bOx2000R2082 — EN — 15.06.2002 — 001.001 — 194
▼B
Base Standard Features Profile Features
ItemFacilities Received in
INCOMING CALL PacketsReferences Status References Status
FR24i End-to-end Transit
Delay Negotiation14.4, 15.3.2.4 O x
FR25i Expedited Data Nego-
tiation14.7, 15.3.2.7 O x
FR26i Priority 14.5, 15.3.2.5 O x
FR27i Protection 14.6, 15.3.2.6 O x
Table 20
Facilities Received in CALL CONNECTED Packets
Base Standard Features Profile Features
ItemFacilities Received in
CALL CONNECTED
PacketsReferences Status References Status
FR1pr Flow Control Para-
meter Negotiation,
packet size13.12,
15.2.2.1.1, Table
14Ox
FR1wr Flow Control Para-
meter Negotiation,
window size13.12,
15.2.2.1.2, Table
14Ox
FR2rb Basic Throughput
Class Negotiation13.13,
15.2.2.2.1, Table
20aOx
FR2re Extended Throughput
Class Negotiation13.13,
15.2.2.2.2, Table
20bOx
FR10r Called Line Address
Modified Notification13.26, 15.2.2.12 O x
FR12r Transit Delay Selection
and Indication13.27, 15.2.2.13 O x
FR99r Local non-X.25 facil-
ities, following Facility
Marker15.1, Table 18 O x
FR20r Facility Marker,
CCITT-specified DTE
facilities15.1 O x
FR22r Called Address Exten-
sion14.2, 15.3.2.2 O x
FR24r End-to-end Transit
Delay Negotiation14.4, 15.3.2.4 O x
FR25r Expedited Data Nego-
tiation14.7, 15.3.2.7 O x
FR26r Priority 14.5, 15.3.2.5 O x
FR27r Protection 14.6, 15.3.2.6 O x
Table 21
Facilities Received in CLEAR INDICATION Packets
Base Standard Features Profile Features
ItemFacilities Received in
CLEAR INDICATION
PacketsReferences Status References Status
FR8ad Charging information,
monetary unit13.22, 15.2.2.8.2 O x2000R2082 — EN — 15.06.2002 — 001.001 — 195
▼B
Base Standard Features Profile Features
ItemFacilities Received in
CLEAR INDICATION
PacketsReferences Status References Status
FR8bd Charging information,
segment count13.22, 15.2.2.8.3 O x
FR8cd Charging information,
call duration13.22, 15.2.2.8.4 O x
FR10d Called Line Address
Modified Notification13.26, 15.2.2.12 O x
FR99d Local non-X.25 facil-
ities, following Facility
Marker15.1, Table 18 O x
FR20d Facility Marker, ITU-
T-specified DTE facil-
ities15.1 O x
FR22d Called Address Exten-
sion14.2, 15.3.2.2 O x
Table 22
Facilities Received in CLEAR CONFIRMATION Packets
Base Standard Features Profile Features
ItemFacilities Received in
CLEAR CONFIRMATION
PacketsReferences Status References Status
FR8af Charging information,
monetary unit13.22, 15.2.2.8.2 O x
FR8bf Charging information,
segment count13.22, 15.2.2.8.3 O x
FR8cf Charging information,
call duration13.22, 15.2.2.8.4 O x
E.8.2.5. Parameter Values and Ranges
Table 23
Parameter Values and Ranges
Base Standard Features Profile Features
ItemParameter Values and
RangesReferences Status References Status
What values are
supported:
V1s — Default packet sizes
(sending)?16.2.2.5 16, 32,
64, 128,
256, 512,
1 024,
2 048,
4 096
octets6.3.2 At
least
128
and
256
V1r — Default packet sizes
(receiving)?16.2.2.5 16, 32,
64, 128,
256, 512,
1 024,
2 048,
4 096
octets6.3.2 At
least
128
and
256
V2s — Default window
sizes, sending?16.2.2.6 ( M8:in
the range
1-7)22000R2082 — EN — 15.06.2002 — 001.001 — 196
▼B
Base Standard Features Profile Features
ItemParameter Values and
RangesReferences Status References Status
V2r — Default window
sizes, receiving?16.2.2.6 ( M8:in
the range
1-7)2
E.8.3.Datalink Layer Requirements
The PRLs given in this section are based on the PICS proforma for
ISO/IEC 7776:1994 [Reference 6]. The entries in the ‘References’
column under ‘Base standard features’ of the following tables are
references to clauses in that standard.
Table 24
Datalink Protocol
Base Standard Features Profile Features
Item Data Link Protocol References Status References Status
Lm Multilink procedure 6 O ox
Lc DTE/DCE operation 1, 5.1 M mo.1
Lt DTE/DTE operation 1, 5.1 O mo.1
M8 Basic (Modulo 8)
operation1, 3, 4.1.1 O.1 mm
M128 Extended (Modulo
128) operation1, 3, 4.1.1 O.1 ox
T4 Timer T4 procedure 5.3.2, 5.6.1 O mm
SPN1 Maximum number
(N1) of bits in an I-
frame5.7.3 N1 ≥1
080N1≥
2 104
SPk Maximum number of
outstanding frames (k)5.7.4 1 ≤k≤
7k=7
E.8.4.Physical Layer Requirements
See ISO/IEC TR 10609-9 clause A.4 [Reference 8].2000R2082 — EN — 15.06.2002 — 001.001 — 197
▼B
ANNEX F (Informative)
CONFORMANCETESTINGMETHODOLOGY
F.1.Introduction
F.1.1. It is important that implementations of this ICD are such that there is
a high level of confidence for interoperation between Air Traffic
Control Centres (ATCCs) interworking across the interface.
F.1.2. Implementations of the interface are undertaken by member states in
a manner that is likely to rely on procurement from various sources.
To achieve a high level of confidence that such implementations will
interoperate, a common set of conformance test requirements is
required to standardise preparation for test, testing and presentation
of results.
F.2.PurposeandScope
F.2.1. This Annex defines requirements for the testing of conformance of
implementations of this Eurocontrol Standard of which this Annex is
a part.
F.2.2. It identifies mechanisms whereby confidence in the declared interface
is established through a process of test to validate the claim.
F.3.Bibliography
The following document is relevant to the testing of implementations
of this Eurocontrol Standard Document:
Eurocontrol (Maastricht Upper Area Control (UAC) Systems Divi-
sion) FDE ICD Part 1 Integration Test Plan Version 1.0, dated 10
May 1996 [Reference 15].
F.4.DevelopmentMethodsandPractices
F.4.1. Implementations of the ICD can be effected using certain options and
versions of the ICD itself. In order to establish the potential for inter-
working, a Member State implementing the interface must identify
which parts of the ICD are supported with a defined statement as to
the capability and what limitations, if any, on variable parameters are
supported.
F.4.2. Any implementation should be subject to a conformance test as
described below.
F.5.Tests
F.5.1.Introduction
F.5.1.1. In order to provide confidence in and support for FDE Interface
within an ATCC to the interworking between co-operating FDE
applications, it is desirable for eachto be tested for conformance to
the standards of which this Annex forms a part. Such testing is
against the external behaviour of the System Under Test (SUT) and
is intended to test for interworking rather than the serviceability of
the end system.
F.5.1.2. The results of such testing can serve as evidence in support of claims
of conformance made in accordance withSection 5.1 of th is part of
this Eurocontrol Standard Document. The PICS proformas and PRLs
called up by this profile specification can be used as the basis of
conformance tests; in addition, international standards (e.g. ISO/IEC
8208 [Reference 7]) may already have abstract test suites defined
that can be used in conformance testing.
F.5.1.3. The intention of this document is to provide for a standardised
programme of test relying on a standardised test suite, use of which
should lead to comparability of test results, wide acceptance of such
test results and a minimisation of conformance testing required. The
standardised test suite has been developed, in part, by Eurocontrol.
F.5.1.4. Based on Figure 2, the testing of the complete end system takes the
form of tests on the lower 3 layers. It is advisable that testing include
tests on the FDE application, Status, System and Operator Messages.2000R2082 — EN — 15.06.2002 — 001.001 — 198
▼B
F.5.1.5. Each test described below should be conducted in order. The latter
test will only be successful if the lower layers are functioning
correctly and it is likely that this will be ascertained with the earlier
tests.
F.5.1.6. Notwithstanding the above, the testing described in this section is
voluntary.
F.5.2.Testing of the Lower Layers (Layers 1-3)
In support of the requirement for inter-operation between any one
ATCC and its peers, it is recommended that any testing shall be based
on the use of the test plan given in the Eurocontrol (Maastricht UAC
Systems Division) FDE ICD Integration Test Plan. Test procedures
are to be bilaterally agreed between co-operating ATCCs.
F.5.3.Testing of the Application Layer
A series of bilaterally agreed tests should be agreed and conducted
between co-operating ATCCs.
F.5.4.Certification
The results of tests should be recorded and agreed between the co-
operating parties.
F.5.5.Notification
Member states should pass details of the results of any tests to Euro-
control.2000R2082 — EN — 15.06.2002 — 001.001 — 199
▼B
ANNEX G (Informative)
ASSIGNMENTOFATCUNITIDENTIFIERS
The following table shows the ATC unit identifiers assigned as at April 22nd,
1997. The Eurocontrol can provide information on the current assignment of
identifiers. The table also shows in hexadecimal the binary encoding of the iden-
tifier as part of the NSAP address encoding defined in Annex C.
Table 1
ATC Unit Identifiers
ATC Unit Identifier Encoding Description
00 Reserved
01 '01'H CATCAS, Copenhagen
02 '02'H MADAP, Maastricht
03 '03'H ZKSD, Frankfurt/Main
04 '04'H CANAC Brussels
05 '05'H Generic CAUTRA, France
06 '06'H Dublin
07 '07'H Shannon
08 '08'H LATCC, London
09 '09'H Oslo ATCC
10 '10'H Karlsruhe ATCC
11 '11'H Langen (future German system)
12 '12'H FATMI-system, Tampere
13 '13'H ROVA-system, Rovaniemi14 '14'H VAS, Vienna
15 '15'H CFMU Haren
16 '16'H CFMU Brétigny
17 '17'H Geneva ACC/FMP
18 '18'H ZurichACC/FMP
19 '19'H Barcelona
20 '20'H Madrid
21 '21'H Palma
22 '22'H Milan
23 '23'H Rome
24 '24'H Jersey
25 '25'H Shanwick
26 '26'H Athis-Mons
27 '27'H Reims
28 '28'H Brest
29 '29'H Bordeaux
30 '30'H Aix-en-Provence
31 '31'H Bratislava
32 '32'H Stockholm-Arlanda
33 '33'H Malmö-Sturup
34 '34'H Sundsvall35 '35'H Lisbon
36 '36'H Seville
37 '37'H Gran Canaria
38 '38'H Prague2000R2082 — EN — 15.06.2002 — 001.001 — 200
▼B
ATC Unit Identifier Encoding Description
39 '39'H Amsterdam
40 '40'H LIZ Offenbach
41 '41'H German Military System
42 '42'H German Military System
43 '43'H German Military System
44 '44'H German Military System
45 '45'H German Military System
46 '46'H German Military System
47 '47'H German Military System
48 '48'H German Military System
49 '49'H German Military System
50 '50'H Munchen (Future German System)
51 '51'H Zagreb
52 '52'H Hahn Airport, Germany
53 '53'H Santa Maria FIR
54 '54'H Ljubljana
55 '55'H Belgian Military System
56 '56'H Budapest57 '57'H Warsaw2000R2082 — EN — 15.06.2002 — 001.001 — 201
▼B
ANNEX H (Informative)
GUIDANCEONRELIABILITY,AVAILABILITYANDSECURITY
H.1.Introduction
It is expected that ATC applications such as OLDI shall make use of
interconnected X.25 networks and/or public or private telecommuni-
cation services. As a consequence, it is deemed necessary to provide
guidance to FDE ICD Part 1 implementations.
H.2.PurposeandScope
H.2.1. The purpose of this Annex is to give guidance on issues relating to
reliability, availability and security.
H.2.2. The scope of this Annex is based on two scenarios. The first scenario
is a point-to-point connection over leased line. The second scenario is
based within an interconnected X.25 network environment.
NOTE For the second scenario, issues relating to the interconnection
of the X25 networks are not considered.
H.2.3. It is assured that implementations are physically protected against
intrusion, power failures and other external threats that can affect
normal operation.
H.3.Bibliography
The following document is a detailed technical analysis of which this
Annex is an overview:
Eurocontrol FDE ICD Part 1: Reliability, Availability and Security
— Technical Report [Reference 16].
H.4.LeasedLineImplementations
H.4.1.Reliability
To increase service reliability, leased line, PSTN, Integrated Services
Digital Network (ISDN) cables must follow physically different paths
and linked to different telecommunication operator switches (this
must be specified to the telecommunication operator).
H.4.2.Availability
H.4.2.1. Due to long setup times on PSTN which are incompatible with time
constraining applications, ISDN should be used as a backup medium.
H.4.2.2. In event of DTE switchover, the standby DTE should generate a
DISC frame to accelerate connection re-establishment.
H.4.3.Security
H.4.3.1. When using ISDN as backup medium, the called ISDN terminal
adapter (TA) should validate the caller's E.164 address [Reference
18].
H.4.3.2. The calling DTE should comply to ITU-T Recommendation X.32
[Reference 17] by including caller identification and for authentica-
tion information.2000R2082 — EN — 15.06.2002 — 001.001 — 202
▼B
H.4.4.Configuration Example
Figure H.1
Leased Line Configuration Example
H.5.NetworkImplementation
H.5.1.Reliability
To increase service reliability, hosts on a given site should be
connected to two DCEs belonging to different network switches
(this requirement should be specified to the network operator).
H.5.2.Availability
H.5.2.1. The hunt group facility should be used so as to be able to assign a
single X.121 address [Reference 20] to the DCEs located on a given
site, thereby optimising network routing and limiting unsuccessful
calls.
H.5.2.2. In the event other call mechanisms are implemented resulting in a
different called DTE address value in the CALL REQUEST and
CALL ACCEPT packets, the calling DTE should be configured so
there is no impact on the setting up of the call.
H.5.2.3. In the event of DCE disconnection due to a network failure and a
second access to the network is available, call re-establishment
should be made via this second access.
H.5.3.Security
Within the scope of this Annex, the Closed User Group (CUG)
facility is the only applicable network facility that should be used.
H.6.GeneralGuidanceforLeasedLineandNetworkImplementations
H.6.1.Reliability
H.6.1.1. As a full host switchover can be long, it is advantageous to consider
the use a front-end processor (FEP) to cater for host failures.
H.6.1.2. An architecture based on an FEP can increase service reliability.
NOTE Inclusion of a transport stack in the profile specification may
be developed in the context of a future FDE ICD Part 2 stan-
dard.
H.6.2.Availability
When a call is unsuccessful, the calling site should make a second
call using the second X.121 address (if available).
H.6.3.Systems Management
H.6.3.1. The use of switches that are automatically toggled by scanning of the
interface signals should be used where possible.2000R2082 — EN — 15.06.2002 — 001.001 — 203
▼B
H.6.3.2. A local error indication during data transmission can be used to
trigger a host switchover.
H.6.3.3. The switchover of a FEP should generate a TC-disconnect to ensure
the local host is in the IDLE state.
H.6.3.4. On expiry of the time-outs on the X.25 network or datalink layers,
the higher layers should be released.
H.6.3.5. A total FEP failure should generate a TC-disconnect.
H.6.3.6. The management system should poll the Message Transfer Protocol
layer (Annex A) and check the state machine to distinguish between
a Message Transfer Protocol failure and an application failure.
H.6.4.Configuration Example
Figure H.2
Network Configuration Example2000R2082 — EN — 15.06.2002 — 001.001 — 204