Commission Regulation (EC) No 2082/2000 of 6 September 2000 adopting Eurocontrol standards and amending Directive 97/15/EC, adopting Eurocontrol standards and amending Council Directive 93/65/EEC
Date: 2000-09-06
Institutions: European Commission
Subjects: Eurocontrol, air traffic, air traffic control, electronic equipment, technical specification, technical standard

9.10.2000

EN

Official Journal of the European Communities

L 254/1

I

(Acts whose publication is obligatory)

COMMISSION

COMMISSION REGULATION (EC) No 2082/2000

of 6 September 2000

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

THE COMMISSION OF THE EUROPEAN COMMUNITIES,

(3)

Having regard to the Treaty establishing the European Com-
munity,

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

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

(4)

(5)

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

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

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

Whereas:

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

HAS ADOPTED THIS REGULATION:

Article 1

(2)

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

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

(1) OJ L 187, 29.7.1993, p. 52.
(2) OJ L 95, 10.4.1997, p. 16.

— 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,

L 254/2

EN

Official Journal of the European Communities

9.10.2000

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

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

Article 2

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

Article 3

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

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

Done at Brussels, 6 September 2000.

For the Commission

Loyola DE PALACIO

Vice-President

9.10.2000

EN

Official Journal of the European Communities

L 254/3

ANNEX I

ON-LINE DATA INTERCHANGE (OLDI) EDITION 2.2

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

L 254/4

EN

Official Journal of the European Communities

9.10.2000

TABLE OF CONTENTS

COPYRIGHT NOTICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

FOREWORD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.

1.1.

1.2.

2.

3.

3.1.

3.2.

4.

4.1.

4.2.

INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

DEFINITIONS, SYMBOLS AND ABBREVIATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Symbols and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

GENERAL REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Flight Data Processing System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2.1.

Flight Data Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2.2.

Operation in Real Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2.3.

Data Communications Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2.4.

Application Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2.5.

Human-Machine Interface (HMI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2.6.

Initiation of Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2.7.

Reception of Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3.

4.4.

Updating from Surveillance Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Recording of OLDI Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4.1.

Content

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4.2.

Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.5.

Availability, Reliability, Data Security and Data Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.5.1.

Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.5.2.

Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.5.3.

Data Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.5.4.

Data Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

12

15

15

15

15

16

16

18

19

19

20

20

20

20

20

21

21

22

22

22

22

22

22

22

23

23

23

9.10.2000

EN

Official Journal of the European Communities

L 254/5

4.6.

Operational Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.6.1.

Evaluation Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.6.2.

Operational Introduction Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.

MESSAGE CATEGORIES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1.

General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1.1.

Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1.2.

Message Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2.

Transaction Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2.1.

Transaction Time Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3.

Message Classification and Categorisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3.1.

Message Classification — Mandatory and Complementary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3.2.

Categorisation of Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.

BASIC PROCEDURE — MANDATORY MESSAGES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.1.

General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.1.1.

Description of Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.1.2.

Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.2.

Advance Boundary Information Message (ABI)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.2.1.

Purpose of the ABI Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.2.2.

Message Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.2.3.

Rules of Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.2.4.

Acknowledgement of ABI

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.2.5.

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.3.

Activate Message (ACT)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.3.1.

Purpose of the ACT Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.3.2.

Message Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.3.3.

Rules of Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.3.4.

Acknowledgement of ACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.3.5.

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

23

23

23

23

23

23

24

24

24

24

25

26

26

26

26

26

26

27

27

28

28

29

29

29

29

31

31

L 254/6

EN

Official Journal of the European Communities

9.10.2000

6.4.

Logical Acknowledgement Message (LAM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.4.1.

Purpose of the LAM Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.4.2.

Message Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.4.3.

Rules of Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.4.4.

Acknowledgement of LAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.4.5.

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.

BASIC PROCEDURE — COMPLEMENTARY MESSAGES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.1.

General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.1.1.

Description of Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.1.2.

Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.2.

Preliminary Activate Message (PAC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.2.1.

Purpose of the PAC Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.2.2.

Message Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.2.3.

Rules of Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.2.4.

Acknowledgement of PAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.2.5.

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.3.

Revision Message (REV)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.3.1.

Purpose of the REV Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.3.2.

Message Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.3.3.

Rules of Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.3.4.

Acknowledgement of REV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.3.5.

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.4.

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

7.4.1.

Purpose of the MAC Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.4.2.

Message Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.4.3.

Rules of Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.4.4.

Acknowledgement of MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.4.5.

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

31

32

32

32

32

32

32

32

32

33

33

33

33

35

35

36

36

36

36

38

39

39

39

39

39

41

41

9.10.2000

EN

Official Journal of the European Communities

L 254/7

7.5.

SSR Code Assignment Message (COD)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.5.1.

Purpose of the COD Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.5.2.

Message Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.5.3.

Rules of Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.5.4.

Acknowledgement of COD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.5.5.

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.6.

Information Message (INF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.6.1.

Purpose of the INF Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.6.2.

Message Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.6.3.

Rules of Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.6.4.

Acknowledgement of INF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.6.5.

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.

DIALOGUE PROCEDURE — COORDINATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.1.

General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.1.1.

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.1.2.

The Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.1.3.

Message Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.1.4.

Simultaneous Message Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.1.5.

Reject Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.1.6.

Operational Reply Time-out

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.1.7.

Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.2.

Activate Message (ACT)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.2.1.

Purpose of the ACT Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.2.2.

Message Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.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 Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.3.2.

Message Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

42

42

42

43

43

43

43

43

44

44

44

45

45

45

45

46

47

47

47

47

48

48

48

48

49

49

49

49

L 254/8

EN

Official Journal of the European Communities

9.10.2000

8.3.3.

Rules of Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.3.4.

Acknowledgement of RAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.3.5.

Operational Reply to RAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.3.6.

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.4.

Revision Message (REV)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.4.1.

Purpose of the REV Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.4.2.

Message Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.4.3.

Rules of Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.4.4.

Acknowledgement of REV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.4.5.

Operational Reply to REV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.5.

Referred Revision Proposal Message (RRV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.5.1.

Purpose of the RRV Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.5.2.

Message Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.5.3.

Rules of Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.5.4.

Acknowledgement of RRV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.5.5.

Operational Reply to RRV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.5.6.

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.6.

Stand-by Message (SBY)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.6.1.

Purpose of the SBY Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.6.2.

Message Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.6.3.

Rules of Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.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 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.7.4.

Acknowledgement of ACP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.7.5.

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

50

51

51

51

51

51

51

52

52

53

53

53

53

53

54

54

54

54

54

55

55

55

55

55

55

56

56

57

9.10.2000

EN

Official Journal of the European Communities

L 254/9

8.8.

Co-ordination Message (CDN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.8.1.

Purpose of the CDN Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.8.2.

Message Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.8.3.

Rules of Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.8.4.

Acknowledgement of CDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.8.5.

Operational Reply to CDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.8.6.

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.9.

Reject Co-ordination Message (RJC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.9.1.

Purpose of the RJC Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.9.2.

Message Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.9.3.

Rules of Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.9.4.

Acknowledgement of RJC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.9.5.

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.

DIALOGUE PROCEDURE — TRANSFER OF COMMUNICATION . . . . . . . . . . . . . . . . . . . . . . . . . .

9.1.

General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.1.1.

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.1.2.

Message Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.1.3.

Transfer of Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.2.

Transfer Initiation Message (TIM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.2.1.

Purpose of the TIM Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.2.2.

Message Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.2.3.

Rules of Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.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 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.3.4.

Acknowledgement of SDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.3.5.

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

57

57

58

58

59

59

59

59

59

60

60

60

60

60

60

61

61

61

61

61

62

62

63

63

63

63

64

64

65

L 254/10

EN

Official Journal of the European Communities

9.10.2000

9.4.

Hand-Over Proposal (HOP)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.4.1.

Purpose of the HOP Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.4.2.

Message Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.4.3.

Rules of Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.4.4.

Acknowledgement of HOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.4.5.

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.5.

Request on Frequency Message (ROF)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.5.1.

Purpose of the ROF Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.5.2.

Message Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.5.3.

Rules of Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.5.4.

Acknowledgement of ROF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.5.5.

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.6.

Change of Frequency Message (COF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.6.1.

Purpose of the COF Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.6.2.

Message Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.6.3.

Rules of Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.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 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.7.4.

Acknowledgement of MAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.7.5.

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ANNEX A (NORMATIVE) DATA INSERTION RULES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ANNEX B (NORMATIVE)

SPECIAL ROUTE PROCESSING REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . .

ANNEX C (INFORMATIVE) DIALOGUE PROCEDURE (SYSCO LEVEL 1) PHASES — MESSAGE
SEQUENCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

65

65

65

66

66

67

67

67

67

67

68

68

68

68

68

69

69

69

69

69

69

70

70

71

82

88

9.10.2000

EN

Official Journal of the European Communities

L 254/11

COPYRIGHT NOTICE

This document has been produced by the Eurocontrol Agency.

Copyright is vested with the Eurocontrol Agency.

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

L 254/12

EN

Official Journal of the European Communities

9.10.2000

FOREWORD

1.

Responsible Body

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

2.

Relation to the EATCHIP Work Programme Document

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

3.

Approval and Amendments

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

— Approval by the EATCHIP Operational Requirement and ATM Data Processing Team (ODT) by

correspondence procedure;

— Consultation of all ECAC States through their representatives in the Committee of Management or

EATCHIP Project Board;

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

— Adoption by the Permanent Commission.

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

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

4.

Editorial Practices

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

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

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

9.10.2000

EN

Official Journal of the European Communities

L 254/13

5.

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

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

6.

Significant Changes from Edition 1

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

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

procedure:

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

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

— Information (INF) Message.

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

3. Incorporation of a dialogue procedure which allows:

— the identification and negotiation of non-standard transfer conditions by controllers performing

the planning function;

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

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

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

5. Deletion of the following Annexes to Edition 1:

A: ATC Unit Identification.

B: OLDI Message Structure

(all messages in Edition 3 include examples).

D: Historical Overview.

E:

Implementation Plan.

F:

Compliance by States.

G: Guidelines for Implementation.

H: Guidelines for Evaluation of OLDI.

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

L 254/14

EN

Official Journal of the European Communities

9.10.2000

7.

Relationship to Other Documents

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

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

Formats for ADEXP fields are described in Reference 2.

NOTE Referenced documents are listed at Section 2.

8.

Language

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

9.10.2000

EN

Official Journal of the European Communities

L 254/15

1.

INTRODUCTION

1.1.

Purpose

1.1.1.

1.1.2.

1.1.3.

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

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

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

1.2.

Scope

1.2.1.

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

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

— the transfer of communication of such flights.

1.2.2.

This document:

— defines the message formats and rules for the content;

1.2.3.

1.2.4.

2.

2.1.

— describes the facilities required at such units which are prerequisite to the use of data interchange

for this purpose.

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

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

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

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

REFERENCES

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

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

L 254/16

EN

Official Journal of the European Communities

9.10.2000

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

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

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

2.2.

The following documents are referenced in this Standard Document:

1. Procedures for Air Navigation Services — Rules of the Air & Air Traffic Services, ICAO Document

4444, Thirteenth Edition dated 7 Nov. 1996, as amended.

2. Edition 2.0 of the Eurocontrol Standard Document for ATS Data Exchange Presentation (ADEXP),

reference DPS-ET1-ST09-STD-01-00, dated June 1998.

3.

DEFINITIONS, SYMBOLS AND ABBREVIATIONS

3.1.

Definitions

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

3.1.1.

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

3.1.2.

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

3.1.3.

3.1.4.

3.1.5.

3.1.6.

3.1.7.

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.

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

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

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

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.

9.10.2000

EN

Official Journal of the European Communities

L 254/17

3.1.11.

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

3.1.12.

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

3.1.13.

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

3.1.14.

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

3.1.15.

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

3.1.16.

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

3.1.17.

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

3.1.18.

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

3.1.19.

3.1.20.

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.

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

3.1.21.

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

3.1.22.

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

3.1.23.

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

3.1.24.

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

3.1.25.

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

3.1.26.

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

3.1.27.

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

3.1.28.

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

L 254/18

EN

Official Journal of the European Communities

9.10.2000

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.

3.1.32.

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

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

3.1.33.

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

3.1.34.

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

3.1.35.

Transmit: Communicate a message from one system to another.

3.1.36.

Unit: Air traffic service unit

3.1.37.

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

3.2.

Symbols and Abbreviations

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

ABI

ACC

ACP

ACT

Advance Boundary Information Message

Area Control Centre

Accept Message

Activate Message

ADEXP

ATS Data Exchange Presentation

ATC

ATM

ATS

CDN

CNL

COD

COF

COP

DED

Air Traffic Control

Air Traffic Management

Air Traffic Service

Co-ordination Message

Flight Plan Cancellation

SSR Code Assignment Message

Change of Frequency Message

Co-ordination Point

Directorate of EATCHIP Development, Eurocontrol

9.10.2000

EN

Official Journal of the European Communities

L 254/19

EATCHIP

European ATC Harmonisation and Integration Programme

ECAC

ETO

ETOT

EWPD

FDPS

FRF

HMI

HOP

ICAO

INF

LAM

LoA

MAC

MAS

NM

European Civil Aviation Conference

Estimated Time Over

Estimated Take-Off Time

EATCHIP Work Programme Document

Flight Data Processing System

Further Route of Flight

Human-Machine Interface

Handover Proposal Message

International Civil Aviation Organisation

Information Message

Logical Acknowledgement Message

Letter of Agreement

Message for the Abrogation of Co-ordination

Manual Assumption of Communications

Nautical Mile

OLDI

ORCAM

On-Line Data Interchange

Originating Region Code Assignment Method

PAC

RAP

REV

RJC

ROF

RRV

SBY

SDM

SSR

Preliminary Activate Message

Referred Activate Proposal Message

Revision Message

Reject Co-ordination Message

Request on Frequency Message

Referred Revision Message

Stand-by Message

Supplementary Data Message

Secondary Surveillance Radar

SYSCO

System Supported Co-ordination

TI

TIM

Transfer Initiation

Transfer Initiation Message

TWR/APP

Tower (aerodrome control) and Approach Control

4.

GENERAL REQUIREMENTS

4.1.

Introduction

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

L 254/20

EN

Official Journal of the European Communities

9.10.2000

4.2.

Flight Data Processing System Requirements

4.2.1.

Flight Data Base

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

4.2.2.

Operation in Real Time

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

4.2.3.

Data Communications Capability

4.2.3.1.

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

4.2.3.2.

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

4.2.3.3.

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

— assuring the integrity of OLDI message transmission;

and

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

applicable.

4.2.3.4.

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

4.2.4.

Application Functions

4.2.4.1.

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

4.2.4.2.

The FDPS shall:

— reflect current operational data relevant to the OLDI function as required by this Standard, updated

either automatically, through manual input, or by a combination of both;

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

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

9.10.2000

EN

Official Journal of the European Communities

L 254/21

4.2.4.3.

The following shall be agreed bilaterally:

— Co-ordination Points (COPs);

— Reference points used for bearing and distance notations in identifying the COP on direct, off-ATS

route segments, where used.

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

4.2.5.

Human-Machine Interface (HMI)

4.2.5.1.

The HMI shall be able to:

— display the operational contents of OLDI messages and relevant warnings related to received

messages for immediate attention;

— route co-ordination and transfer message warnings to the operational positions responsible for

the co-ordination of the flights concerned.

4.2.5.2.

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

4.2.5.3.

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

4.2.5.4.

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

4.2.5.5.

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

4.2.5.6.

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

4.2.6.

Initiation of Messages

4.2.6.1.

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

4.2.6.2.

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

4.2.6.3.

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

4.2.6.4.

The system shall utilise time parameters to define the following:

— lead time, prior to transmission, when the operational contents of the messages within the

transferring unit are displayed;

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

— time after transmission of a message within which an application level acknowledgement is to be

received (time-out).

L 254/22

EN

Official Journal of the European Communities

9.10.2000

4.2.6.5.

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

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

4.2.7.

Reception of Messages

4.2.7.1.

The ATC system shall be able to:

— receive OLDI messages;

— process them automatically in accordance with this Standard;

— output flight data in accordance with the message received, and display required warnings in case

of inconsistency in the data received;

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

4.2.7.2.

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

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

message.

4.3.

Updating from Surveillance Data

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

4.4.

Recording of OLDI Data

4.4.1.

Content

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

4.4.2.

Facilities

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

4.5.

Availability, Reliability, Data Security and Data Integrity

4.5.1.

Availability

4.5.1.1.

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

4.5.1.2.

Recommendation The OLDI facility should be available 24 hours every day.

4.5.1.3.

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

9.10.2000

EN

Official Journal of the European Communities

L 254/23

4.5.2.

Reliability

4.5.2.1.

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

4.5.2.2.

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

4.5.3.

Data Security

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

4.5.4.

Data Integrity

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

4.6.

Operational Evaluation

4.6.1.

Evaluation Period

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

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

Eurocontrol.

4.6.2.

Operational Introduction Date

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

5.

MESSAGE CATEGORIES

5.1.

General

5.1.1.

Purpose

This Section of the document:

— defines the categories of messages;

— states transaction time requirements for the categories;

— states which messages are mandatory and which are complementary;

— assigns message types to categories.

5.1.2.

Message Categories

OLDI messages have been assigned to the following categories:

— Category 1: Transfer of Communication;

— Category 2: Co-ordination;

— Category 3: Notification.

L 254/24

EN

Official Journal of the European Communities

9.10.2000

5.2.

Transaction Times

5.2.1.

Transaction Time Conditions

5.2.1.1.

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

5.2.1.2.

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

Table 5-1

Maximum Transaction Times

Message Category

1

2

3

90 %

4 sec

10 sec

15 sec

99,8 %

10 sec

25 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 respectively.

5.3.

Message Classification and Categorisation

5.3.1.

Message Classification — Mandatory and Complementary

5.3.1.1.

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

5.3.1.2.

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

5.3.1.3.

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

NOTE In exceptional cases, where the traffic flow between two units is unidirectional, the mandatory messages

may be applicable in only one direction.

5.3.1.4.

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

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

9.10.2000

EN

Official Journal of the European Communities

L 254/25

5.3.1.5.

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

5.3.1.6.

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

5.3.2.

Categorisation of Messages

5.3.2.1.

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

5.3.2.2.

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

5.3.2.3.

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

Table 5-2

Basic Procedure Messages

Message Type

Abbreviation

Category

Transmission

Reception

Advance Boundary
Information

Activate

Revision

Preliminary Activate

Abrogation of Co-ordination

SSR Code Assignment

Information

Logical Acknowledgement
Message

ABI

ACT

REV

PAC

MAC

COD

INF

LAM

3

2

2

2

2

2

3

M

M

C (1)

C

C

C

C

M

M

M

C (1)

C

C

C

C

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

Referred Revision

Co-ordination

Stand-by (1)

Accept

Reject Co-ordination (2)

RAP

RRV

CDN

SBY

ACP

RJC

NOTES
(1) See paragraph 5.2.1.1 Transaction Time Conditions.
(2) Not used in all airspace configurations.

2

2

2

2

2

C

C

M

M

M

C

M

M

M

M

M

C

L 254/26

EN

Official Journal of the European Communities

9.10.2000

Table 5-4

Dialogue Procedure — Transfer Phase Messages

Message Type

Abbreviation

Category

Transmission

Reception

Transfer Initiation

Supplementary Data

Handover Proposal

Change of Frequency (2)

Request on Frequency

Manual Assumption (2)

TIM

SDM

HOP

COF

ROF

MAS

1

1

1

1

1

1

M

(1)

M

C

C

C

M

(1)

M

M

M

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.

BASIC PROCEDURE — MANDATORY MESSAGES

6.1.

General

6.1.1.

Description of Requirement

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

6.1.2.

Implementation

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

6.2.

Advance Boundary Information Message (ABI)

6.2.1.

Purpose of the ABI Message

The ABI satisfies the following operational requirements:

— provide for acquisition of missing flight plan data;

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

— update the basic flight plan data;

— facilitate early correlation of radar tracks;

— facilitate accurate short-term sector load assessment.

The ABI is a notification message.

9.10.2000

EN

Official Journal of the European Communities

L 254/27

6.2.2.

Message Contents

The ABI message shall contain the following items of data:

— Message Type;

— Message Number;

— Aircraft Identification;

— SSR Mode and Code (if available);

— Departure Aerodrome;

— Estimate Data;

— Destination Aerodrome;

— Aircraft number and type;

— Route (optional);

— Other Flight Plan Data (optional).

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

6.2.3.

Rules of Application

6.2.3.1.

G e n e r a l

6.2.3.1.1.

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

6.2.3.1.2.

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

6.2.3.1.3.

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

6.2.3.1.4.

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

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

6.2.3.1.5.

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

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

accurate;

— the aerodrome of destination has been changed;

or

— the type of aircraft has been changed.

6.2.3.1.6.

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

— The expected boundary crossing level;

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

— When the estimated time over (ETO) at the COP differs from the previous ABI message more than the time

specified in the Letter of Agreement (LoA);

— Any other data as bilaterally agreed.

L 254/28

EN

Official Journal of the European Communities

9.10.2000

6.2.3.2.

P r o c e s s i n g i n t h e R e c e i v i n g U n i t

6.2.3.2.1.

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

6.2.3.2.2.

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

6.2.3.2.3.

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

6.2.3.3.

T i m e P a r a m e t e r s f o r T r a n s m i s s i o n

6.2.3.3.1.

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

6.2.3.3.2.

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

6.2.3.3.3.

Recommendation The ABI generation parameter(s) should be:

— variable, based on the provisions of the LoA;

— defined separately for each of the COPs.

6.2.4.

Acknowledgement of ABI

6.2.4.1.

A c k n o w l e d g e m e n t

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

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

6.2.4.2.

N o A c k n o w l e d g e m e n t

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

6.2.5.

Examples

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

6.2.5.1.

I C A O

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

BNE

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
-ROUTE N0480F390 UB4 BNE UB4 BPK UB3 HON

9.10.2000

EN

Official Journal of the European Communities

L 254/29

6.3.

Activate Message (ACT)

6.3.1.

Purpose of the ACT Message

The ACT message satisfies the following operational requirements:

— Replace the verbal boundary estimate by transmitting automatically details of a flight from one

ATC unit to the next prior to the transfer of control;

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

— Facilitate distribution and display of flight plan data within the receiving ATC unit to the working

positions involved;

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

— Provide transfer conditions to the receiving ATC unit.

6.3.2.

Message Contents

The ACT message shall contain the following items of data:

— Message Type;

— Message Number;

— Aircraft Identification;

— SSR Mode and Code

— Departure Aerodrome;

— Estimate Data;

— Destination Aerodrome;

— Aircraft number and type;

— Route (optional);

— Other flight plan data (optional).

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

6.3.3.

Rules of Application

6.3.3.1.

G e n e r a l

6.3.3.1.1.

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

6.3.3.1.2.

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

6.3.3.1.3.

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

6.3.3.1.4.

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

L 254/30

EN

Official Journal of the European Communities

9.10.2000

6.3.3.1.5.

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

6.3.3.1.6.

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

6.3.3.1.7.

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

6.3.3.1.8.

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

6.3.3.1.9.

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

6.3.3.1.10.

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

6.3.3.1.11.

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

6.3.3.2.

P r o c e s s i n g i n t h e R e c e i v i n g U n i t

6.3.3.2.1.

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

6.3.3.2.2.

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

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

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

— a LAM shall be returned.

6.3.3.2.3.

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

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

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

— a LAM shall be returned;

— a flight plan shall be created;

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

6.3.3.3.

P a r a m e t e r s f o r T r a n s m i s s i o n

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.

9.10.2000

EN

Official Journal of the European Communities

L 254/31

6.3.3.3.3.

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

6.3.3.3.4.

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

6.3.3.3.5.

The specified parameters shall allow sufficient time for:

— the transmitting unit to update the transfer flight level to reflect the expected conditions at the

COP;

and

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

6.3.4.

Acknowledgement of ACT

6.3.4.1.

A c k n o w l e d g e m e n t

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

6.3.4.2.

N o A c k n o w l e d g e m e n t C a s e s

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)

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 -ROUTE N0480F390 UB4 BNE UB4 BPK UB3 HON

6.4.

Logical Acknowledgement Message (LAM)

6.4.1.

Purpose of the LAM Message

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

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

— a warning when no acknowledgement has been received;

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

L 254/32

EN

Official Journal of the European Communities

9.10.2000

6.4.2.

Message Contents

The LAM message shall contain the following items of data:

— Message Type;

— Message Number;

— Message Reference.

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

6.4.3.

Rules of Application

6.4.3.1.

G e n e r a l

6.4.3.1.1.

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

6.4.3.1.2.

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

6.4.3.1.3.

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

6.4.3.1.4.

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

6.4.3.1.5.

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

6.4.4.

Acknowledgement of LAM

The LAM message shall not require any acknowledgement.

6.4.5.

Examples

6.4.5.1.

I C A O

(LAML/E012E/L001)

6.4.5.2.

A D E X P

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

7.

BASIC PROCEDURE — COMPLEMENTARY MESSAGES

7.1.

General

7.1.1.

Description of Requirement

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

7.1.2.

Implementation

7.1.2.1.

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

9.10.2000

EN

Official Journal of the European Communities

L 254/33

7.1.2.2.

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

7.2.

Preliminary Activate Message (PAC)

7.2.1.

Purpose of the PAC Message

The PAC message satisfies the following operational requirements:

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

— notification and pre-departure co-ordination of a flight before departure by a local (aerodrome/

approach control) unit to the next unit that will take control of the flight;

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

of flight plan data;

— request the assignment of an SSR code from the unit to which the above notification/co-ordination

is sent, if required.

7.2.2.

Message Contents

The PAC message shall contain the following items of data:

— Message Type;

— Message Number;

— Message Reference (optional);

— Aircraft Identification;

— SSR Mode and Code;

— Departure Aerodrome;

— Estimated Take-Off Time or Estimate Data;

— Destination Aerodrome;

— Type of Aircraft;

— Route (optional);

— Other flight plan data (optional).

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

7.2.3.

Rules of Application

7.2.3.1.

G e n e r a l

7.2.3.1.1.

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

7.2.3.1.2.

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

7.2.3.1.3.

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

L 254/34

EN

Official Journal of the European Communities

9.10.2000

7.2.3.1.4.

As bilaterally agreed, the message shall contain either:

— Estimated Take-Off Time;

or

— Estimate Data.

7.2.3.1.5.

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

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

— be included on second and subsequent PAC messages.

7.2.3.1.6.

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

7.2.3.1.7.

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

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

accurate;

— the type of aircraft has been changed;

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

7.2.3.1.8.

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

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

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

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

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

7.2.3.2.

P r o c e s s i n g i n t h e R e c e i v i n g U n i t

7.2.3.2.1.

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

7.2.3.2.2.

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

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

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

— a LAM shall be returned.

7.2.3.2.3.

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

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

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

— a LAM shall be returned;

— a flight plan shall be created;

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

9.10.2000

EN

Official Journal of the European Communities

L 254/35

7.2.3.2.4.

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

7.2.3.2.5.

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

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

7.2.3.3.

T i m e P a r a m e t e r s f o r T r a n s m i s s i o n

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

7.2.4.

Acknowledgement of PAC

7.2.4.1.

A c k n o w l e d g e m e n t

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

7.2.4.2.

N o A c k n o w l e d g e m e n t

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.

N o - L A M c a s e s

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

7.2.4.4.

N o C O D M e s s a g e

7.2.4.4.1.

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

7.2.4.4.2.

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

7.2.5.

Examples

7.2.5.1.

E s t i m a t e d T a k e - O f f T i m e a n d C o d e R e q u e s t

7.2.5.1.1.

ICAO

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

7.2.5.1.2.

ADEXP

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

L 254/36

EN

Official Journal of the European Communities

9.10.2000

7.2.5.2.

T i m e a t C O P

7.2.5.2.1.

ICAO

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

7.2.5.2.2.

ADEXP

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

7.3.

Revision Message (REV)

7.3.1.

Purpose of the REV Message

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

7.3.2.

Message Contents

The REV message shall contain the following items of data:

— Message Type;

— Message Number;

— Message Reference (optional);

— Aircraft Identification;

— SSR Mode and Code (optional);

— Departure Aerodrome;

— Estimate Data;

— Co-ordination point (optional);

— Destination Aerodrome;

— Route (optional);

— Other flight plan data (optional).

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

7.3.3.

Rules of Application

7.3.3.1.

G e n e r a l

7.3.3.1.1.

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

7.3.3.1.2.

The following elements shall be subject to revisions:

— ETO at the COP;

— Transfer level(s);

— SSR Code.

9.10.2000

EN

Official Journal of the European Communities

L 254/37

7.3.3.1.3.

A REV message shall be sent when:

— the ETO at the COP differs from that in the previous message by more than a value bilaterally

agreed, rounded to the nearest integer value;

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

7.3.3.1.4.

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

— COP;

— route;

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

NOTE Operational rules may require that modifications effected after ACT be subject to prior co-ordination

between the units concerned.

7.3.3.1.5.

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

7.3.3.1.6.

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

7.3.3.1.7.

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

7.3.3.2.

F o r m a t t i n g o f R e v i s i o n M e s s a g e s

7.3.3.2.1.

ICAO Format

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

— a change to the ETO at the COP or transfer level(s) shall be incorporated by the inclusion of the

revised data in field 14;

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

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

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

7.3.3.2.2.

ADEXP Format

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

— a change to the ETO at the COP or transfer level(s) shall be incorporated by the inclusion of the

revised data in primary field COORDATA;

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

L 254/38

EN

Official Journal of the European Communities

9.10.2000

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

— modifications to other flight plan data shall be incorporated by the inclusion of the requisite

primary field(s) as defined for other Flight Plan Data in Annex A.

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

7.3.3.2.3.

SSR Code

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

7.3.3.3.

P r o c e s s i n g i n t h e R e c e i v i n g U n i t

7.3.3.3.1.

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

7.3.3.3.2.

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

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

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

7.3.3.4.

I n i t i a t i o n o f T r a n s m i s s i o n

7.3.3.4.1.

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

7.3.3.4.2.

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

7.3.3.4.3.

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

7.3.3.5.

C h a n g e o f R e c e i v i n g A T C U n i t

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.

A c k n o w l e d g e m e n t

If the REV message:

— can be associated with a flight plan within the receiving system, a LAM message shall be transmitted

in acknowledgement;

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

transmitted.

7.3.4.2.

N o A c k n o w l e d g e m e n t

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.

9.10.2000

EN

Official Journal of the European Communities

L 254/39

7.3.4.2.2.

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

7.3.5.

Examples

7.3.5.1.

I C A O

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

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

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

7.4.

Message for the Abrogation of Co-ordination (MAC)

7.4.1.

Purpose of the MAC Message

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

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

7.4.2.

Message Contents

The MAC message shall contain the following items of data:

— Message Type;

— Message Number;

— Message Reference (optional);

— Aircraft Identification;

— Departure Aerodrome;

— Co-ordination Point;

— Destination Aerodrome;

— Co-ordination Status and Reason (optional).

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

7.4.3.

Rules of Application

7.4.3.1.

G e n e r a l

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;

L 254/40

EN

Official Journal of the European Communities

9.10.2000

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

sequence;

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

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

7.4.3.1.2.

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

7.4.3.1.3.

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

7.4.3.1.4.

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

7.4.3.1.5.

A message reference shall be included if bilaterally agreed.

7.4.3.1.6.

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

7.4.3.1.7.

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

7.4.3.1.8.

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

7.4.3.1.9.

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

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

— the status is INI (initial);

— the reason is one of the following:

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

— RTE if the reason is a change of route;

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

— CAN if the reason is a cancellation;

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

— when one of the following conditions applies:

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

or

— following the transmission of an ABI message, the flight is holding for an indefinite period and

is expected to be subject to a revised ABI or ACT, as appropriate:

— the status is NTF (notification);

— the reason is one of the following:

— DLY if the reason is a delay;

— HLD if the reason is a hold;

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

9.10.2000

EN

Official Journal of the European Communities

L 254/41

7.4.3.1.10.

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

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

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

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

7.4.3.2.

P r o c e s s i n g i n t h e R e c e i v i n g U n i t

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.

A c k n o w l e d g e m e n t

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.

N o A c k n o w l e d g e m e n t

7.4.4.2.1.

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

7.4.4.2.2.

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

7.4.5.

Examples

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

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

7.4.5.1.

I C A O

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

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

7.4.5.2.

A D E X P

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

L 254/42

EN

Official Journal of the European Communities

9.10.2000

7.5.

SSR Code Assignment Message (COD)

7.5.1.

Purpose of the COD Message

7.5.1.1.

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

7.5.1.2.

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

7.5.2.

Message Contents

The COD message shall contain the following items of data:

— Message type;

— Message number;

— Message reference (optional);

— Aircraft identification;

— SSR mode and code;

— Departure aerodrome;

— Destination aerodrome;

— Route (optional).

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

7.5.3.

Rules of Application

7.5.3.1.

G e n e r a l

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.

P r o c e s s i n g i n t h e R e c e i v i n g U n i t

7.5.3.2.1.

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

9.10.2000

EN

Official Journal of the European Communities

L 254/43

7.5.3.2.2.

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

7.5.3.2.3.

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

7.5.3.3.

T i m e P a r a m e t e r s f o r T r a n s m i s s i o n

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.

A c k n o w l e d g e m e n t

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

7.5.4.2.

N o A c k n o w l e d g e m e n t C a s e s

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.

I C A O

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

7.5.5.2.

A D E X P

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

7.6.

Information Message (INF)

7.6.1.

Purpose of the INF Message

7.6.1.1.

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

7.6.1.2.

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

7.6.1.3.

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

7.6.1.4.

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

7.6.2.

Message Contents

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

— Message type;

— Message number;

L 254/44

EN

Official Journal of the European Communities

9.10.2000

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

copied;

— Reference Message Type.

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

7.6.3.

Rules of Application

7.6.3.1.

M e s s a g e T y p e s

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

7.6.3.2.

M e s s a g e A d d r e s s e e s

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

7.6.3.3.

O p e r a t i o n a l C o n t e n t

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

7.6.3.4.

Recommendations

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

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

bilaterally with the receiving agency.

7.6.4.

Acknowledgement of INF

Recommendations

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

a LAM message.

2. Subject

to bilateral agreement between the units concerned,

if no LAM message is received as an

acknowledgement for an INF message, a warning should be displayed at an appropriate position.

7.6.5.

Examples

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

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

The following give examples of the INF message.

7.6.5.1.

I C A O

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

A D E X P

-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

9.10.2000

EN

Official Journal of the European Communities

L 254/45

8.

DIALOGUE PROCEDURE — COORDINATION

8.1.

General

8.1.1.

Introduction

8.1.1.1.

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

8.1.1.2.

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

8.1.1.3.

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

8.1.1.4.

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

8.1.1.5.

The co-ordination dialogue procedure allows the identification of:

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

— those which require to be referred to the controller at the receiving unit for a decision regarding

acceptance.

8.1.1.6.

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

8.1.2.

The Filter

8.1.2.1.

G e n e r a l

8.1.2.1.1.

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

8.1.2.1.2.

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

— agreed co-ordination points;

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

— aerodromes of departure;

— destinations;

— agreed direct routes;

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

non-standard;

— any other conditions, as bilaterally agreed.

8.1.2.1.3.

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

L 254/46

EN

Official Journal of the European Communities

9.10.2000

8.1.2.1.4.

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

8.1.2.2.

A c t i o n I n t h e T r a n s f e r r i n g U n i t

8.1.2.2.1.

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

8.1.2.2.2.

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

8.1.2.3.

A c t i o n i n t h e A c c e p t i n g U n i t

8.1.2.3.1.

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

8.1.2.3.2.

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

8.1.2.4.

S y n c h r o n i s a t i o n o f t h e F i l t e r s

8.1.2.4.1.

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

8.1.2.4.2.

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

8.1.3.

Message Sequence

8.1.3.1.

G e n e r a l

8.1.3.1.1.

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

8.1.3.1.2.

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

8.1.3.1.3.

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

8.1.3.1.4.

CDN messages shall only be transmitted and acknowledged:

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

message; or

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

9.10.2000

EN

Official Journal of the European Communities

L 254/47

8.1.4.

Simultaneous Message Handling

8.1.4.1.

G e n e r a l

8.1.4.1.1.

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

8.1.4.1.2.

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

8.1.5.

Reject Handling

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

8.1.6.

Operational Reply Time-out

8.1.6.1.

G e n e r a l

8.1.6.1.1.

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

8.1.6.1.2.

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

8.1.6.1.3.

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

8.1.6.1.4.

Recommendations

1. A warning should be displayed to the ATC position at the accepting unit responsible for the flight when the

time-out in the transferring unit is imminent.

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

8.1.6.1.5.

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

8.1.7.

Implementation

8.1.7.1.

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

8.1.7.2.

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

— the transfer dialogue addresses primarily the executive control function and requires a fast and

user-friendly HMI;

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

order.

L 254/48

EN

Official Journal of the European Communities

9.10.2000

8.1.7.3.

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

— co-ordination phase dialogue procedure plus any complementary messages as bilaterally agreed

(Sections 7 and 8);

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

— co-ordination and transfer phase dialogue procedure plus any complementary co-ordination

messages as bilaterally agreed (Sections 7, 8 and 9).

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

8.1.7.4.

The scenario used for the implementation shall be bilaterally agreed.

8.2.

Activate Message (ACT)

8.2.1.

Purpose of the ACT Message

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

8.2.2.

Message Contents

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

8.2.3.

Rules of Application

8.2.3.1.

G e n e r a l

8.2.3.1.1.

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

8.2.3.1.2.

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

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

Message).

8.2.3.1.3.

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

8.2.3.2.

P r o c e s s i n g i n t h e R e c e i v i n g U n i t

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.

9.10.2000

EN

Official Journal of the European Communities

L 254/49

8.2.3.2.3.

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

8.2.3.2.4.

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

8.2.4.

Acknowledgement of ACT

8.2.4.1.

A c k n o w l e d g e m e n t

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.

N o A c k n o w l e d g e m e n t C a s e s

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

8.3.

Referred Activate Proposal Message (RAP)

8.3.1.

Purpose of the RAP Message

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

— the proposal by the transferring controller and referral to the accepting controller of flights with

non-standard transfer conditions;

— allow the transferring controller, if he/she requires to do so, to force the referral to the accepting

controller of standard transfer conditions for a specific flight.

8.3.2.

Message Contents

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

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

8.3.3.

Rules of Application

8.3.3.1.

G e n e r a l

8.3.3.1.1.

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

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

— the transferring controller has indicated that the proposed transfer conditions are to be referred to

the accepting controller.

L 254/50

EN

Official Journal of the European Communities

9.10.2000

8.3.3.1.2.

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

8.3.3.1.3.

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

8.3.3.1.4.

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

8.3.3.2.

P r o c e s s i n g i n t h e R e c e i v i n g U n i t

8.3.3.2.1.

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

8.3.3.2.2.

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

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

— an SBY shall be returned.

8.3.3.2.3.

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

8.3.3.2.4.

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

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

and

— an SBY message returned;

and

— a flight plan created.

8.3.3.2.5.

In all other cases the message shall not be acknowledged.

8.3.3.3.

M a n u a l T r i g g e r

8.3.3.3.1.

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

8.3.3.3.2.

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

8.3.3.4.

T i m e P a r a m e t e r s f o r A u t o m a t i c T r a n s m i s s i o n

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.

A c k n o w l e d g e m e n t

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

8.3.4.2.

N o A c k n o w l e d g e m e n t C a s e

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.

9.10.2000

EN

Official Journal of the European Communities

L 254/51

8.3.5.

Operational Reply to RAP

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

8.3.5.1.

A c c e p t a n c e

8.3.5.1.1.

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

8.3.5.1.2.

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

8.3.5.2.

C o u n t e r - P r o p o s a l

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

8.3.5.3.

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

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

different unit.

8.3.6.

Examples

8.3.6.1.

I C A O

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

8.3.6.2.

A D E X P

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

8.4.

Revision Message (REV)

8.4.1.

Purpose of the REV Message

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

8.4.2.

Message Contents

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

8.4.3.

Rules of Application

8.4.3.1.

G e n e r a l

8.4.3.1.1.

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

L 254/52

EN

Official Journal of the European Communities

9.10.2000

8.4.3.1.2.

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

8.4.3.2.

I n i t i a t i o n o f T r a n s m i s s i o n

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

8.4.3.3.

P r o c e s s i n g i n t h e R e c e i v i n g U n i t

8.4.3.3.1.

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

— the REV message shall be acknowledged;

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

8.4.3.3.2.

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

8.4.3.3.3.

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

8.4.3.3.4.

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

8.4.3.3.5.

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

8.4.4.

Acknowledgement of REV

8.4.4.1.

A c k n o w l e d g e m e n t

8.4.4.1.1.

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

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

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

8.4.4.1.2.

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

8.4.4.1.3.

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

8.4.4.2.

N o A c k n o w l e d g e m e n t C a s e s

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.

9.10.2000

EN

Official Journal of the European Communities

L 254/53

8.5.

Referred Revision Proposal Message (RRV)

8.5.1.

Purpose of the RRV Message

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

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

— when the proposed revision is standard, but the transferring controller wants to refer the revision

to the accepting controller.

8.5.2.

Message Contents

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

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

8.5.3.

Rules of Application

8.5.3.1.

G e n e r a l

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

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

or

— the transferring controller has indicated that the proposed transfer conditions are to be referred to

the accepting controller. This use of the RRV is optional.

8.5.3.2.

I n i t i a t i o n o f T r a n s m i s s i o n

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.

P r o c e s s i n g i n t h e R e c e i v i n g U n i t

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.

A c k n o w l e d g e m e n t

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

L 254/54

EN

Official Journal of the European Communities

9.10.2000

8.5.4.2.

N o A c k n o w l e d g e m e n t C a s e s

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.

A c c e p t a n c e

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.

C o u n t e r - P r o p o s a l

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

8.5.5.3.

R e j e c t i o n

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.

I C A O

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

8.5.6.2.

A D E X P

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

8.6.

Stand-by Message (SBY)

8.6.1.

Purpose of the SBY Message

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

8.6.2.

Message Contents

The SBY message shall contain the following items of data:

— Message Type;

— Message Number;

— Message Reference.

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

9.10.2000

EN

Official Journal of the European Communities

L 254/55

8.6.3.

Rules of Application

8.6.3.1.

G e n e r a l

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

— a RAP, RRV or CDN message;

— an ACT or REV message which fails the filter.

8.6.4.

Acknowledgement of SBY

The SBY message shall not be acknowledged.

8.6.5.

Examples

8.6.5.1.

I C A O

(SBYL/E027E/L002)

8.6.5.2.

A D E X P

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

8.7.

Acceptance Message (ACP)

8.7.1.

Purpose of the ACP Message

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

— indicate the manual acceptance by a controller in one unit of the transfer conditions proposed by

the controller in the other unit in one of the following messages:

— RAP;

— RRV;

— CDN;

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

— when bilaterally agreed, provide the automatic acceptance of an ACT or REV message that has

passed the filter in the accepting unit (in place of the LAM);

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

message).

8.7.2.

Message Contents

The ACP message consists of the following items of data:

— Mandatory data — the message shall contain:

— Message Type;

— Message Number;

— Message Reference;

L 254/56

EN

Official Journal of the European Communities

9.10.2000

— Optional data — the message may also include:

— Frequency;

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

— Aircraft Identification;

— Departure Aerodrome;

— Destination Aerodrome.

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

8.7.3.

Rules of Application

8.7.3.1.

G e n e r a l

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.

P r o c e s s i n g i n t h e R e c e i v i n g U n i t

8.7.3.2.1.

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

8.7.3.2.2.

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

8.7.3.2.3.

If the ACP cannot be associated with a flight plan:

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

— a LAM shall not be sent.

8.7.4.

Acknowledgement of ACP

8.7.4.1.

A c k n o w l e d g e m e n t

8.7.4.1.1.

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

9.10.2000

EN

Official Journal of the European Communities

L 254/57

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.

N o A c k n o w l e d g e m e n t C a s e s

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.

I C A O

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

8.7.5.2.

A D E X P

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

8.8.

Co-ordination Message (CDN)

8.8.1.

Purpose of the CDN Message

The CDN message satisfies the following operational requirements:

— to forward a counter proposal from the accepting controller to the transferring controller as a

reply to an ACT, a RAP, a REV or an RRV message;

— to initiate a proposed modification to agreed transfer conditions by the accepting controller to the

transferring controller.

8.8.2.

Message Contents

The CDN message consists of the following items of data:

— Mandatory data — the message shall contain:

— Message Type;

— Message Number;

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

— Aircraft Identification;

— Departure Aerodrome;

— Destination Aerodrome;

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

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

— Direct Routing Request.

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

— Frequency.

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

L 254/58

EN

Official Journal of the European Communities

9.10.2000

8.8.3.

Rules of Application

8.8.3.1.

G e n e r a l

8.8.3.1.1.

CDN messages shall be initiated by the accepting controller only.

8.8.3.1.2.

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

NOTE This can be in a dialogue as a reply to a proposal forwarded by an ACT, RAP, REV, or RRV, or as the

start of a dialogue to amend previously agreed transfer conditions.

8.8.3.1.3.

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

8.8.3.1.4.

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

8.8.3.1.5.

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

— only be used if bilaterally agreed; and

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

8.8.3.1.6.

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

8.8.3.1.7.

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

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

8.8.3.1.8.

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

8.8.3.2.

P r o c e s s i n g i n t h e R e c e i v i n g U n i t

8.8.3.2.1.

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

— the operational content shall be presented at the ATC position responsible for the co-ordination

of the flight;

and

— an SBY shall be returned.

8.8.3.2.2.

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

8.8.4.

Acknowledgement of CDN

8.8.4.1.

A c k n o w l e d g e m e n t

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

9.10.2000

EN

Official Journal of the European Communities

L 254/59

8.8.4.2.

N o A c k n o w l e d g e m e n t C a s e s

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.

A c c e p t a n c e

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

8.8.5.2.

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

NOTE The proposed co-ordination is implicitly rejected if no acceptance has been received by the time that the

CDN message times-out.

8.8.6.

Examples

8.8.6.1.

I C A O

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

8.8.6.2.

A D E X P

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

8.9.

Reject Co-ordination Message (RJC)

8.9.1.

Purpose of the RJC Message

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

— RAP;

— RRV;

— CDN;

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

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

8.9.2.

Message Contents

The RJC message shall contain the following items of data:

— Message Type;

— Message Number;

— Message Reference.

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

L 254/60

EN

Official Journal of the European Communities

9.10.2000

8.9.3.

Rules of Application

8.9.3.1.

G e n e r a l

8.9.3.1.1.

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

8.9.3.1.2.

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

8.9.3.1.3.

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

8.9.3.2.

P r o c e s s i n g i n t h e R e c e i v i n g U n i t

8.9.3.2.1.

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

— the rejection shall be indicated at the ATC position responsible for the co-ordination of the relevant

flight; and

— a LAM shall be returned in acknowledgement.

8.9.3.2.2.

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

8.9.4.

Acknowledgement of RJC

8.9.4.1.

A c k n o w l e d g e m e n t

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

8.9.4.2.

N o A c k n o w l e d g e m e n t C a s e s

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.

I C A O

(RJCMC/E746E/MC324)

8.9.5.2.

A D E X P

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

9.

DIALOGUE PROCEDURE — TRANSFER OF COMMUNICATION

9.1.

General

9.1.1.

Introduction

9.1.1.1.

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

9.10.2000

EN

Official Journal of the European Communities

L 254/61

9.1.1.2.

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

9.1.1.3.

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

9.1.2.

Message Sequence

9.1.2.1.

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

9.1.2.2.

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

9.1.3.

Transfer of Communications

9.1.3.1.

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

9.1.3.2.

The conditions shall be one or both of the following:

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

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

9.1.3.3.

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

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

9.2.

Transfer Initiation Message (TIM)

9.2.1.

Purpose of the TIM Message

The purpose of the TIM is to:

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

transfer phase);

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

9.2.2.

Message Contents

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

— Mandatory data — the message shall contain:

— Message Type;

— Message Number;

— Aircraft Identification;

L 254/62

EN

Official Journal of the European Communities

9.10.2000

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

— Cleared Flight Level;

— Assigned Heading or Direct Clearance;

— Assigned Speed;

— Assigned Rate of Climb/Descent;

— Optional data — the message may also contain:

— Position.

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

9.2.3.

Rules of Application

9.2.3.1.

G e n e r a l

9.2.3.1.1.

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

9.2.3.1.2.

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

9.2.3.1.3.

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

9.2.3.1.4.

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

9.2.3.2.

T i m e P a r a m e t e r s f o r T r a n s m i s s i o n

9.2.3.2.1.

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

9.2.3.2.2.

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

9.2.3.2.3.

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

9.2.3.2.4.

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

9.2.3.2.5.

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

9.2.3.3.

P r o c e s s i n g i n t h e R e c e i v i n g U n i t

9.2.3.3.1.

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

9.2.4.

Acknowledgement of TIM

9.2.4.1.

A c k n o w l e d g e m e n t

If the TIM message:

— can be unambiguously associated with a flight plan, it shall be acknowledged by the generation

and transmission of a LAM message;

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

9.10.2000

EN

Official Journal of the European Communities

L 254/63

9.2.4.2.

N o A c k n o w l e d g e m e n t C a s e s

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

9.2.5.

Example

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

9.3.

Supplementary Data Message (SDM)

9.3.1.

Purpose of the SDM Message

9.3.1.1.

G e n e r a l

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.

M e s s a g e s f r o m t h e T r a n s f e r r i n g U n i t

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.

M e s s a g e s f r o m t h e A c c e p t i n g U n i t

The SDM shall contain the following data:

— Message Type;

— Message Number;

— Aircraft Identification;

— Frequency.

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

L 254/64

EN

Official Journal of the European Communities

9.10.2000

9.3.3.

Rules of Application

9.3.3.1.

M e s s a g e s f r o m t h e T r a n s f e r r i n g U n i t

9.3.3.1.1.

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

— cleared flight level;

— assigned speed;

— assigned rate of climb/descent;

— assigned heading; or

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

NOTE The HOP message is required to be used when approval by the accepting controller is required prior to

the transfer of communication.

9.3.3.1.2.

The message shall contain only the fields which have changed.

9.3.3.1.3.

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

9.3.3.1.4.

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

9.3.3.2.

M e s s a g e s f r o m t h e A c c e p t i n g U n i t

9.3.3.2.1.

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

NOTE Units may agree bilaterally to send other information. Such transfer is not defined in, and therefore, not

part of, this Standard.

9.3.3.2.2.

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

9.3.3.3.

P r o c e s s i n g i n t h e R e c e i v i n g U n i t

9.3.3.3.1.

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

9.3.3.3.2.

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

— a LAM shall be returned; and

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

9.3.3.3.3.

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

— no LAM shall be returned; and

— a warning shall be output at an appropriate position.

9.3.4.

Acknowledgement of SDM

9.3.4.1.

A c k n o w l e d g e m e n t

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

9.10.2000

EN

Official Journal of the European Communities

L 254/65

9.3.4.2.

N o A c k n o w l e d g e m e n t C a s e s

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

9.3.5.

Example

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

9.4.

Hand-Over Proposal (HOP)

9.4.1.

Purpose of the HOP Message

The purpose of the HOP Message is:

— for the transferring controller to draw the attention of the accepting controller to a specific flight

for handover purposes;

— for the transferring controller to propose the flight for hand-over to the accepting controller when

it is required to do so;

— to forward modifications to the executive control data which require the approval of the accepting

controller, as bilaterally agreed.

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

NOTE With respect to paragraph c) above, the SDM is used to forward modifications to executive control data

which do not require the approval of the accepting controller.

9.4.2.

Message Contents

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

— Mandatory data — the message shall contain:

— Message Type;

— Message Number;

— Aircraft Identification;

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

— Cleared Flight Level;

— Assigned Heading/Direct Clearance;

— Assigned Speed;

— Assigned Rate of Climb/Descent;

— Optional data — the message may also contain:

— Position.

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

9.4.3.

Rules of Application

9.4.3.1.

G e n e r a l

9.4.3.1.1.

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

L 254/66

EN

Official Journal of the European Communities

9.10.2000

9.4.3.1.2.

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

9.4.3.1.3.

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

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

9.4.3.1.4.

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

9.4.3.1.5.

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

9.4.3.2.

P r o c e s s i n g i n t h e R e c e i v i n g U n i t

9.4.3.2.1.

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

9.4.3.2.2.

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

9.4.3.2.3.

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

9.4.3.2.4.

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

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

9.4.3.2.5.

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

9.4.4.

Acknowledgement of HOP

9.4.4.1.

A c k n o w l e d g e m e n t

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

9.4.4.2.

N o A c k n o w l e d g e m e n t C a s e s

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

EN

Official Journal of the European Communities

L 254/67

9.5.

Request on Frequency Message (ROF)

9.5.1.

Purpose of the ROF Message

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

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

— to request the early transfer of the flight.

9.5.2.

Message Contents

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

— Mandatory data — the message shall contain:

— Message Type;

— Message Number;

— Aircraft Identification;

— Optional data — the message may also contain:

— Frequency.

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

9.5.3.

Rules of Application

9.5.3.1.

G e n e r a l

9.5.3.1.1.

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

9.5.3.1.2.

The accepting controller may trigger a ROF, either:

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

— as a reply to a HOP message.

9.5.3.2.

P r o c e s s i n g i n t h e R e c e i v i n g U n i t

9.5.3.2.1.

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

9.5.3.2.2.

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

9.5.3.2.3.

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

9.5.4.

Acknowledgement of ROF

9.5.4.1.

A c k n o w l e d g e m e n t

9.5.4.1.1.

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

L 254/68

EN

Official Journal of the European Communities

9.10.2000

9.5.4.1.2.

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

9.5.4.2.

N o A c k n o w l e d g e m e n t C a s e s

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

9.5.5.

Example

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

9.6.

Change of Frequency Message (COF)

9.6.1.

Purpose of the COF Message

9.6.1.1.

G e n e r a l

9.6.1.1.1.

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

9.6.1.1.2.

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

9.6.2.

Message Contents

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

— Mandatory data — the message shall contain:

— Message Type;

— Message Number;

— Aircraft Identification;

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

— Release Indication;

— Frequency;

— Cleared Flight Level;

— Assigned Heading or Direct Clearance;

— Assigned Speed;

— Assigned Rate of Climb/Descent;

— Optional data — the message may also contain:

— Position.

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

9.6.3.

Rules of Application

9.6.3.1.

G e n e r a l

9.6.3.1.1.

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

9.10.2000

EN

Official Journal of the European Communities

L 254/69

9.6.3.1.2.

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

9.6.3.1.3.

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

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

9.6.3.2.

P r o c e s s i n g i n t h e R e c e i v i n g U n i t

9.6.3.2.1.

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

9.6.3.2.2.

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

9.6.4.

Acknowledgement of COF

9.6.4.1.

A c k n o w l e d g e m e n t

9.6.4.1.1.

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

9.6.4.1.2.

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

9.6.4.2.

N o A c k n o w l e d g e m e n t C a s e s

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

9.6.5.

Examples

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

9.7.

Manual Assumption of Communications Message (MAS)

9.7.1.

Purpose of the MAS Message

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

9.7.2.

Message Contents

The MAS message shall contain the following items of data:

— Message Type;

— Message Number;

— Aircraft Identification.

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

9.7.3.

Rules of Application

9.7.3.1.

G e n e r a l

9.7.3.1.1.

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

L 254/70

EN

Official Journal of the European Communities

9.10.2000

9.7.3.1.2.

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

9.7.3.2.

P r o c e s s i n g i n t h e R e c e i v i n g U n i t

9.7.3.2.1.

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

9.7.3.2.2.

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

9.7.4.

Acknowledgement of MAS

9.7.4.1.

A c k n o w l e d g e m e n t

9.7.4.1.1.

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

9.7.4.1.2.

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

9.7.4.2.

N o A c k n o w l e d g e m e n t C a s e s

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

9.7.5.

Example

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

9.10.2000

EN

Official Journal of the European Communities

L 254/71

ANNEX A (Normative)

DATA INSERTION RULES

CONTENTS

A.1.

A.2.

A.3.

A.4.

A.5.

A.6.

A.7.

A.8.

A.9.

A.10.

A.11.

A.12.

A.13.

A.14.

A.15.

A.16.

A.17.

A.18.

A.19.

A.20.

A.21.

A.22.

A.23.

A.24.

A.25.

A.26.

A.27.

A.28.

Purpose

Generic Message Formats

Message Type

Message Number

Message Reference

Aircraft Identification

SSR Mode and Code

Departure Aerodrome

Estimate Data

Co-ordination Point

Destination Aerodrome

Aircraft Number and Type

Route

Other Flight Plan Data

Co-ordination Status and Reason

Assigned Heading (ADEXP only)

Assigned Speed (ADEXP only)

Assigned Rate of Climb/Descent (ADEXP only)

Direct Clearance (ADEXP only)

Direct Routing Request

Position (ADEXP only)

Release Indication (ADEXP only)

Frequency

Reason (ADEXP only)

Cleared Flight Level (ADEXP only)

Transfer Flight Level (ADEXP only)

Estimated Take-Off Time

Reference Message Type

L 254/72

EN

Official Journal of the European Communities

9.10.2000

A.1.

Purpose

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

A.2.

Generic Message Formats

A.2.1.

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

6 Basic Procedure — Mandatory Messages;

7 Basic Procedure — Complementary Messages;

8 Dialogue Procedure — Co-ordination.

A.2.2.

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

A.2.3.

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

NOTES

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

2. Messages described in Section 9, Dialogue Procedure — Transfer of Communication, are described only in

ADEXP format.

A.3.

Message Type

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

ABI: Advance Boundary Information.

ACP: Acceptance.

ACT: Activate.

CDN: Co-ordination.

COD: SSR Code Assignment.

COF: Change of Frequency.

HOP: Hand-Over Proposal.

INF:

Information.

LAM: Logical Acknowledgement Message.

MAC: Message for Abrogation of Co-ordination.

MAS: Manual Assumption of Communications.

PAC: Preliminary Activation.

RAP: Referred Activate Proposal.

REV: Revision.

RJC:

Reject Co-ordination.

ROF: Request on Frequency.

RRV: Referred Revision Proposal.

SBY:

Stand-by.

SDM: Supplementary Data Message.

TIM:

Transfer Initiation Message.

9.10.2000

EN

Official Journal of the European Communities

L 254/73

A.3.1.

ICAO

Field type 3, element (a).

A.3.2.

ADEXP

Primary field ‘title’.

A.4.

Message Number

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

A.4.1.

ICAO

Field type 3, element (b).

A.4.2.

ADEXP

Primary field ‘refdata’.

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

Sub-field ‘seqnum’ shall contain the sequence number.

A.5.

Message Reference

A.5.1.

ICAO

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

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

A.5.2.

ADEXP

Primary field ‘msgref’.

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

A.6.

Aircraft Identification

A.6.1.

ICAO

Field type 7, element (a).

A.6.2.

ADEXP

Primary field ‘arcid’.

L 254/74

EN

Official Journal of the European Communities

9.10.2000

A.7.

SSR Mode and Code

Either:

1.

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

or

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

A.7.1.

ICAO

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

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

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

A.7.2.

ADEXP

Primary field ‘ssrcode’.

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

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

A.8.

Departure Aerodrome

A.8.1.

ICAO

Field type 13, element (a).

A.8.2.

ADEXP

Primary field ‘adep’.

A.9.

Estimate Data

A.9.1.

General

A.9.1.1.

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

A.9.1.2.

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

A.9.1.3.

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

A.9.1.4.

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

9.10.2000

EN

Official Journal of the European Communities

L 254/75

A.9.1.5.

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

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

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

A.9.2.

ICAO

Field type 14.

A.9.3.

ADEXP

Primary field ‘coordata’.

Subfield ‘ptid’ within Primary field ‘coordata’ shall contain either:

— a known reference point; or

— a bearing and distance from a known reference point, as defined in the same message by Primary

field ‘REF’ or ‘GEO’.

A.10.

Co-ordination Point

A.10.1.

General

A.10.1.1.

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

A.10.1.2.

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

A.10.2.

ICAO

Field 14, element (a).

A.10.3.

ADEXP

Primary field ‘cop’ containing:

— a known reference point; or

— a bearing and distance from a known reference point, as defined in the same message by Primary

field ‘REF’ or ‘GEO’.

A.11.

Destination Aerodrome

A.11.1.

ICAO

Field 16, element (a).

A.11.2.

ADEXP

Primary field ‘ades’.

L 254/76

EN

Official Journal of the European Communities

9.10.2000

A.12.

Aircraft Number and Type

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

A.12.1.

ICAO

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

A.12.2.

ADEXP

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

A.13.

Route

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

A.13.1.

Content

A.13.1.1.

F l i g h t s P r o c e e d i n g v i a a D e f i n e d C O P

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

F l i g h t s P r o c e e d i n g O f f A T S R o u t e

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

I C A O

Field type 15, in field type 22 format.

A.13.2.2.

A D E X P

Primary field ‘route’.

A.14.

Other Flight Plan Data

A.14.1.

ICAO

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

9.10.2000

EN

Official Journal of the European Communities

L 254/77

A.14.2.

ADEXP

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

A.15.

Co-ordination Status and Reason

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

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

following:

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

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

— CRD, when the system flight plan is to be in co-ordinated status, i.e. basic ACT received or

initial co-ordination dialogue completed with conditions agreed.

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

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

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

— HLD, to indicate that the flight is holding for an indefinite period and will be subject to a

further message;

— DLY, to indicate that the departure is delayed;

— CAN, if the reason is a cancellation;

— CSN, for a change of callsign;

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

A.15.1.

ICAO

A.15.1.1.

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

A.15.1.2.

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

— STA followed by an oblique stroke;

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

— the indicator specifying the reason.

A.15.2.

ADEXP

Primary field ‘cstat’.

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

L 254/78

EN

Official Journal of the European Communities

9.10.2000

A.16.

Assigned Heading (ADEXP only)

Primary field ‘ahead’ shall contain either:

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

or

— if no heading is assigned, the indicator ‘ZZZ’, e.g. when an SDM message is used to indicate that a

previously assigned heading no longer applies.

A.17.

Assigned Speed (ADEXP only)

Primary field ‘aspeed’ shall contain either:

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

or

— if no speed is assigned, the indicator ‘ZZZ’, e.g. when an SDM message is used to indicate that a

previously assigned speed no longer applies.

A.18.

Assigned Rate of Climb/Descent (ADEXP only)

Primary field ‘rate’ shall contain:

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

or

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

A.19.

Direct Clearance (ADEXP only)

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

Primary field ‘DCT’ containing:

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

— a known reference point;

or

— a range and bearing from a known reference point, as defined in the same message by Primary

field ‘REF’;

or

— the value ‘ZZZ’ if the sending unit does not require to designate the deviation point.

— the point situated on the original flight plan route to which the aircraft has been or will be cleared,

defined as:

— a known reference point;

or

— a range and bearing from a known reference point, as defined in the same message by Primary

field ‘REF’.

9.10.2000

EN

Official Journal of the European Communities

L 254/79

A.20.

Direct Routing Request

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

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

A.20.1.

ICAO

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

It shall contain:

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

— a known reference point;

or

— a range and bearing from a known reference point;

or

— the value ‘ZZZ’ if a direct routing is being requested by the receiving ATC unit.

— the abbreviation ‘DCT’,

— followed by the point situated on the original flight plan route to which the aircraft is requested to

be cleared, defined as:

— a known reference point;

or

— a range and bearing from a known reference point.

A.20.2.

ADEXP

Primary field ‘DCT’ containing:

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

— a known reference point;

or

— a range and bearing from a known reference point, as defined in the same message by Primary

field ‘REF’;

or

— the value ‘ZZZ’ if a direct routing is being requested by the receiving ATC unit but the precise

point at which it would commence is not known.

— the point situated on the original flight plan route to which the aircraft is requested to be cleared,

defined as:

— a known reference point;

or

— a range and bearing from a known reference point, as defined in the same message by Primary

field ‘REF’.

L 254/80

EN

Official Journal of the European Communities

9.10.2000

A.21.

Position (ADEXP only)

A.21.1.

General

A.21.1.1.

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

A.21.1.2.

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

A.22.

Release Indication (ADEXP only)

Primary field ‘release’ shall contain one of the following:

— C, if the flight is released for climb;

— D, if the flight is released for descent;

— T, if the flight is released for turns;

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

A.23.

Frequency

A.23.1.

ICAO

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

— FRQ, followed by an oblique stroke;

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

A.23.2.

ADEXP

Primary field ‘freq’.

A.24.

Reason (ADEXP only)

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

A.25.

Cleared Flight Level (ADEXP only)

Primary field ‘cfl’.

A.26.

Proposed Transfer Flight Level (ADEXP only)

Primary field ‘propfl’.

9.10.2000

EN

Official Journal of the European Communities

L 254/81

A.27.

Estimated Take-Off Time

A.27.1.

ICAO

Field type 13 element (b).

A.27.2.

ADEXP

Primary field ‘etot’.

A.28.

Reference Message Type

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

A.28.1.

ICAO

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

A.28.2.

ADEXP

Primary field ‘msgtyp’.

L 254/82

EN

Official Journal of the European Communities

9.10.2000

ANNEX B (Normative)

SPECIAL ROUTE PROCESSING REQUIREMENTS

B.1.

Introduction

B.1.1.

General

B.1.1.1.

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

— a flight routes on a direct track, off route, across the boundary as the result of a direct route

segment filed in the flight plan;

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

— a different ATS route;

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

B.1.1.2.

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

B.2.

Application of Messages

B.2.1.

Basic Rules for Direct Routings

B.2.1.1.

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

B.2.1.2.

The data required for the notification and co-ordination of flights on direct routings is contained in the
co-ordination point (estimate data (ICAO format) and co-ordination data (ADEXP format)) and route
in the applicable messages.

B.2.2.

Direct Route Filed

When the route indicates that the flight will cross the boundary on a direct track, the direct route
segment and the resultant COP will be included in the ABI message(s). This COP is included in the
subsequent ACT or RAP message.

The COP and route data shall be formatted as described in paragraph B.3.2.

B.2.3.

Re-routings after ABI and before ACT Transmission

A new ABI message shall be sent with data corresponding to the new route.

B.2.4.

Re-routing after ACT transmission

B.2.4.1.

A REV message shall be used to indicate re-routings after the ACT message has been sent until a
bilaterally agreed time before the ETO at the COP previously co-ordinated.

NOTE A REV message is only used where the accepting unit does not change as the result of the modification.
If it does change, a MAC message must be sent to the original accepting unit or the co-ordination
verbally cancelled.

9.10.2000

EN

Official Journal of the European Communities

L 254/83

B.2.4.2.

The message shall contain the following data elements:

— Co-ordination point (previous COP, for reference purposes);

— Estimate data;

— Route.

B.2.4.3.

ICAO format messages shall contain the following fields:

3 Message type and number; message reference if bilaterally agreed;

7

Aircraft identification. Elements b and c shall not be included unless a revision o the SSR code is
being co-ordinated simultaneously;

13 Departure aerodrome;

14 Element a only, containing the previous COP for reference purposes;

16 Destination;

22 Field 14 containing the estimate data for the new boundary crossing conditions in field 22 format;

22 Field 15 containing the new route in field 22 format.

B.2.4.4.

ADEXP format messages shall
identification, departure aerodrome, destination and,
number:

include,

in addition to the message type and number, aircraft
if bilaterally agreed, the message reference

— the previous COP in the COP field;

— the new co-ordination conditions in the COORDATA field;

— the new route in the ROUTE field.

B.2.4.5.

Route revisions sent as part of the dialogue procedure shall be sent as RRV messages unless bilaterally
agreed to be considered ‘standard’.

B.3.

Field Contents

B.3.1.

ATS Routes

For flights which re-route via an alternative ATS Route, the estimate and route fields are formatted as
for ABI and ACT messages.

B.3.2.

Direct Routes

B.3.2.1.

The co-ordination point in the estimate data shall be the point of boundary crossing expressed as a
bearing and distance from a reporting point. Such points shall be bilaterally agreed. Where the distance
is zero or a flight will pass within a bilaterally agreed distance from such a point, only the identifier of
the point shall be included.

B.3.2.2.

When bilaterally agreed, the co-ordination point for a flight on a direct route may be expressed by
reference to latitude/longitude.

B.3.2.3.

The route shall contain:

— the point situated on the original route from which the aircraft is to route direct; where a flight is
routed direct from ‘present position’, the point may be expressed as a bearing and distance from
a reporting point. When bilaterally agreed,
the point may be expressed by reference to
latitude/longitude;

L 254/84

EN

Official Journal of the European Communities

9.10.2000

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

A B I a n d A C T M e s s a g e s

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

Direct Route

ATS Route

Boundary

Flight trajectory

Point C
(PTC)

COP

UA134

Point A
(PTA)

AMM 253

distance: 22 NM

Point B
(PTB)

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.

 
9.10.2000

EN

Official Journal of the European Communities

L 254/85

B.4.1.2.

R E V M e s s a g e

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

Direct Route

ATS Route

Boundary

Flight trajectory

MYY

TDS

WSS

HZT 2051

RQA

The flight is then routed from 40 NM west of point RQA direct to MYY. The closest point to the
boundary crossing is TDS from which the distance to the actual crossing point is 26 NM at bearing
240 degrees. The following revision message is sent:

(REVQW/FG464-HZT2051-HECA-WSS-EHBK-14/TDS240026/1842F310-15/N0458F310
RQA270040 DCT MYY)

Direct Route

ATS Route

Boundary

Flight trajectory

MYY

WSS

COP

distance: 26 NM

TDS

HZT 2051

distance: 40 NM

RQA

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.

 
 
L 254/86

EN

Official Journal of the European Communities

9.10.2000

B.4.2.

Re-route via ATS Routes after ACT Transmission

B.4.2.1.

A C T M e s s a g e

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)

Direct Route

ATS Route

Boundary

Flight trajectory

EMT

UM247

XAT

UJ124

Point A
(PTA)

UM247

GKP 217
CFL 270

The flight subsequently re-routes via ATS route UM247 within the sending centre’s airspace to new
co-ordination point XAT following which it is to follow ATS route UJ124. The accepting centre
remains the same. The following revision message is sent:

(REVK/G214-GKP217-EGNX-EMT-DTTA-14/XAT/1225F270-15/N0430F290 UM247 XAT UJ124)

D ire c t R o u te

A T S  R o u te

B o u n d a ry

F lig h t tra je c to ry

E M T

X A T

U M 2 4 7

U J 1 2 4

P o in t A
(P T A )

U M 2 4 7

G K P  2 1 7
C F L  2 7 0

 
 
9.10.2000

EN

Official Journal of the European Communities

L 254/87

The flight is then cleared to FL290 resulting in the following message (containing the new COP):

(REVK/G233-GKP217-EGNX-XAT/1225F290-DTTA)

Direct Route

ATS Route

Boundary

Flight trajectory

EMT

XAT

UM247

UJ124

Point A
(PTA)

UM247

GKP 217
&)/(cid:3)(cid:21)(cid:28)(cid:19)

B.4.2.2.

A D E X P E q u i v a l e n t s

The ADEXP equivalents of the two revision messages are as follows:

a. -TITLE REV -REFDATA -SENDER -FAC K -RECVR -FAC G -SEQNUM 214 -ARCID GKP217 -ADEP
EGNX -COP EMT -ADES DTTA -COORDATA -PTID AT -TO 1225 -TFL F270 -ROUTE N0430F290
UM247 XAT UJ124

b. -TITLE REV -REFDATA -SENDER -FAC K -RECVR -FAC G -SEQNUM 233 -ARCID GKP217 -ADEP

EGNX -COORDATA -PTID XAT -TO 1225 -TFL F290 -ADES DTTA

 
L 254/88

EN

Official Journal of the European Communities

9.10.2000

ANNEX C (Informative)

DIALOGUE PROCEDURE (SYSCO LEVEL 1) PHASES — MESSAGE SEQUENCE

Message Sequence

9.10.2000

EN

Official Journal of the European Communities

L 254/89

ANNEX II

AIR TRAFFIC SERVICES DATA EXCHANGE PRESENTATION (ADEXP) EDITION 2.0

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

L 254/90

EN

Official Journal of the European Communities

9.10.2000

TABLE OF CONTENTS

COPYRIGHT NOTICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

FOREWORD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.

2.

3.

3.1.

3.2.

3.3.

3.4.

3.5.

3.6.

4.

4.1.

4.2.

4.3.

5.

5.1.

5.2.

6.

6.1.

6.2.

6.3.

6.4.

6.5.

SCOPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

DEFINITIONS, SYMBOLS AND ABBREVIATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ADEXP PRINCIPLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Textual, Human Readable Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Identified and Retrievable Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Unrecognised Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ADEXP SYNTAX RULES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Lexical Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

NORMALISED DESCRIPTION OF ADEXP MESSAGES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Auxiliary Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Definition of Primary Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Definition of Subfields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Group of Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ANNEX A (NORMATIVE)

FIELD DEFINITIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ANNEX B (NORMATIVE) CENTRAL INDEX OF ADEXP MESSAGE TITLES . . . . . . . . . . . . . . . . . . . . . . . . . .

ANNEX C (NORMATIVE) CENTRAL INDEX OF RESERVED MESSAGE TITLES . . . . . . . . . . . . . . . . . . . . . .

ANNEX D (NORMATIVE) CENTRAL INDEX OF RESERVED FIELD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ANNEX E (INFORMATIVE)

INTRODUCTION OF MESSAGE GROUPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ANNEX F (INFORMATIVE)

EXAMPLES OF ADEXP MESSAGE FORMAT . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ANNEX G (INFORMATIVE)

FUTURE DEVELOPMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

91

92

94

94

95

95

95

95

95

96

97

98

98

99

99

100

100

104

106

106

107

108

108

108

110

137

140

145

159

164

167

9.10.2000

EN

Official Journal of the European Communities

L 254/91

COPYRIGHT NOTICE

This document has been produced by the Eurocontrol Agency.

Copyright is vested with the Eurocontrol Agency.

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

L 254/92

EN

Official Journal of the European Communities

9.10.2000

FOREWORD

1.

Responsible Body

This Standard has been developed and is maintained by the User Requirements Section of the Central
Flow Management Unit (CFMU) of the European Organisation for the Safety of Air Navigation
(Eurocontrol).

2.

EATCHIP Work Programme Document

This Standard has been produced as a deliverable of the EATCHIP Work Programme Document
(EWPD), Data Processing Systems Domain (DPS), Executive Task 09.

3.

3.1.

3.2.

Approval of the Standard

This Standard is adopted in accordance with the procedures outlined in the Directives for Eurocontrol
Standardisation, Ref. 000-2-93, Edition 1.0.

The provisions of this Standard became effective after adoption of edition 1.0 by the Permanent
Commission of Eurocontrol in 1995 and had a date of application with effect from 1st. December
1997.

4.

Technical Corrigenda and Amendments

This Standard is kept under review to ascertain required amendments or technical corrigenda. The
procedure for the maintenance of this Standard is laid down in Annex H of the Directives for the
Uniform Drafting and Presentation of Eurocontrol Standard Documents.

Amendments or additions affecting the basic principles or grammar of the ADEXP format shall only
be made following the formal review procedure as provided in the Directives for the Uniform Drafting
and Presentation of Eurocontrol Standard Documents.

Amendments or additions to this Standard shall be proposed in writing to: CFMU Users Requirements
Section (ADEXP), Eurocontrol Agency.

5.

5.1.

Editorial Conventions

The format of this Standard complies with the Directives for the Uniform Drafting and Presentation of
Eurocontrol Standard Documents, there are however some departures from the Directives. The minor
formatting exemptions from the Directives are to avoid confusion with the ATS Data Exchange
Presentation (ADEXP) notation.

5.2.

The following notation has been used to indicate the status of each statement:

— Normative Elements use the operative verb ‘shall’ and have been printed in light faced roman text;

— Recommended Elements use the operative verb ‘should’ and have been printed in light faced italics,

the status being indicated by the prefix; Recommendation.

6.

Relationship to other Standard Documents

This Standard is related to:

Eurocontrol Standard Document for On-Line Data Interchange (OLDI)

9.10.2000

EN

Official Journal of the European Communities

L 254/93

7.

Status of Annexes to this Standard

There are 6 Annexes to this Directive, the status of each being defined as follows:

Annex A

Annex B

Annex C

Annex D

Annex E

Annex F

Annex G

Normative

Normative

Normative

Normative

Informative

Informative

Informative.

8.

Language used

The English language has been used for the original text of this Standard.

L 254/94

EN

Official Journal of the European Communities

9.10.2000

1.

1.1.

1.2.

1.3.

1.4.

1.5.

2.

2.1.

SCOPE

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.

ADEXP provides a format for use primarily in on-line, computer to computer message exchange.

This document defines the principles and syntax rules of the ADEXP format. It provides this definition
in terms of a comprehensive definition of the ADEXP fields.

The ADEXP format has been specified for use within the following areas of message exchange (for
document reference information see Section 2, page 3):

— Flight Planning: exchange of flight plan data and associated messages between the Integrated Initial
Flight Plan Processing System (IFPS), Air Traffic Services (ATS) and Aircraft Operators (AO).
(Document Ref. 3)

— Air Traffic Flow Management (ATFM): exchange of messages between the Tactical System (TACT)

of the CFMU, AO and ATS. (Document Ref. 5)

— Air Traffic Control Co-ordination: exchange of tactical co-ordination messages between Air Traffic

Control Units (ATCU). (Document Ref. 6)

— Airspace Management: exchange of data between National ATS Units, the CFMU and AO,

concerning airspace availability. (Document Ref. 7)

— Civil / Military Co-ordination: messages concerning civil/military flight data and airspace crossing

messages. (Document Ref. 7).

Detailed specifications concerning the usage and content of the messages within each of the above
groups shall be found in the referenced documents.

REFERENCES

The following documents and standards contain provisions which, through reference in this text,
constitute provisions of this Eurocontrol Standard Document.

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

Any revision of the referenced International Civil Aviation Organisation (ICAO) Documents shall be
immediately taken into account to revise this Eurocontrol Standard Document.

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

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

2.2.

At the time of publication, the documents listed below are those that are referenced from this Standard
however users are invited to check the usage and message field composition tables in the latest editions
of these documents.

1. ICAO Chicago Convention Annex 10 Volume I, edition dated November 1985;

2. ICAO Chicago Convention Annex 10 Volume II, edition dated July 1995;

3. IFPS and RPL Dictionary of Messages, edition 1.0, dated March 1998;

9.10.2000

EN

Official Journal of the European Communities

L 254/95

4.

‘Rules of the Air and Air Traffic Services’, PANS-RAC Doc 4444, edition dated November 1985
(including Amendment No 6 dated November 1995);

5. Guide To ATFM Message Exchange Eurocontrol Document Ref. TACT/USD/MSGGUID, edition 6.0,

effective March 1998,

6. Eurocontrol Standard for On-Line Data Interchange, edition 2.0, dated October 1996.

7. Functional Specifications for System Support to Airspace Data Distribution and Civil Military Co-

ordination, edition 1.0, dated May 1996.

3.

DEFINITIONS, SYMBOLS AND ABBREVIATIONS

3.1.

Notation

The notation used to define the syntax is termed Backus Naur Form (BNF). BNF defines a set of rules
which determines a class of character strings. In this case, the class of character strings is the set of
messages which can be called a syntactically valid ADEXP message.

3.2.

Definitions

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

Token: A character or set of characters which can be ‘extracted’ by a lexical analyser due to the presence
of separators.

Symbol: Any ‘term’ which appears in a BNF rule but which is not a character.

Terminal Symbol: A symbol which is represented in terms of a sequence of characters.

Non-Terminal Symbol: A symbol which is represented by one or more terminal symbols.

NOTE A non-terminal symbol may also be represented as a mixture of terminal and non-terminal symbols.

3.3.

Construction

3.3.1.

BNF consists of a set of rules or constructs of the form:

symbol ::= expression

NOTES

1) The ‘::=’ notation should be read as ‘can be replaced by’.

2) The ‘symbol’ is classed as non-terminal.

3) The ‘expression’ part contains terminal and non-terminal symbols.

3.3.2.

Terminal symbols have a direct representation as a sequence of characters which can be identified as a
token by a lexical analyser, using the presence of separators.

3.4.

Conventions

For the purposes of this Eurocontrol Standard document, the following conventions shall apply:

— Terminal symbols are in upper case.

NOTE By convention, the NIL terminal symbol stands for ‘no terminal symbol’.

It is used in choices as in the following example:
a ::= b (c | NIL) where a can be replaced by (b followed by c) or by b only.

L 254/96

EN

Official Journal of the European Communities

9.10.2000

— Non-Terminal symbols (e.g. the left hand side of a grammar production) are in lower case.

— Characters and String Literals appearing inside rules are respectively enclosed in quotes (') or double

quotes (").

Examples

1) HYPHEN ::= '-'

2) title ::= '-' "TITLE" titleid

It may be required, for some data modelling applications, to distinguish between terminal and non-
terminal symbols by means other than the use of upper and lower case lettering.

Whenever it is required to explicitly distinguish between terminal and non-terminal symbols, other
than by the use of upper and lower case lettering, it is recommended to use the addition of a suffix as
follows: ‘–at’ for an Auxiliary term, ‘–pf’ for a Primary field and ‘–sf’ for a Subfield.

3.5.

Operators

For the purposes of this Eurocontrol Standard document, the following operators shall apply:

Optional: When some symbols can legally appear or not appear at some point in the grammar. The
optional symbols are enclosed in square brackets ‘[’ and ‘]’.

Closure: When a group of symbols may appear zero or more times. The symbols are enclosed in curly
brackets ‘{’ and ‘}’. If a number is specified before the ‘{’ it gives the minimum number of times that the
group of symbols may appear. If a number is specified after the ‘}’ it gives the maximum number of
times that the group of symbols may appear.

Choice: When a number of alternative symbols may appear at some point in the grammar. Choice is
represented by ‘|’.

Concatenation: Representation of symbols that follow sequentially, even though one or more separators
may come in the middle. There is no explicit representation of this. They are two types:

— Strict Concatenation: at the lexical level, rules may involve concatenation of terminals indicating that
they strictly follow each other (no separator in the middle), in this case the ‘!’ symbol shall be used.

Example datetime :: = date ! timehhmm

e.g. "9912251200" meaning 25th December 1999, at 12h00.

— Loose Concatenation: the allowed presence of separators between terminals. The representation of

Loose Concatenation within a rule may be either Implicit or Explicit

Examples

1) Implicit:

dct ::= '-' "DCT" point point

2) Explicit

dct ::= '-'!{SEP}!"DCT"!1{SEP}!point!1{SEP}!point

e.g. "-DCT NTM RMS".

9.10.2000

EN

Official Journal of the European Communities

L 254/97

NOTES

1) Concatenation shall always takes precedence over choice. Parenthesis ‘(’ and ‘)’ are used to alter the expression

evaluation 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 is a risk of confusion due to precedence between the above mentioned operators,
it is recommended to use the parenthesis, in order to clarify the desired evaluation order.

3.6.

Abbreviations

For the purposes of this Eurocontrol Standard Document, the following abbreviations shall apply:

ACH

ADEG

ADEXP

AFIL

AFP

AFTN

ANM

AO

APL

ATC

ATCU

ATFM

ATS

BNF

CASA

CIDIN

CFL

CFMU

CMTP

CNL

CTOT

DPS

ECAC

EFL

EOBT

ETO

ATC Flight Plan Amendment Message

ATS Data Exchange Group

ATS Data Exchange Presentation

Air-Filed Flight Plan

ATC Flight Plan Proposal

Aeronautical Fixed Telecommunication Network

ATFM Notification Message

Aircraft Operator(s)

ATC Flight Plan

Air Traffic Control

Air Traffic Control Unit(s)

Air Traffic Flow Management

Air Traffic Services

Backus Naur Form

Computer Assisted Slot Allocation

Common ICAO Data Interchange Network

Cleared Flight Level

Central Flow Management Unit

Common Medium-Term Plan

Cancellation Message

Calculated Take-Off Time

Data Processing Systems Domain

European Civil Aviation Conference

Estimated Flight Level

Estimated Off-Block Time

Estimated Time Over

Eurocontrol

European Organisation for the Safety of Air Navigation

EWPD

EATCHIP Work Programme Document

FIR

FIW

FMP

FNM

FPL

Flight Information Region

Flight Plan Input Workstation

Flow Management Position

Flight Notification Message

Flight Plan Message (ICAO format)

L 254/98

EN

Official Journal of the European Communities

9.10.2000

GAT

IA

IAFP

ICAO

IFPD

IFPS

IFPU

IFR

ISO

ITA

LAM

LRM

MAC

MFS

OAT

OLDI

RFL

RFP

RFPD

RPL

RVR

SFL

SRD

SSR

TACT

TOS

UIR

VFR

General Air Traffic

International Alphabet

Individual ATC Flight Plan Proposal

International Civil Aviation Organisation

Individual Flight Plan Data

Integrated Initial Flight Plan Processing System

IFPS Unit

Instrument Flight Rules

International Standards Organisation

International Telegraph Alphabet

Logical Acknowledgement Message

Logical Rejection Message

Co-ordination Abrogation Message

Message from Shanwick

Operational Air Traffic

On-Line Data Interchange

Requested Flight Level

Replacement Flight Plan

Repetitive Flight Plan Data

Repetitive Flight Plan

Runway Visual Range

Supplementary Flight Level

Software Requirements Document

Secondary Surveillance Radar

Tactical System of the CFMU

Traffic Orientation Scheme

Upper Information Region

Visual Flight Rules

4.

ADEXP PRINCIPLES

4.1.

Textual, Human Readable Format

4.1.1.

The ADEXP format is a textual format, based on characters.

4.1.2.

The ADEXP messages remain readable to a human operator which enables better tuning, or operational
issues, to be addressed.

4.1.3.

A textual format is also more open and understandable.

9.10.2000

EN

Official Journal of the European Communities

L 254/99

4.2.

Identified and Retrievable Fields

4.2.1.

A message in ADEXP format shall be composed of fields.

4.2.2.

Fields shall be delimited by a special start-of-field character, the hyphen character (‘-’) and identified by
specific keywords.

NOTE It should be noted that certain fields (those syntactically defined as containing the lexical

item

‘CHARACTER’) may legally contain a ‘-’ character as part of the field content.

4.2.3.

4.2.4.

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

As another consequence, the order of fields in a message shall not be relevant to determine its legality,
except for the first field (mandatory title field) which determines the allowed fields.

4.2.5.

Fields may be basic or compound.

4.2.6.

The constituent parts of compound fields are called subfields, and are defined by the presence of
keywords, delimited by the a start-of-field character.

4.2.7.

Basic fields are fields which do not contain subfields.

4.2.8.

The basic or compound fields composing the first level of definition of a message are called its primary
fields.

4.2.9.

All lower level constituents are by definition subfields, which in turn, may be basic or compound.

4.2.10.

Compound fields are of two kinds, structured fields or list fields.

4.2.11.

Structured fields have a pre-defined content made exclusively of subfields. The order of subfields in a
structured field is NOT significant.

4.2.12.

List fields are introduced by the BEGIN keyword and terminated by the END keyword. Between these,
repeating occurrences of a same subfield or combination of subfields may take place. The order of the
occurrences inside a list field is semantically significant.

4.2.13.

In the following, the term ‘field’ will be used generically to mean primary and/or subfields, except
when explicitly qualified otherwise.

4.2.14.

Fields in a message may be optional or mandatory, as defined by their syntax.

4.3.

Unrecognised Fields

4.3.1.

If an unknown field appears in a message, it shall be ignored.

4.3.2.

In other words, if the system which analyses the message does not recognise a keyword, all the text up
to the next known Primary Field, which is not within a List Field, will be ignored.

L 254/100

EN

Official Journal of the European Communities

9.10.2000

4.3.3.

Depending on the message title, the ignored field may or may not cause a rejection of the message
being parsed.

NOTE It should be noted that although ADEXP is designed to provide this type of flexibility, it is at the
discretion of those responsible for defining the interface requirements, to indicate, for each message, how
the system should react to an unrecognised field.

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.

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

4.3.5.

4.3.6.

This allows the definition of two kinds of keywords:

— Primary keywords;

— Sub-keywords.

4.3.7.

Once it is defined as being of one kind, a keyword shall not be further re-used in another group of
messages as the other kind, with the one exception when it is inside a list field. It is possible to have
inner occurrences of a primary keyword anywhere within a list field without creating ambiguity, since
the presence of the BEGIN keyword indicates we may consider the inner occurrence as a subfield.

Examples (of use of keyword types)

1) Primary Field

-RFL F330

2) Sub-Field: always within a ‘Compound Field’

-GEO -GEOID 01 -LATTD 520000N -LONGTD 0150000W

where -GEO is a primary compound field and -GEOID, -LATTD and LONGTD are all sub-fields.

3) List Field

-BEGIN RTEPTS -PT -PTID CMB -ETO 9305091430 -RFL F370 -PT -PTID

..........

-END RTEPTS

where ‘-BEGIN’ is the list field indicator and ‘RTEPTS’ is a primary field.

NOTE ‘RFL’ is defined as a primary field. Inclusion within a list field is the only occasion when a primary field

may be used as a subfield. (See Example 3 above)

5.

ADEXP SYNTAX RULES

5.1.

Lexical Elements

5.1.1.

Character Set

5.1.1.1.

The character set to be used for the exchange of messages in ADEXP format shall be International
Alphabet Number 5 (IA-5) as defined in Reference 1.

9.10.2000

EN

Official Journal of the European Communities

L 254/101

5.1.1.2.

The ADEXP format is designed as a computer to computer exchange format which may be transmitted
on different computer networks or on dedicated computer-computer links. In addition, a requirement
exists to be able to exchange some ADEXP messages, typically Flight Planning and ATFM related, on
the Aeronautical Fixed Telecommunication Network (AFTN).

5.1.1.3.

Messages which may be required to be transmitted via AFTN shall have their character set restricted to
those characters that have a direct correlation between International Telegraph Alphabet Number 2
(ITA-2) and IA-5, as defined in Reference 1.

NOTE Besides graphic characters and format effectors as defined below, the ITA-2 character set defines ‘signals’
(like perforated tape, for instance). They are not part of the allowed character set for ADEXP messages.

5.1.1.4.

The characters which are permitted for use within ADEXP messages which may be transmitted via
AFTN, are the graphic characters and the format effectors as defined below:

Graphic Characters

a) upper case letters (A to Z)

b) digits (0 to 9)

c) special graphic characters, as follows:

1) space character ‘ ’

2) open bracket ‘(’

3) close bracket ‘)’

4) hyphen ‘-’

5) question mark ‘?’

6) colon ‘:’

7) full stop ‘.’

8) comma ‘,’

9) apostrophe ‘'’

10) equal sign ‘=’

11) plus sign ‘+’

12) oblique ‘/’

Format Effectors

a) Carriage-Return

b) Line-Feed

5.1.2.

Basic Lexical Items

The following basic lexical items are defined for use in this specification:

— ALPHA ::= 'A'|'B'|'C’|'D'|'E’|'F'|'G’|'H'|'I’|'J'|'K’|'L'|'M’|'N'|'O’|'P'|'Q’|'R'|'S’| 'T'|'U’|'V'|'W'|'X'|'Y'|'Z'

— DIGIT ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'

— ALPHANUM ::= ALPHA | DIGIT

L 254/102

EN

Official Journal of the European Communities

9.10.2000

— SPACE ::= ' '

— HYPHEN ::= '-'

— FEF ::= Carriage–return | Line–Feed

— SEP ::= 1{ SPACE | FEF }

— SPECIAL ::= SPACE | '(' | ')' | '?' | ':' | '.' | ',' | '’' | '=' | '+' | '/'

— CHARACTER ::= ALPHA | DIGIT | SPECIAL | FEF | HYPHEN

— LIM–CHAR ::= ALPHA | DIGIT | SPECIAL | FEF

— START-OF-FIELD ::= HYPHEN

NOTE LIM–CHAR represents any allowed character except HYPHEN which is reserved to indicate the start of

a field. On the contrary, CHARACTER represents any allowed element of the character set.

5.1.3.

Lines, Separators and Delimiters

5.1.3.1.

The division into lines of the text of a message shall have no syntactic effect.

5.1.3.2.

A separator can be a space character or format effector.

5.1.3.3.

Fields shall be delineated only by the presence of a start-of-field character followed by a keyword.

5.1.3.4.

Hence the whole message could legally be on one line.

5.1.4.

Signed Values

5.1.4.1.

It may be required to indicate a numeric value as being negative.

5.1.4.2.

Fields which are required to indicate a negative value shall, within their syntax definition, explicitly
indicate the value as being a ‘signed value’ i.e. as being either positive or negative. A field which has
not been so defined may not represent a negative value.

5.1.4.3.

A ‘signed value’ shall always be preceded by either the letter ‘N’ meaning negative or ‘P’ meaning
positive. A zero value may be preceded by either ‘N’ or ‘P’.

5.1.4.4.

The syntax of a field which allows a ‘signed value’ shall be as follows:

'-' "KEYWORD" ("P" | "N") ! 1{DIGIT}

Example: A field called ‘NUMBER’ which may contain a negative value of one to eight digits would

be defined as:

'-' "NUMBER" ("P" | "N") ! 1{DIGIT}8

Therefore:

-NUMBER P5

— value of ‘number’ is +5

-NUMBER N5

— value of ‘number’ is –5

-NUMBER 5

— invalid syntax, either a ‘P’ or a ‘N’ must be

present

9.10.2000

EN

Official Journal of the European Communities

L 254/103

5.1.5.

Keywords

5.1.5.1.

A keyword is any sequence of upper case letters or digits. It introduces a field only when it is preceded
by a start-of-field character (‘-’).

keyword ::= 1{ ALPHANUM }

5.1.5.2.

Keywords shall comply with the following syntax:

'-'!{SEP}!"KEYWORD"!1{SEP}! <subfield/s or contained value>

i.e. a keyword shall be separated from it's ‘start-of-field character’ by zero or more separators. It shall
be followed immediately by one or more separators, followed by the relevant subfield/s or contained
value.

NOTE It is important to note that a keyword and its preceding start-of-field character may be

separated by any number of separators, including none.

Examples (The following sequences all validly introduce a field)

1) -TITLE IFPL

2) - TITLE IFPL

3) - TITLE IFPL

4) -

TITLE IFPL

5.1.5.3.

Recommendation It is a recommended practice to avoid the use of a separator between the start-of-field
character ‘-’ and the subsequent keyword.

NOTE

1) In the examples above, the first occurrence is the recommended choice.

2) It is also important to note that a keyword must be immediately followed by at least one separator.

5.1.5.4.

Throughout the document the concatenation of items separated by at least one separator is implicitly
represented by the notation of ‘Loose Concatenation’ (see 3.5).

NOTE As will be explained later, keywords also introduce list fields when they are preceded by the

BEGIN keyword.

5.1.5.5.

Keywords shall be as short as possible while remaining semantically meaningful.

5.1.5.6.

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:

BEGIN:

END:

identifies a category of messages and defines the corresponding set of
allowed primary fields;

identifies the beginning of a list field;

identifies the end of a list field;

COMMENT:

identifies a COMMENT field.

L 254/104

EN

Official Journal of the European Communities

9.10.2000

5.1.5.7.

In order to avoid ambiguity (duplicate use of a same keyword with different meanings) or redundancy
(different keywords with the same meaning), a Central Definition Table of Primary Fields (i.e. primary
keywords) is maintained in this Standard at Annex A (A3) and a Central Definition Table of Subfields
(i.e. sub-keywords) is also maintained at Annex A (A4).

5.2.

Fields

5.2.1.

Field Syntax

field ::= basic–field | structured–field | list–field

basic–field ::= '-' keyword contained–values

contained–values ::= {CHARACTER}

list–field ::= '-' "BEGIN" keyword {subfields} '-' "END" keyword

structured–field ::= '-' keyword field–1 field–2 .............field–n

NOTE As will be seen, in the case of list fields, the keyword is not preceded directly with ‘-’ but with

the ‘-’‘BEGIN’ construct.

5.2.2.

Message Composition in Terms of Fields

5.2.2.1.

The first field of an ADEXP message shall always be a TITLE field (i.e. a field introduced by the TITLE
keyword).

5.2.2.2.

The remaining contents of a message in terms of its primary fields, shall be defined by its TITLE.

5.2.2.3.

The syntax of messages corresponding to a given TITLE shall be defined by the fields it contains
(defined by their keywords):

— The name and allowed content of its primary fields;

— The name and allowed content of its subfields.

5.2.3.

Basic Fields

5.2.3.1.

The syntax of basic field shall be as follows:

basic–field ::= '-' keyword contained–values

5.2.3.2.

‘Contained–values’ defines the text which provides the value of the field, and may not introduce any
subfield.

Example rule arctyp ::= '-' "ARCTYP" (icaoaircrafttype | "ZZZZ")

NOTE

1) An explicit equivalent rule of which being:

arctyp ::= '-'!{SEP}!"ARCTYP"!1{SEP}!(icaoaircrafttype | "ZZZZ").

2) An example portion of a message is :: "-ARCTYP ZZZZ".

9.10.2000

EN

Official Journal of the European Communities

L 254/105

5.2.3.3.

Recommendation Where there are more than two contained values within a basic field and there is, in
addition, the need to express ‘choice’ or ‘option’ amongst the values, it is recommended to make the field a
structured field and to include the contained values within subfields.

5.2.4.

List Fields

5.2.4.1.

The syntax of list fields shall be as follows:

list–field ::='-' "BEGIN" keyword { subfields } '-' "END" keyword

5.2.4.2.

The ‘subfields’ may be any combination of subfields, the occurrence of which may appear zero or
more times inside the list field.

5.2.4.3.

The list of subfields contained in a given list field shall form an ordered set (the order of subfields is
significant).

Example rule addr ::= '-' "BEGIN" "ADDR" { fac } '-' "END" "ADDR"

NOTE

1) This example shows that an ‘addr’ field is a list field containing 0 or more occurrences of a ‘fac’

subfield (an ATS facility).

2) An example portion of a message showing ADDR as a list field containing FAC subfields is:

-BEGIN ADDR -FAC LLEVZPZX -FAC LFFFZQZX -END ADDR.

3) An example portion of a message showing a combination of subfields is:

xxx ::= '-' "BEGIN" "XXX" { yyy | zzz } '-' "END" "XXX".

5.2.5.

Structured Fields

5.2.5.1.

The syntax of structured fields shall be as follows:

structured–field ::= '-' keyword field–1 field–2......field–n

5.2.5.2.

The allowed contained subfields in a given structured field shall depend only on the structured field
itself.

5.2.5.3.

The order of appearance of subfields in a structured field shall not be significant, which allows for easy
future extensions (by adding new contained subfields).

Example rule pt ::= '-' "PT" ptid [fl] [eto]

NOTES

1) This defines the ‘pt’ field as a structured field containing a point (‘ptid’ subfield), optionally followed
by a calculated flight level (‘fl’ subfield), optionally followed by an estimated time over the point
(‘eto’ subfield).

2) An example occurrence of that field may be for instance:

"-PT -PTID RMS -FL F250 -ETO 921225120000".

L 254/106

EN

Official Journal of the European Communities

9.10.2000

5.2.5.4.

Recommendation Wherever it is felt that the contents of a field might evolve in the future, it is desirable to
make it a structured field. This will allow progressive extensions of its subfields.On the contrary, a basic field may
be simpler or more familiar to use, but it imposes a fixed sequence of elements (values) with very reduced extension
possibilities.

5.2.6.

The COMMENT Field

5.2.6.1.

The comment field introduces an area of free text where all available characters except the start-of-
field character (‘-’) can be used, and which extends to the next field.

comment ::= '-' "COMMENT" { LIM–CHAR }

Example

COMMENT THIS IS THE BEGINNING OF A FREE ROUTE TEXT AREA

5.2.7.

The TITLE Field

5.2.7.1.

The first field of an ADEXP message shall always be a title field. The syntax of which shall be as
follows:

title ::= '-' "TITLE" 1{ ALPHA }10

5.2.7.2.

The possible values of the title field consist of the set of ADEXP message titles, as listed in Annex B of
this Standard.

Example -TITLE IFPL

6.

NORMALISED DESCRIPTION OF ADEXP MESSAGES

6.1.

Introduction

6.1.1.

The following paragraphs define how the ADEXP format of different categories of messages shall be
described in a normalised way, in the frame of the present Standard.

6.1.2.

The Normalised description involves:

— Definition of auxiliary terms;

— Definition of each individual primary field's syntax and semantic;

— Definition of each individual subfield's syntax and semantic;

— Definition of each group of messages with reference to their defining documentation.

6.1.3.

6.1.4.

This Standard does not provide the detail concerning the field composition and data insertion rules
for each message title.

Reference should be made to the defining documentation (Interface Specification) which is applicable
to the relevant message group (See section 6.5.7).

9.10.2000

EN

Official Journal of the European Communities

L 254/107

6.1.5.

Defining documentation should provide, in a normalised manner, the following information for each
message title:

— a list of compulsory primary fields;

— a list of optional primary fields;

— the data insertion rules for each field, and in particular, the rules concerning the use of subfields

defined as optional within this Standard;

— the rules concerning recovery following the detection of an unrecognised field.

6.1.6.

The fields currently defined and agreed throughout Eurocontrol member states for use within the
different categories of messages which have been defined for use using ADEXP, are those provided in
Annex A of this document.

6.1.7.

A field shall not be used for a purpose other than that specified in it's semantic description.

6.1.8.

A central index of reserved fields is provided at Annex D. ‘Reserved fields’ have not been agreed for
use within the currently defined ADEXP messages. Typically they are fields which have been foreseen
for possible future use, or they are used locally within national systems. The purpose of including
them in this Standard is to assist in ensuring the uniqueness of field titles and avoidance of unnecessary
redundancy.

6.2.

Auxiliary Terms

6.2.1.

6.2.2.

In order to provide a readable definition of fields, it is often useful to introduce auxiliary terms in the
grammar description.

Auxiliary terms do not introduce a field or subfield and hence, are not associated with a particular
keyword. However, they may appear in the definition of more than one field, or subfield, or auxiliary.
For instance an auxiliary term like ‘date’ may be used in the definition of many fields.

6.2.3.

All necessary auxiliary terms shall be introduced in alphabetical order and are defined in Annex A (A2)
of this Standard.

6.2.4.

The description may be presented in a table as follows, sorted in alphabetical order:

Auxiliary Term

Syntax

Semantic

Used in
Primary Field

Used in Subfield

Used in
Auxiliary

adexpmsg

{ CHARACTER }

text

con-
to the
described
an ADEXP

Free
forming
syntax
for
message.

ifpdlong
rfpdlong
preproctxt
postproctxt

aidequipment

( ('N' | 'S') ! [ equip- Radio communi- ceqpt
mentcode ] ) | equip- cation, navigation
and approach aid
mentcode
equipment.

aircraftid

1{ ALPHANUM }7

Aircraft
cation.

Identifi- arcid
arcidk
arcidold
prevarcid

L 254/108

EN

Official Journal of the European Communities

9.10.2000

6.3.

Definition of Primary Fields

6.3.1.

All primary fields used in ADEXP messages shall conform to the syntax and semantics as expressed in
Annex A (A3) of this Standard.

6.3.2.

The syntax of each field will be given first, then its semantic in plain clear and unambiguous terms.

6.3.3.

The syntax of fields will be expressed using the BNF notation as introduced in section 3 of this
Standard.

6.3.4.

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.

Definition of Subfields

6.4.1.

6.4.2.

6.4.3.

All subfields used in ADEXP messages shall conform to the syntax and semantics expressed in Annex A
(A4) of this Standard.

Additionally, for cross-reference purposes, the primary fields inside which a given subfield appears are
identified.

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

Semantic

Used in Primary
Field

Used in
Subfield

brng

b

'-' "BRNG" refbear- Bearing of a point ref
ing

from a navigation aid
(in magnetic degrees)

6.5.

Group of Messages

6.5.1.

6.5.2.

The operational categories (groups) of messages which have been defined for use using the ADEXP
format are introduced in Annex E of this Standard.

The groups are defined in terms of the operational nature of the messages being exchanged and are
often characterised by the systems concerned.

9.10.2000

EN

Official Journal of the European Communities

L 254/109

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.

6.5.7.

A reference to the related group is given for each message title listed in the central index of message
titles. Reference to the defining documentation for each message title is therefore provided via the
message group.

A central index of reserved message titles is also provided at Annex C. ‘Reserved’ message titles have
not been agreed for use within the currently defined groups of messages using ADEXP. Typically they
are messages which have been foreseen for possible future use within one of the defined groups, or
they are used locally within national systems. The purpose of including them in this Standard is to
assist in ensuring the uniqueness of message titles and avoidance of unnecessary redundancy.

L 254/110

EN

Official Journal of the European Communities

9.10.2000

ANNEX A (Normative)

ADEXP FIELD DEFINITIONS

A.1.

Introduction

This Annex provides a listing of all the fields; Auxiliary Terms, Primary Fields and Sub-Fields which have been
defined for use in ADEXP.

A.2. ADEXP Auxiliary Terms

Auxiliary Term

Syntax

Semantic

Used in
Primary Field

Used in
Subfield

Used in
Auxiliary

adexpmsg

{ CHARACTER }

Free text conforming
syntax
the
to
described
an
for
ADEXP message.

ifpdlong
rfpdlong
preproctxt
postproctxt

aidequipment

|

('N'

'S')
(
mentcode ]
mentcode

!
)

[ equip- Radio
| equip-

communica- ceqpt

tion, navigation and
approach aid equip-
ment.

aircraftid

2{ ALPHANUM }7

Aircraft Identification. arcid
arcidk
arcidold
prevarcid

aircraftidwldcrd 1{ ALPHANUM | '+' |
'?' }7

Wildcard form of air- arcidk
craftid to be used in
Query messages:
‘?’
character
‘+’ replaces any num-
ber of characters.

replaces

one

atsroute

2 {ALPHANUM} 7

The designator of an atsrt
ATS route.

refatsrte

fulldate

statid

statreason

refatsrte

century

2{DIGIT}2

coorstatusident

3 {ALPHA} 3

coorstatusreason 3 {ALPHA} 7

country

2{ALPHA}2

datalink

1 {'S' | 'H' | 'V' | 'M' } 4

Two first digits of a
century.

An indicator of the co-
ordination status of a
flight.

The reason for notify-
ing a change in the co-
ordination status.

The two letter ICAO
designator of a coun-
try.

The ICAO designator dat
of the datalink capa-
bility.
May contain any of
the values: S, H, V or
M in any order but
without repetition.

9.10.2000

EN

Official Journal of the European Communities

L 254/111

Auxiliary Term

Syntax

Semantic

Used in
Primary Field

Used in
Subfield

Used in
Auxiliary

date

year ! month ! day

datetime

date ! timehhmm

eto

datetime

A date indication in ada
add
the format,
aobd
YYMMDD.
cobd
e.g. 930424 =
ctod
24th. April 1993.
eobd
eobdk
eobdold
etod
fstday
iobd
lstday
neweobd
valfrom
valfromk
valfromold
validitydate
valuntil
valuntilk
valuntilold

term as origindt

A ‘date’
described above and
immediately followed
by the time in the for-
mat, HHMM.
e.g. 9304240930 =
0930Z on the
24th. April 1993.

datewldcrd

1{ DIGIT | '+' | '?' )6

A ‘date’
may be wild carded.

term which valfromk
valuntilk

day

('0' | '1' | '2' | '3') ! DIGIT A two digit number endtime

emergradio

1 {'U' | 'V' | 'E' } 3

which may contain filtim
the digits from 00 to starttime
31.

Indicator of the type splr
of emergency radio
equipment on board
the aircraft. May be
one or more of the
defined characters in
any order but without
repetition.

equipmentcode

to indicate

1 {('A' | 'B' | 'C' | 'D' | 'E' | A valid ICAO code let-
the
'F' | 'G' | 'H' | 'I' | 'J' | 'K' |
'L' | 'M' | 'O' | 'P' | 'Q' | 'R'
carried.
| 'T' | 'U' | 'V' | 'W' | 'X' | May be one or more of
the defined characters
'Y' | 'Z' )} 24
in any order but with-
out repetition.

ter
equipment

errorcode

1{DIGIT}4

Error message code error
number.

date
fulldate

endreg
from
startreg
until

aidequip-
ment

L 254/112

EN

Official Journal of the European Communities

9.10.2000

Auxiliary Term

Syntax

Semantic

Used in
Primary Field

Used in
Subfield

Used in
Auxiliary

fieldid

1{ ALPHANUM }

firindicator

4{ ALPHA }4

Valid ADEXP
name (i.e. keyword).

field errfield
ifpsmod

An ICAO designator eetfir
of an FIR.

crfl1
crfl2
efl
fl
tfl
sfl
ptrfl

rfl

sts

flightlevel

('F' | 'A') ! 3{ DIGIT }3 | A flight level expres-
('S' | 'M') ! 4{ DIGIT } 4

sed either as;
‘F’ or ‘A’ followed by
three digits or,
‘S’ or ‘M’ followed by
four digits.

flightplanstatus

'EMER' | 'HUM' | 'HOSP' | The reason for special
treatment as indicated
'SAR' | 'HEAD' | 'STATE'
in Field 18 element
‘STS/’.
EMER = Emergency
HUM = Humanitarian
flight
HOSP
flight
SAR = Search and
Rescue
HEAD = Head of State
STATE = State flight

= Hospital

flightrule

'I' | 'V' | 'Y' | 'Z'

flighttype

'S' | 'N' | 'G' | 'M' | 'X'

flighttypechg

'OAT' | 'GAT'

The flight rule indi-
cator of a flight.

fltrul

The type of flight as
indicated by the ICAO
designator used.

flttyp

The indication pro- chgrul
vided in the route of
flight of a change in
the type of flight to
‘OAT’ or ‘GAT’.

fulldate

century ! year ! month ! A date indication in
format
day

the
CCYYMMDD
eg. 19970801 = 1st.
Aug. 1997

ptrulchg

fulldatetime

fulldatetime

fulldate ! timehhmm

geoname

"GEO" ! 2{DIGIT}2

heading

3{DIGIT}3

A date, as described in mesval-
'fulldate', and immedi- period
ately followed by the
time in the format
HHMM
e.g. 199708010930 =
0930 hours on
1st. Aug. 1997

The
identification
given to a geographi-
cal position expressed
in latitude and longi-
tude.

A three digit number ahead
in the range 001 to
360.

geoid

9.10.2000

EN

Official Journal of the European Communities

L 254/113

Auxiliary Term

Syntax

Semantic

Used in
Primary Field

Used in
Subfield

Used in
Auxiliary

icaoaerodrome

4{ ALPHA }4

icaoaerodro-
mewldcrd

1{ ALPHA | '+' | '?' }4

letter

A four
designator
aerodrome.

for

ICAO adarr
an adep
adepk
adepold
ades
adesk
adesold
altrnt1
altrnt2

Wildcard
form of adepk
icaoaerodrome, to be adesk
used in Query mess-
ages:
‘?’
character
‘+’ replaces any num-
ber of characters.

replaces

one

icaoaircrafttype ALPHA ! 1{ ALPHANUM An ICAO designator arctyp

}3

of an aircraft type.

icaomsg

{ CHARACTER }

msgtxt

An ICAO message.
(conforming to the
syntax described in
Ref. {4})

ifpuid

1{ ALPHANUM }

The identifier of an ifpuresp
IFPS Unit.

latitudelong

6{ DIGIT }6

latitudeside

'N' | 'S'

lifejackets

1 {'L' | 'F' | 'U' | 'V'} 4

longitudelong

7{ DIGIT }7

longitudeside

'E' | 'W'

A latitude expressed as
six digits.

for
indicator
An
‘North’ or ‘South’ lati-
tude.

splj

The ICAO indicator of
the type of lifejackets
carried.
May be one or more of
the defined characters
in any order but with-
out repetition.

A longitude expressed
as seven digits.

An indicator for ‘East’
or ‘West’ longitude.

adid

lattd

lattd

longtd

longtd

machnumber

'M' ! 3{ DIGIT }3

The Mach number.

mach
aspeed

crmach
ptmach

modifind

1{ALPHANUM}

Indication of the type ifpsmod
of modification made
to a field.

L 254/114

EN

Official Journal of the European Communities

9.10.2000

Auxiliary Term

Syntax

Semantic

Used in
Primary Field

Used in
Subfield

Used in
Auxiliary

month

('0' | '1' ) ! DIGIT

Month, expressed as a
two digit number.

date
fulldate

numdays

('0' | '1') ! ('0' | '2') ! ('0' | The indication of the days
'3') ! ('0' | '4') ! ('0' | '5') ! days of the week on daysk
('0' | '6') ! ('0' | '7')

which a RPL is active.

daysold

numdayswldcrd 1{ DIGIT | '+' | '?' }7

originatorid

1{ ALPHANUM }10

point

2{ ALPHANUM }5

refbearing

3{ DIGIT }3

refname

"REF" ! 2{DIGIT}2

regulid

1{ ALPHANUM }20

renameid

"REN" ! 2{DIGIT}2

rrteid

1{ ALPHANUM} 20

rtf

6{DIGIT}6

rulechg

VFR' | 'IFR'

The indication of the daysk
days of the week on
which a RPL is active.
Wildcard
characters
may also be used.

Identifier of the orig- orgnid
qrorgn
inator of a message.

The designator of a atsrt
significant point. May chgrul
be a published point, cop
a geographical point, dct
a reference point or a eetpt
point given artificially mach
such as a ‘re-named’
point (RENxx).

rfl
speed
sid
star

Reference Bearing val-
ue.

The identifier given to
a point expressed by
bearing and distance
from a
published
point

The identification of
an ATFM regulation
concerning a flight.

Identifier of
named point.

a

re-

The identifier of a re-
routing.

rrteref

frequency freq

A radio
expressed in MHz to
three decimal places.

The indicators used in chgrul
the route of a flight to
indicate a change in
the flight rules.

ptid
refatsrte

brng

refid

ptrulchg

eto
sto

regul

regid

renid

seconds

( '0' | '1' | '2' | '3' | '4' | '5' Seconds.
) ! DIGIT

Two digits from ‘00’
to ‘59’.

spd

('K' | 'N') ! 4{ DIGIT }4

Speed.
Expressed as either ‘K’
or ‘N’ followed by four
digits.

aspeed
speed

crspeed
ptspeed

9.10.2000

EN

Official Journal of the European Communities

L 254/115

Auxiliary Term

Syntax

Semantic

Used in
Primary Field

Used in
Subfield

Used in
Auxiliary

ssrequipment

1 {ALPHA} 2

seqpt

The ICAO designator
of the SSR equipment
carried and optionally,
indication of a data
link capability.

stayidentifier

STAY' ! ( '1' | '2' | '3' | '4' Designator of a ‘stay’
period, a period of
| '5' | '6' | '7' | '8' | '9' )
‘special activity’ within
the route of a flight.

ptstay
stayident

survivaleqpt

1 {'P' | 'D' | 'M' | 'J' } 4

text20

1{ LIM–CHAR }20

spls

The ICAO designator
of the survival equip-
ment carried.
May be one or more of
the defined characters
in any order but with-
out repetition.

Text made of 1 to 20 altnz
characters, excluding com
the hyphen character. depz
destz
nav
per
sts
typz

datetime
fulldatetime

cto
endreg
eto
from
ptstay
startreg
sto
time
to
until

timehhmm

Time,

expressed in aobt

( '0' | '1' | '2' ) ! DIGIT ! (
'0' | '1' | '2' | '3' | '4' | '5' ) hours (2 digits 00-23) ata
and minutes (2 digits atd
! DIGIT
00-59). May be the atot
time of day or a dur- cobt
ctot
ation.
delay
endtime
eobt
eobtk
eobtold
etot
filtim
iobt
minlineup
newctot
neweobt
newptot
ptot
rejctot
respby
starttime
taxitime

timehhmm–
elapsed

DIGIT ! DIGIT ! ('0' | '1' | An unlimited number
ttleet
'2' | '3' | '4' | '5' ) ! DIGIT of hours and minutes, eetfir
eetpt
sple

used for durations.

timewldcrd

1{ DIGIT | '+' | '?' }4

titleid

1{ ALPHA }10

Wild card form of a eobtk
timehhmm.

A valid ADEXP mess- msgtyp
age title. (see Annex B) orgmsg

title

L 254/116

EN

Official Journal of the European Communities

9.10.2000

Auxiliary Term

Syntax

Semantic

Used in
Primary Field

Used in
Subfield

Used in
Auxiliary

waketurbcat

'H' | 'M' | 'L'

year

2{ DIGIT }2

The ICAO wake tur- wktrc
bulence category des-
ignator.

Two last digits of a
year.

date
fulldate

A.3. ADEXP Primary Fields

ADEXP
Primary Field

Kind

Syntax

Semantic

ad

ada

adarr

adarrz

add

addr

adep

adepk

c

b

b

b

b

c

b

b

adepold

b

ades

adesk

b

b

'-' "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
routing information
description additional
may be provided.

'-' "ADA" date

Actual date of arrival.

-' "ADARR" (icaoaerodrome | 'ZZZZ') Actual aerodrome of arrival.

'-' "ADARRZ" text20

Name of actual aerodrome of arrival
ICAO location indicator exists.

if no

'-' "ADD" date

Actual date of departure.

'- "BEGIN" "ADDR" 1 { fac } '-' "END"
"ADDR"

List of addressees.

'-' "ADEP" (icaoaerodrome | 'AFIL' |
'ZZZZ')

'-' "ADEPK" (icaoaerodrome | 'AFIL' |
'ZZZZ' | icaoaerodromewldcrd)

ICAO location indicator of the aerodrome of
departure or the indication ‘AFIL’ meaning an
air-filed flight plan or ‘ZZZZ’ when no ICAO
location indicator is assigned to the aerodrome
of departure.

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 indi-
cator is assigned to the aerodrome of departure
or a combination of alphabetic and wildcard
characters.

'-' "ADEPOLD" (icaoaerodrome | 'AFIL' The ‘previous’ aerodrome of departure. May
contain the ICAO location indicator or the
| 'ZZZZ')
indication ‘AFIL’ meaning an air-filed flight
plan or ‘ZZZZ’ when no ICAO location indi-
cator is assigned to the aerodrome of departure.

'-' "ADES" (icaoaerodrome | 'ZZZZ')

'-' "ADESK" (icaoaerodrome | 'ZZZZ' |
icaoaerodromewldcrd)

The ICAO location indicator of the aerodrome
of destination or ‘ZZZZ’ when no ICAO
location indicator is assigned to the aerodrome
of destination.

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 destination
or a combination of alphabetic and wildcard
characters.

9.10.2000

EN

Official Journal of the European Communities

L 254/117

ADEXP
Primary Field

Kind

Syntax

Semantic

adesold

b

'-' "ADESOLD" (icaoaerodrome |
'ZZZZ')

The ‘previous’ aerodrome of destination. May
contain the ICAO location indicator or ‘ZZZZ’
when no ICAO location indicator has been
assigned to the aerodrome of destination.

adexptxt

afildata

c

c

'-' "AFILDATA" ptid fl eto

'-' "ADEXPTXT" (preproctxt | post-
proctxt)

Contains an ADEXP message.

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.

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.

ahead

b

'-' "AHEAD" (heading | "ZZZ")

altnz

altrnt1

altrnt2

aobd

aobt

arcid

arcidk

arcidold

arctyp

aspeed

b

b

b

b

b

b

b

b

b

b

'-' "ALTNZ" text20

Name of alternate aerodrome if no ICAO
location exists.

'-' "ALTRNT1" (icaoaerodrome |
'ZZZZ')

'-' "ALTRNT2" (icaoaerodrome |
'ZZZZ')

'-' "AOBD" date

'-' "AOBT" timehhmm

'-' "ARCID" aircraftid

'-' "ARCIDK" (aircraftid | air-
craftidwldcrd)

'-' ARCIDOLD aircraftid

The ICAO location indicator of the first alter-
nate aerodrome of destination or the indicator
‘ZZZZ’ when no ICAO location indicator has
been assigned to the aerodrome.

The ICAO location indicator of the second
alternate aerodrome of destination or the indi-
cator ‘ZZZZ’ when no ICAO location indicator
has been assigned to the aerodrome.

Actual Off–Block Date.

Actual Off–Block Time.

Aircraft Identification.
May be the registration marking of the aircraft,
or the ICAO designator of the aircraft operator
followed by the flight identifier.

Aircraft Identification used as database key in
a query; may be wild-carded.
Must be a combination of alphanumeric and
wild-card characters up to maximum 7 charac-
ters in total.

The ‘previous’ aircraft id. Where the aircraft id.
is to be amended, the new value will be given
in ‘ARCID’.

'-' "ARCTYP" (icaoaircrafttype |
"ZZZZ")

Type of aircraft (ICAO identification of the
type) or ZZZZ.

'-' "ASPEED" (spd | machnumber |
"ZZZ")

The currently assigned speed of the flight, in
kilometres per hour, knots or Mach number.
Must be ‘M’ followed by three digits, ‘K‘ or ‘N’
followed by four digits or ‘ZZZ’ indicating that
no speed restriction is assigned.

L 254/118

EN

Official Journal of the European Communities

9.10.2000

ADEXP
Primary Field

Kind

Syntax

Semantic

ata

atd

atot

atsrt

cassaddr

ceqpt

cfl

chgrul

cobd

cobt

com

comment

condid

coordata

cop

crsclimb

cstat

ctod

ctot

dat

b

b

b

b

c

b

c

b

b

b

b

b

b

c

b

c

c

b

b

b

'-' "ATA" timehhmm

Actual time of arrival.

'-' "ATD" timehhmm

Actual time of departure.

'-' "ATOT" timehhmm

Actual Time of Take-off

'-' "ATSRT" atsroute point point

ATS route designator and identifiers of first
and last points.

'-' "BEGIN" "CASSADDR" { fac } '-'
"END" "CASSADDR"

Addresses to which ATFM messages should be
addressed.

'-' "CEQPT" aidequipment

'-' "CFL" fl [ptid]

'-' "CHGRUL" ( rulechg | flighttypechg
| rulechg flighttypechg ) point

Radio
approach aid equipment (as ICAO field 10).

communication,

navigation

and

Cleared Flight Level. The flight level currently
assigned by ATC to the pilot
level
number).

(flight

Indication 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" date

Calculated Off-Block Date.

'-' "COBT" timehhmm

Calculated Off-Block Time.

'-' "COM" text20

Communication equipment (as ICAO field 18
COM/).

'-' "COMMENT" 1 { LIM–CHAR }

A general comment
hyphen.

in free text without

'-' "CONDID" 1 {LIM–CHAR} 30

Identification of an ‘exceptional condition’
raised in the context of ATFM.

'-' "COORDATA" ptid (to | sto) tfl [sfl]

'-' "COP" point

'-' "CRSCLIMB" ptid (crspeed | crmach)
crfl1 crfl2

'-' "CSTAT" statid [statreason]

The transfer conditions of a flight. A point id.,
the flight level and estimated time at that
point and optional supplementary flight level
information.

A co-ordination point identifier, either a coded
designator of a point or a name given artificially
(GEOxx, RENxx or REFxx).

Indication of a cruiseclimb. Giving the point at
which the climb will begin, speed or mach no.
and 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.

An indicator confirming the new co-ordination
status of a flight and, optionally, the reason for
the change.

'-' "CTOD" date

Calculated Take-Off Date.

'-' "CTOT" timehhmm

'-' "DAT" datalink

Calculated Take-Off Time (CTOT): reference
time of an ATFM Slot.

Indication of the datalink capability carried by
the aircraft.

9.10.2000

EN

Official Journal of the European Communities

L 254/119

ADEXP
Primary Field

Kind

Syntax

Semantic

days

b

'-' "DAYS" numdays

Days of operation for a repetitive flight plan
(1234567 where 1 is for Monday, 2 for
Tuesday, ..., with 0 in columns of non-oper-
ation).

daysk

daysold

b

b

'-' "DAYSOLD" numdays

'-' "DAYSK" (numdays | num-
dayswldcrd)

Days of operation for a repetitive flight plan,
used as database key in a query message, may
be wildcarded.

dct

b

'-' "DCT" point point

delay

b

'-' "DELAY" timehhmm

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

Indicates a direct route between two points.
The points may either be a valid ICAO desig-
nator of a point or a point appearing in a GEO,
REN or REF field of the form GEOxx, RENxx
or REFxx.

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

desc

destz

eetfir

eetlat

eetlong

eetpt

endtime

entrydata

eobd

eobdk

b

b

b

b

c

c

b

b

c

b

b

'-' "DEPZ" text20

Name of departure aerodrome if no ICAO
location indicator exists.

'-' "DESC" 1 {LIM–CHAR}

Description of a condition or entity which is
of relevance to the content of the message.

'-' "DESTZ" text20

Name of destination aerodrome if no ICAO
location indicator exists.

'-' "EETFIR" firindicator timehhmm–
elapsed

FIR identification and the accumulated elapsed
time (in hours and minutes) to the FIR bound-
ary.

'-' "EETLAT" lattd time

Indication of an elapsed time to a position
given by latitude only.

'-' "EETLONG" longtd time

Indication of an elapsed time to a position
given by longitude only.

'-' "EETPT" point timehhmm–elapsed

Point identifier and the accumulated elapsed
time to the point.

'-' "ENDTIME" day ! timehhmm

The time at which a period of time ends.

'-' "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 both
of the fields; ‘ptid’, ‘airspdes’, must be present.

'-' "EOBD" date

Estimated Off-Block Date.

'-' "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.

L 254/120

EN

Official Journal of the European Communities

9.10.2000

ADEXP
Primary Field

Kind

Syntax

Semantic

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

eobtk

eobtold

errfield

error

estdata

etod

etot

extaddr

filrte

filtim

flband

fltrul

flttyp

fmp

fmplist

freq

b

b

b

b

b

c

b

b

c

b

b

c

b

b

b

c

b

'-' "EOBT" timehhmm

Estimated Off-Block Time (EOBT)

'-' "EOBTK" (timehhmm | timewldcrd)

Estimated Off-Block Time used as database key
in a query, may be wildcarded.

'-' "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’.

'-' "ERRFIELD" fieldid

ADEXP name of erroneous field(s).

'-' "ERROR" [errorcode] 1{ LIM–
CHAR }

Error message text. May optionally contain an
error identification code.

'-' "ESTDATA" ptid eto fl [sfl]

Estimate data. A point id., the estimated 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" date

Estimated Take-Off Date.

'-' "ETOT timehhmm

Estimated Take-Off Time.

'-'"EXTADDR" num | { fac } | (num
{fac})

Addresses which are provided in addition to
those which are determined automatically i.e.
‘extra addresses’. May contain only the number
of addresses or the actual addresses or both.

'-' "FILRTE" {LIM–CHAR}

The route exactly as filed i.e. without any
processing.

'-' "FILTIM" day ! timehhmm

Day-time group specifying when the message
was filed for transmission.

'-' "FLBAND" fl fl

A flight level band defining the airspace verti-
cally, inclusive of the flight levels given.

'-' "FLTRUL" flightrule

Flight rule, as ICAO field 8.

'-' "FLTTYP" flighttype

Type of flight, as ICAO field 8.

'-' "FMP" 4{ ALPHA }4

Identifier of a ‘Flow Management Position’.

'-' "BEGIN" "FMPLIST" fmp reglist
'-' "END" "FMPLIST"

List of FMPs and their associated ATFM regu-
lations.

'-' "FREQ" rtf

Radio frequency.

9.10.2000

EN

Official Journal of the European Communities

L 254/121

ADEXP
Primary Field

Kind

Syntax

Semantic

'-' "IFP" 1{ALPHA}

Indication of known errors within a FPL.

'-' "BEGIN" "IFPDLIST" 1 { ifpdlong }
'-' "END" "IFPDLIST"

ifpdslist

c

'-' "BEGIN" "IFPDSLIST" 1 { ifpdsum }
'-' "END" "IFPDSLIST"

'-' "IFPLID" ALPHA ALPHA { DIGIT }8 A unique flight plan identifier, assigned by the
IFPS.

fstday

b

'-' "FSTDAY" date

furthrte

b

'-' "FURTHRTE" {LIM–CHAR}

'-' "GEO" geoid lattd longtd

geo

ifp

ifpdlist

c

b

c

ifplid

ifpsmod

ifpuresp

ignore

b

b

b

c

'-' "IFPSMOD" fieldid modifind

'-' "IFPURESP" ifpuid

'-' "BEGIN" "IGNORE" { (condition |
condition ptid ptid) }'-' "END"
"IGNORE"

iobd

b

'-' "IOBD" date

First day of operation for a repetitive 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.

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.

Point along a route defined by latitude and
longitude and given in the flight plan, as
GEOxx (where xx is a sequence number).

List of complete IFPDs matching the database
key given in a query message.
Contains a list of complete information for
each individual flight which matches given
query keys.

List of ifpdsum matching the database key
given in a query message.
Contains a list of summarised information for
each individual
flight which matches given
query keys.

An indication given by IFPS of those fields
which have been modified, and the nature of
the modification.

Identifier of the IFPU which is responsible for
a query. It must process the query and answer
to it.

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, for example, be a time restric-
tion (route access condition), flight level restric-
tion or TOS violation.

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.

L 254/122

EN

Official Journal of the European Communities

9.10.2000

ADEXP
Primary Field

Kind

Syntax

Semantic

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

latsa

lcatsrte

lfir

lrar

lrca

lstday

mach

mesval-
period

c

c

c

c

c

c

b

b

b

'-' "BEGIN" "LACDR" { airroute } '-'
"END" "LACDR"

List of Active Conditional Routes.

'-' "BEGIN" "LATSA" { airspace } '-'
"END" "LATSA"

List of Active Temporary Segregated Areas.

'-' "BEGIN" "LCATSRTE" { airroute } '-'
"END" "LCATSRTE"

List of Closed ATS Routes.

'-' "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 Con-
ditional Routes or the lists of Available Con-
ditional Routes, Closed ATS Routes, Active
Temporary Segregated Areas, Reduced Air-
space Restrictions and Reduced Co-ordination
Airspaces.

'-' "BEGIN" "LRAR" { airspace } '-'
"END" "LRAR"

List of Reduced Airspace Restrictions.

'-' "BEGIN" "LRCA" { airspace } '-'
"END" "LRCA"

List of Reduced Co-ordination Areas.

'-' "LSTDAY" date

Last day of operation for a repetitive 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.

'-' "MACH" machnumber [ point ]

Mach number, in hundredths of a unit and
optionally the point at which the change is
requested.

'-' "MESVALPERIOD" fulldatetime
fulldatetime

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

9.10.2000

EN

Official Journal of the European Communities

L 254/123

ADEXP
Primary Field

Kind

Syntax

Semantic

msgref

msgsum

msgtxt

msgtyp

nav

nbarc

nbrfpd

newctot

c

c

b

b

b

b

b

b

'-' "MSGREF" sender recvr seqnum

Reference data for associated, previously trans-
mitted messages.

'-' "BEGIN" "MSGSUM" { [arcid] [adep] Contains a summary of a message.
[ades] [eobt] [eobd] [orgn] [days]
[valfrom] [valuntil] }
'-' "END" MSGSUM"

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" icaomsg

Contains a complete ICAO message.

'-' "MSGTYP" titleid

Contains the title of the referenced or copied
message.
May be any valid ADEXP message title (see
Annex B).

'-' "NAV" text20

Significant navigation equipment, as ICAO
field 18 NAV/.

'-' "NBARC" 1{ DIGIT }2

Number of aircraft if more than one.

'-' "NBRFPD" 1{ DIGIT }3

Number of flight plan data matching a query.
Must be between 0 and 999.

'-' "NEWCTOT" timehhmm

A new Calculated Take-Off Time, as updated
by TACT.

newendtime b

'-' "NEWENDTIME" day ! timehhmm

A new time at which a period of time ends.

neweobd

neweobt

newptot

newrte

b

b

b

b

'-' "NEWEOBD" date

A new Estimated Off-Block Date.

'-' "NEWEOBT" timehhmm

A new Estimated Off-Block Time.

'-' "NEWPTOT" timehhmm

A new Provisional Take-Off Time.

'-' "NEWRTE" { LIM–CHAR }

A new route between the same aerodromes of
departure and arrival as in the original message.

newstarttime b

-' NEWSTARTTIME day ! timehhmm A new time at which a period of time starts.

oldmsg

opr

orgmsg

orgn

orgnid

orgrte

origin

b

b

b

b

b

b

c

'-' "OLDMSG" { CHARACTER }

A complete original message, exactly (and in
the same format) as it was received.

'-' "OPR" 1 { LIM–CHAR }

Name of the company or agency operating the
flight, as ICAO Field 18 element OPR/.

'-' "ORGMSG" titleid

The ADEXP Title of an erroneous message, as
it was received by TACT.

'-' "ORGN" 1{LIM–CHAR}30

The address of the originator of a message.

'-' "ORGNID" originatorid

The designator of an addressee having orig-
inated a message.

'-' "ORGRTE" { LIM–CHAR }

Original route between the aerodromes of
departure and arrival.

'-' "ORIGIN" networktype | fac | (net-
worktype fac)

Information concerning the originator of a
message. May include the type of network used
or the address concerned or both.

L 254/124

EN

Official Journal of the European Communities

9.10.2000

ADEXP
Primary Field

Kind

Syntax

Semantic

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

per

position

prevarcid

prevssrcode

propfl

ptot

qrorgn

ralt

rate

ratepdlst

reason

ref

refdata

c

b

c

b

b

c

b

b

b

b

c

b

c

c

'-' "PART" num lastnum

Identification of the part of the message ident-
ified by the title, filing time and validity period.

'-' "PER" text20

Aircraft performance data, as ICAO field 18
PER/.

'-' "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" aircraftid

The previous callsign used.

'-' "PREVSSRCODE" ALPHA ! 4{ '0' |
'1' | '2' | '3' | '4' | '5' | '6' | '7' }4

SSR Mode and Code used by the flight immedi-
ately prior to the SSR Mode and Code given in
field ‘-SSRCODE’.

'-' "PROPFL" tfl [sfl]

A flight level proposed by an accepting unit
for the transfer of a flight.

'-' "PTOT" timehhmm

Provisional Take-Off Time. Provisional refer-
ence time for an ATFM slot.

'-' "QRORGN" originatorid

Identifier of the originator of the Query.

'-' "RALT" 1 {LIM–CHAR} 40

Name of en-route alternate aerodrome/s.

'-' "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.

'-' "BEGIN" "RATEPDLST" 1
{rateperiod} '-' "END" "RATEPDLST"

List of time periods and their respective flow
rates for an ATFM condition.

'-' "REASON" 4{ALPHA}12

Reason for either rejection of a message or
cancellation of a slot by TACT.
Information in support of the message depen-
dent on its context.

'-' "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" [sender] [recvr] seqnum Reference data for message being transmitted.

9.10.2000

EN

Official Journal of the European Communities

L 254/125

ADEXP
Primary Field

Kind

Syntax

Semantic

reg

regloc

regul

rejctot

release

b

b

b

b

b

'-' "REG" 1{ LIM–CHAR }7

Registration markings, as ICAO field 18 REG/.

'-' "REGLOC" 1 {LIM–CHAR} 15

Reference location for an ATFM Regulation.

'-' "REGUL" regulid

Identifier of a Regulation concerning a flight.

'-' "REJCTOT" timehhmm

Rejected Calculated Take-Off Time: negative
response to a Slot Improvement Proposal.

'-' "RELEASE" 1{ALPHA}1

rename

c

'-' "RENAME" renid ptid

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

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

rfl

rfp

rfpdlist

rfpdslist

rif

rmk

route

b

b

b

c

c

b

b

b

'-' "RESPBY" timehhmm

Respond By: time by which a response to a
Slot Improvement Proposal has to be made.

'-' "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" "Q" ( '1' | '2' | '3' | '4' | '5' | '6'
| '7' | '8' | '9' )

Replacement Flight Plan (RFP) indicator.
Must be ‘Q’ followed by a digit (1 - 9).

'-' "BEGIN" "RFPDLIST" { rfpdlong } '-'
"END" "RFPDLIST"

List of complete RFPDs matching the database
keys given in a Query.

'-' "BEGIN" "RFPDSLIST" { rfpdsum }
'-' "END" "RFPDSLIST"

List of rfpdsum (RFPD summarised infor-
mation) matching the database keys given in a
Query.

'-' "RIF 4{LIM–CHAR}

Revised route subject to clearance in flight and
terminating with the ICAO designator of the
revised aerodrome of destination.

'-' "RMK" 1{ LIM–CHAR }

Plain language remarks, as ICAO field 18
RMK/.

'-' "ROUTE" {LIM–CHAR}

Complete ICAO Field 15 information contain-
ing speed, RFL and route (conforming to the
syntax given in Ref. 4).

L 254/126

EN

Official Journal of the European Communities

9.10.2000

ADEXP
Primary Field

Kind

Syntax

Semantic

rrtefrom

rrteref

rrteto

rtepts

rvr

rvrcond

rvrperiod

sector

sel

sendto

seqpt

sid

speed

spla

spladdr

splc

spldcap

spldcol

spldcov

c

b

c

c

b

c

c

b

b

c

b

b

b

b

c

b

b

b

b

'-' "RRTEFROM" tfvid refloc flowlst
flblock

Description of a traffic flow which is to be re-
routed.

'-' "RRTEREF" rrteid

Re-Route Reference.

'-' "RRTETO" tfvid refloc flowlst
flblock

Description of a traffic flow to which traffic is
to be re-routed.

'-' "BEGIN" "RTEPTS" { pt [ad]} '-'
"END" "RTEPTS"

List of route points. May also contain an
aerodrome identifier.

'-' "RVR" 1{ DIGIT }3

Runway Visual Range (RVR).
Operating minima when special meteorologi-
cal conditions exist. Expressed in meters.

'-' "BEGIN" "RVRCOND" 1 {rvrperiod}
'-' "END" "RVRCOND"

List of time periods and their applicable RVR
limits.

'-' "RVRPERIOD" from until rvrlimit

The period of time within which the RVR limit
provided is applicable.

'-' "SECTOR" 1{ ALPHANUM }8

Identification of an ATC sector.

'-' "SEL" 4{ ALPHA }5

SELCAL code as ICAO Feld 18 element ‘SEL/’.

'-' "BEGIN""SENDTO" {unit} '-'
"END""SENDTO"

List of air navigation units which are to be sent
a message

'-' "SEQPT" ssrequipment

Surveillance equipment, as ICAO Field 10.

'-' "SID" point ! 1{DIGIT}1 !
0{ALPHA}1

Identifier of a Standard Instrument Departure
procedure.

'-' "SPEED" spd [ point ]

True airspeed (in kilometres per hours or
knots) and optionally, the point at which a
change of airspeed is requested.

'-' "SPLA" 1{ LIM–CHAR }50

Colour of markings on aircraft, as ICAO Field
19 element ‘A/’.

'-' "BEGIN" "SPLADDR" { fac } '-' "END" Contact data, where flight plan Supplementary
"SPLADDR"

information may be obtained.

'-' "SPLC" 1{ LIM–CHAR }50

Name of pilot in command, as ICAO Field 19
element ‘C/’.

'-' "SPLDCAP" 1{ DIGIT }3

Dinghies total capacity, as ICAO Field 19
element ‘D/’.

'-' "SPLDCOL" 1{ LIM–CHAR }50

Dinghies colour, as ICAO Field 19 element ‘D/’.

'-' "SPLDCOV" ('T' | 'F')

indication if they are covered, as

Dinghies:
ICAO Field 19 element ‘D/’.
T = True (=> ‘C’ in ICAO)
F = False, not covered.

Dinghies: number, as ICAO field 19 element
‘D/’.

spldnb

b

'-' "SPLDNB" 1{ DIGIT }2

9.10.2000

EN

Official Journal of the European Communities

L 254/127

ADEXP
Primary Field

Kind

Syntax

Semantic

sple

splj

spln

splp

splr

spls

src

ssrcode

star

starttime

stay

b

b

b

b

b

b

b

b

b

b

c

'-' "SPLE" timehhmm–elapsed

Fuel endurance, as ICAO Field 19 element ‘E/’.

'-' "SPLJ" lifejackets

Life jackets, as ICAO Feld 19 element ‘J/’.

'-' "SPLN" 1{ LIM–CHAR }

Any other survival equipment and useful
remarks, as ICAO Field 19 element ‘N/’.

'-' "SPLP" 1{DIGIT}3

'-' "SPLR" emergradio

Persons on board, as ICAO Field 19 element
‘P/’.

Emergency radio equipment, as ICAO Field 19
element ‘R/’.

'-' "SPLS" survivaleqpt

Survival equipment, as ICAO Field 19 element
‘S/’.

'-' "SRC" ("RPL" | "FPL" | "AFIL" | "MFS"
| "FNM" | "AFP" | "RQP" | "RQS" | NIL ) on the TITLE field.

Indication of the data source. Contents depend

'-' "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" point ! 1{DIGIT}1 !
0{ALPHA}1

Identification of a Standard Arrival procedure.

'-' "STARTTIME" day ! timehhmm

Time at which a period of time begins.

'-' "STAY" stayident time ((adid adid) |
(ptid ptid) (adid | ptid) | (ptid adid))
[ptspeed] [ptrfl]

stayinfo

c

'-' "STAYINFO" stayident remark

sts

b

'-' "STS" ( "PROTECTED" | flightplan-
status | 1{LIM–CHAR} )

taxitime

b

'-' "TAXITIME" timehhmm

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
aerodromes given for the length of time indi-
cated, i.e. training, mid-air re-fuelling, photo-
graphic mission etc.
NOTE: The order in which the points and/or
aerodromes are given is significant

Information concerning the type of activity
(training, photographic mission, etc.) to be
performed during a ‘stay’ period in the route of
a flight.

Reason for special handling, as ICAO field 18
STS/. Can be either ‘PROTECTED’ to indicate
sensitive handling or one of the recognised
labels, EMER, HOSP, etc. or free text.

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

tfv

b

c

'-' "TFCVOL" 1 {ALPHANUM} 15

Identification of a ‘traffic volume’.

'-' "TFCVOL" tfvid refloc flowlst flblock Description of a traffic volume.

L 254/128

EN

Official Journal of the European Communities

9.10.2000

ADEXP
Primary Field

Kind

Syntax

Semantic

title

ttleet

typz

unit

valfrom

valfromk

b

b

b

c

b

b

'-' "TITLE" titleid

Message title.

'-' "TTLEET" timehhmm–elapsed

Total estimated elapsed time in hours and
minutes.

'-' "TYPZ" text20

Type of aircraft when no ICAO code exists.

'-' "UNIT" unitid [addrinfo]

Information concerning an ‘air navigation unit’
i.e. an ATC unit, an aircraft operator or flight
plan originator. Contains the identification of
the unit and optionally address data.

'-' "VALFROM" date

First date from which the flight is scheduled to
operate (in year, month and day).

'-' "VALFROMK" ( date | datewldcrd )

valfromold

b

'-' "VALFROMOLD" date

validitydate

valuntil

valuntilk

b

b

b

'-' "VALIDITYDATE" date

Date of validity.

'-' "VALUNTIL" date

Last date from which the flight is scheduled to
operate (in year, month and day).

'-' "VALUNTILK" ( date | datewldcrd )

First date from which the flight is scheduled to
operate, used as database key in a query, may
be wildcarded.
Must be a valid date or a combination of a
valid date and wild-card characters.

The ‘previous’
‘valfrom’ date. Used as a data-
base key. Where the start of validity date is to
be amended, the new value will be given in
‘VALFROM’.

Last date from which the flight is scheduled to
operate, used as database key in a Query, may
be wildcarded.
Must be a valid date or a combination of a
valid date and wild-card characters.

The ‘previous’
‘valuntil’ date. Used as a data-
base key. Where the end of validity date is to
be amended, the new value will be given in
‘VALUNTIL’.

valuntilold

b

'-' "VALUNTILOLD" date

wktrc

b

'-' "WKTRC" waketurbcat

Wake turbulence category.

A.4. ADEXP Subfields

Subfield

Kind

Syntax

Semantic

Used in
Primary Field

Used in
Subfield

addrinfo

adid

c

b

'-' "ADDRINFO" network-
type fac

'-' "ADID" icaoaerodrome |
’ZZZZ’

Address information

unit

The designator of an aero- ad
drome. May contain the position
ICAO location indicator or
the characters ‘ZZZZ’ where
no location indicator has
been assigned.

stay

9.10.2000

EN

Official Journal of the European Communities

L 254/129

Subfield

Kind

Syntax

Semantic

Used in
Primary Field

Used in
Subfield

airroute

airspace

airspdes

brng

condition

crfl1

crfl2

crmach

crspeed

cto

distnc

efl

endreg

eto

c

c

b

b

b

b

b

b

b

b

b

b

b

b

'-' "AIRROUTE" [num]
refatsrte flblock valperiod
[remark]

Description of all or part
of an ATS route during a lcatsrte
specified period.

lacdr

'-' "AIRSPACE" [num]
airspdes flblock valperiod
respunit [remark]

Description of all or part of
an airspace during a speci-
fied period.

latsa
lrar
lrca

'-' "AIRSPDES" 3 { ALPHA-
NUM }12

Designates an airspace other entrydata
than an ATS route.

airspace

'-' "BRNG" refbearing

Bearing of a point from a ref
navigation aid in degrees
magnetic.

'-' "CONDITION" 2
{ALPHA} 20

Type of condition or restric-
tion e.g. TOS, FL restriction.

ignore

'-' "CRFL1" flightlevel

The lower limit of the flight crsclimb
level band within which a
cruise climb is requested.

ptcrsclimb

'-' "CRFL2" (flightlevel |
"PLUS")

The upper limit of the flight crsclimb
level band within which a
cruise climb is requested.
‘PLUS’ where the upper limit
is unknown.

ptcrsclimb

'-' "CRMACH" machnumber The Mach No. maintained crsclimb

ptcrsclimb

during a cruise climb.

'-' "CRSPEED" spd

The speed to be maintained crsclimb
during a cruise climb.

ptcrsclimb

'-' "CTO" timehhmm

Calculated Time Over
point.

a ad

position

pt

'-' "DISTNC" 1{ DIGIT }3

from ref

Distance of a point
a navigation aid in nautical
miles.
Must be 1 to 3 digits, poss-
ibly with leading zeroes.

'-' "EFL" flightlevel

Estimated flight level.

Reserved
for future
use.

'-' "ENDREG" day!-
timehhmm

The time at which an ATFM
Regulation finishes.

exccond
regulation

'-' "ETO" date ! timehhmm !
seconds

Estimated Time Over
point, in year, month, day, afildata
hours, minutes and seconds. estdata

a ad

pt

position

L 254/130

EN

Official Journal of the European Communities

9.10.2000

Subfield

Kind

Syntax

Semantic

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.

fac

b

'-' "FAC" 1{ LIM–CHAR }30 Address data.

Used in
Primary Field

Used in
Subfield

reglist

addrinfo
recvr
sender

addr
cassaddr
extaddr
origin
spladdr

fir

fl

b

b

'-' "FIR" 7{ ALPHA }7

Designates a FIR or UIR.

lfir

'-' " FL" flightlevel

A generic flight level field.
May be a ‘SFL’,
‘RFL’, etc. depending on its cfl
context.

ad

‘EFL’, ‘CFL’, afildata

entrydata
estdata
flband
position

flblock

c

'-' "FLBLOCK" fl fl

rrteto
rrtefrom
tfv

A flight level block defining ad
an airspace vertically, inclus-
ive of the flight levels given.
A block defined as below or
above a flight level shall be
expressed
as
from flight level 000 to the
specified level or as from the
specified level to flight level
999.

respectively

flow

c

'-' "FLOW" frompos [via1]
[via2] topos [via3] [via4]
flowrole

Description of a ‘flow’ giving
the source area, optionally
the routes or points to be
overflown from the source
area,
the destination area
and optionally the routes or
points to be overflown to
the destination area.

flowlst

flowrate

flowrole

c

b

b

'-' "BEGIN" "FLOWLST" 1
{flow} '-' "END" "FLOWLST"

List of traffic flows.

rrteto
rrtefrom
tfv

'-' "FLOWRATE"
3{LIM–CHAR}7

The ‘rate’ which is imposed
by an ATFM Regulation.

'-' "FLOWROLE" 'EX' | 'IE' |
'EM' | 'IN'

An indication of the ‘role’ of
a flow.
EX = excluded
IE = included exempted
EM = exempted
IN = included

flblock
pt

airspace
airroute
pt
regulation
exccond

flowlst

rateperiod

flow

from

b

'-' "FROM" day!timehhmm

The time from which a per-
iod of time begins.

rvrperiod

rateperiod

9.10.2000

EN

Official Journal of the European Communities

L 254/131

Subfield

Kind

Syntax

Semantic

frompos

b

'-' "FROMPOS" 1
{ALPHANUM} 15

A position from which a
route, a route portion, a
‘path’ or a flow begins.
May be a region, an aero-
drome or a significant point.

Used in
Primary Field

Used in
Subfield

flow

geoid

b

'-' "GEOID" geoname

Identifier of a geographical geo
fol-
point made of
lowed by a sequence number
(example: ‘GEO12’).

‘GEO’

ifpdlong

ifpdsum

lastnum

lattd

longtd

c

c

b

b

b

'-' "BEGIN" "IFPDLONG"
adexpmsg '-' "END"
"IFPDLONG"

Complete information con-
cerning an individual flight
plan.

ifpdlist

'-' "IFPDSUM" arcid adep
ades eobt orgn

ifpdslist

Summary information con-
cerning an individual flight
plan. It contains the arcid,
adep, ades, eobt and orgn
fields.

'-' "LASTNUM" 3{DIGIT}3

A three digit number indicat-
ing the end of a sequence.

'-' "LATTD" latitudelong !
latitudeside

'-' "LONGTD" longitudelong
! longitudeside

Latitude in degrees, minutes, eetlat
seconds
(North or South).

direction geo

and

in

Longitude
minutes, seconds and direc- geo
tion (East or West).

degrees, eetlong

networktype b

'-' "NETWORKTYPE"
2{ALPHANUM}10

Indication of the type of net- origin
work used for a message
exchange.

addrinfo

num

penrate

b

b

'-' "NUM" 3{DIGIT}3

A three digit number.

extaddr
part

airspace
airroute

'-' "PENRATE"
3{LIM–CHAR}7

The ‘pending rate’, used for
ATFM purposes.

rateperiod

postproctxt

b

'-' "POSTPROCTXT"
adexpmsg

Contains a complete ADEXP adexptxt
message after it has been
processed.

preproctxt

b

'-' "PREPROCTXT"
adexpmsg

Contains a complete ADEXP adexptxt
message prior to it being
processed i.e.
it was
received.

as

L 254/132

EN

Official Journal of the European Communities

9.10.2000

Used in
Primary Field

Used in
Subfield

rtepts

Subfield

Kind

Syntax

Semantic

pt

c

'-' "PT" ptid [(fl | flblock)]
[sfl] [eto] [to] [cto] [sto]
[ptrte] [ptstay] [ptrfl]
[ptrulchg] [(ptspeed |
ptmach)] [ptcrsclimb]

a supplementary flight

Point along a route.
=> Contains a point identifi-
cation and optionally;
- a flight level or flight level
block,
-
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,
Mach No.

flight rules, speed/

ptcrsclimb

c

'-' "PTCRSCLIMB" (crspeed |
crmach) crfl1 crfl2

of

Indication in the route of a
flight
cruiseclimb.
a
Giving the speed or mach
no. followed by the two lev-
els indicating the flight level
band to be occupied during
the climb. The second level
may be ‘PLUS’ where the
upper level is unknown.

ptfltrul

ptid

ptmach

ptmilrul

ptrfl

ptrte

b

b

b

b

b

b

'-' "PTFLTRUL" ’VFR’ | ’IFR’

An indication of the flight entrydata
rules which are applicable at
the point concerned.

'-' "PTID" point

identification, either afildata

Point
coded designator or a name cfl
given artificially
REFxx or RENxx).

(GEOxx, coordata
crsclimb
entrydata
estdata
ignore
position
ref
rename
stay

'-' "PTMACH" machnumber Mach number,

in hun- ad

pt

'-' "PTMILRUL" ’OAT’ |
’GAT’

'-' "PTRFL" flightlevel

'-' "PTRTE" 2{LIM–CHAR}

dredths of a unit, associated entrydata
to a point on the route.

An indication of the ‘mili- entrydata
tary’ flight rules which are
applicable at the point con-
cerned.

flight

Requested
associated to a point on the entrydata
route.

level, ad

The route of flight following
the point indicated. May be
the complete route to the
destination aerodrome or
simply the routing element
to the next point.

pt

pt

pt

pt

9.10.2000

EN

Official Journal of the European Communities

L 254/133

Subfield

Kind

Syntax

Semantic

Used in
Primary Field

Used in
Subfield

ptrulchg

b

'-' "PTRULCHG" rulechg |
flighttypechg | rulechg
flighttypechg

the

Indication of a change in ad
either
rules’
‘flight
(VFR/IFR) or the ‘type of
flight’
(OAT/GAT) or both
and associated to a point on
the route.

ptspeed

ptstay

b

b

'-' "PTSPEED" spd

True airspeed (in kilometres ad
per hours or knots) associ- entrydata
ated to a point on the route.

'-' "PTSTAY" stayidentifier
timehhmm

Indication within the filed ad
route of flight of a period of
‘special activity’ when the
aircraft will ‘stay’ in the area
defined for the length of time
given,
i.e. training, mid-air
re-fuelling, etc.

pt

pt

pt

rateperiod

c

'-' "RATEPERIOD" from
until flowrate penrate

time during ratepdlst

A period of
which the given flow rates
are applicable for an ATFM
Regulation.

regcond

'-' "RECVR" fac

The receiver of
enced message.

the refer- msgref
refdata

recvr

refatsrte

b

b

'-' "REFATSRTE" atsroute
point [country] point [coun-
try]

airroute

ATS route designator and
identifiers of first and last
points. The points listed may
be ICAO identifiers or arti-
ficially given GEOxx, RENxx
or REFxx points. The identif-
ier of
the country within
which the point is located
may optionally be included.
The end points must be con-
sistent with the route infor-
mation.

Identifier of a reference point
made of ‘REF’ followed by a
sequence number (example:
‘REF02’).

ref

refid

b

'-' "REFID" refname

refloc

regcond

regdesc

regid

b

c

b

b

'-' "REFLOC"
1{LIM–CHAR}15

Reference location of an rrteto
ATFM Regulation.

rrtefrom
tfv

exccond
regulation

'-' "BEGIN" "REGCOND"
{rateperiod} '-' "END"
"REGCOND"

List of time periods and their
respective flow rates for a
particular regulation.

'-' "REGDESC"
1{LIM–CHAR}

'-' "REGID" regulid

Description of an ATFM
Regulation.

Identification of a flow man-
agement ‘Regulation’.

regulation

regulation

regulation

L 254/134

EN

Official Journal of the European Communities

9.10.2000

Subfield

Kind

Syntax

Semantic

Used in
Primary Field

Used in
Subfield

reglist

regnum

c

b

'-' "BEGIN" "REGLIST" regu-
lation [exccond] '-' "END"
"REGLIST"

List of ‘Regulations’ for flow fmplist
management purposes.

'-' "REGNUM" 3{DIGIT}3 !
"/" ! 2{DIGIT}2

A reference number for an
ATFM ‘Regulation’. Provides
a unique reference followed
by a validity indication.

regreason

b

'-' "REGREASON" 4
{ALPHA} 12

The reason for an ATFM
Regulation.

regulation

c

'-' "REGULATION" regnum A ‘Regulation’ imposed for
regid regdesc refloc startreg
flow management purposes.
endreg [flblock] [remark]
[tfvid] [regreason]
[regcond]

exccond
regulation

exccond
regulation

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

rfpdlong

b

c

rfpdsum

c

'-' "RESPUNIT"
12{ALPHA}12

The responsible ATC Unit.

airspace

'-' "BEGIN" "RFPDLONG"
{adexpmsg} '-' "END"
"RFPDLONG"

Complete information con-
cerning a repetitive flight
plan.

rfpdlist

Summary of the information rfpdslist

'-' "RFPDSUM" arcid adep
ades eobt orgn days valfrom concerning a repetitive flight
plan. It contains the arcid,
valuntil
adep, ades, eobt, orgn, days,
valfrom and valuntil fields.

rvrlimit

b

'-' "RVRLIMIT" 3{DIGIT}3

rvrperiod

exccond

Runway
Range:
Visual
operating minima when spe-
con-
cial meteorological
ditions exist. Expressed in
meters.

sender

seqnum

b

b

'-' "SENDER" fac

The sender of the referenced msgref
refdata
message.

'-' "SEQNUM" 3{DIGIT}3

The serial number of
message being sent (a 3 digit
number unique to the sender/
receiver combination).

the msgref
refdata

9.10.2000

EN

Official Journal of the European Communities

L 254/135

Subfield

Kind

Syntax

Semantic

Used in
Primary Field

Used in
Subfield

sfl

b

'-' SFL flightlevel ! (’A’|’B’)

pt

Supplementary flight level. coordata
The flight level at or above estdata
which or, at or below which propfl
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).

startreg

b

'-' "STARTREG"
day!timehhmm

The time at which an ATFM
Regulation becomes effec-
tive.

exccond
regulation

statid

b

'-' "STATID" coorstatusident The indicator of the co-ordi- cstat

nation state of a flight.

statreason

b

'-' "STATREASON" coorsta-
tusreason

The reason for a change in cstat
the co-ordination status of a
flight.

stayident

b

'-' "STAYIDENT" stayidenti-
fier

Identification of a period of
‘special activity’ or a ‘stay’
within the route of a flight.

stay
stayinfo

sto

b

'-' "STO" timehhmm !
seconds

tfl

b

'-' "TFL" flightlevel

pt

A generic time field which ad
may contain the time for a coordata
point or for an aerodrome. position
The time may be an esti-
mated, calculated or actual
time depending upon its
context.

Transfer Flight Level. The coordata
flight level at which a flight propfl
has been or will be co-ordi-
nated to cross one point
(flight level number),
if in
level flight, or the cleared
level to which it is proceed-
ing if climbing or descending
at the boundary point.

tfvid

b

'-' "TFVID"
1{ALPHANUM}15

Identification of a ‘traffic rrteto
volume’.

rrtefrom
tfv

regulation

time

b

'-' "TIME" timehhmm

A time indication. May be stay
an actual time or a period of
time, depending upon the
message context.

L 254/136

EN

Official Journal of the European Communities

9.10.2000

Subfield

Kind

Syntax

Semantic

Used in
Primary Field

Used in
Subfield

to

b

'-' "TO" timehhmm

‘Time Over/Off’. A generic position
time field which may con- coordata
tain the time for a point or
for an aerodrome. The time
may be an estimated, calcu-
lated
time
depending upon its context.

actual

or

'-' "TOPOS" 1 {ALPHANUM} A position to which a route,
a route portion, a ‘path’ or a
15
flow extends.
May be a region, an aero-
drome or a significant point.

'-' "UNITID" 2{
ALPHANUM}10

Identification of an air navi- unit
gation unit i.e. an ATC unit,
aircraft operator or
flight
plan originator.

'-' "UNTIL" day!timehhmm The time at which a period rvrperiod

rateperiod

of time ends.

'-' "VALPERIOD"
fulldatetime fulldatetime

A validity period, inclusive
of the times given.

topos

unitid

until

valperiod

via1

via2

b

b

b

b

b

b

'-' "VIA1" 1 {ALPHANUM}
15

'-' "VIA2" 1 {ALPHANUM}
15

via3

b

'-' "VIA3" 1 {ALPHANUM}
15

via4

b

'-' "VIA4" 1 {ALPHANUM}
15

pt

flow

airroute
airspace

flow

flow

flow

flow

A 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 con-
tain the first in the sequence.

A 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 con-
tain the
second in the
sequence.

A 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 con-
tain
the
third
the
sequence.

in

A 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 con-
tain the
fourth in the
sequence.

9.10.2000

EN

Official Journal of the European Communities

L 254/137

ANNEX B (Normative)

CENTRAL INDEX OF ADEXP MESSAGE TITLES

Title

Definition

Introduced in Section

ABI

ACK

ACP

ACT

AUP

BFD

CDN

CFD

Advance Boundary Information Message

Acknowledge Message

Acceptance Message

Activation Message

Airspace Use Plan Message

Basic Flight Data Message

Co-ordination Message

Change to Flight Data Message

CNLCOND

ATFM Exceptional Condition Cancellation Message

CNLREG

ATFM Regulation Cancellation Message

COD

COF

CRAM

DES

ERR

SSR Code Assignment Message

Change of Frequency Message

Conditional Route Availability Message

De-Suspension Message

Error Message

EXCOND

ATFM Exceptional Condition Notification Message

FCM

FLS

FSA

HOP

IACH

IAFP

IAPL

IARR

ICHG

ICNL

IDEP

IDLA

IFPL

INF

IRPL

IRQS

Flight Confirmation Message

Flight Suspension Message

First System Activation Message

Hand-Over Proposal Message

Individual ATC Modification Message

Individual ATC Flight Plan Proposal Message

Individual ATC Flight Plan Message

Individual Arrival Message

Individual Modification Message

Individual Cancellation Message

Individual Departure Message

Individual Delay Message

Individual Flight Plan Message

Information Message

Individual Repetitive Flight Plan

Individual Request Supplementary Flight Plan

E.3

E.1

E.5

E.3

E.4

E.5

E.3

E.5

E.2.3

E.2.3

E.3

E.3

E.4

E.2.2

E.2.2

E.2.3

E.2.2

E.2.2

E.2.3

E.3

E.1

E.1

E.1

E.1

E.1

E.1

E.1

E.1

E.1

E.3

E.1

E.1

L 254/138

EN

Official Journal of the European Communities

9.10.2000

Title

Definition

Introduced in Section

ISPL

LAM

LRM

MAC

MAN

MAS

Individual Supplementary Flight Plan

Logical Acknowledgement Message

Logical Rejection Message

Message for Abrogation of Co-ordination

Manual Processing Pending Message

Manual Assumption of Communications Message

MODCOND

ATFM Exceptional Condition Modification Message

MODREG

MRA

MRCNL

MRMOD

NEWREG

NTA

NTACNL

NTAMOD

OLRA

OLRCNL

OLRMOD

PAC

RAP

RCHG

RCNL

RDY

REJ

REV

RJC

RJT

ROF

RRP

RRV

SAM

SBY

SDM

SIP

SLC

SMM

SPA

SRJ

ATFM Regulation Modification Message

Mandatory Route Activation Message

Mandatory Route Cancellation Message

Mandatory Route Modification Message

New ATFM Regulation Notification Message

No Traffic Accepted Message

No Traffic Accepted Cancellation Message

No Traffic Accepted Modification Message

Off-Load Route Activation Message

Off-Load Route Cancellation Message

Off-Load Route Modification Message

Preliminary Activation Message

Referred Activate Proposal Message

Repetitive Flight Plan Data Modification Message

Repetitive Flight Plan Data Cancellation Message

Ready Message

Rejection Message

Revision Message

Reject Co-ordination Message

Re-Routing Rejection Message

Request On Frequency Message

Re-Routing Proposal Message

Referred Revision Proposal Message

Slot Allocation Message

Stand-by Message

Supplementary Data Message

Slot Improvement Proposal Message

Slot Requirement Cancellation Message

Slot Missed Message

Slot Proposal Acceptance Message

Slot Proposal Rejection Message

E.1

E.3, E.5

E.3

E.3

E.1

E.3

E.2.3

E.2.3

E.2.3

E.2.3

E.2.3

E.2.3

E.2.3

E.2.3

E.2.3

E.2.3

E.2.3

E.2.3

E.3

E.3

E.1

E.1

E.2.2

E.1

E.3

E.5

E.2.2

E.3

E.2.2

E.3

E.2.2

E.3

E.3

E.2.2

E.2.2

E.2.2

E.2.2

E.2.2

9.10.2000

EN

Official Journal of the European Communities

L 254/139

Title

Definition

Introduced in Section

SRM

SRR

TIM

UUP

XAP

XCM

XIN

XRQ

Slot Revision Message

Slot Revision Request Message

Transfer Initiation Message

Updated Airspace Use Plan Message

Crossing Alternate Proposal Message

Crossing Cancellation Message

Crossing Intention Notification Message

Crossing Request Message

E.2.2

E.2.2

E.3

E.4

E.5

E.5

E.5

E.5

L 254/140

EN

Official Journal of the European Communities

9.10.2000

ANNEX C (Normative)

CENTRAL INDEX OF RESERVED MESSAGE TITLES

C.1.

Introduction

This annex contains a central index of reserved message titles which have not yet been defined for use in
ADEXP. Their inclusion in this annex indicates that they have either been foreseen for future use or that they
are already in use but their usage is limited to within local systems.

C.2.

Purpose

The purpose of providing a listing of titles which have not yet been formally adopted for use within this
ADEXP Standard is to prevent, in so far as possible, either the creation of redundancy whenever a new title is
required for a particular purpose or the creation of a title which is already in use within a local system.

C.3. Reserved Message Titles

Reserved Title

Message Type

Reserved by

ACTARR

ACTDEP

ADMFPL

ADMFPT

Activation Message for an Arrival

Activation Message for a Departure

ADMAR2000 Flight Plan Message

ADMAR2000 Flight Plan Termination Message

ADMFPU

ADMAR2000 Flight Plan Update Message

ANM

ATFM Notification Message

ANSWERCT

Response Message (Terminal Control System)

ANSWM

Response Message (ODS)

ANSXFPLCT

Response Message

ATT

Landing Message

BEGINPROC

Begin Processing Message

BEGPROC

Controller Working Position Initialisation Procedure Message
(ODS)

FRANCE

FRANCE

GERMANY

GERMANY

GERMANY

CFMU

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

BEGPROCCT

Controller Working Position Initialisation Message (Terminal
Control System)

FRANCE

CDA

CDAFTX

CHGDEP

CLD

CLDFTX

CNLARR

Departure Cleanance Message (ARINC 623)

Departure Clearance (ARINC 620)

Modification message for a Departure flight

Departure Clearance (ARINC 623)

Departure Clearance (ARINC620)

Cancellation of an Arrival

CNLCOND

Cancellation of Exceptional Condition

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

CFMU

9.10.2000

EN

Official Journal of the European Communities

L 254/141

Reserved Title

Message Type

Reserved by

CNLDEP

CNLREG

Cancellation of a Departure

Cancellation of an ATFM Regulation

CONFEND

End Message to a change of Operational Configuration

CONFIDM

Operational Configuration Message (ODS)

FRANCE

CFMU

FRANCE

FRANCE

CONFIDMCT

Operational Configuration Message (Terminal Control System)

FRANCE

DEC

Take-Off Message

DOUBM

Duplication Flight Plan Message

DRT

Modification of Destination Message

EATARR

Update of Estimated Arrival Time Message

ENDPROC

Controller Working Position Initialisation Procedure Last Message
(ODS)

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

ENDPROCCT

Controller Working Position Initialisation Procedure Last Message
(Terminal Control System)

FRANCE

EVLARR

EVLDEP

Pre-Activation Message for Arrival

Pre-Activation Message for Departure

EXCOND

Activation of an Exceptional Condition

FICM

FLXVIVO

FPCLOSE

Flight Data Creation Message

‘Flexible Track’ Description Display Message

Flight Plan Data Close Message (ODS)

FPCLOSECT

Flight Plan Data Close Message (Terminal Control System)

FPCLOSED

Duplication of Flight Plan Data Close Message (ODS)

FPCRD

Activation of Flight Plan Message (ODS)

FRANCE

FRANCE

CFMU

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

FPCRDCT

Activation of Flight Plan Message (Terminal Control System)

FRANCE

FPCRDD

FPCRE

Duplication of Flight Plan Data Activation Message (ODS)

Creation of Flight Plan Message (ODS)

FRANCE

FRANCE

FPCRECT

Creation of Flight Plan Message (Terminal Control System)

FRANCE

FPINI

FPINICT

FPINID

FPNTF

FPNTFD

FPRDU

Pre-Activation of Flight Plan Message (ODS)

FRANCE

Pre-Activation of Flight Plan Message (Terminal Control System)

FRANCE

Duplication of Pre-Activation of Flight Plan Message

Pre-Activation of Flight Plan Message (ODS)

FRANCE

FRANCE

Duplication of Pre-Activation of Flight Plan Message (ODS)

FRANCE

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)

FSMFTX

Departure Clearance System Message (ARINC 620)

FRANCE

FRANCE

L 254/142

EN

Official Journal of the European Communities

9.10.2000

Reserved Title

Message Type

Reserved by

FSR

IACHD

ICHGD

IDEPD

IDLAD

IFPDQ

IFPDQR

IFPDSQ

Flight Suspension Request Message

Individual ATC Modification Message

Individual Modification Message

Individual Departure Message

Individual Delay Message

Individual Flight Plan Data Query Message

Individual Flight Plan Data Query Reply Message

Individual Flight Plan Data Summary Query Message

IFPDSQR

Individual Flight Plan Data Summary Query Reply Message

IFPLD

INFOM

IRQS

ISPL

LGR

LISTFP

LISTFPCT

LOGON

Individual Flight Plan

Information Message

Individual Request for Supplementary Information Message

Individual Supplementary Flight Plan Message

Flight Plan Message List

Flight Plan Message List (ODS)

Flight Plan Message List (Terminal Control System)

Identification of Flight Plan Message

MAJVIVO

Daily Movements Message

MCOM

Co-ordination Message

MODCOND

Modification of an Exceptional Condition

MODREG

Modification of an ATFM Regulation

MRA

MRCNL

MRMOD

MRR

Activation of a Mandatory Route

Cancellation of a Mandatory Route

Modification of a Mandatory Route

Mandatory Re-Routing Message

MVTVIVO

Movements Information Message

NEWREG

Activation of an ATFM Regulation

NTA

Activation of a ‘Not Allowed’ Traffic Flow

NTACNL

Cancellation of a ‘Not Allowed’ Traffic Flow

NTAMOD

Modification of a ‘Not Allowed’ Traffic Flow

OCLM

OCLMD

OLRA

Oceanic Clearance Message

Duplication of Oceanic Clearance Message

Activation of an Off-Load Route

OLRCNL

Cancellation of an Off-Load Route

OLRMOD

Modification of an Off-Load Route

PAMAER

Runway Application Message

CFMU

GERMANY

GERMANY

GERMANY

GERMANY

CFMU

CFMU

CFMU

CFMU

GERMANY

FRANCE

CFMU

CFMU

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

CFMU

CFMU

CFMU

CFMU

CFMU

CFMU

FRANCE

CFMU

CFMU

CFMU

CFMU

FRANCE

FRANCE

CFMU

CFMU

CFMU

FRANCE

9.10.2000

EN

Official Journal of the European Communities

L 254/143

Reserved Title

Message Type

Reserved by

PAMARB

’On-Stand ’Confirmation Message

PAMARRANN

Cancellation of Parking Allocation for an Arrival

PAMARRCRE

Allocation of Parking Position for an Arrival

PAMARRPST

Modification of Parking Allocation for an Arrival

PAMDAPARB

Parking Message for Arrival Aircraft

PAMDAPCRE

Allocation of a Parking Position

PAMDEPANN

Cancellation of Parking Allocation for a Departure

PAMDEPCRE

Parking Allocation for a Departure

PAMDEPPST

Modification of Parking Allocation for a Departure

PAMDRB

QTAARR

QTADEP

RCD

RCDFTX

REVARR

RFPDQ

RFPDQR

RFPDSQ

’Off-Stand’ Confirmation Message

Return to Original ‘Created’ Status for an Arrival

Return to Original ‘Created’ Status for a Departure

Request Departure Clearance Message (AIRINC 623)

Request Departure Clearance Message (AIRINC 620)

Revision Message for an Arrival

Repetitive Flight Plan Data Query Message

Repetitive Flight Plan Data Query Reply Message

Repetitive Flight Plan Data Summary Query Message

RFPDSQR

Repetitive Flight Plan Data Summary Query Reply Message

RIEM

RMG

RRA

RREC

RRN

RSUS

Flight Data Information Message

Missed Approach Message

Re-Routing Acceptance Message

Repetitive Flight Plan Recovery Message

Re-Routing Notification Message

Repetitive Flight Plan Suspension Message

RWYCHGCT

Runway Configuration Message

TRACT

Request for Flight Plan Activation (ODS)

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

CFMU

CFMU

CFMU

CFMU

FRANCE

FRANCE

CFMU

CFMU

CFMU

CFMU

FRANCE

FRANCE

TRACTCT

Request for Flight Plan Activation (Terminal Control System)

FRANCE

TRCNL

Request for Flight Plan Cancellation (ODS)

FRANCE

TRCNLCT

Request for Flight Plan Cancellation (Terminal Control System)

FRANCE

TRCOR

Request for Manual Correlation

TRDECOR

Request for Manual De-Correlation

TRFIC

TRFICCT

Request for Creation of Flight Plan Data (ODS)

Request for Creation of Flight Plan Data (Terminal Control
System)

TRFLRQT

Request Flight Level Message

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

L 254/144

EN

Official Journal of the European Communities

9.10.2000

Reserved Title

Message Type

Reserved by

TRMOD

Request for Flight Plan Modification (ODS)

FRANCE

TRMODCT

Request for Flight Plan Modification (Terminal Control System)

FRANCE

TRMODH

Request for Time Modification

TRMODHD

Request for Time Modification for Delayed Flight

Co-ordination Request for Exiting Flight (ODS)

Co-ordination Request for Exiting Flight (Terminal Control Sys-
tem)

Specific Flight Data Request Message

Request for Revision of Flight Plan to ‘Created’ Status (ODS)

Request for Revision of Flight Plan to ‘Created’ Status (Terminal
Control System)

Request for Display of Flight Data Information (ODS)

Request for Display of Flight Data Information (Terminal Control
System)

Flight Plan Request (ODS)

Flight Plan Request (Terminal Control System)

Request for SHOOT Action

Controller Working Position Initialisation Request (ODS)

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

FRANCE

Controller Working Position Initialisation Request
Control System)

(Terminal

FRANCE

Transfer Position Message

Suppression of Flight Plan Message (ODS)

FRANCE

FRANCE

UNKFPCT

Suppression of Flight Plan Message (Terminal Control System)

FRANCE

TRMVT

TRMVTCT

TRPOINT

TRRET

TRRETCT

TRRIP

TRRIPCT

TRRQT

TRRQTCT

TRSHRQT

TRSTAR

TRSTARCT

TRTRP

UNKFP

9.10.2000

EN

Official Journal of the European Communities

L 254/145

ANNEX D (Normative)

CENTRAL INDEX OF RESERVED FIELDS

D.1.

Introduction

This annex contains a central index of reserved fields, Primary, Subfield and Auxiliary Terms, which have not
yet been defined for use in ADEXP. Their inclusion in this annex indicates that they have either been foreseen
for future use or that they are already in use but their usage is limited to within local systems.

D.2.

Purpose

The purpose of providing a listing of fields which have not yet been formally adopted for use within this
ADEXP Standard is to prevent, in so far as possible, either the creation of redundancy whenever a new field is
required for a particular purpose or the creation of a keyword which is already in use within a local system.

D.3. Reserved Auxiliary Terms

Reserved
Auxiliary Term

Syntax

Semantic

Used in
Primary Field

Used in
Subfield

Used in
auxilary

centreidentifica- 1{ALPHA}4
tion

Centre identification.

ctdest

ctsrc
ripsrc
ctripe

contextfdpsid

'opepal' | 'opesos' | 'evalpal' Mode of operation of ctxtfdps
| 'tstopepal' |'tstopesos'

an FDPS application.
(Operational,
etc.)

Test,

contextphidiasid 'ope'|'eval1'|'EVAL2'

|('TST'!1{DIGIT}1)

Specific to the French ctxtpos
system

coordpoints

('E'!('S'!('X'!('O'|NIL)
|NIL)|NIL)
|'S'!('X'!('O'|NIL)|NIL)
|'X'!('O'|NIL)|NIL)
|'O'

the

the

for

Entry point
control position (‘E’).
Exit point
control position (‘S’),
XFL point (X),
OCL point (O)

for

coorpt

eoidentification 1{ALPHANUM}6

Identification of
‘operational entity’

an eosrc

eoid

fl3

'F' ! 3{DIGIT}3

flighttendancy

'U'|'D'|'S'

Flightlevel
in hundred of feet.

expressed autfl1
autfl2
curfl

Projected tendency of etrfl
the flight profile.
trfl
U for UP
D for Down
S for Stable

L 254/146

EN

Official Journal of the European Communities

9.10.2000

Reserved
Auxiliary Term

fpcentrestate

Syntax

Semantic

Used in
Primary Field

Used in
Subfield

Used in
auxilary

'CREE'|'EVEIL'|
'EVLCRT'|'ACTIVE'|
'TERM'

Flight
within an ACC.

plan

status

fpctst

latitude

4{ DIGIT }4

latitudeshort

2{ DIGIT }2

longitude

5{ DIGIT }5

longitudeshort

3{ DIGIT }3

A latitude expressed as Reserved
future use
four digits

A latitude expressed as Reserved
future use
two digits.

A longitude expressed Reserved
future use
as five digits.

A longitude expressed Reserved
future use
as three digits.

for

for

for

for

pointcautra

1{ALPHANUM}5

Specific to the French firstpid
system

positionidentif-
ication

1{ALPHANUM}6

Working
actual or logical

position

pointid
ptcid
ptid

posid

qfuid

('0'|'1'|'2'|'3')!1{ DIGIT }
1!('L'|'C'|'R'|NIL)

qfu

qful

QFU for a runway.
L = Left
C = Centre
R = Right

secidentification 1{ALPHANUM}2

Sector identification.

secdest
secsrc

secid

sendingreason

'INI'|'NTF'|'ACT'|
'MOD'|'MVT'|
'MVTSEC'|'COORAUTO'|
'MODHD'|
'CNL'|'RADAR'|'INIT'|
'RQT'|'TRF'|'RIP'|
'CONF'|'END'|'QTA'|
'ESLSA'|'OCM'|
'DMER'|'TRFSEC'|
'COLLAT'|'SHRQT'|
'POINT'|'FLRQT'|
'PKG'

starreason

'TOTAL'

temperature

("N" | "P") ! 2{DIGIT}2

updatereason

('T'!('R'|NIL)|'R')

Reason for
flight plan data.

sending event

The type of initialisa-
tion of a position with
flight plan data

streason

temp

Temperature
expressed in degrees
Celsius (00-99) with
the indication of the
sign (Negative or Posi-
tive)

Type of update last
made to a flight data.-
Operator Transaction
update
(‘T’). Radar
(‘R’).

udpt

9.10.2000

EN

Official Journal of the European Communities

L 254/147

D.4. Reserved Primary Fields

Reserved
Primary Field

Kind

Syntax

Semantic

aabd

aabt

acnf

aobd

aobt

apptyp

arcidao

arcidatc

atis

autfl1

autfl2

automsg

avail

bkrow

bkt

codetr

confid

confl

crspd

ctripe

ctrow

b

b

c

b

b

b

b

b

b

b

b

c

b

b

b

b

b

c

b

b

b

'-' "AABD" date

Actual arrival on-block date

'-' "AABT" timehhmm

Actual arrival on-block time

'-' "ACNF" ad rcnf [qfulist]

Runway configuration

'-' "AOBD" date

Actual off-block date

'-' "AOBT" timehhmm

Actual off-block time

'-' "APPTYP" 1{ALPHANUM}1

'-' "ARCIDAO" 1{ALPHANUM}11

'-' "ARCIDATC" 8{DIGIT}8

'-' "ATIS" 1{ALPHA}1

'-' "AUTFL1" fl3

'-' "AUTFL2" fl3

'-' "AUTOMSG" (sendt ptcid flb pflt)|'NO'

'-' "AVAIL" 'YES'|'NO'

'-' "BKROW" 1{DIGIT}2

'-' "BKT" datetime

'-' "CODETR" 'YES'|'NO'

'-' "CONFID" 1{DIGIT}5

'-' "BEGIN" "CONFL"
1{eopos}
'-' "END" "CONFL"

Approach type of the flight (1 digit,
values: 1, 2, 3)

Aircraft identification used by aircraft
operators

Locally unique aircraft identification
number used by ATC

Automatic Terminal
Service indicator.

Information

Authorised flight level 1

Authorised flight level 2

in

Provides the data which is to be
transmitted
co-ordination
a
message: sending time, exit point,
flight level over exit point, planed
flight level and information concern-
ing whether the level is in accordance
with agreements.

Indication as to whether a sector is
permitted or not to modify a flight
plan data.

The position of a point of reference
in a list of route points.

Time over the reference point for a
transaction.

ssrcode
Indication whether
should be transmitted (or not) to the
pilot by the control position

the

Operational configuration identifi-
cation (sectors|positions).

List of sectors/positions associations
for an en-route centre.

'-' "CRSPD" 1{DIGIT}4

Cruise speed in knots

'-' "CTRIPE" centreidentification

'-' "CTROW" 1{DIGIT}1

Name of the receiving centre for a
transaction

The position of a centre in a list of
centres.

L 254/148

EN

Official Journal of the European Communities

9.10.2000

Reserved
Primary Field

Kind

Syntax

Semantic

ctsrc

ctxtct

ctxtfdps

ctxtpos

curfl

curpos

curpost

curptt

curptx

dcatcid

dcbtxt

dcbtxtftx

dccar

dcid

dcmtyp

dcref

dcrmk

dcs1txt

dcs2txt

dcdt

delcode

dfdpsid

doubid

ecurptt

b

b

b

b

b

c

b

b

b

b

b

b

b

b

b

b

b

b

b

b

b

b

b

b

'-' "CTSRC" centreidentification

Identification of sending centre

'-' "CTXTCT" 'OPE' | 'TST'

Mode of operation of Terminal Con-
trol System.

'-' "CTXTFDPS" contextfdpsid

Mode of operation of an FPDS

'-' "CTXTPOS" contextphidiasid

Mode of operation for ODS

'-' "CURFL" fl3

Current flight level

'-' "CURPOS" ptid | (lattd longtd)

Current position

'-' "CURPOST" datetime

Date and time at current position

'-' "CURPTT" datetime

'-' "CURPTX" 1{DIGIT}2

'-' "DCATCID" icaoaerodrome

Date and time of overflight of current
point

Numbered position of current point
in a list of route points.

Aerodrome responsible for departure
clearance when given by FDPS to the
aircraft via datalink.

'-' "DCBTXT" 'PDC REQUEST
RECEIVED'|'PDC REQUEST UNKNOWN' |
'PDC REQUEST IGNORED' | 'ACK'

Basic text for ARINC 623 departure
clearance messages.
for
acknowledgement message.

‘ACK’

'-' "DCBTXTFTX" 'PDC REQUEST
RECEIVED'|'PDC REQUEST UNKNOWN' |
'PDC REQUEST IGNORED' | 'ACK'

Basic text for ARINC 620 departure
clearance messages.
for
acknowledgement message.

‘ACK’

'-' "DCCAR" 'DMER'|'COLLAT'|'NO'

'-' "DCID" 1{DIGIT}3

Departure clearance status
flight.

for a

System number for departure clear-
ance.

'-' "DCMTYP" 1{ALPHA}3

Departure clearance message type.

'-' "DCREF" 1{ALPHANUM}5

Context reference for a departure
clearance.

'-' "DCRMK" 1{LIM–CHAR}80

Remark for a departure clearance.

'-' "DCS1TXT"
'REQUEST BEING PROCESSED' | 'REQUEST
ALREADY RECEIVED' | 'FLIGHT PLAN NOT
HELD' | 'ERROR IN MESSAGE'.

Supplementary text for the Departure
Clearance System Message (ARINC
623).

'-' "DCS2TXT" 'STANDBY'| 'REVERT TO
VOICE PROCEDURE'

'-' "DCDT" datetime ! seconds

Second Supplementary text for the
Departure
message
Clearance
(ARINC 623).

Day, hours, minutes, seconds for the
departure clearance.

'-' "DELCODE" 1{ALPHANUM}20

Reason for a delay

'-' "DFDPSID datetime ! seconds

Data of Flight Data Processing System
Identification

'-' "DOUBID" 1{ALPHANUM}2

Identification of a ‘duplicate’ entity.

'-' "ECURPTT" datetime

Estimated time of overflight of cur-
rent point

9.10.2000

EN

Official Journal of the European Communities

L 254/149

Reserved
Primary Field

Kind

Syntax

Semantic

eda

elastptt

endhldt

entrnb

entryt

enxtptt

eobdt

eosrc

espfl

eta

etrfl

event

firstpid

flbk

fpbaseid

fpctst

fpkwl

fplcat

fplist

fpllist

fplnb

fplstat

b

b

b

b

b

b

b

b

b

b

b

b

b

b

b

b

c

b

c

c

b

b

'-' "EDA" date

Estimated date of arrival

'-' "ELASTPTT" datetime

Estimated time of overflight of last
point of the route

'-' "ENDHLDT" datetime

Holding pattern ending time.

'-' "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" datetime

Entry time for the position.

'-' "ENXTPTT" datetime

Estimated time of overflight of next
point (not given if current point is
the last point).

'-' "EOBDT" datetime

Date and estimated off-block time.

'-' "EOSRC" eoidentification

Operational ‘entity’ identification

'-' "ESPFL" flightlevel

Supplementary transfer flight level
for the preceding control position.

'-' "ETA" timehhmm

Estimated time of arrival.

'-' "ETRFL" flightlevel|flighttendancy

Entry Flight Level or flight profile
tendency.

'-' "EVENT" sendingreason

Triggering event for FDPS.

'-' "FIRSTPID" pointcautra

Specific to the French system

'-' "FLBK" flightlevel

Flight level of the last transaction
reference point for an activated flight,
or modified level for reference point
for a transaction.

'-' "FPBASEID" datetime!seconds

Flight Plan Data Base Identification

'-' "FPCTST" fpcentrestate

Flight Plan Status within a Centre.

'-' "BEGIN" "FPKWL" 1{fpident}300 '-' "END"
"FPKWL"

List of the known but not yet trans-
ferred flight plans for a position.

'-' "FPLCAT" "T" | "E" | "S" | "I"

Flight category:
T = overflight
E = inbound
S = outbound
I = internal.

'-' "BEGIN" "FPLIST" 1{fpsum}50
'-' "END" "FPLIST"

List of Flight plan information for a
callsign.

'-' BEGIN "FPLLIST" fpllgr
'-' "END"

'-' "FPLNB" 1{DIGIT}1

'-' "FPLSTAT" "T" | "C"

List of flight plans fields

Number of flight plans
from 0 to 5

Flight status:
T = terminated
C = active.

L 254/150

EN

Official Journal of the European Communities

9.10.2000

Reserved
Primary Field

Kind

Syntax

Semantic

fprmk

fpsrc

fpunkl

freetxt

ftxid

ftxname

ftxnum

grspd

hldbkrw

icing

indstip

initid

interid

lalglist

lang

lastradt

lights

maint

modea

modec

msgbody

msgct

nat

b

b

c

c

b

b

b

b

b

b

b

b

b

c

b

b

b

b

b

b

b

b

b

'-' "FPRMK" 1{LIM–CHAR}8

Initial flight plan remarks.

'-' "FPSRC"
("FICTOT"|"FICEVL"|"FICMOD"|FICABI"|
"FICACT""|FICPAC"|'FPL"|"RPL"|"NKW")

Flight Plan source.

'-' "BEGIN" "FPUNKL" 1{fpident}300 '-' "END" List of ‘unknown’ flight plans.
"FPUNKL"

'-' "BEGIN" "FREETXT" 1{txt}3 '-' "FREETXT"

Free text message.

'-' "FLXID" 1{ALPHANUM}14

Flex-track identity.

'-' "FLXNAME" 1{ALPHANUM}4

Flex-track name.

'-' "FLXNUM" 1{DIGIT}2

Flex-track generation number.

'-' "GRSPD" 1{DIGIT}4

Ground speed in knots.

-' "HLDBKRW" 1{DIGIT}2

'-' "ICING" 1{ALPHA}8

Number position of a reference point
for an holding pattern in a list of
route points.

Icing.
‘TRACE’ or ‘LIGHT’ or ‘MODERATE’
or ‘SEVERE’.

'-' "INDSTIP" 'STIP'

Specific to the French system

'-' "INITID" 1{DIGIT}1

Initialisation number.

'-' "INTERID" 'V'!2{DIGIT}2!'R'!2{DIGIT}2

FDPS/ODS or FDPS/Terminal system
interface identifier.

'-' BEGIN "LALGLIST" lalg
'-' END "LALGLIST"

List of
points in the route.

latitude and longitude of

'-' "LANG" '?'

'-' "LASTRADT" datetime

Conversational language indicator.
‘?’ = the language is not usual in the
company

Last update time given by radar infor-
mation.

'-' "LIGHTS" 1{ALPHANUM}1

Lights code.

'-' "MAINT" 'YES'|'NO'

Indication whether the data infor-
mation for a control position is con-
tinually maintained or not.

'-' "MODEA" 'A'!4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'}4

SSR Mode A .information

'-' "MODEC" flightlevel

SSR Mode C information

'-' "MSGBODY" 1{CHARACTER}

'-' "MSGCT" datetime ! seconds

'-' "NAT" 1{ALPHA}1

Contains a character string which is
identical to the body of the equivalent
and existing non-ADEXP message.

Time stamp of the message in the
format: Day, hours, minutes, seconds.

Identification of a North Atlantic
track .

9.10.2000

EN

Official Journal of the European Communities

L 254/151

Reserved
Primary Field

Kind

Syntax

Semantic

nfc

nxtfir

nxtpos

nxtpost

oclfl

oprfl

oprmk

oprmkct

oriented

pfl

pistcoord

pistid

pkarr

pkdep

plnid

plnold

posst

ptnb

qfu

quebec

radioid

reqid

reqtyp

ripel

b

b

c

b

b

b

c

b

b

b

c

b

c

b

b

b

b

b

b

b

b

b

b

c

'-' "NFC" 3{DIGIT}3 ! '.' ! 3{DIGIT}3

Next frequency contact.

'-' "NXTFIR" icaoaerodrome

Next FIR to be contacted

'-' "NXTPOS" ptid | (lattd longtd)

Next position.

'-' "NXTPOST" datetime

Time over the next position.

'-' "OCLFL" flightlevel

'-' "OPRFL" flightlevel

Oceanic Clearance Limit (OCL) flight
level.

Request Flight Level modified by an
operator.

'-' "BEGIN" "OPRMK" 1{rmktxt}2 '-' "END"
"OPRMK"

List of Operator remarks.

'-' "OPRMKCT" 1{LIM–CHAR}20

Operator remarks.

'-' "ORIENTED" 'YES'|'NO'

Oriented flight or not.

'-' "PFL" flightlevel

Planned Flight Level (PFL).

'-' "PISTCOORD" xpist ypist vxpist vypist

Radar track coordinates and speed
vector coordinates.

'-' "PISTID" 1{DIGIT}4

Radar track identification.

'-' "PKARR" [pka] [pkc] pkatt

Parking position for an arriving flight

'-' "PKDEP" 1{ALPHANUM}3

Parking position for a departing
flight.

'-' "PLNID" 4{DIGIT}4

Flight Plan identification

'-' "PLNOLD" 4{DIGIT}4

Old Fight Plan identification

'-' "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 Pro-
posed Movement for the Exit (MPS)
or Proposed Movement Exit Alarm
(MPSA) or position not yet move-
ment co-ordinated (NO).

'-' "PTNB" 1{DIGIT}2

Number of points in the route.

'-' "QFU" qfuid

Runway in use (QFU) identification.

'-' "QUEBEC" 'YES'|'NO'

Quebec flight or not.

'-' "RADIOID" 1{ALPHANUM}20

Radio identification.

'-' "REQID" 1{DIGIT}5

Number of a request.

'-' "REQTYP" ('STPV' | 'STIP')

Flight plan request type.

'-' "BEGIN" "RIPEL"
1{destid}12
'-' "END" "RIPEL"

List of entities to receive flight plan
data

L 254/152

EN

Official Journal of the European Communities

9.10.2000

Reserved
Primary Field

Kind

Syntax

Semantic

ripsrc

rstid

rte

rtetr

scnf

secdest

seclist

seclistct

secsrc

spfl

ssrcodes

stamp

streason

strid

temp

terminal

translist

trfl

turb

validend

validst

visi

wddir

wdspd

xfl

xfpltxt

b

b

c

c

c

b

c

c

b

b

c

b

b

b

b

b

c

b

b

b

b

b

b

b

b

b

'-' "RIPSRC" centreidentification

'-' "RSTID" '1'|'2'|'3'|'4'|'5'

'-' "BEGIN" "RTE"
1{ptc}22
'-' "END" "RTE"

Identification of the centre respon-
sible for initiating the transmission
of flight plan data.

IFPS transaction number in a flight
plan request.

List of the CAUTRA points of undi-
rected route.

'-' "BEGIN" "RTETR" 1{ptpro}22
'-' "END" "RTETR"

List of route points for certain trans-
actions.

'-' "BEGIN" "SCNF"
1{acnf}3
'-' "END" "SCNF"

List of aerodrome configurations.

'-' "SECDEST" secidentification

Receiving sector identifier.

'-' "BEGIN" "SECLIST" 1{sec}30
'-' "END" "SECLIST"

'-' "BEGIN" "SECLISTCT" 1{secct}30
'-' "END" "SECLISTCT"

Global List of sectors.

Global List of the sectors.

'-' "SECSRC" secidentification

Originating sector identifier.

'-' "SPFL" flightlevel

Supplementary Flight Level.

'-' "SSRCODES" (code1 code2) | code | codep) Transmitted SSR code.

'-' "STAMP" 3{DIGIT}3 ! timehhmm

Stamp identification.

'-' "STREASON" starreason

'-' "STRID" 1{DIGIT}

'-' "TEMP" temperature

Reason for an initialisation request
issued from a working position.

RDPS identifier.

Temperature

'-' "TERMINAL" 1{ALPHANUM}2

Name of the terminal.

'-' "BEGIN" "TRANSLIST"
1 {transid}
'-' "END" "TRANSLIST"

'-' "TRFL" flightlevel | flighttendancy

'-' "TURB" 1{ALPHA}8

List of possible transactions for the
control position and for the flight
plan specified.

Transfer Flight Level or tendency
information about a flight profile

Turbulence = LIGHT or MODERATE
or SEVERE

'-' "VALIDEND" datetime

End time of display.

'-' "VALIDST" datetime

Start time of display.

'-' "VISI" 1{ALPHANUM}20

Visibility.

'-' "WDDIR" 1{DIGIT}3

Wind direction expressed in degrees
from 0 to 359.

'-' "WDSPD" 1{DIGIT}3

Wind speed expressed in knots.

'-' "XFL" flightlevel

Exit Flight Level (XFL).

'-' "XFPLTXT" 1{CHARACTER | ASCII–SUP}
768

Response message to a flight plan
request.

9.10.2000

EN

Official Journal of the European Communities

L 254/153

D.5. Reserved Subfields

Reserved
Subfields

Kind

Syntax

Semantic

Used in
Primary
Field

Used in
Subfield

bktchg

cflchg

code

codep

code1

code2

c

c

b

b

b

b

act

C

'-' "BEGIN" "ACT" 1{fieldid}20
'-' "END" "ACT"

bkchg

C

'-' "BKCHG" flimp flmin flmax

'-' "BKTCHG"
delta1 delta2

'-' "CFLCHG" flimp flmin flmax

Flight plan fields which are
modifiable at the time of
activation of a flight.

Implicit FL, minimum FL
and maximum FL for the
reference point for a trans-
action. The FL is generic,
may be RFL, PFL, etc.

The value (+/-) by which
a time modification for a
point is permitted.

Implicit Cleared Flight Lev-
el (CFL), minimum CFL and
maximum CFL for the ref-
erence point for a trans-
action.

'-' "CODE" ('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'}4

SSR mode and allocated ssrcodes
code.

'-' "CODEP"
('A'|'C'|'X')! 4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'}4

SSR mode and code which ssrcodes
is available for use.

'-' "CODE1" ('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'}4

SSR mode and code pre-
viously allocated.

ssrcodes

'-' "CODE2"
('A'|'C'|'X')! 4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'}4

SSR mode and code which ssrcodes
has been reserved for use
and is therefore not avail-
able.

Characteristic of co-ordi-
Initial, Exit,
nation point:
OCL, XFL

coorpt

b

'-' "COORPT" coordpoints

ctdest

delta1

delta2

deltsp1

deltsp2

destid

b

b

b

b

b

c

'-' "CTDEST" centreidentification

Receiving centre (ACC)

'-' "DELTA1" ('0'|'1'|'2'|'3'|'4'|'5')!DIGIT

'-' "DELTA2" ('0'|'1'|'2'|'3'|'4'|'5')!DIGIT

'-' "DELTSP1" 1{DIGIT}4

'-' "DELTSP2" 1{DIGIT}4

'-' "DESTID" ctdest secrip

Time interval for the calcu-
lation of a minimum time.

Time interval for the calcu-
lation of a maximum time.

Speed interval for the calcu-
lation of a minimum speed.

Speed interval for the calcu-
lation of a maximum speed.

ATC Centre and list of sec-
tors to whom flight plan
data is to be sent

ripel

transid

fieldid

fieldid

fieldid

ptc

destid

bktchg

bktchg

spdchg

spdchg

L 254/154

EN

Official Journal of the European Communities

9.10.2000

Reserved
Subfields

Kind

Syntax

Semantic

Used in
Primary
Field

Used in
Subfield

edto

b

'-' "EDTO" datetime|"WT"

Estimated time over a point
in year, month, day, hours,
minutes or indicator ‘point
without time’ ‘WT’.

eoid

eolist

eopos

fieldid

b

c

c

c

'-' "EOID" eoidentification

Operational ‘entity’ name.

'-' "BEGIN" "EOLIST" 1{eoid}
'-' "END" "EOLIST"

List of operational entities
associated to a control pos-
ition.

'-' "EOPOS" posid [eolist]

'-' "FIELDID"
'TYPA'|'ADES'|'RTE'|'ADEP'|'CODE'|
'LANG'|'BK'|spdchg|rflchg|cflchg|pflchg|
tflchg|sflchg|xflchg|bkchg|bktchg|'QFU'|
'PKDEP'|'SID'|'NFC'|'ATIS'|'DCRMK'|
'OPRMK'

Control position name and confl
list of operational entities
associated to this position.

Identification of modifiable
fields for a transaction.

flb

b

'-' "FLB" flightlevel

Calculated flightlevel at exit automsg
co-ordination point which
may be transmitted in the
automatic
co-ordination
message to the next centre.

flimp

b

'-' "FLIMP" flightlevel

Implicit flight level.

flmax

b

'-' "FLMAX" flightlevel

Maximum flight level.

flmin

b

'-' "FLMIN" flightlevel

Minimum flight level.

ptc
ptpro

eolist

eopos

act
mod
mvt
ret
modh

bkchg
rflchg
pflchg
cflchg
tflchg
sflchg

bkchg
rflchg
pflchg
cflchg
tflchg
sflchg
xflchg

bkchg
rflchg
pflchg
cflchg
tflchg
sflchg
xflchg

fpident

fpllgr

c

c

'-' "FPIDENT" plnid stamp ctrow entrnb

Flight plan identification in fpunkl
fpkwl
a message.

'-' "FPLLGR" arcidatc arcid adep ades
eobd eobt

‘Summary’ flight plan data.

fpllist

9.10.2000

EN

Official Journal of the European Communities

L 254/155

Reserved
Subfields

Kind

Syntax

Semantic

Used in
Primary
Field

Used in
Subfield

'-' "FPSUM" plnid eobdt adep ades ctrow Flight plan identification.
firstpid

fplist

'-' "LALG" lattd longtd

Latitude and longitude of
each point in the route

laglist

'-' "BEGIN" "MOD" 1{fieldid}20
'-' "END" "MOD"

fields which are
List of
modifiable after activation.

fpsum

lalg

mod

modh

mvt

c

c

c

c

c

pka

pkatt

pkc

pointid

posid

ptc

ptcid

ptpro

qful

b

b

b

b

b

c

b

c

c

'-' "BEGIN" "MODH" 1{fieldid}2
'-' "END" "MODH"

'-' "BEGIN" "MVT" 1{fieldid}2
'-' "END" "MVT"

pflchg

c

'-' "PFLCHG" flimp flmin flmax

pflt

b

'-' "PFLT" flightlevel!('NA'|NIL)

transid

transid

transid

fieldid

List of
fields which are
modifiable in a time update
transaction after activation.

List of
fields which are
modifiable in a manually
co-ordination
triggered
between sectors

Implicit, minimum and
maximum level for modifi-
cation of PFL.

Planned flightlevel which automsg
will be transmitted in the
co-ordination
automatic
message to the next centre.
Plus an indication whether
the level
is in accordance
with the applicable oper-
ational agreements.
NA = Not according agree-
ment.

Reserved parking position, pkarr
not yet allocated.

Indicator that the aircraft pkarr
is waiting for a parking
position.

'-' "PKA" 1{ALPHANUM}3

'-' "PKATT" 'YES' | 'NO'

'-' "PKC" 1{ALPHANUM}3

Allocated parking position. pkarr

'-' "POINTID" pointcautra

Specific to the French sys-
tem.

ptpro

'-' "POSID" positionidentification

Control position name.

eopos

'-' "PTC" ptcid edto [fl] [view] [udpt]
[traj] [coorpt] [ref]

Characteristics of a route rte
point.

'-' "PTICD" pointcautra|geoname

Specific to the French sys- automsg ptc
tem.

'-' "PTPRO" pointid [edto] [fl] [traj]

Description of proposed rtetr
route points.

'-' "QFUL" qfuid

Valid QFU for a given run-
way on an aerodrome.

qfulist

L 254/156

EN

Official Journal of the European Communities

9.10.2000

Reserved
Subfields

Kind

Syntax

Semantic

Used in
Primary
Field

Used in
Subfield

qfulist

rcnf

ref

refid

ref1id

c

b

c

b

b

'-' BEGIN" "QFULIST"
1{qful}8
'-' "END" "QFULIST"

'-' "RCNF" 1{ALPHA}5

'-' "REF" (refid|ref1id)

'-' "REFID" 'REF'!2{DIGIT}2

'-' "REF1ID" 'REF'!2{DIGIT}2

regulid1

b

'-' "REGULID1" 1{ALPHANUM}5

regulid2

b

'-' "REGULID2" 1{ALPHANUM}5

regult

ret

rflchg

rmktxt

sec

seccar

b

c

c

b

c

b

'-' "REGULT" datetime

'-' "BEGIN" "RET" 1{fieldid}1
'-' "END" "RET"

'-' "RFLCHG" flimp flmin flmax

'-' "SEC" secid [seccar]

'-' "SECCAR"
('F'!('L'!('M'!('D'|NIL)|NIL)|NIL)|NIL)
|('L'! ('M'!('D'|NIL)|NIL)|NIL)
|('M'!('D'|NIL)|NIL)
|'D'

seccarct

b

'-' "SECCARCT"
('F'!('L'!('M'!('V'/NIL)/NIL)/NIL)/NIL)
/('L'! ('M'!('V'/NIL)/NIL)/NIL)
/('M'!('V'/NIL)/NIL)
/'V'

secct

c

'-' "SECCT" secid [seccarct]

List of valid QFUs for an acnf
aerodrome.

and acnf

take-off

General
landing direction for an
aerodrome.
(East, West,
etc.)

Characteristics of a refer-
ence point
for a trans-
action.

Identification of a possible
reference point for a trans-
action.

Identification of the most
probable reference point
for a transaction.

information regul

Regulation
specific to the French sys-
tems.

information regul

Regulation
specific to the French sys-
tems.

information regul

Regulation
specific to the French sys-
tems.

fields which are
List of
modifiable in a transaction
to return the flight plan
data to it's previous status.

Implicit, minimum and
maximum level
the
modification of the RFL.

for

ptc

ref

ref

transid

fieldid

seclist

secrip

sec

secct

Identification and charac-
teristics of ACC sectors to
whom flight plan data is to
be sent.

Characteristic of an ACC
sector:
- First sector (‘F’)
- Last sector (‘L’)
- Accepted for Entry (‘M’)
- source sector for ‘dupli-
cation’ (‘D’)

Characteristic of a Terminal
Area sector:
- First sector (‘F’)
- Last sector (‘L’)
- Accepted for Entry(‘M’)

Identification and charac-
teristics of Terminal Area
sectors.

seclistct

'-' "RMKTXT" 1{LIM–CHAR}20

Text of a controller remark. oprmk

9.10.2000

EN

Official Journal of the European Communities

L 254/157

Reserved
Subfields

Kind

Syntax

Semantic

Used in
Primary
Field

Used in
Subfield

secct
sec

destid

fieldid

fieldid

fieldid

ptc
ptpro

ptc

ptc

secid

secrip

sendt

sflchg

b

c

b

c

'-' "SECID" secidentification

Sector identification.

'-' "BEGIN" "SECRIP" 1{sec}40
'-' "END" "SECRIP"

List of
receiving entities
(sectors or departure/ar-
rival control entities)
to
whom flight plan data is to
be sent.

'-' "SENDT" datetime

Time for sending co-ordi- automsg
nation message.

'-' "SFLCHG" flimp flmin flmax

spdchg

c

'-' "SPDCHG" deltsp1 deltsp2

tflchg

c

'-' "TFLCHG" flimp flmin flmax

traj

b

'-' "TRAJ"
('S'!'M')|'S'|'M'|'T'|
('S'!'M'!'A')|('S'!'A')|
('M'!'A')|'A'

Implicit, minimum and
maximum level for modifi-
cation of Supplementary
Flight Level (SFL)

an upper

speed
Lower
the modifi-
intervals for
cation of
the flight plan
speed during a transaction.

Implicit, minimum and
maximum level for modifi-
cation of Transfer Flight
Level (TFL).

Characteristics of a point in
relation to the trajectory of
a flight:
S = Splitpoint
M = Mergepoint
T = Abeam point
A = STAR point

transid

b

'-' " TRANSID" (act | mod | mvt | ret |
modh | 'CNL' | 'RIP') | 'NO'

Identification of possible translist
transaction for the control
position for this flight plan
or ‘NO’ indicator meaning
transaction not possible.

'-' "TXT" 1{LIM–CHAR}80

Free text.

freetxt

txt

udpt

b

b

'-' "UDPT" updatereason

view

b

'-' "VIEW" ('V'|'VNX')

vxpist

b

vypist

b

'-' "VXPIST" ALPHA 1{DIGIT}5
ALPHA:= P|N
P:= Positif
N:= Negative

'-' "VYPIST" ALPHA 1{DIGIT}5
ALPHA:= P|N
P:= Positif
N:= Negative

Last update brought by
operator and/or by radar
information.

Indication of ‘viewable’ nat-
ure of a point.
V = viewable
VNX = not viewable (arti-
ficial point)

X coordinate of the speed pistcoord
vector of a radar position.

Y coordinate of the speed pistcoord
vector of a radar position.

L 254/158

EN

Official Journal of the European Communities

9.10.2000

Reserved
Subfields

Kind

xflchg

xpist

ypist

c

b

b

'-' "XFLCHG" flmin flmax

'-' "XPIST" 'P'|'N' 1{DIGIT}6
P:= Positif
N:= Negative

'-' "YPIST" 'P'|'N' 1{DIGIT}6
ALPHA:= P/N
P:= Positif
N:= Negative

Syntax

Semantic

Used in
Primary
Field

Used in
Subfield

fieldid

Minimum and maximum
level for modification of an
Exit Flight Level (XFL).

X coordinate of a radar pos- pistcoord
ition.

Y coordinate of a radar pos- pistcoord
ition.

9.10.2000

EN

Official Journal of the European Communities

L 254/159

ANNEX E (Informative)

INTRODUCTION OF MESSAGE GROUPS

INTRODUCTION

This Annex provides an introduction to the different groups or categories of messages which can be exchanged in
ADEXP. A complete listing of all ADEXP message titles is given in Annex B.

NOTE

For the exact conditions, rules of application and field usage, particularly the use of optional fields, reference should be
made to the relevant documentation (e.g. Interface Specification document) of the systems concerned.

E.1.

Flight Plan Messages

E.1.1.

Introduction

Messages within this category are exchanged primarily between the AO, IFPS and the relevant ATS
Units.

E.1.2.

Definition of Message Titles

Message titles within this category are:

ACK, IACH, IAFP, IAPL, IARR, ICHG, ICNL, IDEP, IDLA, IFPL, IRPL, IRQP, MAN, RCHG, RCNL, REJ.

All defining material for these messages is held within Document Ref. 3

E.1.3.

Primary Fields Composition

Detailed definition of message content, data insertion rules and the use of compulsory and optional
fields can be found in Document Ref. 3.

Example

Flight Plan Message

-TITLE IFPL

-BEGIN ADDR -FAC CFMUTACT -FAC EGZYTTFO -FAC EGZYTTTE -FAC EGTTZGZP

-FAC EGKKZPZI -FAC LFFBTEST -FAC LESCYFPX -FAC LPPCIFPS -FAC LPPTYWYA

-FAC LPAMYWYA -FAC LPAMYCYX -FAC LPPTIFPS

-END ADDR

-ADEP EGKK -ADES LPPT -ARCID AZX752 -ARCTYP BA11 -CEQPT S

-EOBD 980305 -EOBT 1130 -FILTIM 041530 -IFPLID AA00463686 -ORGNID AZXRPLO

-SEQPT C -SRC RPL -WKTRC M -TTLEET 0230 -RFL F330 -SPEED N0400 -FLTRUL I

-FLTTYP S

-ROUTE N0400F330 SAM UR41 ORTAC UR1 QPR UR107 AVS UG41 FTM

-BEGIN RTEPTS

L 254/160

EN

Official Journal of the European Communities

9.10.2000

-PT -PTID EGKK -FL F000 -ETO 980305113000

-PT -PTID SAM -FL F196 -ETO 980305114012

-PT -PTID ASPEN -FL F288 -ETO 980305114658

-PT -PTID ORTAC -FL F311 -ETO 980305114959

-PT -PTID GUR -FL F330 -ETO 980305115617

-PT -PTID AKEMI -FL F330 -ETO 980305120118

-PT -PTID LARSI -FL F330 -ETO 980305120626

-PT -PTID QPR -FL F330 -ETO 980305121236

-PT -PTID ERWAN -FL F330 -ETO 980305123152

-PT -PTID LOTEE -FL F330 -ETO 980305124401

-PT -PTID AVS -FL F330 -ETO 980305125357

-PT -PTID KORET -FL F330 -ETO 980305130137

-PT -PTID BARKO -FL F330 -ETO 980305130734

-PT -PTID CANAR -FL F330 -ETO 980305131544

-PT -PTID VIS -FL F330 -ETO 980305132220

-PT -PTID FTM -FL F234 -ETO 980305133230

-PT -PTID LPPT -FL F000 -ETO 980305134529

-END RTEPTS

-ATSRT UR41 SAM ORTAC -ATSRT UR1 ORTAC QPR -ATSRT UR107 QPR AVS

-ATSRT UG41 AVS FTM

E.2.

Air Traffic Flow Management Messages

E.2.1.

Introduction

Messages within this category are exchanged primarily between the TACT system of the Eurocontrol
CFMU, Aircraft Operators and ATS Units.

E.2.2.

Computer Assisted Slot Allocation Messages (CASA)

Message titles within this category are:

DES, ERR, FCM, FLS, RDY, RJT, RRP, SAM, SIP, SLC, SMM, SPA, SRJ, SRM, SRR.

E.2.2.1.

D e f i n i t i o n o f M e s s a g e T i t l e s

All defining material for these messages is held within Document Ref. 5

E.2.2.2.

P r i m a r y F i e l d s C o m p o s i t i o n

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

9.10.2000

EN

Official Journal of the European Communities

L 254/161

E.2.3.

Information Messages

Message titles within this category are:

FSA

E.2.3.1.

D e f i n i t i o n o f M e s s a g e T i t l e s

Defining material for this message will be available in Document Ref. 5

E.2.3.2.

P r i m a r y F i e l d s C o m p o s i t i o n

Definition of message content, data insertion rules and the use of compulsory and optional fields will
be found in Document Ref. 5.

Example

First System Activation Message

-TITLE FSA -ARCID EIN636 -ADEP EIDW -ADES EBBR -POSITION -PTID LIFFY -TO 1646

E.3.

ATC Co-ordination Messages

E.3.1.

Introduction

Co-ordination Messages are used to automate operational co-ordination and the exchange of
information between ATC units. The messages ensure the timely delivery of operational information
related to co-ordination through standardised data extraction and transmission capabilities.

E.3.2.

Definition of Message Titles

Message titles within this category are:

ABI, ACT, CDN, COD, COF, HOP, INF, LAM, LRM, MAC, MAS, PAC, RAP, REV, ROF, RRV, SBY,
SDM, TIM.

All defining material for these messages is held within Document Ref. 6

E.3.3.

Primary Fields Composition

All defining material for these messages is held within Document Ref. 6.

Examples

Hand-Over Proposal Message

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

-CFL F190 -ASPEED N0420 -RATE D25 -DCT BEN STN

Activate Message

-TITLE ACT -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 005 -ARCID AMM253

-SSRCODE A7041 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F350

-ADES EGBB -ARCTYP B757 -ROUTE N0480F390 UB4 BNE UB4 BPK UB3 HON

L 254/162

EN

Official Journal of the European Communities

9.10.2000

E.4.

Airspace Management Messages

E.4.1.

Introduction

Messages used in the of co-ordination of airspace management. These messages cover the management
of the environment in which the traffic is moving: the permanent and conditional routes, temporary
segregated areas, danger and prohibited areas, etc.

E.4.2.

Definition of Message Titles

Message titles within this category are:

AUP, CRAM, UUP.

All defining material for these messages is held within Document Ref.7.

E.4.3.

Primary Fields Composition

All defining material for these messages is held within Document Ref. 7.

Example:

Conditional Route Availability Message

-TITLE CRAM -PART -NUM 001 -LASTNUM 010

-FILTIME 281353 -MESVALPERIOD 199803290600 1998703300600

-BEGIN LACDR

-AIRROUTE -NUM 001 -REFATSRTE UA23 ELVAR LP BEJ LP

-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803290600 199803300600

-AIRROUTE -NUM 002 -REFATSRTE UA44 ESP LP BEJ LP

-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803290600 199803290730

-AIRROUTE -NUM 003 -REFATSRTE UA44 ESP LP BEJ LP

-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803291830 199803300600

-AIRROUTE -NUM 004 -REFATSRTE A44 ESP LP BEJ LP

-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803290600 199803290730

-AIRROUTE -NUM 005 -REFATSRTE A44 ESP LP BEJ LP

-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803291830 199803300600

-AIRROUTE -NUM 006 -REFATSRTE A44 BEJ LP ROSAL LP

-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803292030 199803300530

-AIRROUTE -NUM 007 -REFATSRTE UA57 FFM ED DIK EL

-FLBLOCK -FL F250 -FL F450 -VALPERIOD 199803290700 199803291330

-END LACDR

E.5.

Civil / Military Co-ordination Messages

E.5.1.

Introduction

Messages used in the co-ordination of flight data and airspace crossing requests between civil and
military ATS units.

9.10.2000

EN

Official Journal of the European Communities

L 254/163

E.5.2.

Definition of Message Titles

Message titles within this category are:

ACP, BFD, CFD, LAM, RJC, XAP, XCM, XIN, XRQ.

All defining material for these messages is held within Document Ref. 7.

E.5.3.

Primary Fields Composition

All defining material for these messages is held within Document Ref. 7.

Example:

Crossing Clearance Request Message

-TITLE XRQ -REFDATA -SENDER -FAC EBSZZXZQ -RECVR -FAC EBBUZXZQ

-SEQNUM 012 -ARCID DEUCE22 -SSRCODE A1240 -ARCTYP F111 -SECTOR SOUTH

-BEGIN RTEPTS

-PT -PTID GEO01 -TO 1630 -FL F250

-PT -PTID GEO02 -TO 1631 -FL250

-END RTEPTS

-GEO -GEOID GEO01 -LATTD 500000N -LONGTD 0051000E

-GEO -GEOID GEO02 -LATTD 500000N -LONGTD 0051500E

Acceptance Message

-TITLE ACP -REFDATA -SENDER -FAC EBBUZXZQ -RECVR -FAC EBSZZXZQ

-SEQNUM 014 -MSGREF -SENDER -FAC EBSZZXZQ -RECVR -FAC EBBUZXZQ

-SEQNUM 012

L 254/164

EN

Official Journal of the European Communities

9.10.2000

ANNEX F (Informative)

EXAMPLES OF ADEXP MESSAGE FORMAT

The following examples are provided as a demonstration of the ADEXP format, not as an example of message
content. The message used is an IFPL and although correct at the time of publication, accuracy of field composition
etc. is not guaranteed.

The EXAMPLE 1 below has been presented in a manner which makes it easily readable. This has been achieved
through the use of carriage returns, line feeds, indents etc. Such a layout however does not form part of the ADEXP
format rules.

Presentation of a message is therefore at the discretion of the receiving system. The examples provided as EXAMPLE 2
and EXAMPLE 3 are both valid representations of the same message as that in EXAMPLE 1.

EXAMPLE 1

-TITLE IFPL

-BEGIN ADDR

-FAC CFMUTACT

-FAC LFFFSTIP

-FAC EDFFZRZL

-FAC EDZZZQZA

-FAC EDUUZQZA

-FAC LOVVZQZX

-FAC LHBPZEZX

-FAC LYBAZQZX

-FAC LWSSZQZX

-FAC LGTSZAZX

-END ADDR

-ADEP EDDF

-ADES LGTS

-ARCID DLH3728

-ARCTYP B73A

-CEQPT SDMRY

-EOBD 980517

-EOBT 0715

-FILTIM 170421

-IFPLID AA05966101

-ORGNID DLHAOCC

-ORIGIN -NETWORKTYPE SITA -FAC FRAOXLH

-REG DABHM

-SEL KMGJ

-SRC FPL

-FLTTYP S

-WKTRC M

-TTLEET 0210

9.10.2000

EN

Official Journal of the European Communities

L 254/165

-RFL F330

-SPEED N0417

-FLTRUL I

-SEQPT C

-ROUTE N0417F330 NDG3D NDG UW70 MUN UB103 UNKEN UT23 BABIT UR26

SAVIN UG18 BUI UB1 TALAS

-ALTRNT1 LBSF

-EETFIR EDUU 0014

-EETFIR LOVV 0035

-EETFIR LJLA 0054

-EETFIR LHCC 0057

-EETFIR LYBA 0113

-EETFIR LWSS 0148

-EETFIR LGGG 0159

-BEGIN RTEPTS

-PT -PTID EDDF -FL F000 -ETO 980317071500

-PT -PTID NDG -FL F311 -ETO 9803173414

-PT -PTID RIDER -FL F327 -ETO 980317073726

-PT -PTID MAH -FL F330 -ETO 980317074130

-PT -PTID MUN -FL F330 -ETO 980317074449

-PT -PTID CHIEM -FL F330 -ETO 980317074754

-PT -PTID UNKEN -FL F330 -ETO 980317075109

-PT -PTID GRZ -FL F330 -ETO 9803170080830

-PT -PTID DIMLO -FL F330 -ETO 980317081443

-PT -PTID BABIT -FL F330 -ETO 980317083107

-PT -PTID SAVIN -FL F330 -ETO 980317083613

-PT -PTID UPIVO -FL F330 -ETO 980317084054

-PT -PTID KLENA -FL F330 -ETO 980317084204

-PT -PTID VAL -FL F330 -ETO 980317084629

-PT -PTID KAVOR -FL F330 -ETO 980317085329

-PT -PTID BUI -FL F330 -ETO 980317090135

-PT -PTID SARAX -FL F330 -ETO 980317090650

-PT -PTID PEP -FL F312 -ETO 980317091414

-PT -PTID TALAS -FL F241 -ETO 980317091746

-PT -PTID LGTS -FL F000 -ETO 980317093138

-END RTEPTS

-SID NDG3D

-ATSRT UW70 NDG MUN

-ATSRT UB103 MUN UNKEN

-ATSRT UT23 UNKEN BABIT

-ATSRT UR26 BABIT SAVIN

-ATSRT UG18 SAVIN BUI

-ATSRT UB1 BUI TALAS

L 254/166

EN

Official Journal of the European Communities

9.10.2000

EXAMPLE 2

-TITLE IFPL -BEGIN ADDR -FAC CFMUTACT -FAC LFFFSTIP -FAC EDFFZRZL -FAC EDZZZQZA -FAC EDUUZQZA
-FAC LOVVZQZX -FAC LHBPZEZX -FAC LYBAZQZX -FAC LWSSZQZX -FAC LGTSZAZX -END ADDR -ADEP
EDDF -ADES LGTS -ARCID DLH3728 -ARCTYP B73A -CEQPT SDMR -EOBD 980517 -EOBT 0715 -FILTIM
170421 -IFPLID AA05966101 -ORGNID DLHAOCC -ORIGIN -NETWORKTYPE SITA -FAC FRAOXLH -REG
DABHM -SEL KMGJ -SRC FPL -FLTTYP S -WKTRC M -TTLEET 0210 -RFL F330 -SPEED N0417 -FLTRUL I -SEQPT
C -ROUTE N0417F330 NDG3D NDG UW70 MUN UB103 UNKEN UT23 BABIT UR26 SAVIN UG18 BUI UB1
TALAS -ALTRNT1 LBSF -EETFIR EDUU 0014 -EETFIR LOVV 0035 -EETFIR LJLA 0054 -EETFIR LHCC 0057
-EETFIR LYBA 0113 -EETFIR LWSS 0148 -EETFIR LGGG 0159 -BEGIN RTEPTS -PT -PTID EDDF -FL F000 -ETO
980317071500 -PT -PTID NDG -FL F311 -ETO 9803173414 -PT -PTID RIDER -FL F327 -ETO 980317073726
-PT -PTID MAH -FL F330 -ETO 980317074130 -PT -PTID MUN -FL F330 -ETO 980317074449 -PT -PTID CHIEM
-FL F330 -ETO 980317074754 -PT -PTID UNKEN -FL F330 -ETO 980317075109 -PT -PTID GRZ -FL F330 -ETO
9803170080830 -PT -PTID DIMLO -FL F330 -ETO 980317081443 -PT -PTID BABIT -FL F330 -ETO
980317083107 -PT -PTID SAVIN -FL F330 -ETO 980317083613 -PT -PTID UPIVO -FL F330 -ETO 980317084054
-PT -PTID KLENA -FL F330 -ETO 980317084204 -PT -PTID VAL -FL F330 -ETO 980317084629 -PT -PTID
KAVOR -FL F330 -ETO 980317085329 -PT -PTID BUI -FL F330 -ETO 980317090135 -PT -PTID SARAX -FL
F330 -ETO 980317090650 -PT -PTID PEP -FL F312 -ETO 980317091414 -PT -PTID TALAS -FL F241 -ETO
980317091746 -PT -PTID LGTS -FL F000 -ETO 980317093138 -END RTEPTS -SID NDG3D -ATSRT UW70 NDG
MUN -ATSRT UB103 MUN UNKEN -ATSRT UT23 UNKEN BABIT -ATSRT UR26 BABIT SAVIN -ATSRT UG18
SAVIN BUI -ATSRT UB1 BUI TALAS

EXAMPLE 3

-TITLE IFPL-BEGIN ADDR-FAC CFMUTACT-FAC LFFFSTIPFAC EDFFZRZL-FAC EDZZZQZA-FAC EDUUZQZA-
FAC LOVVZQZX-FAC LHBPZEZX-FAC LYBAZQZX-FAC LWSSZQZX-FAC LGTSZAZX-END ADDR-ADEP EDDF-
ADES LGTS-ARCID DLH3728-ARCTYP B73A-CEQPT SDMR-EOBD 980517-EOBT 0715-FILTIM 170421-IFPLID
AA05986101-ORGNID DLHAOCC-ORIGIN-NETWORKTYPE SITA-FAC FRAOXLH-REG DABHM-SEL KMGJ-SRC
FPL-FLTTYP S-WKTRC M-TTLEET 0210-RFL F330-SPEED N0417-FLTRUL I-SEQPT C-ROUTE N0417F330 NDG3D
NDG UW70 MUN UB103 UNKEN UT23 BABIT UR26 SAVIN UG18 BUI UB1 TALAS-ALTRNT1 LBSF-EETFIR
EDUU 0014-EETFIR LOVV 0035-EETFIR LJLA 0054-EETFIR LHCC 0057-EETFIR LYBA 0113-EETFIR LWSS 0148-
EETFIR LGGG 0159-BEGIN RTEPTS-PT-PTID EDDF-FL F000-ETO 980317071500-PT-PTID NDG-FL F311-ETO
9803173414-PT-PTID RIDER-FL F327-ETO 980317073726-PT-PTID MAH-FL F330-ETO 980317074130-PT PTID
MUN-FL F330-ETO 980317074449-PT-PTID CHIEM-FL F330-ETO 980317074754-PT-PTID UNKENFL F330-ETO
980317075109-PT-PTID GRZ-FL F330-ETO 9803170080830-PT-PTID DIMLO-FL F330-ETO 980317081443-PT-
PTID BABIT-FL F330-ETO 980317083107-PT-PTID SAVIN-FL F330-ETO 98031708361-PT-PTID UPIVO-FL F330-
ETO 980317084054-PT-PTID KLENA-FL F330-ETO 980317084204-PT-PTID VAL-FL F330-ETO 980317084629-
PT-PTID KAVOR-FL F330-ETO 980317085329-PT-PTID BUI-FL F330-ETO 980317090135-PT-PTID SARAX-FL
F330-ETO 980317090650-PT-PTID PEP-FL
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

F312-ETO 980317091414-PT-PTID TALAS-FL

9.10.2000

EN

Official Journal of the European Communities

L 254/167

ANNEX G (Informative)

FUTURE DEVELOPMENTS

G.1.

Introduction

This annex is intended to provide an indication of the proposed future development of ADEXP and
the reasons and objectives behind the development.

G.2.

Objectives

One of the most important objectives during the development of ADEXP was the requirement to
develop a format which would enable a receiving system to successfully ‘ignore’ or ‘skip’ an unknown
or unrecognised field without necessarily having to invalidate the message being processed. This
implementation can allow the addition of a new field within a message without the requirement to
have all receiving systems modified in advance followed by a very carefully co-ordinated ‘switch-over’.
The enormous flexibility that this can provide is one of the advantages of the ADEXP format.

This objective is achieved in the current standard through the use of pre-defined primary and sub-
fields, introduced by unique keywords. A lexical analyser or parser which does not ‘recognise’ a
keyword is required to ignore all the text up to the next known Primary Field, which is not within a
List Field. Recovery is therefore achieved at the level of primary fields.

Current and future development in the definition of new messages indicate that in certain areas a
greater level of complexity is required, where third and even fourth level nesting of fields is needed.
(The Conditional Route Allocation Message (CRAM) is a current example of this requirement). ADEXP
today provides the ability to build a message with any level of nesting. However, the ability to recover
from an unrecognised subfield, which occurs at perhaps the third or fourth level of nesting, without
the chance of misinterpretation of data or of having to invalidate the message, does not exist. The
proposed modifications required of the ADEXP format are designed to ensure that a lexical analyser or
parser is able, at all times, to determine where it is within the structure of a message or individual field
and in so doing, to enable recovery to take place at any level of nesting without the danger of
misinterpretation of data.

G.3.

Proposal

In order to achieve the objective of recovery at any level within a message it is necessary for the lexical
analyser to be able to determine the end, as well as the start, of a field. The current format allows only
the determination of the start of a field using the ‘-’ character.

It will be proposed, in a future release of ADEXP, to introduce the use of parenthesis to indicate
respectively the start and end of a field. The current use of the ‘-’ character to introduce the start of
field would be replaced by the ‘(’ character. The end of field, which is not explicitly indicated today,
would be indicated in future by the ‘)’ character. The following examples are intended to demonstrate
the principle.

Examples

Current Format

Proposed Format

Example of Basic Field:

Example of Compound Field:

-RFL F330

-CRSCLIMB

-PTID DUB

-CRSPEED M084

-CRFL1 F370

-CRFL2 F430

(RFL F330)

(CRSCLIMB

(PTID DUB)

(CRSPEED M084)

(CRFL1 F370)

(CRFL2 F430))

L 254/168

EN

Official Journal of the European Communities

9.10.2000

ANNEX III

FLIGHT DATA EXCHANGE — INTERFACE CONTROL DOCUMENT (FDE-ICD), EDITION 1.0

(Eurocontrol document reference COM.ET1.ST12-STD)

9.10.2000

EN

Official Journal of the European Communities

L 254/169

TABLE OF CONTENTS

COPYRIGHT NOTICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

174

FOREWORD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

175

1.

2.

3.

3.1.

3.2.

4.

4.1.

4.2.

4.3.

5.

5.1.

5.2.

5.3.

6.

6.1.

6.2.

6.3.

INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

177

SCOPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

177

REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

178

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

178

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

178

DEFINITIONS, SYMBOLS AND ABBREVIATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

179

Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

179

Symbols and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

180

Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

181

TECHNICAL OVERVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

182

Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

182

Structure of the Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

182

Relation to Previous Versions of the Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

183

PROFILE REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

183

Conformance Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

183

Upper-layer Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

183

Lower-layer Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

183

6.3.1.

Transport Layer Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

183

6.3.2.

Network Layer Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

183

6.3.3.

Datalink Layer Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

184

6.3.4.

Physical Layer Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

184

7.

TEST METHODS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

184

ANNEX A (NORMATIVE) MESSAGE TRANSFER PROTOCOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

185

A.1.

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

185

A.2.

Service Implemented . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

185

A.3.

Service Assumed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

185

L 254/170

EN

Official Journal of the European Communities

9.10.2000

A.4.

Protocol Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.4.1.

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.4.2.

Types of Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.4.3.

Association Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.4.4.

Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.4.5.

Orderly Association Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.4.6.

Association Re-establishment

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.4.7.

Association Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.4.8.

Disorderly Association Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.4.9.

Recovery From Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.4.10. Message Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.5.

Protocol State Transition Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.5.1.

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.5.2.

State Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.5.3.

Possible Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.5.4.

Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.5.5.

State Transition Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.5.6.

State Transition Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ANNEX B (NORMATIVE) MESSAGE HEADER PROTOCOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

B.1.

B.2.

B.3.

B.4.

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Service Implemented . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Service Assumed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Protocol Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

B.4.1.

Connection Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

B.4.2.

Avoidance of Redundant Network Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

B.4.3.

Connection Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

B.4.4.

Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ANNEX C (NORMATIVE) NETWORK PROTOCOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C.1.

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C.2.

Service Provided . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

185

185

185

186

186

187

187

187

188

188

188

189

189

189

190

190

191

192

194

194

194

194

194

194

194

195

195

197

197

197

9.10.2000

EN

Official Journal of the European Communities

L 254/171

C.3.

Service Assumed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C.4.

NSAP Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C.4.1.

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C.4.2.

NSAP Address Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C.4.3.

Assignment of ATC Unit Identifiers and Selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C.5.

Protocol Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

197

197

197

198

198

198

C.5.1.

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

198

C.5.2.

Address Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

199

C.5.3.

Encoding of the User Data Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

199

C.5.4.

Treatment of Addresses in INCOMING CALL Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

199

C.5.5.

Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

200

ANNEX D (NORMATIVE)

PROFILE-SPECIFIC PICS PROFORMAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

201

D.1.

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

201

D.2.

Instructions for Completing the PICS Proformas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

201

D.2.1.

General Structure of the PICS Proformas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

D.2.2.

Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

201

202

D.2.3.

Exception Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

202

D.2.4.

Conditional Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

202

D.3.

PICS Proforma for the Message Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

203

D.3.1.

Abbreviations and Special Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

D.3.2.

Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

203

203

D.3.3.

Protocol Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

204

D.4.

PICS Proforma for the Message Header Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

204

D.4.1.

Abbreviations and Special Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

204

D.4.2.

Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

D.4.3.

Protocol Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

205

206

D.5.

PICS Proforma for the Network Protocol

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

206

D.5.1.

Abbreviations and Special Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

206

D.5.2.

Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

207

D.5.3.

Protocol Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

207

L 254/172

EN

Official Journal of the European Communities

9.10.2000

ANNEX E (NORMATIVE)

PROFILE REQUIREMENTS LIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

E.1.

E.2.

E.3.

E.4.

E.5.

E.6.

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The Role of the PRL and PICS Proformas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Instructions for Completing the PICS Proformas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Conformance Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

E.6.1.

Conformance Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

E.6.2.

Dynamic Conformance Requirements4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

E.7.

E.8.

Upper Layer Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Lower Layer Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

E.8.1.

Transport Layer Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

E.8.2.

Network Layer Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

E.8.3.

Datalink Layer Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

E.8.4.

Physical Layer Requirements10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ANNEX F (INFORMATIVE) CONFORMANCE TESTING METHODOLOGY . . . . . . . . . . . . . . . . . . . . . . . . . .

F.1.

F.2.

F.3.

F.4.

F.5.

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Development Methods and Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

F.5.1.

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

F.5.2.

Testing of the Lower Layers (Layers 1 — 3)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

F.5.3.

Testing of the Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

F.5.4.

Certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

F.5.5.

Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

208

208

208

209

209

210

211

211

212

212

212

212

213

226

227

228

228

228

228

228

228

208

229

229

229

229

ANNEX G (INFORMATIVE) ASSIGNMENT OF ATC UNIT IDENTIFIERS . . . . . . . . . . . . . . . . . . . . . . . . . . . .

230

ANNEX H (INFORMATIVE) GUIDANCE ON RELIABILITY, AVAILABILITY AND SECURITY . . . . . . . . . .

H.1.

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

H.2.

Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

H.3.

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

232

232

232

232

9.10.2000

EN

Official Journal of the European Communities

L 254/173

H.4.

Leased Line Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

H.4.1.

Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

H.4.2.

Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

H.4.3.

Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

H.4.4.

Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

H.5.

Network Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

H.5.1.

Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

H.5.2.

Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

H.5.3.

Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

H.6.

General Guidance for Leased Line and Network Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . .

H.6.1.

Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

H.6.2.

Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

H.6.3.

Systems Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

H.6.4.

Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

232

232

232

232

233

233

233

233

233

233

233

234

234

234

L 254/174

EN

Official Journal of the European Communities

9.10.2000

COPYRIGHT NOTICE

This document has been produced by the Eurocontrol Agency.

Copyright is vested with the Eurocontrol Agency.

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

9.10.2000

EN

Official Journal of the European Communities

L 254/175

FOREWORD

1.

Responsible Body

This Standard Document has been prepared by and is maintained by the Flight Plan related Data
the European Organisation for the Safety of Air Navigation
Exchange (FPDE) Task Force of
(Eurocontrol).

2.

EATCHIP Work Programme Document

This Standard relates to the EATCHIP Work Programme Document (EWPD), Communications Domain,
Executive Task 01, Specialist Task 12

3.

3.1.

3.2.

Approval of the Standard

This Standard is adopted in accordance with the procedures outlined in the Directives for Eurocontrol
Standardisation Ref. 000-2-93.

This Standard becomes effective upon adoption by the Permanent Commission of Eurocontrol and
supersedes Eurocontrol Standard for On-Line Data Interchange (OLDI), Edition 1, Part 3: TECHNICAL
REQUIREMENTS (Short Term Interface Control Document) Ref. 001-3-92.

4.

Technical Corrigenda and Amendments

This Standard is kept under review to ascertain required amendments or technical corrigenda. The
procedure for the maintenance of this Standard is laid down in Annex H of the Directives for the
Uniform Drafting and Presentation of Eurocontrol Standard Documents Ref. 000-1-92.

5.

5.1.

Editorial Conventions

The format of this Standard complies with the Directives for the Uniform Drafting and Presentation of
Eurocontrol Standard Documents.

5.2.

The following notation has been used to indicate the status of each statement:

— Normative statements use the operative verb ‘shall’ and have been printed in light faced roman text;

— Recommended statements use the operative verb ‘should’ and have been printed in light faced italics,

the status being indicated by the prefix Recommendation.

Any other information which is considered essential to the understanding of a particular indent will
be integrated within the text as a NOTE. A note is considered to be informative only, therefore does
not contain specifications and is placed immediately after the indent to which it refers.

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.

Relationship to other Standard Documents

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

This Eurocontrol Standard Document is the first part in a expected series of Eurocontrol Standard
Interface Control Documents (ICDs) for Flight Data Exchange.

5.3.

5.4.

6.

6.1.

6.2.

L 254/176

EN

Official Journal of the European Communities

9.10.2000

7.

Status of Annexes to this Standard

The Annexes to this Standard have the following status:

— Annex A — Normative

— Annex B — Normative

— Annex C — Normative

— Annex D — Normative.

— Annex E — Normative

— Annex F — Informative

— Annex G — Informative

— Annex H — Informative

8.

Language Used

The English language has been used for the original text of this Standard.

9.10.2000

EN

Official Journal of the European Communities

L 254/177

1.

INTRODUCTION

This Eurocontrol Standard is based on the Short Term Interface Control Document developed by the
former OLDI Technical Sub-Group which was tasked with defining new interface standards for the
future operation of OLDI between Area Control Centres.

Earlier OLDI links were based on proprietary protocols such as INTERCAUTRA or Datenübertragungs-
und Verteilungssystem (DU¨ V), which run over dedicated point-to-point circuits or limited networks,
and require the use of specialised hardware and software.

For the larger number of new links planned, it was felt to be desirable to move towards a network-
based architecture and the adoption of international telecommunications standards, enabling links to
be implemented in a more cost-effective manner, by reducing the number of connections at each
Centre and allowing the use of standard ‘off the shelf’ hardware and software.

This Eurocontrol Standard formalises and extends the Short Term ICD. The ST-ICD has been rewritten
to give a more rigorous specification that will improve interoperability and, in addition, is suitable to
form the basis of future ICDs to meet the evolving requirements for Flight Data Exchange (FDE),
including wider use of shared networks and the introduction of new lower layer standards. This
Eurocontrol Standard provides a minimum set of functionalities that can be supported by existing
OLDI implementations with minimal modifications, using either point-to-point links or Comité
Consultatif des Téléphones et Télégraphes (CCITT) Recommendation X.25, 1980 or later, packet-
switched networks. For procurement, more possibilities can be specified. This ICD does not prevent
agreements on a bilateral basis to go further.

Installations wishing to run other application protocols in addition to, or in place of the one described
in this document may either apply for amendment of the present protocol, or separate their protocol
using different virtual circuits.

2.

2.1.

SCOPE

This Eurocontrol Standard Document specifies a data communications interface for the exchange of
flight-related data messages between Area Control Centres (ACCs). It is presented in the form of
an Open Systems Interconnection (OSI) profile as defined in International Organisation for
Standardisation/International Electrotechnical Commission (ISO/IEC) Technical Report (TR) 10000-2
[Reference 3]. The profile covers both lower layers (T-profile) and upper layers (A-profile).

2.2.

This Eurocontrol Standard Document is applicable to the following scenarios:

— support of OLDI as described in Eurocontrol Standard No. 001-92 Edition 1;

— support of transmission of OLDI application messages from ACCs to the Central Flow Management

Unit (CFMU) systems.

2.3.

The Standard is applicable for connection using either:

— leased line point-to-point circuits, or

— Public Switched Telephone Network (PSTN) point-to-point circuits, or

— packet-switched data networks, or interconnected packet-switched data networks, that provide an

interface conforming to CCITT Recommendation X.25, 1980 or later.

NOTES

1. The arrangement between Flight Plan Processing Systems (FPPSs) is represented in Figure 1.

2. Figure 1 does not illustrate potential backup connections, such as PSTN, for which guidance is given in

Annex H.

L 254/178

EN

Official Journal of the European Communities

9.10.2000

FPPS
A

Message
Transfer
Protocol

(cid:1)(cid:2)(cid:3)(cid:4)(cid:5)(cid:6)(cid:7)(cid:8)(cid:4)

X.25 DTE-DTE

FPPS
B

Message
Transfer
Protocol

FPPS
C

Message
Transfer
Protocol

X.25 DTE-DCE

X.25 Network

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 Eurocontrol Standard.

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

Any revision of the referenced International Civil Aviation Organisation (ICAO) Documents shall be
immediately taken into account to revise this Eurocontrol Standard.

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

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

3.2.

References

1. ITU-T Recommendation X.25 (1993) (Rev. 1), Interface between data terminal equipment (DTE)
and data circuit-terminating equipment (DCE) for terminals operating in the packet mode and
connected to public data networks by dedicated circuit.

2. ISO/IEC TR 10000-1:1992, Information technology — Framework and taxonomy of International

Standardized Profiles: — Part 1: Framework (2nd edition).

3. ISO/IEC TR 10000-2:1994, Information technology — Framework and taxonomy of International

Standardized Profiles — Part 2: Principles and Taxonomy for OSI Profiles (3rd edition).

9.10.2000

EN

Official Journal of the European Communities

L 254/179

4. ITU-T Recommendation X.21 (1992) (Rev. 1), Interface between data terminal equipment (DTE)
and data circuit-terminating equipment (DCE) for synchronous operation on public data networks.

5. CCITT Recommendation X.21bis (1988), Use on public data networks of data terminal equipment

(DTE) which is designed for interfacing to synchronous V-Series modems.

6. ISO/IEC 7776:1994, Information technology — Telecommunications and information exchange
between systems — High-level data link control procedures — Description of the X.25 LAPB-
compatible DTE Data Link procedures (2nd edition).

7. ISO/IEC 8208:1993, Information Technology — Data communications — X.25 Packet Layer

Protocol for Data Terminal Equipment (3rd edition).

8. ISO/IEC ISP 10609-9:1992, Information technology — International Standardized Profiles TB, TC,
TD and TE — Connection-mode Transport Service over Connection-mode Network Service — Part
9: Subnetwork-type dependent requirements for Network Layer, Data Link Layer and Physical Layer
concerning permanent access to a packet-switched data network using virtual calls.

9. ISO/IEC 7498-1:1994,

Information technology — Open Systems Interconnection — Basic

Reference Model: The Basic Model (2nd edition).

10. ISO/IEC 8348:1993, Information technology — Open Systems Interconnection — Network

Service Definition (1st edition).

11. ISO/IEC 8072:1994, Information technology — Open Systems Interconnection — Transport

service definition (2nd edition).

12. ISO/IEC 8878:1992, Information Technology — Telecommunications and information exchange
between systems — Use of X.25 to provide the OSI connection-mode Network Service (2nd
edition).

13. Eurocontrol Standard for On-Line Data Interchange (OLDI), No. 001-92, Edition 1, 1992.

14. ISO/IEC 9646-1:1994, Information technology — Open Systems Interconnection — Conformance

testing methodology and framework — Part 1: General concepts (2nd edition).

15. Eurocontrol (Maastricht Upper Area Control (UAC) Systems Division) FDE ICD Part 1 Integration

Test Plan Version 1.0, dated 10 May 1996.

16. Eurocontrol FDE ICD Part 1 — Reliability, Availability and Security — Technical Report version

1.0, dated 20 April 1997.

17. ITU-T Recommendation X.32 (1993) (Rev. 1), Interface between DTE and DCE for terminals
operating in the packet mode and accessing a packet switched public data through a public
switched telephone network or an integrated services digital network or a circuit switched public
data network.

18. ITU-T Recommendation E.164 (1991) (Rev. 1), Numbering plan for the ISDN era.

19. ITU-T Recommendation X.75 (1993) (Rev. 1), Packet-switched signalling system between public

network providing data transmission service.

20. ITU-T Recommendation X.121 (1993), International numbering plan for public data networks.

4.

DEFINITIONS, SYMBOLS AND ABBREVIATIONS

4.1.

Definitions

4.1.1.

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

4.1.2.

Profile: A set of one or more base standards, and, where applicable, the identification of chosen classes,
subsets, options and parameters of those base standards, necessary for accomplishing a particular
function [Reference 2].

L 254/180

EN

Official Journal of the European Communities

9.10.2000

4.1.3.

Profile Requirements List (PRL): The profile requirements are expressed in the form of conformance
requirements and are arranged in a tabular list format [Reference 2].

4.1.4.

T-profile: Transport Profile providing a Connection mode Transport Service [Reference 3].

4.1.5.

A-profile: Application Profile requiring a Connection-mode Transport Service [Reference 3].

4.1.6.

Protocol Implementation Conformance Statement (PICS): A statement made by the supplier of an OSI
system, stating which capabilities have been implemented, for a given OSI protocol [Reference 14].

4.2.

Symbols and Abbreviations

For the purpose of this Eurocontrol Standard Document, the following symbols and abbreviations are
used:

ACC

AFI

ASCII

ATC

ATCC

Area Control Centre

Authority and Format Identifier

American Standard Code for Information Interchange

Air Traffic Control

Air Traffic Control Centre

CAUTRA

Coordinateur Automatique du Trafic Aérien

CCITT

CFMU

CUG

DCE

DCTS

DSP

DTE

DU¨ V

FDE

FEP

FPDE

FPPS

ICAO

ICD

IDI

IDP

IEC

Comité consultatif international télégraphique et téléphonique (now ITU-T)

Central Flow Management Unit

Closed User Group

Data Circuit-terminating Equipment

Digital Communications Terminal System

Domain Specific Part

Data Terminal Equipment

Datenübertragungs- und Verteilungssystem

Flight Data Exchange

Front-End Processor

Flight Plan related Data Exchange

Flight Plan Processing System

International Civil Aviation Organisation

Interface Control Document

Initial Domain Identifier

Initial Domain Part

International Electrotechnical Commission

INTERCAUTRA

Inter-CAUTRA protocol

ISO

ITU-T

ISDN

International Organization for Standardization

International Telecommunication Union — Telecommunication Standardization
Sector

Integrated Services Digital Network

9.10.2000

EN

Official Journal of the European Communities

L 254/181

LAPB

LSB

M, m

MSB

MT

NA

NS

NSAP

NSDU

Link Access Procedure Balanced

Least Significant Bit

Mandatory

Most Significant Bit

Message Transfer

Not Applicable

Network Service

Network Service Access Point

Network Service Data Unit

O, O.<n>

o, o.<n>

Optional, where <n> is a numeral for referencing

Optional, where <n> is a numeral for referencing

OLDI

OSI

PICS

PLP

PRL

PSTN

ST-ICD

SUT

T<x>

TA

TSDU

TPDU

TR

X

x

On-Line Data Interchange

Open Systems Interconnection

Protocol Implementation Conformance Statement

Packet Layer Protocol

Profile Requirements List

Public Switched Telephone Network

Short Term Interface Control Document

System Under Test

Timer (where <x> is a single or double letter for referencing)

Terminal Adaptor

Transport Service Data Unit

Transport Protocol Data Unit

ISO Technical Report

Prohibited

Excluded

<item>:

Conditional Item (dependent on the value of item)

4.3.

Notations

4.3.1.

4.3.2.

4.3.3.

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.

For the purpose of this Eurocontrol Standard Document, the hexadecimal representation of a bit
sequence is formed by taking 4 bits at a time from the most significant bit (MSB) to the least significant
bit (LSB).

NOTE Unless otherwise specified in the referred international Standards, a sequence of bits is transmitted from

MSB to LSB.

For the purpose of this Eurocontrol Standard Document, the status of the support for features of a
base standard, or this Eurocontrol Standard, shall be shown in upper case (e.g. M, O, O.<n>, X). The
exact meaning of each status symbol is described in the Annexes of this Eurocontrol Standard prior to
their use.

L 254/182

EN

Official Journal of the European Communities

9.10.2000

4.3.4.

For the purpose of defining the FDE ICD Part 1 profile in this Eurocontrol Standard Document, the
status of the support for features of a base standard or this Eurocontrol Standard, shall be shown in lower
case (e.g. m, o, o.<n>, x).

NOTE The result is a further refinement of the features of the base standards that areconditional, optional, or

value dependent (see E.3.1).

5.

TECHNICAL OVERVIEW

5.1.

Protocol Stack

NOTE The protocol stack for the profile of this Eurocontrol Standard is illustrated in Figure 2. The figure places
the protocols in the framework of the OSI Basic Reference Model [Reference 9] by aligning the stack
with the corresponding OSI layers. However, the protocol stack is a specification for pre-OSI systems and
it does not support the many functions that are allowed in the OSI protocols of the corresponding OSI
layers.

OSI Layers(cid:3)

Protocol Stack(cid:3)

References(cid:3)

7 

6 

5 

4 

3 

2 

1(cid:3)

(cid:1)(cid:2)(cid:3)(cid:3)(cid:4)(cid:5)(cid:2)(cid:3) 
(operational, operator and status)(cid:3)

Message Transfer Protocol (1)(cid:3)
Message Header Protocol (2)(cid:3)

Network Protocol using(cid:3)
X.25 Packet Layer Protocol(cid:3)

LAPB Single Link Protocol(cid:3)

X.21(cid:3)

X.21bis(cid:3)

Annex A(cid:3)

Annex B(cid:3)

Annex C(cid:3)
ISO/IEC 8208(cid:3)

ISO/IEC 7776(cid:3)

ITU-T Recommendations 
X.21 and X.21bis(cid:3)

NOTES 
(cid:1)(cid:2)(cid:3) (cid:1)(cid:2)(cid:3)(cid:4) (cid:5)(cid:3)(cid:6)(cid:6)(cid:7)(cid:8)(cid:3)(cid:4) (cid:1)(cid:9)(cid:7)(cid:10)(cid:6)(cid:11)(cid:3)(cid:9)(cid:4) (cid:12)(cid:9)(cid:13)(cid:14)(cid:13)(cid:15)(cid:13)(cid:16)(cid:4) (cid:17)(cid:7)(cid:18)(cid:3)(cid:6)(cid:4) (cid:19)(cid:6)(cid:3)(cid:4) (cid:13)(cid:11)(cid:4) (cid:6)(cid:20)(cid:6)(cid:14)(cid:3)(cid:17)(cid:4) (cid:17)(cid:3)(cid:6)(cid:6)(cid:7)(cid:8)(cid:3)(cid:6)(cid:4) (cid:21)(cid:2)(cid:22)(cid:15)(cid:2)(cid:4) (cid:2)(cid:7)(cid:23)(cid:3)(cid:4) (cid:14)(cid:2)(cid:3)(cid:4) (cid:6)(cid:7)(cid:17)(cid:3)

(cid:8)(cid:3)(cid:10)(cid:3)(cid:9)(cid:7)(cid:16)(cid:4)(cid:11)(cid:13)(cid:9)(cid:17)(cid:4)(cid:7)(cid:6)(cid:4)(cid:14)(cid:2)(cid:3)(cid:4)(cid:13)(cid:14)(cid:2)(cid:3)(cid:9)(cid:4)(cid:7)(cid:24)(cid:24)(cid:16)(cid:22)(cid:15)(cid:7)(cid:14)(cid:22)(cid:13)(cid:10)(cid:4)(cid:17)(cid:3)(cid:6)(cid:6)(cid:7)(cid:8)(cid:3)(cid:6)(cid:2)(cid:3)

(cid:4)(cid:2)(cid:3)(cid:3) (cid:1)(cid:2)(cid:3)(cid:4)(cid:5)(cid:3)(cid:6)(cid:6)(cid:7)(cid:8)(cid:3)(cid:4)(cid:25)(cid:3)(cid:7)(cid:26)(cid:3)(cid:9)(cid:4)(cid:12)(cid:9)(cid:13)(cid:14)(cid:13)(cid:15)(cid:13)(cid:16)(cid:4)(cid:7)(cid:15)(cid:14)(cid:6)(cid:4)(cid:7)(cid:6)(cid:4)(cid:7)(cid:4)(cid:17)(cid:22)(cid:10)(cid:22)(cid:17)(cid:7)(cid:16)(cid:4)(cid:14)(cid:9)(cid:7)(cid:10)(cid:6)(cid:24)(cid:13)(cid:9)(cid:14)(cid:4)(cid:16)(cid:7)(cid:20)(cid:3)(cid:9)(cid:2)(cid:3)

Figure 2

Profile Protocol Stack

5.2.

Structure of the Profile

NOTES

1. As shown in Figure 2, the profile stack combines several lower layer protocols, of which only the X.25 Packet
Layer Protocol (PLP) [Reference 1] and its supporting protocols, X.21 [Reference 4] and X.21bis [Reference
5], are defined in existing ISO/IEC and International Telecommunication Union-Telecommunication
Standardization Sector (ITU-T) standards. The other higher layer protocols are defined in Annexes (Annexes
A, B and C) in this Eurocontrol Standard Document.

2. Conformance requirements for the profile can refer to these specifications on an equal footing with external
standards and are stated in Section 6. The detailed requirements are stated using the tabular format of PRLs
(Annex E) and PICS proformas (proformas for protocols defined in the Annexes are given in Annex D). The
use of these PRLs and PICS proformas in development and/or procurement is explained in Annex E.

 
 
 
 
 
 
9.10.2000

EN

Official Journal of the European Communities

L 254/183

5.3.

Relation to Previous Versions of the Specification

NOTES

1. This profile is based on the ST-ICD developed by the former OLDI Technical Sub-Group. The protocols and
packet formats defined in this Eurocontrol Standard Document are a compatible subset of those of the
ST-ICD with the exception that this Eurocontrol Standard makes more detailed requirements on the use of the
X.25 PLP, includes mandatory support of the M-bit and corrects the inconsistent specification of the Authority
and Format Identifier (AFI) value in the Network Service Access Point (NSAP) address.

2. The main change in the style of this Eurocontrol Standard Document relates to the structure of the ICD
specification. The Message Transfer Protocol (Annex A) is separated from the supporting T-profile. This will
facilitate the use of other T-profiles as this becomes necessary to support evolving FDE requirements.

3. Those parts of the ST-ICD specification dealing with control of X.25 virtual circuits and delimiting application
messages are now found in the Message Header Protocol (Annex B), which constitutes a minimal transport
layer for FDE.

6.

PROFILE REQUIREMENTS

6.1.

Conformance Requirements

6.1.1.

6.1.2.

An implementation claiming conformance to this specification shall meet the requirements laid down
in sections 6.2 and 6.3 below.

A claim of conformance shall be supported by a Profile Implementation Conformance Statement as
described in and Annex D and Annex E.

6.2.

Upper-layer Requirements

6.2.1.

A conforming implementation shall satisfy the requirements of the base standard, given at Annex A.

6.2.2.

A conforming implementation shall satisfy the constraints given in the Profile Requirements List at
Annex E.7.

6.3.

Lower-layer Requirements

6.3.1.

Transport Layer Requirements

6.3.1.1.

A conforming implementation shall satisfy the requirements of the base standard, given at Annex B.

6.3.1.2.

6.3.1.3.

A conforming implementation shall satisfy the constraints given in the Profile Requirements List at
Annex E.8.1.

A conforming implementation shall satisfy the requirement of supporting Transport Service Data Unit
(TSDU) sizes of up to and including 4 097 octets.

NOTE The first octet of the TSDU corresponds to a field of the Message Header (see and A.4.10, B.4.4),

leaving a maximum of 4 096 octets for user data.

6.3.2.

Network Layer Requirements

6.3.2.1.

6.3.2.2.

A conforming implementation shall satisfy the requirements of ISO/IEC 8208 [Reference 7] in
accordance with the protocol mapping given at Annex C.

A conforming implementation shall satisfy the constraints given in the Profile Requirements List at
Annex E.8.2.

L 254/184

EN

Official Journal of the European Communities

9.10.2000

6.3.2.3.

A conforming implementation shall, if data terminal equipment (DTE)-DTE operation is supported, be
capable of configuring by system management mechanisms the choice of DTE or data circuit-
terminating equipment (DCE) role for the DTE-DTE operation.

6.3.2.4.

A conforming implementation shall, in either role defined by 6.3.2.3, be capable of initiating a
connection according to the specification of Annex C i.e. the protocol is totally symmetric.

NOTE Some existing implementations based on the ST-ICD, may not be able to initiate network connections

according to the protocol of Annex C.

6.3.2.5.

A conforming implementation shall agree for a period of time to the facility of Non-standard Default
Packet Sizes, with the value 256 for both directions of transmission.

6.3.2.6.

A conforming implementation shall use NSAP addresses as defined in Annex C.

6.3.2.7.

A conforming implementation shall set the D-bit to 0 in CALL REQUEST, CALL ACCEPTED and
DATA packets.

NOTE Setting D=0 in CALL REQUEST and CALL ACCEPTED packets has the effect of not using Delivery

Confirmation.

6.3.3.

Datalink Layer Requirements

6.3.3.1.

6.3.3.2.

A conforming implementation shall satisfy the conformance requirements of ISO/IEC 7776 [Reference
6] for the Link Access Protocol Balanced (LAPB) Single Link Protocol.

A conforming implementation shall also satisfy the constraints given in the Profile Requirements List
at Annex E.8.3.

6.3.4.

Physical Layer Requirements

A conforming implementation shall satisfy the conformance requirements of ISO/IEC ISP 10609-9
clause 7 [Reference 8].

7.

TEST METHODS

NOTES

1. An approach to conformance testing of implementations of this specification is outlined in Annex F.

2. The use of the PRLs and PICS proformas provided with this specification to document conformance is outlined

in Annex E.

9.10.2000

EN

Official Journal of the European Communities

L 254/185

ANNEX A (Normative)

MESSAGE TRANSFER PROTOCOL

A.1.

Introduction

This specification defines a protocol to implement a simple message transfer service for applications
that require flight data exchange.

A.2.

Service Implemented

The Message Transfer (MT) protocol implements the following unconfirmed services:

MT-Associate: establish an application message transfer association;

MT-Data: transfer an application message consisting of American Standard Code for Information
Interchange (ASCII) characters;

MT-Abort: terminate an application message transfer association.

A.3.

Service Assumed

This Message Transfer protocol assumes a subset of the Connection-mode Transport Service as defined
in ISO/IEC 8072 [Reference 11], such as that offered by the protocol defined in of this Eurocontrol
Standard.

A.4.

Protocol Specification

A.4.1.

Introduction

In the following text, only the operation of one application initiated Message Transfer association is
described. Further associations may be supported on the same network interface, by repeating these
procedures for each underlying transport connection.

A.4.2.

Types of Data

This Annex identifies four types of application messages that are equivalent to those defined in
Eurocontrol Standard No 001-3-92 Edition 1:

System Messages: These messages shall be used for link monitoring (HEARTBEAT message) and
application control (STARTUP and SHUTDOWN messages).

Operational Messages: These messages shall be linked to a specific operational context and are defined
in the Eurocontrol Standards and Documents that make use of this Standard for data interchange.
Eurocontrol Standard Document for On-Line Data Interchange defines operational messages such as
the Activation (ACT), Advanced Boundary Information (ABI), Logical Acknowledgement (LAM)
messages.

Operator Messages: These messages shall contain free text. Their use shall be bilaterally agreed. For
example, they may be used to exchange test information or to inform the other side about operator
actions.

Status Messages: The use and the contents of these messages shall be bilaterally agreed. For example,
they may be used to exchange system management information.

NOTES

1. The use of System messages is part of the operation of this protocol and their format is specified in

paragraph A.4.10.3 of this Annex.

L 254/186

EN

Official Journal of the European Communities

9.10.2000

2. The use and format of Status messages are subject to bilateral agreement, and are not further specified in this

Eurocontrol Standard.

3. The state of the protocol determines which types of messages can be transmitted, as specified in the following

paragraphs.

A.4.3.

Association Establishment

A.4.3.1.

The protocol is initially in the IDLE state.

A.4.3.2.

The MT-Associate-Request primitive is executed to establish an application association and bring the
protocol into the DATA–READY state. The primitive has to be invoked by both the local and remote
applications.

A.4.3.3.

It is first necessary to establish an underlying transport connection, following the T-connect primitive
procedures described in Annex B paragraph B.4.1, after which the protocol enters the READY state.
At this stage only System messages (and possibly, by bilateral agreement, Operator messages) can be
transferred. To transfer a System or Operator message, the sender uses the T-Data primitive (see B.4.4),
with the message as parameter.

A.4.3.4.

A STARTUP message (system message) shall then be transmitted, timer Tr (see A.4.7) shall be started,
and the protocol enters the ASSOCIATION–PENDING state. If timer Tr expires while the protocol is
still in this state, the STARTUP message shall be retransmitted and the timer shall be restarted.

NOTE The protocol will remain in the ASSOCIATION–PENDING state until a STARTUP message is

received. Continuous time-outs of the Tr timer could be signalled locally.

A.4.3.5.

Receipt of the STARTUP message shall cause the following actions:

— in the ASSOCIATION–PENDING state, a further STARTUP message is transmitted, the protocol

enters the DATA–READY state and the MT-Associate-Indication primitive is signalled;

— in any other state, the message is ignored.

A.4.3.6.

Receipt of the STARTUP message in state ASSOCIATION–PENDING corresponds to either:

— the remote application issued a MT-Associate-Request primitive and its Message Transfer protocol

has entered the ASSOCIATION–PENDING state, or

— the remote Message Transfer protocol is responding to a previously received STARTUP message

and has entered the DATA–READY State.

NOTE This uncertainty occurs because the same message is used for STARTUP and for response to STARTUP.
As a result, the Message Transfer protocol that first entered the DATA–READY state will receive a
further STARTUP message. As specified in A.4.3.5, this STARTUP message is ignored.

A.4.3.7.

Once STARTUP messages have been exchanged, the association is established and all the identified
types of messages can be transferred (DATA–READY state).

A.4.4.

Data Transfer

Other types of messages are transferred in the same way as System messages, using the T-Data service,
with the message as parameter. This corresponds to the MT-Data-Request and the MT-Data-Indication
service primitives.

9.10.2000

EN

Official Journal of the European Communities

L 254/187

NOTE Each message is sent as a single TSDU: there is no concatenation or segmentation of messages at this

level.

A.4.5.

Orderly Association Release

A.4.5.1.

The Message Transfer association between two applications can be cleared by either one. This
corresponds to the MT-Abort-Request service primitive.

A.4.5.2.

The following actions shall be taken:

— in the DATA–READY state, a SHUTDOWN message (system message) shall be transmitted, timers

Tr and Ts shall be stopped, and the transport connection shall be released;

— in the ASSOCIATION–PENDING state, a SHUTDOWN message (system message) shall be

transmitted, timer Tr shall be stopped, and the transport connection shall be released;

— in the READY state the transport connection shall be released;

— otherwise no action is taken.

NOTE The SHUTDOWN message is not an early warning — the association is terminated immediately. There

is no confirmation of this message from the other side.

A.4.5.3.

Receipt of a SHUTDOWN message shall cause the following actions:

— in the DATA–READY state, timer Ts (see A.4.7) shall be stopped, MT-Abort-Indication is signalled
and the interface enters the ASSOCIATION–PENDING state without sending a STARTUP message;

— in any other state, no action is taken.

A.4.6.

Association Re-establishment

The application which initiated the clearing of the association has the responsibility, when it is ready,
for re-establishing the application association and any lower levels (if necessary).

NOTE If the clearing of the association has resulted in the release of the underlying network connection, the

association establishment procedure specified in paragraph A.4.3 must be followed.

A.4.7.

Association Integrity

A.4.7.1.

The integrity of the association between two applications is provided by the idle heartbeat facility.

A.4.7.2.

On entering the DATA–READY state and on transmitting any type of message on the transport
connection, a configurable timer Ts shall be (re)started. If the timer Ts expires in the DATA–READY
state, a HEARTBEAT message (System message) shall be transmitted (and the timer shall be restarted).

A.4.7.3.

Similarly, on entering the DATA–READY state and on receiving any message except a STARTUP
message on the connection, a configurable timer Tr shall be (re)started. If the timer Tr expires in the
DATA–READY state, MT-Abort-Indication is signalled, the transmission of all messages is stopped,
timer Ts is stopped and the timer Tr is restarted. The interface is in the ASSOCIATION–PENDING
state.

NOTE The applications will recover and resynchronise through the exchange of STARTUP messages (see A.4.3).

L 254/188

EN

Official Journal of the European Communities

9.10.2000

A.4.8.

Disorderly Association Release

A.4.8.1.

There can be an abnormal association release if:

— the transport connection fails (e.g. line failure, protocol error),

— one of the two applications or systems fails (this could be due to hardware or software failure; in

some cases, the underlying transport connection can still be working).

NOTE Following the definition of the transport procotol in Annex B, there is no end-to-end transport connection.
As a result, failure of the transport connection is a direct result of the network connection failure.

A.4.8.2.

An application or system failure can be detected by the expiry of a time-out for the receipt of an
expected HEARTBEAT message (see A.4.7) from this application.

A.4.9.

Recovery From Failure

A.4.9.1.

Two cases have to be considered:

— after a transport connection failure;

— after an application failure.

A.4.9.2.

In both cases, the re-establishment involves the normal association establishment procedure (see
A.4.3), including exchange of STARTUP messages.

NOTE In the event of a failure at the application level that does not cause the underlying connection to be
released, the failed system may transmit a SHUTDOWN message (i.e. L–shutdown invoked either
manually or as part of the application logic) before attempting to restart the link. This will curtail the
remote application’s time-out Tr and may result in a quicker recovery with less chance of lost data.

A.4.10.

Message Formats

A.4.10.1.

G e n e r a l M e s s a g e S t r u c t u r e

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
representation 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
octet 1

Message Body
octet 2 ... octet n

A.4.10.2.

M e s s a g e B o d y L e n g t h

Message bodies of length up to and including 4 096 octets shall be supported.

A.4.10.3.

S y s t e m M e s s a g e F o r m a t s

System messages are coded with TYP = 4, encoded as '44'H. The 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").

9.10.2000

EN

Official Journal of the European Communities

L 254/189

A.4.10.4.

O t h e r M e s s a g e F o r m a t s

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 State Transition Tables

A.5.1.

Introduction

The state tables given below are the definitive specification of the protocol. In case of discrepancy with
the main text above, the specification below shall prevail.

NOTE The notation used to describe states, events, timers and actions are based on the ST-ICD. However, the
following definitions and resulting actions have been reviewed and may differ from the ST-ICD.

A.5.2.

State Definitions

Table 1

State Definitions

State

State Description

Additional State Information

state 0

state 1

state 2

state 3

IDLE

READY

No transport connection

Transport connection established, local
user down, remote user down

ASSOCIATION–PENDING

Transport connection established, local
user up, remote user down

DATA–READY

Local user up, remote user up

L 254/190

EN

Official Journal of the European Communities

9.10.2000

A.5.3.

Possible Events

Table 2

Possible Events

Event Description

Additional State Information

L–data

L–shutdown

L–startup

R–data

R–heartbeat

R–shutdown

R–startup

Ts–timeout

Tr–timeout

Indication that data (Operational, Operator, or Status message) is to be sent
from the local to the remote user (MT-Data Request primitive)

A command is given to stop the local user (MT-Abort Request)

A command is given to start the local user (MT-Associate Request)

Indicates that data has been received from the remote user (T-Data
Indication, TYP =/ ‘System’)

A HEARTBEAT message is received from the remote user (T-Data
Indication, TYP = ‘System’, Message code = HEARTBEAT)

A SHUTDOWN message is received from the remote user (T-Data
Indication, TYP = ‘System’, Message code = SHUTDOWN)

A STARTUP message is received from the remote user (T-Data Indication,
TYP = ‘System’, Message code = STARTUP)

Expiry of timer Ts

Expiry of timer Tr

TC–disconnect

A Transport connection release indication has been received (T-Disconnect
Indication)

TC–setup

(e.g. explicit command, application request) which causes a

Event
T-Connect Request primitive

A.5.4.

Timers

Table 3

Timers

Timer

Timer information

Tr

Ts

Time-out when a HEARTBEAT or a data message is expected

Time-out for sending a HEARTBEAT to the remote user

The value of these timers shall be such that Tr = 2Ts + transit time.

NOTE Typical values of these timers are: Ts = 30s, Tr = 70s.

9.10.2000

EN

Official Journal of the European Communities

L 254/191

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 noti-
fied (1)

state 1

TC–disconnect

The system takes appropriate actions but
remains in state 0

state 0

Ignored

state 0

Ignore (event should not happen)

state 0

L–data
L–shutdown
L–startup
Tr–timeout
Ts–timeout

R–data
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

L–data
R–data
R–heartbeat
R–shutdown
TC–setup

Tr–timeout
Ts–timeout

L–shutdown

TC–disconnect

state 2

R–startup

state 1

state 1

state 1

state 0

state 0

state 3

The local user receives a STARTUP message
from the remote user, this STARTUP message
is ignored since an L–startup event has not
occurred

Ignored

Ignored

The transport connection is cleared

The local user is notified that the transport
connection is disconnected (e.g. due to an
error or a remote shutdown)

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 association and the reception
of the STARTUP message is explicitly notified
by replying with another STARTUP mess-
age (3)

Tr–timeout

The local user retransmits a STARTUP mess-
age if it did not receive a STARTUP message
from the remote user within a specified time
period Tr, timer Tr is restarted

state 2

L 254/192

EN

Official Journal of the European Communities

9.10.2000

State

Event

Actions to be Taken

New State

L–startup
L–data
R–data
R–heartbeat
R–shutdown
Ts–timeout
TC–setup

L–shutdown

TC–disconnect

state 3

L–data

R–data
R–heartbeat

R–startup

Ts–timeout

L–startup
TC–setup

R–shutdown

Tr–timeout

L–shutdown

TC–disconnect

Ignored

state 2

The local user is directed to shut down
the association: a SHUTDOWN message is
timer Tr is stopped and the
transmitted,
transport connection is released

The local user is notified that the transport
connection is disconnected (e.g. due to an
error), timer Tr is stopped and the association
is aborted

Timer Ts is restarted

Timer Tr is restarted

If a STARTUP message is received from the
remote user, it is considered as an acknowl-
edgement of a previously sent STARTUP
message; timer Tr is not restarted

state 0

state 0

state 3

state 3

state 3

A HEARTBEAT message is sent and timer Ts
is restarted

state 3

Ignored

state 3 (4)

Timer Ts is stopped; MT-Abort-Indication is
signalled to the local user

state 2

Timer Ts is stopped. MT-Abort-Indication is
signalled to the local user; timer Tr is restarted

state 2

A SHUTDOWN message is transmitted; timers
Tr and Ts are stopped and the transport
connection is released

The local user is notified that the transport
connection is disconnected (e.g. due to an
error); timers Tr and Ts are stopped and the
association is aborted

state 0

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

A.5.6.

State Transition Diagram

NOTE The protocol is described in Figure A.1 in the form of a state transition diagram. The diagram is only
informative: in case of conflict between the diagram and the state tables above, the latter shall take
precedence.

9.10.2000

EN

Official Journal of the European Communities

L 254/193

Figure A.1

Message Transfer Protocol: State Transition Diagram

L 254/194

EN

Official Journal of the European Communities

9.10.2000

ANNEX B (Normative)

MESSAGE HEADER PROTOCOL

B.1.

Introduction

This Annex defines the Message Header protocol, a minimal transport protocol to be used for
applications such as OLDI.

B.2.

Service Implemented

B.2.1.

The Message Header protocol corresponds to a subset of the Connection-mode transport Service, as
defined in ISO/IEC 8072 [Reference 11], comprising the following service primitives.

T-Connect: establish a transport connection for an application

T-Data: transfer ASCII data

T-Disconnect: terminate the transport connection of an application

B.2.2.

The service does not support multiplexing, error recovery, or segmentation and reassembly.

B.3.

Service Assumed

The protocol assumes a reliable basic network service as provided by the X.25 Packet Layer Protocol.

NOTE Only a single transport connection is supported on each network connection.

B.4.

Protocol Specification

B.4.1.

Connection Establishment

The T-Connect primitive shall be implemented by using the N-Connect service of the underlying
network service. There is a direct mapping between the two sets of (request, indication) primitives.
Alternatively, an existing network connection may be used (e.g. one established by system management
mechanisms).

Recommendations

1. In the latter case above the network connection should be reset before use. The N-Connect primitive may be

reissued automatically if no response has been received within a certain time.

2. If this automatic retry is implemented, retries should be attempted approximately every 15s.

B.4.2.

Avoidance of Redundant Network Connections

If an N-Connect-Request primitive is outstanding (i.e. no corresponding N-Connect-Confirm or
N-Disconnect primitive has been signalled) and an N-Connect-Indication is signalled, then the incoming
network establishment attempt shall be rejected or cleared, by responding with an N-Disconnect-
Request primitive, only when both the following conditions apply:

9.10.2000

EN

Official Journal of the European Communities

L 254/195

— the calling NSAP address of the N-Connect-Indication is the same as the called NSAP address of

the outstanding N-Connect-Request;

— the calling NSAP address of the outstanding N-Connect-Request is greater than the called NSAP
address of the outstanding N-Connect-Request, the comparison being made on the bit strings
formed by the preferred binary encoding of each NSAP address, as defined in ISO/IEC 8348
Annex A [Reference 10] (a string shall be considered greater than any of its proper initial substrings,
e.g. '8800'H > '88'H).

B.4.3.

Connection Release

B.4.3.1.

Connection release shall use the N-Disconnect and N-Reset service primitives of the underlying network
service.

B.4.3.2.

To implement a T-Disconnect-Request, an N-Disconnect-Request shall be signalled. Alternatively, if the
establishment of network connections using N-Connect primitives is not supported, the network
connection shall not be explicitly released.

Recommendation In the latter case, above the network connection should be reset.

B.4.3.3.

A T-Disconnect-Indication shall be signalled on the receipt of either of the following network service
primitives on a network connection corresponding to a wholly or partly established transport
connection:

— N-Disconnect-Indication;

— N-Reset-Indication.

B.4.4.

Data Transfer

B.4.4.1.

The T-Data primitive shall be implemented by using the N-Data primitive of the underlying network
service. There is a direct mapping between the two sets of (request, indication) primitives. The mapping
uses a Transport Protocol Data Unit (TPDU) which is transferred by the network service.

B.4.4.2.

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.

LENG ADEST DEST AEMM EMM data(1) ADR
'40'H
'40'H
'48'H

'40'H

'40'H

'40'H

data(2) ... data(n)

ETX
'03'H

STX
'02'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 ADR with values other than '40'H is beyond the

scope of this Eurocontrol Standard Document, but may be subject to bilateral agreement.

B.4.4.3.

The T-Data service shall be restricted to the transfer of printable ASCII character data. In particular,
none of the data octets shall have the value '03'H (the character ETX).

B.4.4.4.

A conforming implementation shall satisfy the requirement of supporting Network Service Data Unit
(NSDU) sizes of up to and including 4 105 octets.

L 254/196

EN

Official Journal of the European Communities

9.10.2000

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.

9.10.2000

EN

Official Journal of the European Communities

L 254/197

ANNEX C (Normative)

NETWORK PROTOCOL

C.1.

Introduction

This Annex specifies a basic Network Protocol using the X.25 packet layer protocol, for use in both
point-to-point and packet-switched network environments, to support the transfer of flight data. The
protocol subset is compatible with that defined in versions of [Reference 1] from the 1980 edition on.

C.2.

Service Provided

C.2.1.

The protocol implements the connection-mode OSI Network Service as defined in ISO/IEC 8348
[Reference 10], with the following exceptions.

— NSAP addresses are restricted to the form defined in ;

— there is no facility for establishing agreement between the Network Service (NS) users and the NS

provider on the quality of service associated with a network connection;

— transfer of NS-User-Data during network connection establishment and release is not supported

except for provisions described in C.5.3.

C.2.2.

The following NS provider-options are not offered:

— Receipt Confirmation;

— Expedited Data Transfer.

C.3.

Service Assumed

The protocol assumes the provision of an OSI Datalink Service, such as that offered by ISO/IEC 7776
(LAPB) [Reference 6].

C.4.

NSAP Addressing

C.4.1.

Introduction

C.4.1.1.

The structure of the NSAP addresses follows that defined in ISO/IEC 8348 Annex A [Reference 10], as
illustrated below.

← 

IDP 

→ 

← 

DSP 

→ 

AFI 

IDI 

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

 
 
 
L 254/198

EN

Official Journal of the European Communities

9.10.2000

C.4.2.

NSAP Address Structure

C.4.2.1.

For the purpose of this Eurocontrol Standard Document, the address components shall be limited to
the following form.

C.4.2.2.

The AFI value 48 shall be used, indicating a Local format IDI with decimal abstract syntax.

C.4.2.3.

The IDI is null, following the Local format.

C.4.2.4.

The DSP shall consist of 2 pairs of decimal digits, as follows:

— the first pair is an Air Traffic Control (ATC) unit identifier, which identifies an ATC system and

thus indirectly a location;

— the second pair is an ATC unit selector, which may be used to identify a particular end point within

an ATC unit.

C.4.2.5.

The resulting NSAP address structure is illustrated below.

AFI

48

DSP

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 each ATC system will be the responsibility of Eurocontrol,
while ATC unit selectors will be assigned by the relevant authority within the ATC Administration or
Organisation.

C.4.3.2.

The allocation of ATC unit identifiers at the time of preparing this Standard is shown in

C.5.

Protocol Specification

C.5.1.

Overview

The protocol is based on the Subnetwork-Dependent Convergence Protocol for X.25(1980) defined in
of ISO/IEC 8878 [Reference 12], with the following differences:

— the Fast Select user facility is not used; however, the encoding defined in Annex A of ISO/IEC 8878
[Reference 12] for use with the extended format User Data field available with the Fast Select
facility is used here with the basic format User Data field in CALL REQUEST and INCOMING CALL
packets, since restrictions on the allowed network service parameters ensure that the encoded
information fits into 16 octets;

— of the network service parameters for which encodings are defined in ISO/IEC 8878 [Reference
12], only the called and calling NSAP addresses (and only in the form defined in ) are sent in the
CALL REQUEST packet;

— the User Data field is not used in the CALL ACCEPTED, CALL CONNECTED, CLEAR REQUEST, or

CLEAR INDICATION packets;

— the alternative procedures for network connection establishment and release are not used;

— receipt confirmation using the D-bit is not supported.

NOTE The first three of these restrictions ensure that all information which will be transmitted between two

DTEs will respect the limitations of the User Data field in X.25 (1980) PLP.

9.10.2000

EN

Official Journal of the European Communities

L 254/199

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 Description

High Order Semi-Octet

Low Order Semi-Octet

Octet 0: Protocol identity

Octet 1: Message code type

Octet 2: Message code value (N CR)

Octet 3: Parameter type = Called NSAP

Octet 4: Parameter length

bin(1000)

bin(0010)

bin(0000)

bin(1100)

bin(0000)

Octet 5: Parameter value (1st octet) = AFI value

bin(0100)

bin(0100)

bin(0000)

bin(0001)

bin(1001)

bin(0110)

bin(1000)

Octet 6: Parameter value (2nd octet) = ATC unit
identifier

high order digit

low order digit

Octet 7: Parameter value (3rd octet) = ATC unit selector

high order digit

low order digit

Octet 8: Parameter type = Calling NSAP

Octet 9: Parameter length

bin(1100)

bin(0000)

Octet 10: Parameter value (1st octet) = AFI value

bin(0100)

bin(1011)

bin(0110)

bin(1000)

Octet 11: Parameter value (2nd octet) = ATC unit
identifier

high order digit

low order digit

Octet 12: Parameter value (3rd octet) = ATC unit
selector

high order digit

low order digit

Octet 13: Reserved for future use

Octet 14: Reserved for future use

Octet 15: Reserved for future use

bin(0000)

bin(0000)

bin(0000)

bin(0000)

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.

D T E A d r e s s e s

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.

L 254/200

EN

Official Journal of the European Communities

9.10.2000

NOTES

1. The called DTE address, if present, in an INCOMING CALL packet, if present, may optionally also be

validated against a list (typically of one item) of valid local DTE addresses for the system.

2. In some instances the DTE address of a unit may differ in value and/or length when the unit is acting as the
calling or called system. Therefore, particular attention must be given to this issue when specifying or
implementing the DTE address validation functionality

C.5.4.2.

N S A P A d r e s s e s

The calling NSAP address encoded as described above in an INCOMING CALL packet shall be validated
against a local list of valid remote NSAP addresses for the system. If an invalid address should be
detected, the call shall be cleared.

NOTE The called NSAP address may optionally also be validated against a list of (typically of one item) valid

local NSAP addresses for the system.

C.5.5.

Data Transfer

C.5.5.1.

As described in ISO/IEC 8878 Annex A.5.3 [Reference 12], NSDUs are transferred in the User Data
field of a DATA packet.

NOTE As a consequence, it is prohibited to transmit more than one user message, such as an OLDI message,

per X.25 packet or M-bit sequence.

C.5.5.2.

NSDUs longer than the maximum User Data allowed for the virtual circuit shall be segmented and
transmitted in the User Data fields of a sequence of DATA packets where all except the last shall have
both maximum length and the M-bit set (i.e. a More-bit-sequence).

C.5.5.3.

On reception, the User Data fields of a More-bit-sequence shall be reassembled in order to form the
received NSDU.

9.10.2000

EN

Official Journal of the European Communities

L 254/201

ANNEX D (Normative)

PROFILE-SPECIFIC PICS PROFORMAS

D.1.

Introduction

D.1.1.

The supplier of a protocol implementation which is claimed to conform to the specifications in
Annexes A-C shall complete the following PICS proformas.

NOTE Copyright release for PICS proformas: users of this Eurocontrol Standard Document may freely
reproduce the PICS proformas in this Annex so that it can be used for the intended purpose and may
further publish the completed PICS.

D.1.2.

A completed PICS proforma is the PICS for the implementation in question. The PICS is a statement
of which capabilities and options of the protocol have been implemented.

D.1.3.

The PICS can have a number of uses, including use:

— by the protocol implementor, as a check-list to reduce the risk of failure to conform to the

standard through oversight;

— by the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication
of the capabilities of the implementation, stated relative to the common basis for understanding
provided by the standard PICS proforma;

— by the user, or potential user, of the implementation, as a basis for initially checking the possibility
of interworking with another implementation (note that, while interworking can never be
guaranteed, failure to interwork can often be predicted from incompatible PICSs);

— by a protocol tester, as the basis for selecting appropriate tests against which to assess the claim

for conformance of the implementation.

D.2.

Instructions for Completing the PICS Proformas

D.2.1.

General Structure of the PICS Proformas

D.2.1.1.

D.2.1.2.

The Implementation Identification and Protocol Summary is the first part of each PICS proforma and
shall be completed as indicated with the information necessary to identify fully both the supplier and
the implementation.

The main part of the PICS proforma is a fixed-format questionnaire. Answers to the questionnaire
items shall be provided in the rightmost column, either by simply marking an answer to indicate a
restricted choice (usually Yes or No), or by entering a value or a set or range of values.

NOTES

1. Each item is identified by a unique item reference in the first column; the second column contains the question
to be answered; the third column contains the reference or references to the material that specifies the item in
this Eurocontrol Standard. The remaining columns record the status of the item (whether support is
mandatory, optional, prohibited or conditional) and provide space for the answers: see also below.

2. A supplier may also provide, or be required to provide, further information categorised as either Additional
Information or Exception Information. When present, each kind of further information is to be provided in a
further subclause of items labelled A<i> or X<i> respectively for cross-referencing purposes, where <i> is any
unambiguous identification for the item (e.g. simply a numeral): there are no other restrictions on its format
and presentation.

D.2.1.3.

A completed PICS proforma, including any Additional Information and Exception Information, shall
be referred to as the Protocol Implementation Conformance Statement for the implementation in
question.

L 254/202

EN

Official Journal of the European Communities

9.10.2000

NOTE Where an implementation is capable of being configured in more than one way, a single PICS may be
able to describe all such configurations. However, the supplier has the choice of providing more than
one PICS, each covering some subset of the implementation’s configuration capabilities, in case that
makes for easier and clearer presentation of the information.

D.2.2.

Additional Information

Items of Additional Information allow a supplier to provide further information intended to assist the
interpretation of the PICS.

NOTES

1.

It is not intended or expected that a large quantity will be supplied, and a PICS can be considered complete
without any such information. Examples might be an outline of the ways in which a (single) implementation
can be set up to operate in a variety of environments and configurations; or a brief rationale (based perhaps
upon specific application needs) for the exclusion of features which, although optional, are nonetheless
commonly present in implementations of this protocol.

2. References to items of Additional Information may be entered next to any answer in the questionnaire, and

may be included in items of Exception Information.

D.2.3.

Exception Information

D.2.3.1.

It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited
status (after any conditions have been applied) in a way that conflicts with the indicated requirement.
No pre-printed answer will be found in the Support column for this: instead, the supplier shall write
the missing answer into the Support column, together with an X<i> reference to an item of Exception
Information.

D.2.3.2.

The supplier shall provide the appropriate rationale in the Exception item itself.

D.2.3.3.

An implementation for which an Exception item is required in this way does not conform to this
specification.

NOTE A possible reason for the situation described above is that a defect in the standard has been reported, a

correction for which is expected to change the requirement not met by the implementation.

D.2.4.

Conditional Items

D.2.4.1.

Individual conditional items are indicated by a conditional symbol of the form ‘<item>: 
’ 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.

NOTE A PICS proforma may contain a number of conditional items. These are items for which both the
applicability of the item itself, and its status if it does apply (mandatory, optional or prohibited) are
dependent upon whether or not certain other items are supported.

D.2.4.2.

If the item referenced by the conditional symbol is marked as supported, the conditional item is
applicable, and its status is given by ‘
’: the support column shall be completed in the usual way.
Otherwise, the conditional item is not relevant and the Not Applicable (NA) answer shall be marked.

D.2.4.3.

Each item whose reference is used in a conditional symbol is indicated by an asterisk in the Item
column.

9.10.2000

EN

Official Journal of the European Communities

L 254/203

D.3.

PICS Proforma for the Message Transfer Protocol

D.3.1.

Abbreviations and Special Symbols

D.3.1.1.

S t a t u s S y m b o l s

M: Mandatory

O: Optional

D.3.1.2.

I t e m R e f e r e n c e s

Items in the PICS proforma are identified by mnemonic item references. PICS items dealing with
related functions are identified by item references sharing the same initial letter or letter-pair (in
capitals). There follows a list of those initials, in the order in which the groups of items occur in the
PICS proforma.

— MTsy, MTop, MTst, Mtor

message types

— MAE, MAR, MCI, MDT, MAV

procedures

— MEsu, MEsd, MEhb, Mety

encodings

— MNmsg message

— Ts, Tr

size

timers

D.3.2.

Identification

Table 1

Message Transfer Implementation Identification

Supplier

Contact point for queries about the PICS

Implementation name/version

Machine name/version

Operating system name/version

Other hardware and operating systems claimed

System name (if applicable)

L 254/204

EN

Official Journal of the European Communities

9.10.2000

D.3.3.

Protocol Implementation

Table 2

Message Transfer Protocol Implementation

Item

Feature

References

Status

Support

Are the following message types sup- A.4.2
ported:

MTsy

MTop

MTst

MTor

MAE

MAR

MCI

MDT

MAV

MEsu

MEsd

MEhb

MEty

— system messages?

— operational messages?

— status messages?

— operator messages?

Association establishment procedures

Association release procedure

Association integrity procedure

Data transfer procedure

Association recovery procedure

Encoding of System Message:

— STARTUP?

— SHUTDOWN?

— HEARTBEAT?

Encoding of TYP field for other
message types

MNmsg

Maximum message body size
supported

A.4.3

A.4.5

A.4.7

A.4.4

A.4.9

A.4.10.1,

A.4.10.3

A.4.10.3

A.4.10.3

A.4.10.3

A.4.10.1,
A.4.10.4

A.4.10.2

Timer values supported:

A.4.7

Ts

Tr

— Association integrity heartbeat

— Association integrity timeout

M

M

O

O

M

M

M

M

M

M

M

M

M

Yes '
Yes '
No ' Yes '
No ' Yes '
Yes '
Yes '
Yes '
Yes '
Yes '

Yes '
Yes '
Yes '
Yes '

at least
4 096 octets

Value:

M

Tr > 2Ts

Yes '
Values:
Yes '
Values:

D.4.

PICS Proforma for the Message Header Protocol

D.4.1.

Abbreviations and Special Symbols

D.4.1.1.

S t a t u s S y m b o l s

M

O

O.<n>

mandatory

optional

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)

9.10.2000

EN

Official Journal of the European Communities

L 254/205

D.4.1.2.

A b b r e v i a t i o n s

NA

not applicable

D.4.1.3.

I t e m R e f e r e n c e s

Items in the PICS proforma are identified by mnemonic item references. PICS items dealing with
related functions are identified by item references sharing the same initial letter or letter-pair (in
capitals). There follows a list of those initials, in the order in which the groups of items occur in the
PICS proforma.

— IHC1, IHC2, IHC3, IHC4, IHCC

connection establishment

— IHR1, IHR2

connection release

— IHT1, IHTx

data transfer

— Tcr

timer

D.4.2.

Identification

Table 3

Message Header Implementation Identification

Supplier

Contact point for queries about the PICS

Implementation name/version

Machine name/version

Operating system name/version

Other hardware and operating systems claimed

System name (if applicable)

L 254/206

EN

Official Journal of the European Communities

9.10.2000

D.4.3.

Protocol Implementation

Table 4

Message Header Protocol Implementation

Item

Feature

References

Status

Support

Does the connection establishment
procedure:

B.4.1

IHC1 (*) — use N-Connect?

IHC2 (*) — rely on a pre-established network

connection?

IHC3

— reset the pre-established connec-

tion

IHC4 (*) — retry the N-Connect automatically

IHCC

Connection collision resolution pro-
cedure

Does the connection release pro-
cedure:

IHR1

— use N-Disconnect?

B.4.2

B.4.3

IHR2

— retain the network connection

IHT1

IHTx

Data Transfer PDU encoding

Use of
the fields ADEST, DEST,
AEMM, EMM, and ADR with values
other than '40'H

B.4.4

B.4.4

Timer values supported:

Tcr

— Connection establishment

retry

B.4.1

timer

NOTES:

1. IHC1 is used in items IHC4, IHR1 and IHR2.
2. IHC2 is used in items IHC3, IHR1 and IHR2.
3. IHC4 is used in item Tcr.

O.1

O.1

Yes ' No '
No ' Yes '

IHC2: O

IHC1: O

NA ' Yes '
No '
NA ' No '
Yes '

M

Yes '

IHC1: M NA ' Yes '
No '
IHC2: X

IHC2: M NA ' No '
Yes '
IHC1: X

M

O

Yes '
No ' Yes '

IHC4: M NA ' No '
Yes '

Values:

D.5.

PICS Proforma for the Network Protocol

D.5.1.

Abbreviations and Special Symbols

D.5.1.1.

S t a t u s S y m b o l s

M

O

mandatory

optional

D.5.1.2.

I t e m R e f e r e n c e s

Items in the PICS proforma are identified by mnemonic item references. PICS items dealing with
related functions are identified by item references sharing the same initial letter or letter-pair (in
capitals). There follows a list of those initials, in the order in which the groups of items occur in the
PICS proforma.

9.10.2000

EN

Official Journal of the European Communities

L 254/207

— SNDCP1

protocol ID field

— NCRdae, NCRgae, NCCx, NDRx

parameters in protocol messages

— NCD1, NCD2, NCN1, NCN2

validation of addresses

— NDT

data transfer

D.5.2.

Identification

Table 5

Network Implementation Identification

Supplier

Contact point for queries about the PICS

Implementation name/version

Machine name/version

Operating system name/version

Other hardware and operating systems claimed

System name (if applicable)

D.5.3.

Protocol Implementation

Table 6

Network Protocol Implementation

Item

Feature

References

Status

Support

SNDCP1

Protocol ID field in Call User Data
field of CALL REQUEST

C.5.1

Parameters in N-CR message:

C.5.1

NCRdae — called address extension

NCRgae — calling address extension

NCCx

Parameters in N-CC message: none

C.5.1

NDRx

Parameters in N-DR message: none

C.5.1

Validation of addresses:

— calling DTE address

— called DTE address

— calling NSAP address

— called NSAP address

NCD1

NCD2

NCN1

NCN2

C.5.4

NDT

Data transfer procedures

C.5.5

M

M

M

M

M

M

O

M

O

M

Yes '

Yes '
Yes '

Yes '

Yes '

Yes '
No ' Yes '
Yes '
No ' Yes '

Yes '

NOTE — ‘address extensions’ are those encoded in the Call User Data field according to ISO/IEC 8878 Annex A.5

[Reference 12], and not the X.25 address extension facilities, whose use is prohibited in this protocol.

L 254/208

EN

Official Journal of the European Communities

9.10.2000

ANNEX E (Normative)

PROFILE REQUIREMENTS LIST

E.1.

Introduction

E.1.1.

This Annex provides the PRL for the FDE ICD profile defined in this Eurocontrol Standard Document.
The Implementation Conformance Statement for an implementation claiming conformance to this
profile shall be generated in accordance with the instructions given below.

NOTE The proformas in this Annex are based on those accompanying the referenced base standards.

E.1.2.

A conforming implementation shall satisfy the mandatory conformance requirements of the base
standards referenced in this profile.

E.2.

The Role of the PRL and PICS Proformas

The status of this section (E.2) is informative: it does not constitute a provision of this Part of this
Eurocontrol Standard.

— The objective of presenting the conformance requirements in the tabular form of the PRL and
PICS proformas is to provide a check-list of the features which must or may be implemented. The
underlying concepts are defined and described in ISO/IEC 9646-1 [Reference 14] (ITU-T
Recommendation X.290 is equivalent) and ISO/IEC TR 10000-1 [Reference 2].

— A profile combines and selects the options of several base standards in order to fulfil a specific
information processing function. Each base standard has a PICS proforma, listing the requirements
of the standard. The PRL comprises the subset of the base standard PICS proforma items that are
constrained by the profile, together with the specific profile requirements; it defines answers
required on the base standard PICS proformas to conform with the profile. In addition, the PRL
will contain PICS-type items which are specific to the profile (at the least, there will be a item
testing whether all the required PICS proformas have been correctly completed); these items must
be completed together with the base standard PICS proformas. The completed proformas together
constitute the profile Implementation Conformance Statement (ICS).

— Following the methodology of ISO/IEC TR 10000-1 [Reference 2], a claim of conformance to a
profile has to be supported by PICS proformas completed in accordance with the PRL. The use of
this material will depend on the procurement approach for an FDE ICD implementation.

— Several possible approaches to an FDE implementation can be imagined:

— In-house implementation by a National Administration or Organisation: the PRL should be
used as the basis of the requirements specification and acceptance test specification for the
implementation; the completed ICS should be produced as part of the acceptance procedure.

— Implementation of the profile by a contractor: the material will be used and produced as for
an in-house implementation, but the contractor should provide the ICS and the need for this
must be a contractual requirement.

— Implementation of the profile by a contractor as part of a turn-key or system integration
contract: the material will be used and produced as for an in-house implementation, but the
contractor must be required to do this internally as well as providing the completed ICS.
that a supplier working for two
Conformance to the profile ensures,
administrations cannot introduce its proprietary protocols to meet the FDE requirement and
thus helps to give control to the contracting administrations.

for instance,

9.10.2000

EN

Official Journal of the European Communities

L 254/209

— Integration of off-the-shelf products into a profile implementation in any of the previous
cases: the supplier of a product should be required to provide those PICS proformas relevant
to the product completed in accordance with the PRL given here and to warrant the
conformance of the product with the applicable profile requirements; this PICS can then be
forwarded as part of the profile ICS.

— Following implementation, the ICS should be maintained as part of the documentation of the
implementation; it can be used to predict interoperability with other administrations, and to
identify changes that may be needed in moving to different protocols.

E.3.

Notation

E.3.1.

The following notations from ISO/IEC TR 10000-1 [Reference 2] are used in the PRL to indicate the
status of features:

mandatory

optional

not applicable (i.e. logically impossible in the scope of the profile)

excluded

m :

o :

- :

x :

NOTES

1. Two-character combinations may be used, in which case the first character refers to the static (implementation)
status, and the second to the dynamic (use); thus ‘mo’ means ‘mandatory to be implemented, optional to be
used’.

2. The ‘o.<n>’ notation is used to show a set of selectable options (i.e. at least one of the set must be

implemented) with the same identifier n.

3. A feature marked ‘x’ may nonetheless be part of an implementation so long as it is not used when the

implementation is operating in conformance with the profile.

4. Use of features marked ‘x’ would require bilateral agreement. In this event, the status of the features should

be revised as they may be of interest to other implementations.

E.3.2.

The following predicate notation is used:

<predicate>::

introduces a group of items, all of which are conditional on <predicate> (the
extent of the group is shown by the layout).

<predicate>:

introduces a single item which is conditional on <predicate>.

NOTE

In each case, the predicate may be the identifier of a profile feature, or a boolean combination of
predicates (‘¬’ is the symbol for logical negation).

E.3.3.

Base standard requirements are shown using the equivalent notations in upper case (i.e. M, O,
O.<n>, X).

L 254/210

EN

Official Journal of the European Communities

9.10.2000

E.4.

Instructions for Completing the PICS Proformas

E.4.1.

To provide the profile ICS, the PICS proformas for the referenced base standards shall be completed,
together with the additional profile-related PICS items provided in this Annex.

E.4.2.

E.4.3.

Where this profile refines the features of the base standards, the requirements expressed in this PRL
shall be applied (as indicated in PRL items with a ‘Profile features’ column) to constrain the allowable
responses in the base standard PICS proformas.

Where this profile makes additional requirements, the response column for such items shall be
completed. In this column, each response shall either be selected from the indicated set of responses,
or comprise a parameter value or values or range of values as requested.

E.4.4.

If a mandatory requirement is not satisfied, exception information must be supplied, by entering a
reference X<i>, where <i> is a unique identifier, to an accompanying rationale for the non-compliance.

NOTE A possible reason for such an exception is compliance with a pending defect report on a provision of the

profile; if the defect report is accepted, the implementation will then be conformant.

E.5.

References

E.5.1.

This profile references the following protocol specifications:

— Message Transfer Protocol (Annex A to this Eurocontrol Standard Document);

— Message Header Protocol (Annex B to this Eurocontrol Standard Document);

— Connection-mode Network Protocol using ISO/IEC 8208 (Annex C to this Eurocontrol Standard

Document);

— ISO/IEC 7776 [Reference 6];

— Physical Layer Standards called up by ITU-T Recommendation X.25 (1993) clause 1 [Reference 1].

E.5.2.

As there are no explicit PICS proformas for the relevant Physical Layer Standards, the interim physical
layer PICS proformas in ISO/IEC ISP 10609-9 clause A.4 [Reference 8] shall be used.

9.10.2000

EN

Official Journal of the European Communities

L 254/211

E.6.

Conformance Statement

E.6.1.

Conformance Overview

Table 1

Conformance Overview

Supplier

Contact point for queries about the PICS

Implementation name/version

Machine name/version

Operating system name/version

Other hardware and operating systems claimed

System name (if applicable)

Date of statement

Have the features of the base standards been
implemented in accordance with requirements of
this PRL?

— Annexe A of this profile

— Annexe B of this profile

— Annexe C of this profile

— ISO/IEC 8208

— ISO/IEC 7776

— ITU-TX.25(1993) clause 1

Are the completed PICS proformas for the base
standards attached?

Yes '
Yes '
Yes '
Yes '
Yes '
Yes '

Yes '

NOTE — Failure to respond « Yes » to all of these questions indicates a failure of conformance to this profile

L 254/212

EN

Official Journal of the European Communities

9.10.2000

E.6.2.

Dynamic Conformance Requirements

Table 2

Dynamic Conformance Requirements

Are TSDU sizes of at least 4 097 octets supported?

Are NSDU sizes of at least 4 105 octets supported?

Is the concatenation and segmentation of TSDUs prohibited?

Is the Non-standard Default Packet Size of 256 supported for both
directions of transmission?

Are NSAP addresses sent only in the format defined in Annex C?

Is D-bit set to 0 in CALL REQUEST, CALL ACCEPTED and DATA
packets?

Yes '

Yes '

Yes '

Yes '

Yes '

Yes '

E.7.

Upper Layer Requirements

Table 3

Message Transfer Protocol

Base Standard Features

Profile Features

Item

Message Transfer Protocol

References

Status

References Status

MTst

— status messages

MTor

— operator messages

A.4.2

A.4.2

O

O

ox

ox

E.8.

Lower Layer Requirements

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, B.4.4
AEMM, EMM and ADR with
values other than '40'H

O

ox

9.10.2000

EN

Official Journal of the European Communities

L 254/213

E.8.2.

Network Layer Requirements

The PRLs given in this section are based on the PICS proforma for ISO/IEC 8208:1993 [Reference 7].
The entries in the ‘References’ column under ‘Base standard features’ of the following tables are
references to clauses in that standard.

E.8.2.1.

G e n e r a l D T E C h a r a c t e r i s t i c s

Table 5

General DTE Characteristics

Base Standard Features

Profile Features

Item

General DTE Characteristics

References

Status

References Status

Vs

Vp

Ec/3

Ec/8

Ec/4

Ec/0

Et/t

Service supported:

— virtual call

— permanent virtual circuit

Environments supported:

3, 3.2

— DTE/DCE(1993)

— DTE/DCE(1988)

— DTE/DCE(1984)

— DTE/DCE(1980)

— DTE/DTE in fixed role as

DTE

O.1

O.1

O.2

O.2

O.2

O.2

O.2

6.3.2

6.3.2

6.3.2

6.3.2

6.3.2

Et/c

— DTE/DTE in fixed role as

Vs: O.2

6.3.2

DCE

Et/d

— DTE/DTE with dynamic role 4.5

Vs: O.2

selection

Packet
supported:

sequence

numbering

M8

— Modulo 8

M128

— Modulo 128

13.2, 12.1.1,
Table 3

13.2, 12.1.1,
Table 3

optional 13.29,

Reference Number
user facility supported, for alter- 13.29.2,
native Logical Channel Identifier 13.29.4, Fig 31
assignment:

13.29.1,
13.29.3,

RNa

— without reversion to use of 13.29.2.1

logical channel ranges

RNb

— with possible reversion to 13.29.2.1

use logical channel ranges

O.3

O.3

Et: O
¬Et: X

Et: O
¬Et: X

m

x

o.2

o.2

o.2

o.2

o.2

o.2

x

m

x

x

x

L 254/214

EN

Official Journal of the European Communities

9.10.2000

E.8.2.2.

P r o c e d u r e s , P a c k e t T y p e s a n d P a c k e t F o r m a t s

Table 6

Packet Layer Functions Independent of Logical Channels

Base Standard Features

Profile Features

Item

Packet Layer Functions Independent
of Logical Channels

References

Status

References Status

Are the following packet layer
functions supported:

Z2s

Sending diagnostic packet

12.7, Table 24

Et: O
¬Et: X

Z4i

Initiating On-line Facility Regis- 13.1,
tration:

13.1.1.3, 13.1.1.4

13.1.1.1,

O

— send

REGISTRATION 12.9.1

REQUEST

— receive

REGISTRATION 12.9.2, Table 10

CONFIRMATION

Z4r

Responding to On-line Facility 13.1,
Registration:

13.1.1.4

13.1.1.1,

Et: O

— receive

REGISTRATION 12.9.1

REQUEST

— send REGISTRATION CON- 12.9.2, Table 10

FIRMATION

Table 7

Call Setup

x

ox

–

Base Standard Features

Profile Features

Item

Call Setup

References

Status

References Status

Are outgoing Virtual Calls sup- 5.2.1, 5.2.5,
ported:

Table 33

S1a

— Fast Select, no restriction on 5.2.4, 13.16

response?

S1b

— Fast Select with restricted 13.16

response?

S1c

— non-Fast Select?

5.2.4

SP1b

CALL REQUEST, basic format

12.2.3.1

SP1e

SP2b

SP2e

send CALL REQUEST, extended 12.2.3.1, 12.2.3.2
format

receive CALL CONNECTED, 12.2.4.1
basic format

receive CALL CONNECTED, 12.2.4.1, 12.2.4.2
extended format

O

O

O

S1c: M
S1ab: O.4

S1ab: O.4

S1ac: M

S1a: M

x

x

m

m

x

m

–

9.10.2000

EN

Official Journal of the European Communities

L 254/215

Base Standard Features

Profile Features

Item

Call Setup

References

Status

References Status

Is alternative addressing sup- 13.28
ported for outgoing Virtual
Calls:

— using A = 1 and expanded 13.28.2.1, 12.2.1.2

Address Block format?

— using the Called Address 13.28.2.2.

Extension Facility?

Ec/3: O
¬Ec/3: X

Ec/3: O
¬Ec/3: X

Are incoming Virtual Calls sup- 5.2.2, 5.2.5, Table
ported:

33

S2a

— Fast Select with acceptance 5.2.3, 13.17

possible?

S2b

S2c

— Fast Select, always cleared?

13.17

— non-Fast Select with accept- 5.2.3

ance possible?

S2d

— non-Fast Select, always cle- 5.2.3

ared?

SP3b

SP3e

SP4b

SP4e

receive INCOMING CALL, basic 12.2.3.1
format

receive
extended format

INCOMING

CALL, 12.2.3.1, 12.2.3.2

send CALL ACCEPTED, basic 12.2.4.1
format

send
extended format

CALL

ACCEPTED, 12.2.4.1, 12.2.4.2

Is D-bit negotiation supported:

DN1

— for outgoing Virtual Calls

DN2

— for incoming Virtual Calls

6.3

6.3

NOTE The D-bit shall always be negociated to 0.

O

O

O

O

S2: M

S2ab: M
S2axc: O.5

S2c: M
S2axc: O.5

S2axc: O.5
S2anc: O

S1ac: O

S1ac: O

Table 8

Call Clearing

x

x

–

m

m

x

m

–

m

–

m

m

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 indication of 5.5.2

O

m

clearing

L 254/216

EN

Official Journal of the European Communities

9.10.2000

Base Standard Features

Profile Features

Item

Call Clearing

References

Status

References Status

C2a

— aborting an outgoing Virtual 5.4, 5.5.1, 5.5.3

S1: O

Call attempt?

C2b

— rejecting an incoming Vir- 5.3, 5.5.1, 5.5.3

tual Call?

S2bd: M
S2acxbd: O

C2c

— originating clearing of an 5.5.1, 5.5.3

O

established Virtual Call?

CP1b

CP1e

CP2b

CP2e

CP3b

CP3e

CP4b

CP4e

receive CLEAR INDICATION, 12.2.5.1
basic format

Cany: M

receive CLEAR INDICATION, 12.2.5.1, 12.2.5.2
extended format

Cany: M

send CLEAR CONFIRMATION, 12.2.6.1
basic format

C1: M

send CLEAR CONFIRMATION, 12.2.6.1, 12.2.6.2
extended format

C1rn: M

send CLEAR REQUEST, basic 12.2.5.1
format

send
CLEAR
extended format

REQUEST, 12.2.5.1,12.2.5.2

receive
MATION, basic format

CLEAR

CONFIR- 12.2.6.1

receive
MATION, extended format

CLEAR

CONFIR- 12.2.6.1, 12.2.6.2

C2a: M
C2bcxa: O.6

C2bcxa: O.6
C2axbc: X

C2: M

C2rnci: M

o

m

o

m

–

m

x

m

x

m

–

Table 9

Resetting of Logical Channels

Base Standard Features

Profile Features

Item

Resetting of Logical Channels

References

Status

References Status

Is resetting supported:

8, 8.4, Table 34

RSi

— as initiator?

send RESET REQUEST

8.1, 8.3

12.5.1

receive RESET CONFIR- 12.5.2, 12.5.1
MATION/INDICATION

RSr

— as responder?

8.2

receive RESET INDICATION 12.5.1

send
MATION

RESET

CONFIR- 12.5.2

O

O

mm

mm

9.10.2000

EN

Official Journal of the European Communities

L 254/217

Table 10

Error Procedures

Base Standard Features

Profile Features

Item Error Procedures (Virtual Call Service)

References

Status

References Status

Is ERROR-C procedure:

5.2.1,
Table 33

5.4,

8.1,

W1a

W1b

— clear the Virtual Call?

— restart the packet layer?

Is ERROR-R procedure for vir- 6.3, 6.4, 6.6, 6.8.1,
6.8.2, 7.1.3, 7.1.4,
tual calls:
8.2, 11.2.1, 13.4.1,
Tables 34-36

W2sc

— restart the packet layer?

O.7

O.7

O.8

m

x

x

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,

O

Table 35

— send INTERRUPT REQUEST 12.3.2
receive INTERRUPT CON- 12.3.3
FIRMATION

Ir

Is receiving interrupts support- 6.8,
ed?
— receive INTERRUPT INDI- 12.3.2

Table 35

CATION

6.8.2,

6.8.3

O

ox

–

— send INTERRUPT CONFIR- 12.3.3

MATION

Table 12

Sending Data

Base Standard Features

Profile Features

Item

Sending Data

References

Status

References Status

DS1

Is sending of DATA packets 6, 6.1, 7.1.1, 7.1.2,
supported?

7.1.3, 12.3.1

Are the following supported:

DS2

— send-window rotation on 7.1, 7.1.2, 7.1.3

receiving
values?

updated

P(R)

O

O

mm

mm

L 254/218

EN

Official Journal of the European Communities

9.10.2000

Base Standard Features

Profile Features

Item

Sending Data

References

Status

References Status

DS4a

— sending M = 0 in DATA 6.4, 6.5, 6.7

packets?

DS4b

— sending M = 1 in DATA 6.4, 6.5, 6.7

packets?

DS5a

— sending Q = 0 in DATA 6.6

packets?

DS5b

— sending Q = 1 in DATA 6.6

packets?

DS6

— responding

to

packet 13.4.2 12.8

retransmission
(received REJECT packets)?

requests

— Window Rotation Timer

DS7a

procedure:

— ERROR-R
expiry

action

on 11.2.1(a)

DS7b

— packet retransmission on 11.2.1(b)

expiry

M

O

O.10

O.10

Et: O

O

Et: O
¬Et: X

DS8

— discard of over-length Table 36 Note 2

O

flow control
(instead of ERROR-R)?

packets

mo.9

mo.9

mm

ox

–

ox

ox

ox

Table 13

Receiving Data

Base Standard Features

Profile Features

Item

Receiving Data

References

Status

References Status

DR1

Is receiving of DATA packets 6, 6.1, 6.2, 7.1.1,
7.1.2, 7.1.3, 12.3.1
supported?

Are the following supported:

DR2

— receive-window rotation by 7.1.2, 7.1.3

sending updated P(R)values?

DR3

— flow control by sending 7.1.5, 7.1.6, 12.4.1,

RECEIVE NOT READY and 12.4.2
RECEIVE READY?

DR4b

— receiving M = 1 in DATA 6.4, 6.5, 6.7

packets?

DR5a

— receiving Q = 0 in DATA 6.6

packets?

DR5b

— receiving Q = 1 in DATA 6.6

packets?

DR6

— requesting packet

retrans- 13.4.1, 12.8

O

O

O

O

O.11

O.11

O

mission by sending REJECT
packets?

— recovery from receipt of
DATA packets containing
invalid P(S), by:

mm

mm

mm

mm

mm

–

ox

9.10.2000

EN

Official Journal of the European Communities

L 254/219

Base Standard Features

Profile Features

Item

Receiving Data

References

Status

References Status

DR7a

DR7b

— ERROR-R action?

11.3(a)

— requesting

packet 11.3(b)

retransmission?

DR7c

— ignoring the packet and 11.3(c)

waiting for a
retransmitted packet?

correct

— recovery from receipt of
DATA packets with invalid
User Data field, by:

DR8a

DR8b

— ERROR-R action?

11.3(a)

— requesting

packet 11.3(b)

retransmission?

DR8c

— ignoring the packet and 11.3(c)

waiting for a
retransmitted packet?

correct

DR9

— Window Status Trans- 11.2.2
Timer

pro-

mission
cedure?

O.12

O.12

O.12

O.13

O.13

O.13

O

mm

ox

ox

mm

ox

ox

ox

Table 14

Delivery Confirmation

Base Standard Features

Profile Features

Item

Delivery Confirmation

References

Status

References Status

DC

Is Delivery Confirmation sup- 6.3, 6.5, 6.7, 7.1.4
ported?

O

x

E.8.2.3.

M i s c e l l a n e o u s F e a t u r e s a n d O p t i o n s

Table 15

Values of Cause and Diagnostic Codes

Base Standard Features

Status

Item

Values of Cause and Diagnostic Codes

References

Profile Features

References Status

In RESTART REQUEST packets 12.6.1.1, 12.6.1.2,
sent:

Tables 24-25

Y1d

— Cause = 128, private diag-

O.14

nostic codes

RESTART

In
packets received:

INDICATION 12.6.1.1, Table 9,

12.6.1.2

Y2b

— Cause not 0 or 128, any

diagnostic code value

EC: M
¬EC: O

ox

m

L 254/220

EN

Official Journal of the European Communities

9.10.2000

Base Standard Features

Status

Item

Values of Cause and Diagnostic Codes

References

Profile Features

References Status

In CLEAR REQUEST packets 12.2.3.1.1,
12.2.3.1.2,
sent:
24-25

Tables

Y3d

— Cause = 128, private diag-

O.15

nostic codes

In CLEAR INDICATION packets 12.2.3.1.1, Table 7,
received:

12.2.3.1.2,

Y4b

— Cause not 0 or 128, any

diagnostic code value

EC: M
¬EC: O

In RESET REQUEST packets 12.5.1.1, 12.5.1.2,
sent:

Tables 24-25

Y5d

— Cause = 128, private diag-

O.16

nostic codes

In RESET INDICATION packets 12.5.1.1, Table 8,
received:

12.5.1.2

Y6b

— Cause not 0 or 128, any

diagnostic code value

EC: M
¬EC: O

ox

m

ox

m

E.8.2.4.

F a c i l i t i e s

Table 16

Facilities Sent in CALL REQUEST Packets

Base Standard Features

Profile Features

Item

Facilities Sent in CALL REQUEST
Packets

References

Status

References Status

FS1pi

FS1wi

FS2ib

FS2ie

FS3b

FS3e

FS4b

Flow Control Parameter Nego- 13.12, 15.2.2.1.1
tiation, packet size

Flow Control Parameter Nego- 13.12, 15.2.2.1.2
tiation, window size

Basic Throughput Class Negoti- 13.13,
ation

Table 20a

15.2.2.2.1,

Extended
Negotiation

Throughput Class 13.13,

15.2.2.2.2,

Table 20b

Closed User Group Selection, 13.14.6, 15.2.2.3.1
basic format

Closed User Group Selection, 13.14.6, 15.2.2.3.2
extended format

Closed User Group With Outgo- 13.14.7, 15.2.2.4.1
ing Access Selection, basic for-
mat

O

O

O

O

O

O

O

x

x

x

x

o

x

x

9.10.2000

EN

Official Journal of the European Communities

L 254/221

Base Standard Features

Profile Features

Item

Facilities Sent in CALL REQUEST
Packets

References

Status

References Status

FS4e

Closed User Group With Outgo- 13.14.7, 15.2.2.4.2
ing Access Selection, extended
format

FS5

Bilateral Closed User Group Sel- 13.15, 15.2.2.5
ection

FS6a

Fast Select

13.16, 15.2.2.6

FS6b

Reverse Charging

13.18, 15.2.2.6

FS6c

ICRD Status Selection

13.25.4.2, 15.2.2.6

FS7i

Network User Identification

13.21,
15.2.2.7

13.21.3,

FS8i

Charging Information, request- 13.22, 15.2.2.8.1
ing service

FS9b

RPOA selection, basic format

13.23,
15.2.2.9.1

13.23.2,

FS9e

FS12

FS99i

FS98i

FS20i

RPOA selection, extended for- 13.23,
mat

15.2.2.9.2

13.23.2,

Transit Delay Selection and 13.27, 15.2.2.13
Indication

Local non-X.25 facilities,
lowing Facility Marker

fol- 15.1, Table 18

Remote non-X.25 facilities, fol- 15.1, Table 18
lowing Facility Marker

Facility Marker, CCITT-specified 15.1
DTE facilities

FS21i

Calling Address Extension

14.1, 15.3.2.1

FS22i

Called Address Extension

14.2, 15.3.2.2

FS23ib

FS23ie

Minimum Throughput Class 14.3,
Negotiation, basic format

Table 20a

15.3.2.3.1,

Minimum Throughput Class 14.3,
Negotiation, extended format

Table 20b

15.3.2.3.2,

FS24i

End-to-end Transit Delay Nego- 14.4, 15.3.2.4
tiation

FS25i

Expedited Data Negotiation

14.7, 15.3.2.7

FS26i

Priority

14.5, 15.3.2.5

FS27i

Protection

14.6, 15.3.2.6

O

O

O

O

O

O

O

O

O

O

O

O

O

O

O

O

O

O

O

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

L 254/222

EN

Official Journal of the European Communities

9.10.2000

Table 17

Facilities Sent in CALL ACCEPT Packets

Base Standard Features

Profile Features

Item

Facilities Sent in CALL ACCEPT
Packets

References

Status

References Status

FS1pr

FS1wr

FS2rb

FS2re

Flow Control Parameter Nego- 13.12,
tiation, packet size

Table 13

15.2.2.1.1,

Flow Control Parameter Nego- 13.12,
tiation, window size

Table 13

15.2.2.1.2,

Basic Throughput Class Negoti- 13.13,
ation

Table 20a

15.2.2.2.1,

Extended
Negotiation

Throughput Class 13.13,

15.2.2.2.2,

FS7r

Network User Identification

Table 20b

13.21,
15.2.2.7

13.21.3

FS8r

FS10r

FS99r

FS98r

FS20r

Charging
requesting service

Information, 13.22, 15.2.2.8.1

Called Line Address Modified 13.26, 15.2.2.12
Notification

Local non-X.25 facilities,
lowing Facility Marker

fol- 15.1, Table 18

Remote non-X.25 facilities, fol- 15.1, Table 18
lowing Facility Marker

Facility Marker, CCITT-specified 15.1
DTE facilities

FS22r

Called Address Extension

14.2, 15.3.2.2

FS24r

End-to-end Transit Delay Nego- 14.4, 15.3.2.4
tiation

FS25r

Expedited Data Negotiation

14.7, 15.3.2.7

FS26r

Priority

FS27r

Protection

14.5, 15.3.2.5

14.6, 15.3.2.6

Table 18

Facilities Sent in CLEAR REQUEST Packets

O

O

O

O

O

O

O

O

O

O

O

O

O

O

O

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

Base Standard Features

Profile Features

Item

Facilities Sent in CLEAR REQUEST
Packets

References

Status

References Status

FS10d

Called Line Address Modified 13.26, 15.2.2.12
Notification

FS13

Call Deflection Selection

13.25.2.2,
15.2.2.10

FS99d

Local non-X.25 facilities,
lowing Facility Marker

fol- 15.1, Table 18

O

O

O

x

x

x

9.10.2000

EN

Official Journal of the European Communities

L 254/223

Base Standard Features

Profile Features

Item

Facilities Sent in CLEAR REQUEST
Packets

References

Status

References Status

FS98d

FS20d

Remote non-X.25 facilities, fol- 15.1, Table 18
lowing Facility Marker

Facility Marker, CCITT-specified 15.1
DTE facilities

FS22d

Called Address Extension

14.2, 15.3.2.2

O

O

O

x

x

x

Table 19

Facilities Received in INCOMING CALL Packets

Base Standard Features

Profile Features

Item

Facilities Received
in INCOMING CALL Packets

References

Status

References Status

FR1pi

FR1wi

FR2ib

FR2ie

FR3b

FR3e

FR4b

FR4e

Flow Control Parameter Nego- 13.12, 15.2.2.1.1
tiation, packet size

Flow Control Parameter Nego- 13.12, 15.2.2.1.2
tiation, window size

Basic Throughput Class Negoti- 13.13,
ation

Table, 20a

15.2.2.2.1

Extended
Negotiation

Throughput Class 13.13,

15.2.2.2.2

Table, 20b

Closed User Group Selection, 13.14.6, 15.2.2.3.1
basic format

Closed User Group Selection, 13.14.6, 15.2.2.3.2
extended format

Closed User Group With Outgo- 13.4.7, 15.2.2.4.1
ing Access Selection, basic for-
mat

Closed User Group With Outgo- 13.4.7, 15.2.2.4.2
ing Access Selection, extended
format

FR5

Bilateral Closed User Group Sel- 13.15, 15.2.2.5
ection

FR6a

Fast Select

FR6b

Reverse Charging

13.16,
15.2.2.6

13.18,
15.2.2.6

13.17,

13.19,

FR11

FR12i

FR99i

Call Redirection or Call Deflec- 13.25.3, 15.2.2.11
tion Notification

Transit Delay Selection and 13.27, 15.2.2.13
Indication

Local non-X.25 facilities,
lowing Facility Marker

fol- 15.1, Table 18

O

O

O

O

O

O

O

O

O

O

O

O

O

O

x

x

x

x

o

x

x

x

x

x

x

x

x

x

L 254/224

EN

Official Journal of the European Communities

9.10.2000

Base Standard Features

Profile Features

Item

Facilities Received
in INCOMING CALL Packets

References

Status

References Status

FR20i

Facility Marker, CCITT-specified 15.1
DTE facilities

FR21

Calling Address Extension

14.1, 15.3.2.1

FR22i

Called Address Extension

14.2, 15.3.2.2

FR23b

FR23e

FR24i

Minimum Throughput Class 14.3,
Negotiation, basic format

Table 20a

15.3.2.3.1,

Minimum Throughput Class 14.3,
Negotiation, extended format

Table 20b

15.3.2.3.2,

End-to-end Transit Delay Nego- 14.4, 15.3.2.4
tiation

FR25i

Expedited Data Negotiation

14.7, 15.3.2.7

FR26i

Priority

FR27i

Protection

14.5, 15.3.2.5

14.6, 15.3.2.6

Table 20

Facilities Received in CALL CONNECTED Packets

O

O

O

O

O

O

O

x

x

x

x

x

x

x

x

x

Base Standard Features

Profile Features

Item

Facilities Received
in CALL CONNECTED Packets

References

Status

References Status

FR1pr

FR1wr

FR2rb

FR2re

FR10r

FR12r

FR99r

FR20r

Flow Control Parameter Nego- 13.12,
tiation, packet size

Table 14

15.2.2.1.1,

Flow Control Parameter Nego- 13.12,
tiation, window size

Table 14

15.2.2.1.2,

Basic Throughput Class Negoti- 13.13,
ation

Table 20a

15.2.2.2.1,

Extended
Negotiation

Throughput Class 13.13,

15.2.2.2.2,

Table 20b

Called Line Address Modified 13.26, 15.2.2.12
Notification

Transit Delay Selection and 13.27, 15.2.2.13
Indication

Local non-X.25 facilities,
lowing Facility Marker

fol- 15.1, Table 18

Facility Marker, CCITT-specified 15.1
DTE facilities

FR22r

Called Address Extension

14.2, 15.3.2.2

FR24r

End-to-end Transit Delay Nego- 14.4, 15.3.2.4
tiation

FR25r

Expedited Data Negotiation

14.7, 15.3.2.7

FR26r

Priority

FR27r

Protection

14.5, 15.3.2.5

14.6, 15.3.2.6

O

O

O

O

O

O

O

O

O

O

O

O

O

x

x

x

x

x

x

x

x

x

x

x

x

x

9.10.2000

EN

Official Journal of the European Communities

L 254/225

Table 21

Facilities Received in CLEAR INDICATION Packets

Base Standard Features

Profile Features

Item

Facilities Received
in CLEAR INDICATION Packets

References

Status

References Status

FR8ad

Charging information, monet- 13.22, 15.2.2.8.2
ary unit

FR8bd

Charging information, segment 13.22, 15.2.2.8.3
count

FR8cd

Charging information, call dura- 13.22, 15.2.2.8.4
tion

FR10d

Called Line Address Modified 13.26, 15.2.2.12
Notification

FR99d

Local non-X.25 facilities,
lowing Facility Marker

fol- 15.1, Table 18

FR20d

Facility Marker, ITU-T-specified 15.1
DTE facilities

FR22d

Called Address Extension

14.2, 15.3.2.2

O

O

O

O

O

O

O

x

x

x

x

x

x

x

Table 22

Facilities Received in CLEAR CONFIRMATION Packets

Base Standard Features

Profile Features

Item

Facilities Received
in CLEAR CONFIRMATION Packets

References

Status

References Status

FR8af

Charging information, monet- 13.22, 15.2.2.8.2
ary unit

FR8bf

Charging information, segment 13.22, 15.2.2.8.3
count

FR8cf

Charging information, call dura- 13.22, 15.2.2.8.4
tion

O

O

O

x

x

x

L 254/226

EN

Official Journal of the European Communities

9.10.2000

E.8.2.5.

P a r a m e t e r V a l u e s a n d R a n g e s

Table 23

Parameter Values and Ranges

Base Standard Features

Profile Features

Item

Parameter Values and Ranges

References

Status

References Status

What values are supported:

V1s

— Default

packet

sizes 16.2.2.5

(sending)?

V1r

— Default

packet

sizes 16.2.2.5

(receiving)?

V2s

— Default

window

sizes, 16.2.2.6

sending?

V2r

— Default

window

sizes, 16.2.2.6

receiving?

6.3.2

6.3.2

16, 32, 64,
128, 256,
512, 1 024,
2 048, 4 096
octets

16, 32, 64,
128, 256,
512, 1 024,
2 048, 4 096
octets

(M8: in the
range 1-7)

(M8: in the
range 1-7)

At least
128
and
256

At least
128
and
256

2

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

Lc

Lt

M8

M128

T4

SPN1

SPk

Multilink procedure

DTE/DCE operation

DTE/DTE operation

6

1, 5.1

1, 5.1

Basic (Modulo 8) operation

1, 3, 4.1.1

Extended
operation

(Modulo

128) 1, 3, 4.1.1

Timer T4 procedure

5.3.2, 5.6.1

Maximum number (N1) of bits 5.7.3
in an I-frame

Maximum number of outstand- 5.7.4
ing frames (k)

O

M

O

O.1

O.1

O

N1 ≥ 1 080

1 ≤ k ≤ 7

ox

mo.1

mo.1

mm

ox

mm

N1 ≥
2 104

k = 7

9.10.2000

EN

Official Journal of the European Communities

L 254/227

E.8.4.

Physical Layer Requirements

See ISO/IEC TR 10609-9 clause A.4 [Reference 8].

L 254/228

EN

Official Journal of the European Communities

9.10.2000

ANNEX F (Informative)

CONFORMANCE TESTING METHODOLOGY

F.1.

Introduction

F.1.1.

F.1.2.

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.

Implementations of the interface are undertaken by member states in a manner that is likely to rely on
procurement from various sources. To achieve a high level of confidence that such implementations
will
interoperate, a common set of conformance test requirements is required to standardise
preparation for test, testing and presentation of results.

F.2.

Purpose and Scope

F.2.1.

F.2.2.

This Annex defines requirements for the testing of conformance of implementations of this Eurocontrol
Standard of which this Annex is a part.

It identifies mechanisms whereby confidence in the declared interface is established through a process
of test to validate the claim.

F.3.

Bibliography

The following document is relevant to the testing of implementations of this Eurocontrol Standard
Document:

Eurocontrol (Maastricht Upper Area Control (UAC) Systems Division) FDE ICD Part 1 Integration Test
Plan Version 1.0, dated 10 May 1996 [Reference 15].

F.4.

Development Methods and Practices

F.4.1.

Implementations of the ICD can be effected using certain options and versions of the ICD itself. In
order to establish the potential for interworking, a Member State implementing the interface must
identify which parts of the ICD are supported with a defined statement as to the capability and what
limitations, if any, on variable parameters are supported.

F.4.2.

Any implementation should be subject to a conformance test as described below.

F.5.

Tests

F.5.1.

Introduction

F.5.1.1.

F.5.1.2.

In order to provide confidence in and support for FDE Interface within an ATCC to the interworking
between co-operating FDE applications, it is desirable for each to be tested for conformance to the
standards of which this Annex forms a part. Such testing is against the external behaviour of the
System Under Test (SUT) and is intended to test for interworking rather than the serviceability of the
end system.

The results of such testing can serve as evidence in support of claims of conformance made in
accordance with Section 5.1 of this part of this Eurocontrol Standard Document. The PICS proformas
and PRLs called up by this profile specification can be used as the basis of conformance tests; in
addition, international standards (e.g. ISO/IEC 8208 [Reference 7]) may already have abstract test
suites defined that can be used in conformance testing.

9.10.2000

EN

Official Journal of the European Communities

L 254/229

F.5.1.3.

F.5.1.4.

F.5.1.5.

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.

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.

Each test described below should be conducted in order. The latter test will only be successful if the
lower layers are functioning correctly and it is likely that this will be ascertained with the earlier tests.

F.5.1.6.

Notwithstanding the above, the testing described in this section is voluntary.

F.5.2.

Testing of the Lower Layers (Layers 1-3)

In support of the requirement for inter-operation between any one ATCC and its peers,
it is
recommended that any testing shall be based on the use of the test plan given in the Eurocontrol
(Maastricht UAC Systems Division) FDE ICD Integration Test Plan. Test procedures are to be bilaterally
agreed between co-operating ATCCs.

F.5.3.

Testing of the Application Layer

A series of bilaterally agreed tests should be agreed and conducted between co-operating ATCCs.

F.5.4.

Certification

The results of tests should be recorded and agreed between the co-operating parties.

F.5.5.

Notification

Member states should pass details of the results of any tests to Eurocontrol.

L 254/230

EN

Official Journal of the European Communities

9.10.2000

ANNEX G (Informative)

ASSIGNMENT OF ATC UNIT IDENTIFIERS

The following table shows the ATC unit identifiers assigned as at April 22nd, 1997. The Eurocontrol can provide
information on the current assignment of identifiers. The table also shows in hexadecimal the binary encoding of the
identifier as part of the NSAP address encoding defined in Annex C.

Table 1

ATC Unit Identifiers

ATC Unit Identifier

Encoding

Description

00

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

'01'H

'02'H

'03'H

'04'H

'05'H

'06'H

'07'H

'08'H

'09'H

'10'H

'11'H

'12'H

'13'H

'14'H

'15'H

'16'H

'17'H

'18'H

'19'H

'20'H

'21'H

'22'H

'23'H

'24'H

'25'H

'26'H

'27'H

'28'H

'29'H

Reserved

CATCAS, Copenhagen

MADAP, Maastricht

ZKSD, Frankfurt/Main

CANAC Brussels

Generic CAUTRA, France

Dublin

Shannon

LATCC, London

Oslo ATCC

Karlsruhe ATCC

Langen (future German system)

FATMI-system, Tampere

ROVA-system, Rovaniemi

VAS, Vienna

CFMU Haren

CFMU Brétigny

Geneva ACC/FMP

Zurich ACC/FMP

Barcelona

Madrid

Palma

Milan

Rome

Jersey

Shanwick

Athis-Mons

Reims

Brest

Bordeaux

9.10.2000

EN

Official Journal of the European Communities

L 254/231

ATC Unit Identifier

Encoding

Description

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

'30'H

'31'H

'32'H

'33'H

'34'H

'35'H

'36'H

'37'H

'38'H

'39'H

'40'H

'41'H

'42'H

'43'H

'44'H

'45'H

'46'H

'47'H

'48'H

'49'H

'50'H

'51'H

'52'H

'53'H

'54'H

'55'H

'56'H

'57'H

Aix-en-Provence

Bratislava

Stockholm-Arlanda

Malmö-Sturup

Sundsvall

Lisbon

Seville

Gran Canaria

Prague

Amsterdam

LIZ Offenbach

German Military System

German Military System

German Military System

German Military System

German Military System

German Military System

German Military System

German Military System

German Military System

Munchen (Future German System)

Zagreb

Hahn Airport, Germany

Santa Maria FIR

Ljubljana

Belgian Military System

Budapest

Warsaw

L 254/232

EN

Official Journal of the European Communities

9.10.2000

ANNEX H (Informative)

GUIDANCE ON RELIABILITY, AVAILABILITY AND SECURITY

H.1.

Introduction

It is expected that ATC applications such as OLDI shall make use of interconnected X.25 networks
and/or public or private telecommunication services. As a consequence, it is deemed necessary to
provide guidance to FDE ICD Part 1 implementations.

H.2.

Purpose and Scope

H.2.1.

The purpose of this Annex is to give guidance on issues relating to reliability, availability and security.

H.2.2.

The scope of this Annex is based on two scenarios. The first scenario is a point-to-point connection
over leased line. The second scenario is based within an interconnected X.25 network environment.

NOTE

For the second scenario, issues relating to the interconnection of the X25 networks are not considered.

H.2.3.

It is assured that implementations are physically protected against intrusion, power failures and other
external threats that can affect normal operation.

H.3.

Bibliography

The following document is a detailed technical analysis of which this Annex is an overview:

Eurocontrol FDE ICD Part 1: Reliability, Availability and Security — Technical Report [Reference 16].

H.4.

Leased Line Implementations

H.4.1.

Reliability

To increase service reliability, leased line, PSTN, Integrated Services Digital Network (ISDN) cables
must follow physically different paths and linked to different telecommunication operator switches
(this must be specified to the telecommunication operator).

H.4.2.

Availability

H.4.2.1.

Due to long setup times on PSTN which are incompatible with time constraining applications, ISDN
should be used as a backup medium.

H.4.2.2.

In event of DTE switchover, the standby DTE should generate a DISC frame to accelerate connection
re-establishment.

H.4.3.

Security

H.4.3.1.

When using ISDN as backup medium, the called ISDN terminal adapter (TA) should validate the
caller’s E.164 address [Reference 18].

H.4.3.2.

The calling DTE should comply to ITU-T Recommendation X.32 [Reference 17] by including caller
identification and for authentication information.

9.10.2000

EN

Official Journal of the European Communities

L 254/233

H.4.4.

Configuration Example

HOST A1

FEP A1

ISDN Terminal Adapter

TA

ISDN

Switch A

Switch B

DTE A1

Modem A1

HOST A2

FEP A2

Switch E

Switch F

Modem A2

Switch G

Leased
Line

Switch C

Switch D

DTE A2

Boundary of Local Implementation

Figure H.1

Leased Line Configuration Example

H.5.

Network Implementation

H.5.1.

Reliability

To increase service reliability, hosts on a given site should be connected to two DCEs belonging to
different network switches (this requirement should be specified to the network operator).

H.5.2.

Availability

H.5.2.1.

H.5.2.2.

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.

In the event other call mechanisms are implemented resulting in a different called DTE address value
in the CALL REQUEST and CALL ACCEPT packets, the calling DTE should be configured so there is
no impact on the setting up of the call.

H.5.2.3.

In the event of DCE disconnection due to a network failure and a second access to the network is
available, call re-establishment should be made via this second access.

H.5.3.

Security

Within the scope of this Annex, the Closed User Group (CUG) facility is the only applicable network
facility that should be used.

H.6.

General Guidance for Leased Line and Network Implementations

H.6.1.

Reliability

H.6.1.1.

As a full host switchover can be long, it is advantageous to consider the use a front-end processor
(FEP) to cater for host failures.

L 254/234

EN

Official Journal of the European Communities

9.10.2000

H.6.1.2.

An architecture based on an FEP can increase service reliability.

NOTE

Inclusion of a transport stack in the profile specification may be developed in the context of a future
FDE ICD Part 2 standard.

H.6.2.

Availability

When a call is unsuccessful, the calling site should make a second call using the second X.121 address
(if available).

H.6.3.

Systems Management

H.6.3.1.

The use of switches that are automatically toggled by scanning of the interface signals should be used
where possible.

H.6.3.2.

A local error indication during data transmission can be used to trigger a host switchover.

H.6.3.3.

The switchover of a FEP should generate a TC-disconnect to ensure the local host is in the IDLE state.

H.6.3.4.

On expiry of the time-outs on the X.25 network or datalink layers, the higher layers should be released.

H.6.3.5.

A total FEP failure should generate a TC-disconnect.

H.6.3.6.

The management system should poll the Message Transfer Protocol layer (Annex A) and check the
state machine to distinguish between a Message Transfer Protocol failure and an application failure.

H.6.4.

Configuration Example

+267(cid:3)$(cid:20)

+267(cid:3)$(cid:21)

Switch A

Switch B

Switch C

Switch D

FEP A1

DTE A1

FEP A2

DTE A2

Switch E

Switch F

DCE A1

,QWHUFRQQHFWHG

;(cid:21)(cid:24)(cid:3)1HWZRUN

DCE A2

Boundary of Local Implementation

Figure H.2

Network Configuration Example