The European Organisation for Civil Aviation Equipment

L’Organisation Européenne pour l’Equipement de l’Aviation Civile

Voice over Internet Protocol (VoIP)

Air Traffic Management (ATM) System
Operational and Technical Requirements

ED-136
“Month Year”

102 rue Etienne Dolet Tel: 33 1 40 92 79 30

92240 MALAKOFF, France Fax: 33 1 46 55 62 65
Web Site: www.eurocae.eu Email: eurocae@eurocae.net
 Voice over Internet Protocol (VoIP)
Air Traffic Management (ATM) System
Operational and Technical Requirements

ED-136
“Month Year”

© EUROCAE, 2009
 i

FOREWORD
1 The document ED-136 “Voice over Internet Protocol (VoIP) Air Traffic Management
(ATM) System Operational and Technical Requirements” was prepared by EUROCAE
Working Group 67 and was accepted by the Council of EUROCAE on “Month Year”.
2 EUROCAE is an international non-profit making organisation. Membership is open to
manufacturers and users in Europe of equipment for aeronautics, trade associations,
national civil aviation administrations and non-European organisations. Its work programme
is principally directed to the preparation of performance specifications and guidance
documents for civil aviation equipment, for adoption and use at European and world-wide
levels.
3 The findings of EUROCAE are resolved after discussion among its members and, where
appropriate, in collaboration with RTCA Inc, Washington D.C. USA and/or the Society of
Automotive Engineers (SAE), Warrendale, PA, USA through their appropriate committee.
4 The document represents “the minimum specification required for Manufacturers and Users
to assure Interoperability between VoIP ATM Components”.
5 EUROCAE performance specifications are recommendations only. EUROCAE is not an
official body of the European governments; its recommendations are valid statements of
official policy only when adopted by a particular government or conference of governments.
6 Copies of this document may be obtained from:

EUROCAE
102 rue Etienne Dolet
92240 MALAKOFF
France

Tel: 33 1 40 92 79 30
Fax: 33 1 46 55 62 65
Email: eurocae@eurocae.net
Web Site: http://www.eurocae.eu

© EUROCAE, 2009
 ii

TABLE OF CONTENTS
CHAPTER 1 INTRODUCTION................................................................................................................ 1
1.1 BACKGROUND..................................................................................................................... 1
1.2 ED-136 PRESENTATION ..................................................................................................... 3
1.3 TERMINOLOGY FOR REQUIREMENTS, RECOMMENDATIONS AND OPTIONS............ 3
CHAPTER 2 RADIO BASELINE REFERENCE CHAPTER.................................................................... 5
2.1 DEFINITIONS ........................................................................................................................ 5
2.2 INTRODUCTION ................................................................................................................... 9
2.2.1 Baseline model configuration diagrams......................................................................... 9
2.3 RADIO SYSTEM PERFORMANCE REQUIREMENTS ...................................................... 18
2.4 RADIO SYSTEM FUNCTIONAL REQUIREMENTS ........................................................... 21
2.5 DETECTION OF SIMULTANEOUS RADIO TRANSMISSIONS......................................... 32
2.5.1 Description ................................................................................................................... 32
2.5.2 Principal Requirement – Safety Warning..................................................................... 32
2.5.3 Case 1 – Two Frequencies F1 and F2 in Cross-Coupled Mode ................................. 32
2.5.4 Case 2 – One Ground Receiver .................................................................................. 33
2.5.5 Case 3 – Two Ground Receivers................................................................................. 34
2.5.6 Case 4– Simultaneous Pilot-Controller transmission .................................................. 36
CHAPTER 3 TELEPHONE BASELINE REFERENCE CHAPTER ....................................................... 37
3.1 DEFINITIONS ...................................................................................................................... 37
3.2 GROUND-GROUND VOICE COMMUNICATION SERVICES ........................................... 38
3.2.1 Communications within a FIR between ATSUs........................................................... 38
3.2.2 Communications within a FIR between ATSUs and other Units ................................. 38
3.2.3 Communications between Flight Information Regions (FIRs) ..................................... 39
3.2.4 Communications out of the ATS community ............................................................... 39
3.3 PRIMARY USER GROUND TELEPHONE FACILITIES..................................................... 40
3.3.1 Supervisory tones ........................................................................................................ 40
3.3.2 Direct Access (DA)....................................................................................................... 41
3.3.3 Instantaneous Access (IA)........................................................................................... 42
3.3.4 Indirect Access (IDA) ................................................................................................... 44
3.3.5 Call Priority................................................................................................................... 45
3.3.6 Instantaneous Access (IA) and Priority Call comparison............................................. 46
3.3.7 Typical call handling behaviour of new call events to CWP in pre-defined states ...... 47
3.3.8 Call Intrusion ................................................................................................................ 48
3.3.9 Call Interruption............................................................................................................ 49
3.3.10 Simultaneous Calls ...................................................................................................... 49
3.3.11 Call Queuing Facility.................................................................................................... 50
3.4 SUPPLEMENTARY TELEPHONE SERVICES................................................................... 52
3.4.1 Inter-ATSU Supplementary Telephone Services......................................................... 52
3.4.2 ATSU Internal Supplementary Telephone Services .................................................... 52
3.5 ADDRESSING AND NUMBERING SCHEMES .................................................................. 54
3.5.1 Numbering Schemes ................................................................................................... 54
3.5.2 Number or Address Assignment.................................................................................. 54
3.5.3 Global Numbering Schemes........................................................................................ 54
3.6 EXTERNAL CONNECTIONS AND PROTOCOLS.............................................................. 55
3.6.1 Signalling in an IP AGVN............................................................................................. 55
3.6.2 External Connections and associated Protocols ......................................................... 55
3.7 INTERWORKING WITH ATS LEGACY SYSTEMS ............................................................ 56
3.8 CONNECTIVTY WITH PRIVATE AND PUBLIC TELEPHONE NETWORKS .................... 57
3.9 INCOMING CALL BARRING AND RESTRICTION............................................................. 57
3.10 HANDLING OF OUTGOING CALLS / ROUTING CRITERIA ............................................. 58
CHAPTER 4 SAFETY AND AVAILABILITY .......................................................................................... 59
4.1 DEFINITIONS ...................................................................................................................... 59
4.2 INTRODUCTION ................................................................................................................. 59
4.3 ASSUMPTIONS .................................................................................................................. 59
4.4 SAFETY ASPECTS ASSOCIATED WITH DIFFERENT TYPES OF VOICE SERVICES .. 60
4.4.1 Introduction .................................................................................................................. 60
4.4.2 Call type discrimination during call establishment phase ............................................ 60
4.4.3 Precedence of Voice services ..................................................................................... 60

© EUROCAE, 2009
 iii

4.4.4 IP-voice packets priviliged ........................................................................................... 61

4.4.5 IP-voice / IP-data packet flow separation .................................................................... 61
4.4.6 No QoS degradation of IP-voice .................................................................................. 61
4.4.7 Precedence Level assignment of Voice Services....................................................... 62
4.4.8 Precedence of Voice packets during Congested or degraded network operation ...... 62
4.5 AVAILABILITY: ISSUES, GUIDANCE AND MAIN PRINCIPLES ....................................... 62
4.5.1 Introduction .................................................................................................................. 62
4.5.2 Availability Issues......................................................................................................... 62
4.5.3 Points of Guidance....................................................................................................... 63
4.5.4 Illustrative Case Examples .......................................................................................... 64
CHAPTER 5 RECORDING ................................................................................................................... 66
5.1 BACKGROUND................................................................................................................... 66
5.2 RECORDING REQUIREMENTS’ ASSERTIONS ............................................................... 66
5.3 RECORDING REQUIREMENTS......................................................................................... 67
5.3.1 Short Term recording at CWP ..................................................................................... 67
CHAPTER 6 VOICE QUALITY.............................................................................................................. 68
6.1 INTRODUCTION ................................................................................................................. 68
6.2 REFERENCES .................................................................................................................... 68
6.3 REQUIREMENTS................................................................................................................ 68
6.3.1 Voice Transmission Quality ......................................................................................... 68
6.3.2 Talker-Echo tolerance.................................................................................................. 69
6.3.3 One-Way Voice delay (Telephone).............................................................................. 70
6.3.4 One-Way Voice delay (Radio) ..................................................................................... 70
6.3.5 Syllable Clipping .......................................................................................................... 70
6.3.6 Clipping Speech Segments ......................................................................................... 70
6.3.7 Voice Transmission Characteristics............................................................................. 70
6.3.8 Voice Frequency Response......................................................................................... 71
6.3.9 Cross-Talk.................................................................................................................... 71
6.3.10 Noise and Hum ............................................................................................................ 71
6.3.11 Total Distortion, including quantizing distortion ........................................................... 71
CHAPTER 7 SYSTEM ENGINEERING AND MANAGEMENT............................................................. 72
7.1 MANAGEMENT AND MONITORING.................................................................................. 72
7.1.1 Basic Definitions and Considerations .......................................................................... 72
7.1.2 Management Interfaces related to the Vienna Agreement.......................................... 75
7.2 SYSTEM ENGINEERING GENERAL REQUIREMENTS ................................................... 77
7.2.1 Redundancy................................................................................................................. 77
7.2.2 Statistics / General....................................................................................................... 77
7.2.3 Statistics / Incoming calls............................................................................................. 77
7.2.4 Statistics / Outgoing calls............................................................................................. 78
7.2.5 Maximum number of CWPs......................................................................................... 78
7.2.6 Operational use of system functionalities .................................................................... 78
7.2.7 Hardware architecture ................................................................................................. 78
7.2.8 System Circuit Check .................................................................................................. 78
7.2.9 Detection of End-to-End Connection Loss .................................................................. 79
7.2.10 Transit .......................................................................................................................... 79
7.2.11 Classes of Service ....................................................................................................... 79
7.2.12 VCS on-line reconfiguration......................................................................................... 79
7.2.13 Audio-mixing capabilities ............................................................................................. 81
7.2.14 Loss of Power .............................................................................................................. 81
7.3 RECORDING SYSTEM ENGINEERING REQUIREMENTS .............................................. 81
7.3.1 Voice Recording........................................................................................................... 81
7.4 TELEPHONE SYSTEM ENGINEERING REQUIREMENTS .............................................. 82
7.4.1 Conference .................................................................................................................. 82
7.4.2 Public Network Security............................................................................................... 82
7.5 RADIO SYSTEM ENGINEERING REQUIREMENTS ......................................................... 82
CHAPTER 8 SECURITY ....................................................................................................................... 86
8.1 INTRODUCTION ................................................................................................................. 86
8.2 ASSUMPTIONS .................................................................................................................. 86
8.3 SECURITY REQUIREMENTS ............................................................................................ 87
8.3.1 Integrity of IP-voice packets......................................................................................... 87

© EUROCAE, 2009
 iv

8.3.2 Confidentiality of IP-voice information ......................................................................... 87

8.3.3 Authenticity of IP-voice packet originator .................................................................... 87
8.3.4 Authenticity of Radio and Telephone IP-voice packet origin ....................................... 87

ANNEX A REFERENCES ..................................................................................................................... 88

ANNEX B ACRONYMS ......................................................................................................................... 92
ANNEX C PAN-EUROPEAN NETWORK SERVICES (PENS) Security Requirements ....................... 95
ANNEX D CROSS-COUPLING MODES OF OPERATION .................................................................. 96
ANNEX E LIST OF EUROCAE WG-67 SUB-GROUP 1 CONTRIBUTORS....................................... 100

© EUROCAE, 2009
 v

FIGURE INDEX
Figure 1: Vienna Agreement ................................................................................................................... 2
Figure 2: Call establishment controller –pilot (Ground – Air) ................................................................ 10
Figure 3: Call establishment pilot –controller (Air – Ground) ................................................................ 11
Figure 4: PTT- A/C call indication (Round-trip) delay............................................................................ 12
Figure 5: Call establishment Pilot – Pilot (Air-Air) ................................................................................. 13
Figure 6: Call establishment Controller – Pilot(s) (Ground–Air with Frequency Cross Coupled) ......... 14
Figure 7: Call establishment Pilot – Controller – Pilot (Air–Ground with Frequency Cross Coupled)... 15
Figure 8: Call establishment Controller–Pilot (Ground – Air with Multi-carrier/Climax)........................ 16
Figure 9: Call establishment Pilot – Controller (Air–Ground with Best Signal Selection) .................... 17
Figure 10: Signalling Delay Requirement.............................................................................................. 18
Figure 11: Voice Delay Requirement (ground components) ................................................................. 19
Figure 12: Example of echo induction caused by delayed reception of same message on different
frequencies F1, F2 and F3..................................................................................................... 23
Figure 13: Simultaneous Transmissions with two frequencies in Cross-Coupled mode. .................... 32
Figure 14: One ground receiver detects both signals of a Simultaneous Transmission....................... 33
Figure 15: Two ground receivers each detect different signals of a Simultaneous Transmission ....... 34
Figure 16: Detection of additional aircraft calls through time difference diagnosis between 2 signals
from 2 radio stations............................................................................................................... 35
Figure 17: Two ground receivers each detect both signals of a Simultaneous Transmission .............. 35
Figure 18: Simultaneous Transmission by Pilot and Controller transmission on the same frequency 36
Figure 19: Operations, Technical architecture and Availability compliance methodology .................... 65
Figure 20: ITU-T G.131 – Talker echo tolerance curves....................................................................... 69
Figure 21: User and Service Management............................................................................................ 73
Figure 22: Illustration of Radio and/or Telephone System .................................................................... 74
Figure 23: Management Services when applied to Vienna Agreement ................................................ 75
Figure 24: Telephone On-line reconfiguration example ........................................................................ 81

© EUROCAE, 2009
 vi

TABLE INDEX
Table 1 – Common facility and service requirements ........................................................................... 22
Table 2 – Supervisory tone definition .................................................................................................... 40
Table 3 – Instantaneous Call-Priority Call comparison ......................................................................... 46
Table 4 – Call handling behaviour for pre-defined CWP states on new call events ............................. 47
Table 5 – Examples of generic identities............................................................................................... 51
Table 6 – Interface and Protocol support documents ........................................................................... 55
Table 7 – Circuit-Switched and Packet-Switched Call interworking...................................................... 56
Table 8 – Association between Call types and the SIP Priority Header field........................................ 60
Table 9 – Example of Voice Services precedence scheme .................................................................. 61
Table 10 – ITU-T G.109- Relationship between E-model (R), MOS and Speech Transmission quality
category.................................................................................................................................. 68
Table 11 – Illustration of Cross-coupling modes functionality ............................................................... 97
Table 12 – Cross-coupling combinations- Frequency F1d received first .............................................. 98
Table 13 – Cross-coupling combinations- Frequency F3s received first .............................................. 99

© EUROCAE, 2009
 vii

REQUIREMENTS INDEX

RADIO SYSTEM PERFORMANCE REQUIREMENTS

1 [REQ RADIO PERFORMANCE] Speech Signalling Integrity necessary......................................... 18
2 [REQ RADIO PERFORMANCE] End-to-End signalling integrity necessary.................................... 18
3 [REQ RADIO PERFORMANCE] 100ms max Transmitter Activation Delay .................................... 18
4 [REQ RADIO PERFORMANCE] 100ms max Aircraft Call Indication Delay .................................... 19
5 [REQ RADIO PERFORMANCE] 250ms max Cross-coupled PTT inhibition period, XC2............... 19
6 [REQ RADIO PERFORMANCE] 130ms max Ground Transmission Voice delay ........................... 19
7 [REQ RADIO PERFORMANCE] 10ms max Voice delay differential for Climax operation.............. 20
8 [REQ RADIO PERFORMANCE] 130ms max Ground reception voice delay .................................. 20
9 [REQ RADIO PERFORMANCE] Transmit signal speech clipping <64ms....................................... 20
10 [REQ RADIO PERFORMANCE] Receive signal speech clipping <64ms....................................... 20

RADIO SYSTEM FUNCTIONAL REQUIREMENTS

1 [REQ RADIO FUNCTIONAL] Radio Access Modes of Operation ................................................... 21

2 [REQ RADIO FUNCTIONAL] Transmit Configuration description ................................................... 21
3 [REQ RADIO FUNCTIONAL] Speechless communications necessary........................................... 21
4 [REQ RADIO FUNCTIONAL] Remote Control Equipment functionality .......................................... 21
5 [REQ RADIO FUNCTIONAL] Radio Gateways backwards compatible with legacy systems.......... 22
6 [REQ RADIO FUNCTIONAL] No voice distortion when simultaneous reception on different
frequencies ....................................................................................................................................... 22
7 [REQ RADIO FUNCTIONAL] Reception Delay differential at a CWP resulting from simultaneous
transmissions from another CWP .......................................................................................... 23
8 [REQ RADIO FUNCTIONAL] Parameters for CWP info display...................................................... 23
9 [REQ RADIO FUNCTIONAL] Frequency technical state info display.............................................. 23
10 [REQ RADIO FUNCTIONAL] 300ms max frequency key activation response time ...................... 23
11 [REQ RADIO FUNCTIONAL] 300ms max frequency key status change response time............... 24
12 [REQ RADIO FUNCTIONAL] Facility isolation/disconnection warning.......................................... 24
13 [REQ RADIO FUNCTIONAL] Frequency blocking prevention....................................................... 24
14 [REQ RADIO FUNCTIONAL] Simultaneous multiple frequency selections for transmission and
reception ........................................................................................................................................ 24
15 [REQ RADIO FUNCTIONAL] Cross-coupling facility to be implemented ...................................... 24
16 [REQ RADIO FUNCTIONAL] Quantity of Frequencies in a cross-coupled frequency group ........ 25
17 [REQ RADIO FUNCTIONAL] Two Cross-Coupled frequency mode ............................................. 25
18 [REQ RADIO FUNCTIONAL] Three Cross-Coupled frequency mode........................................... 25
19 [REQ RADIO FUNCTIONAL] Clear cross-coupled frequency indications ..................................... 25
20 [REQ RADIO FUNCTIONAL] Identical frequencies not allowed in two cross-coupling sessions.. 25
21 [REQ RADIO FUNCTIONAL] Cross-Coupling frequency selection refusal indication................... 25
22 [REQ RADIO FUNCTIONAL] PTT precedence over Cross-coupling transmission....................... 26
23 [REQ RADIO FUNCTIONAL] Aircraft call/cross-coupled frequency distinction............................. 26
24 [REQ RADIO FUNCTIONAL] First received A/C call used as cross-coupled group’s incoming
frequency ....................................................................................................................................... 26
25 [REQ RADIO FUNCTIONAL] Climax operation to be implemented .............................................. 26
26 [REQ RADIO FUNCTIONAL] Echo prevention for Climax operation............................................. 27
27 [REQ RADIO FUNCTIONAL] Best Signal Selection functionality to be implemented ................... 27
28 [REQ RADIO FUNCTIONAL] Best Signal Selection Functionality Manual de-selection .............. 27
29 [REQ RADIO FUNCTIONAL] Manual De-selection of Best Signal Selection individual receiver(s)
............................................................................................................................................... 27
30 [REQ RADIO FUNCTIONAL] No signal degradation on Best Signal Selection receiver changeover
............................................................................................................................................... 27
31 [REQ RADIO FUNCTIONAL] BSS time delay difference compensation ....................................... 27
32 [REQ RADIO FUNCTIONAL] Mixed received signal echo compensation ..................................... 28
33 [REQ RADIO FUNCTIONAL] PTT & A/C call locked-on condition prevention .............................. 28
34 [REQ RADIO FUNCTIONAL] Off-air side tone generation ............................................................ 28

© EUROCAE, 2009
 viii

35 [REQ RADIO FUNCTIONAL] Duplex and Simplex Cross-coupling functionality support............. 29

36 [REQ RADIO FUNCTIONAL] Receiver Status Notification............................................................ 29
37 [REQ RADIO FUNCTIONAL] Transmitter Status Notification........................................................ 30
38 [REQ RADIO FUNCTIONAL] Selected Transmitter Rejection Notification.................................... 30
39 [REQ RADIO FUNCTIONAL] PTT failure notification .................................................................... 30
40 [REQ RADIO FUNCTIONAL] PTT identity notification................................................................... 31

DETECTION OF SIMULTANEOUS RADIO TRANSMISSIONS

1 [REQ RADIO SIMULTANEOUS] Simultaneous Transmissions........................................................ 32

GROUND-GROUND VOICE COMMUNICATION SERVICES

1 [REQ TEL SERVICES] Ground-Ground voice communication services ........................................ 38

PRIMARY USER GROUND TELEPHONE FACILITIES

1 [REQ TEL FUNCTIONAL] Supervisory tones .................................................................................. 40
2 [REQ TEL FUNCTIONAL] Direct Access Calls ................................................................................ 41
3 [REQ TEL FUNCTIONAL] Instantaneous Access Calls................................................................... 42
4 [REQ TEL FUNCTIONAL] Prevention of Eavesdropping................................................................. 44
5 [REQ TEL FUNCTIONAL] Indirect Access calls .............................................................................. 44
6 [REQ TEL FUNCTIONAL] Call Priority............................................................................................. 45
7 [REQ TEL FUNCTIONAL] Instantaneous Access / Priority Call comparison .................................. 46
8 [REQ TEL FUNCTIONAL] Call Intrusion .......................................................................................... 48
9 [REQ TEL FUNCTIONAL] Call Interruption...................................................................................... 49
10 [REQ TEL FUNCTIONAL] Simultaneous Calls .............................................................................. 49
11 [REQ TEL FUNCTIONAL] Call Queuing Facility............................................................................ 50
12 [REQ TEL FUNCTIONAL] Inter-ATSU Supplementary Telephone Services................................. 52
13 [REQ TEL FUNCTIONAL] Numbering Schemes ........................................................................... 54
14 [REQ TEL FUNCTIONAL] Number assignment............................................................................. 54
15 [REQ TEL FUNCTIONAL] Global numbering schemes ................................................................. 54
16 [REQ TEL FUNCTIONAL] External connections and protocols..................................................... 55
17 [REQ TEL FUNCTIONAL] Interworking with ATS Legacy Systems .............................................. 56
18 [REQ TEL FUNCTIONAL] Private & Public Telephone network connectivity................................ 57
19 [REQ TEL FUNCTIONAL] Incoming call barring & restriction........................................................ 57
20 [REQ TEL FUNCTIONAL] Outgoing Calls/Routing Criteria ........................................................... 58

1 [REQ TEL PERFORMANCE] Direct Access Performance Criteria ................................................. 42

2 [REQ TEL PERFORMANCE] Instantaneous Access Performance Criteria .................................... 44

SAFETY AND AVAILABILITY

1 [REQ SAFETY] Call type discrimination during call establishment phase....................................... 60
2 [REQ SAFETY] Precedence of voice services on transport infrastructure ...................................... 60
3 [REQ SAFETY] IP-voice packets privileged..................................................................................... 61
4 [REQ SAFETY] IP-voice / IP-data packet flow separation ............................................................... 61
5 [REQ SAFETY] No QoS degradation of IP-voice............................................................................. 61
6 [REQ SAFETY] Precedence level assignment of voice services..................................................... 62
7 [REQ SAFETY] Precedence of voice packets during Congested or degraded network operation.. 62

© EUROCAE, 2009
 ix

RECORDING
1 [REQ RECORDING] True and faithful representation of audio signal .............................................. 67
2 [REQ RECORDING] Provision for 2 identical autonomous voice recordings ................................... 67
3 [REQ RECORDING] Date & Timestamp Synchronization ................................................................ 67
4 [REQ RECORDING] Entities for voice recording and location identification .................................... 67
5 [REQ RECORDING] Voice recording all communications at CWP .................................................. 67

VOICE QUALITY
1 [REQ VOICE QUALITY] Mean Opinion Score of A/G & G/G communications >4 .......................... 68
2 [REQ VOICE QUALITY] Talker-echo tolerance compliant with ITU-T G.131 .................................. 69
3 [REQ VOICE QUALITY] One-way voice delay (telephone)<150ms ................................................ 70
4 [REQ VOICE QUALITY] One-Way voice delay (radio) <130ms ...................................................... 70
5 [REQ VOICE QUALITY] Speech Clipping segments ≥64ms avoided,<64ms within 0.2% of active
speech .............................................................................................................................................. 70
6 [REQ VOICE QUALITY] Voice transmission characteristics............................................................ 70
7 [REQ VOICE QUALITY] Ground-Ground voice frequency response ............................................. 71
8 [REQ VOICE QUALITY] Cross-Talk level <-60dBm0 for 1KHz test tone ........................................ 71
9 [REQ VOICE QUALITY] Noise and Hum ......................................................................................... 71
10 [REQ VOICE QUALITY] Total Distortion, including quantizing distortion ...................................... 71

SYSTEM ENGINEERING AND MANAGEMENT

1 [REQ SYS ENG] Management Provisions Baseline ........................................................................ 72
2 [REQ SYS ENG] Management Provision Levels ............................................................................. 73
3 [REQ SYS ENG] Management Service on the VCS Interface IfRadio/Telephone .................................... 75
4 [REQ SYS ENG] Management Service on the Radio Interface IfRadio .............................................. 76
5 [REQ SYS ENG] Management Service on the VCS Interface IfRecording ........................................... 76
6 [REQ SYS ENG] Interface Standards .............................................................................................. 76
7 [REQ SYS ENG] Management System............................................................................................ 76
8 [REQ SYS ENG] No single points of failure ..................................................................................... 77
9 [REQ SYS ENG] Call Detail Records/System Performance statistical reporting & analysis ........... 77
10 [REQ SYS ENG] Statistical analysis of incoming calls ................................................................... 77
11 [REQ SYS ENG] Statistical analysis of outgoing calls .................................................................... 78
12 [REQ SYS ENG] No architectural limit of active CWPs .................................................................. 78
13 [REQ SYS ENG] Simultaneous use of any system functionality combination ................................ 78
14 [REQ SYS ENG] Redundant components in separate locations .................................................... 78
15 [REQ SYS ENG] System Circuit Check .......................................................................................... 78
16 [REQ SYS ENG] Detection of End-to-End Connection Loss .......................................................... 79
17 [REQ SYS ENG] Transit Capabilities .............................................................................................. 79
18 [REQ SYS ENG] Classes of Service............................................................................................... 79
19 [REQ SYS ENG] VCS on-line re-configuration ............................................................................... 80
20 [REQ SYS ENG] VCS on-line re-configuration without impacts on neighbouring centres ............. 80
21 [REQ SYS ENG] VCS on-line re-configuration without impacts on established calls..................... 80
22 [REQ SYS ENG] Routing method to establish calls during on-line re-configuration ..................... 80
23 [REQ SYS ENG] Audio-mixing capabilities ..................................................................................... 81
24 [REQ SYS ENG] End to End System Check .................................................................................. 81
25 [REQ SYS ENG] No limit for number of simultaneous activated conferences................................ 82
26 [REQ SYS ENG] Public Network Security....................................................................................... 82
27 [REQ SYS ENG] Radio Gateway of IP transmitter/receiver spec to define different physical layer
architectures .................................................................................................................................. 82
28 [REQ SYS ENG] System to operate all frequencies simultaneously ............................................. 82
29 [REQ SYS ENG] Transmitter/Receiver selection options .............................................................. 82
30 [REQ SYS ENG] Maximum of 7 channels assigned to a frequency .............................................. 83
31 [REQ SYS ENG] Quantity of frequencies in a cross-coupled group.............................................. 83
32 [REQ SYS ENG] No limit on number of cross-coupled groups...................................................... 83
33 [REQ SYS ENG] Maximum of 7 channels in a Climax group ........................................................ 83

© EUROCAE, 2009
 x

34 [REQ SYS ENG] Maximum of 7 channels for BSS operation ........................................................ 83

35 [REQ SYS ENG] Speech Activity Detector with Pseudo Squelch signal generation ..................... 83
36 [REQ SYS ENG] Automated Radio check during PTT .................................................................. 83
37 [REQ SYS ENG] Automatic or manual channel check .................................................................. 84
38 [REQ SYS ENG] VCS switching capabilities at Ground Radio Station.......................................... 84
39 [REQ SYS ENG] Alarm for non-selected frequencies.................................................................... 84
40 [REQ SYS ENG] Automatic Gain Control for Tx & Rx speech levels ............................................ 84
41 [REQ SYS ENG] Easy access to monitor VCS signalling.............................................................. 85
42 [REQ SYS ENG] Headset Operation ............................................................................................. 85
43 [REQ SYS ENG] Date and Time reference source........................................................................ 85
44 [REQ SYS ENG] Evolution (Modification/Upgrade) capability ....................................................... 85

SECURITY
1 [REQ SECURITY] Radio and Telephone IP-voice packet authenticity............................................. 87

© EUROCAE, 2009
 1

CHAPTER 1

INTRODUCTION

1.1 BACKGROUND
Ground-Ground (G-G) ATM voice systems have been based upon analogue and more recently, digital
Time Division Multiplexing / Pulsed Code Modulation (TDM/PCM) technologies for many years.

Nowadays, however, convergence of voice and data into one multimedia network is a popular trend
with a variety of technical solutions available on the market. Following in this direction ATM
communication networks are adopting, by a process of gradual evolution, a common infrastructure for
voice and data services.

As the technology has developed IP Technology has now the true potential to fulfil operational and
technical ATM communication requirements - including those of voice / data convergence, Quality of
Services (QoS), security and safety. There is also the possibility that IP may deliver solutions that will,
over time, bring about true savings in investment and operating costs.

EUROCAE Working Group 67 (WG-67) undertook the mission to assess the feasibility of using Voice
over Internet Protocol (VoIP) for providing ATM voice services. The group defined criteria,
requirements and guidelines based upon the following operational needs and constraints:

• Operational and Technical Air-Ground (A-G) and Ground-Ground (G-G) ATM Voice
system requirements
• Existing IP Voice protocols and signalling standards
• IP network capabilities for Voice services
• Security, Quality of Service (QoS), and Convergence (infrastructure, protocol,
applications)
• Existing IP Voice ATM system capabilities and service interfaces.

The following tasks were identified to fulfil the WG-67 mission:-

• Define ATM Systems and identify their components (Voice Communication System /
VCS, Ground Radio Station)
• Determine possible additional operational and technical ATM requirements for new
ATM voice systems, also taking into consideration A-G communications.
• Make recommendations to upgrade current standardisation documents.
• Develop a Technical Specification for a VoIP Voice ATM System including:
o Minimum performance and safety/security requirements for the system and, if
appropriate, for components;
o Interoperability requirements between IP components of the VoIP ATM system;
o Minimum performance requirements of an IP Network to support ATM Voice
services;
o Guidelines for qualification tests of VoIP ATM systems and their components.

© EUROCAE, 2009
 2

Consequently the following four documents were delivered:

ED-136 - VoIP ATM System Operational and Technical Requirements

ED-137 - Interoperability Standards for VoIP ATM Components

ED-138 - Network Requirements and Performances for VoIP ATM Systems

ED-139 - Qualification tests for VoIP ATM Components and Systems

The contents of all four documents are premised on the “Vienna Agreement” which defines the
different components of a VoIP ATM system and their mutual interfaces as depicted in Figure 1.

F ig u r e 1 : V i e n n a A g r ee m en t

VoIP components are interconnected through an IP network and suppliers are free to define their
internal architecture (IP/Ethernet, TDM/PCM - Time Division Multiplexing/Pulsed Code Modulation,…).
Between VoIP components, required interfaces are defined to guarantee their functional and technical
interoperability.

Therefore, VoIP ATM Systems are composed of:

• VoIP VCS Components performing Radio and / or Telephone functions, including:

1. Controller Working Positions, assuring HMI including voice devices (microphone and
loudspeaker);
2. Possible local VCS Maintenance and Configuration stations;
3. Possible local Recording devices;
4. Possible LAN for local interconnection;
5. Possible Media Gateways to legacy systems (ATS-QSIG, ATS-R2, ATS-No.5, PSTN,

© EUROCAE, 2009
 3

Radio analogue lines, …).

• VoIP Ground Radio Station Components performing AM VHF and UHF Radio functions.

• VoIP Supervision System Components performing monitoring and control functions.

• VoIP Recording Components performing recording functions.

• IP WAN Components performing interconnection services between two or more different

physical components.

1.2 ED-136 PRESENTATION

The scope of WG67 ED-136 is to specify the Operational and Technical Requirements of an Air Traffic
Management (ATM) Voice Communications System. To achieve this objective many potential sources
of these requirements were investigated including ICAO SARPs, EUROCONTROL Guidance
documents as well as individual ANSP specifications.

It was decided at an early stage to produce the requirements without considering any potential
technical solutions. It was also decided to concentrate on defining requirements that had a direct
bearing on the final system architecture; an example of this are the recording requirements in Chapter
V. The boundaries were established as illustrated in the ‘Vienna Agreement’ but it was often found
necessary to stray outside of this in order to ensure that some requirements were set in the context of
a complete system.

It will be observed in CHAPTER 2 RADIO BASELINE REFERENCE CHAPTER, that this section
contains a ‘Baseline Model’ of the radio system. As may be appreciated a considerable amount of
effort was expended in producing this but this was found to be absolutely necessary in order to ensure
that the timing parameters and latency values were clearly delineated. This is one of several
descriptive documents produced by the Sub-Group 1 which has found appreciation outside of the
scope of EUROCAE WG-67.

1.3 TERMINOLOGY FOR REQUIREMENTS, RECOMMENDATIONS AND

OPTIONS
The terminology for requirements, recommendations and options in this document is based on RFC
2119 [44], which specifies Best Current Practice regarding the use of Key Words for the Internet
Community. As such, the following terminology is applied:

• The word SHALL denotes a mandatory requirement;

• The word SHOULD denotes a recommendation;
• The word MAY denotes an option.

To avoid confusion with their natural meanings in the English language, the words SHALL, SHOULD,
and MAY take on the meaning stated above only where printed in boldface. When printed in normal
(Arial) typeface, the natural English meaning is meant.

Detailed description of terminology:

1. SHALL This word has the same meaning as the phrase "REQUIRED" and means that
the definition is an absolute requirement of the specification.

2. SHALL NOT This phrase means that the definition is an absolute prohibition of the
specification.

3. SHOULD This word, or the adjective "RECOMMENDED", means that there may exist
valid reasons in particular circumstances to ignore a particular item, but the

© EUROCAE, 2009
 4

full implications must be understood and carefully weighed before choosing a

different course.

4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" means that there may
exist valid reasons in particular circumstances when the particular behaviour
is acceptable or even useful, but the full implications should be understood
and the case carefully weighed before implementing any behaviour described
with this label.

5. MAY This word, or the adjective "OPTIONAL", means that an item is truly optional.

© EUROCAE, 2009
 5

CHAPTER 2

RADIO BASELINE REFERENCE CHAPTER

2.1 DEFINITIONS
The following terms are used in this document:

• A/C Call Indication: A/C Call is a term used at the Controller Working Position (CWP)
meaning that a transmission is being received on a particular frequency. This event is usually
indicated by means of a lamp or other display device.

• A/C TxRx: Aircraft combined Transmitter/Receiver “Transceiver”

• Aircraft Call Indication Delay (ACD): The end-to-end delay between a transmission being
received at the ground radio station antenna and the A/C call indication at the Controller
Working Position (CWP)

• ARx: A timing parameter associated with a signal received by an aircraft

• ATx: A timing parameter associated with a signal transmitted from an aircraft

• Best Signal Selection Input Delay Differential (BIDD): the comparative time difference
between two received signals as inputs to a VCS BSS Device (Refer to Fig.8)

• BIDD Max: The maximum value of BIDD as specified by the VCS supplier

• BIDD Variation/Jitter: The range by which BIDD MAY vary over time.

• Best Signal Selection (BSS) Delay: The time taken for BSS to be completed.

• Best Signal Selection (BSS): A process by which a particular radio audio signal is selected
“as best” for presentation to the User - and retransmission if cross-coupling is selected.

Note 1: It is assumed that a radio audio signal is presented to the User immediately

Note 2: How BSS is achieved is beyond the scope of this document.

• Call Established: A call established condition exists when a one-way voice channel (i.e. in
half-duplex radio operation) is fully available for use between two Users.

• Call Establishment Delay (CED): The total time taken between the Push-To-Talk (PTT)
action by a User and the time for the squelch to operate in the called party’s receiver. After
this time a Call Established condition exists. This is assumed to be equivalent to the FAA
term “Voice Channel Set-up delay” below

• Called Party: The User who receives the transmission from the Calling Party.

• Calling Party: The User who initiates a transmission by means of their Push-To-Talk (PTT)
key.

• CLIMAX: - see ‘Multi-Carrier’

• Controller Working Position (CWP): Contains all the HMI components (i.e. radio, telephone
and radar facilities etc) as may be required to carry out operational duties (See also “Sector
Suite”).

© EUROCAE, 2009
 6

• Cross-coupling Duplex Mode: All received frequencies in Duplex Mode may be re-
transmitted on all the other frequencies in a Cross-Coupled Group - but only one at a time.
The received frequency re-transmitted is always presented at the CWP.

• Cross-coupled group: Two or more frequencies may be assigned to an individual Cross-

Coupled Group. A Cross-Coupled Group may consist of both Simplex Mode and Duplex Mode
frequencies.

• Cross-coupling Simplex Mode: Received frequencies in Simplex Mode are never re-
transmitted on other frequencies in a Cross-Coupled Group

• ECMA: An international industry association dedicated to the standardisation of information

and communication systems.

• GRx: A timing parameter associated with a signal received on the ground.

• GTx: A timing parameter associated with a signal to be transmitted from the ground.

• Multi-carrier: Multi-carrier operation in the ground to air direction is achieved by using the off-
set carrier or Climax system. This technique allows up to 5 separate radio stations to
simultaneously transmit the same audio signal using a single frequency assignment, but each
using a discrete carrier frequency that is off-set from the assigned frequency. As part of the
Climax methodology, different offsets are applied to the assigned channel frequency of each
transmitter to prevent the heterodyne frequency (audible) distorting the demodulated signals
received by aircraft transceivers.

• Nominal frequency: The expression is used to indicate that a numerical value is not
necessarily the precise frequency being used. As an example a sector frequency given in the
Aeronautical Information Publication (AIP) may be the Nominal value of the centre frequency
used in a Climax / Multi-Carrier radio service.

• Off-Set Carrier: - see ‘Multi-Carrier’

• PTT- A/C Call Round-Trip Delay: The total time taken between a User operating their Push-
To-Talk (PTT) key and when an A/C Call indication appears on their CWP.

• Push-To-Talk Delay (PTTD): This is the delay arising from the need to operate a transmitter
remotely and would be nil if the User was actually physically located in the same place as the
transmitter.

• PTT Key: Push to Talk Key – a physical device for carrying out a Push-To-Talk (PTT) action.

• Push To Talk (PTT): The physical action taken by the User in operating their transmit key.
The term “Key” is used to denote any type of device including buttons, levers, foot switches,
computer mouse and LCD/Plasma panel segments etc.

• Radio Control Equipment (RCE): used to control radio transmitters and receivers remotely
on the ground.

• Radio Control Equipment – Local (RCE-L): RCE in the locality of the controller.

• Radio Control Equipment - Remote (RCE-R): RCE remote from the controller (i.e. located at
the radio station).

© EUROCAE, 2009
 7

• Receiver Activation Time (RAT): The total time taken for a receiver to have detected the
presence of a radio signal of desired minimum quality, causing both the Automatic Gain
Control (AGC) proceeded by the squelch mechanism to operate. After this time period the
audio channel is fully available within the receiver to present any de-modulated audio at the
receiver audio output.

• Receiver De-activation Time (RDAT): The total time taken for a receiver to have detected
the absence of a radio signal that had previously caused Receiver Activation resulting in
inhibition of the Automatic Gain Control (AGC) and de-activation of the squelch mechanism.
After this time period the audio channel is silent with no audio at the receiver audio output.

• Receiver Recovery After Transmission (RRAT): Receiver Recovery after Transmission

A timing parameter characterising the airborne transceiver operation and specifying the time
taken for the receiver audio level after transmission to return to and remain within 3 dB of the
steady output obtained with an input signal of 10 microvolts (-93 dBm), modulated 30% at
1000 Hz. (Reference: ED-23B – Minimum Operational Performance Specification for Airborne
VHF Receiver – Transmitter operating in the Frequency Range 117.975 – 136.975 MHz
(March 1995)) [23].

Note 3: A similar parameter would characterise the ground transceiver operation although
reference is not made by ETSI EN 300 676 [36]
.
• Sector Suite: A number of Controller Working Positions (CWPs) that are co-located so that a
number (typically two or three) Users perform the function of managing a defined area or
sector of airspace. As an example a typical Sector Suite MAY be manned by a Controller,
Planner and an Assistant each with their own CWP.

• Squelch Delay (SqD): The delay arising from the need to operate the squelch output device
at a location remote from the receiver (usually a Controller Working Position – if installed) and
would be nil if the User was actually physically located in the same place as the receiver.

• System: implies entire VCS, Controller Working Positions, IP WAN, radio gateways, ground-
ground elements of radio equipment - and all related internal and external interfaces.

• Transmitter Activation Delay Differential (TADD): the comparative difference in time taken
for two transmitters to be activated when keyed from a common point. (Refer to Figure 8)

• Transmitter Activation Delay Differential (TADD) Max: The maximum value of TADD to
ensure satisfactory Multi-carrier/Climax operation.

• Transmitter Activation Delay Differential (TADD) Variation / Jitter: The range by which
TADD MAY vary over time.

• Transmitter Activation Delay (TAD): the total time taken between the Push-To-Talk (PTT)
action by the User and the time that the transmitter has attained the power level as detailed in
the Transmitter Activation Time (TAT) definition.

• Transmitter Activation Time (TAT): the total time taken for a transmitter to have attained a
nominal usable RF power output using a local Push-To-Talk (PTT). After this time the radio
frequency is regarded as being in use.

Note 4: ETSI EN 300 676 [36] specifies that 90% of designed operating power SHOULD be
achieved within this time.
FAA (NAS-SS-1000 Volume III) use an equivalent term called “Setup Delay” which specifies a
value of within 35 ms.

• Transmitter De-activation Time (TDAT): The total time taken for a transmitter power output
to have decayed to a nominal RF power output after removal of a local Push-To-Talk (PTT).
After this time the radio frequency is regarded as being free for further use.

© EUROCAE, 2009
 8

Note 5: ETSI EN 300 676 [36] specifies that a reduction to 10% of designed operating power
SHOULD be achieved within this time.
FAA (NAS-SS-1000 Volume III) specifies a value of within 35 ms.

Note 6: A similar parameter would characterise the airborne transceiver operation although
reference is not made by EUROCAE ED-23B [23]

• User: an Air Traffic Controller or other operational person carrying out the duties of Air Traffic
Management.

• Voice Communication System (VCS) or Voice Communication Control System (VCCS):

the main equipment providing radio (and telephone) facilities to the Controller Working
Position.

Note 7: The terms VCS and VCCS are equivalent for the purposes of this document.

• Voice Access Delay (VAD): the one-way user-to-user delay starting with Push-To-Talk
(PTT) operation and ending with audio appearing at the remote end of the link, but excluding
any human response times. (FAA definition).

• Voice Channel Setup Delay (VCSD): the time needed by the system to establish a path
between users, prerequisite for voice access and communications.(FAA definition). This is
assumed to be equivalent to Call Establishment Delay (CED) above.

• Voice Delay: the one-way User-to-User voice delay between analogue system interfaces
(Example: Controller microphone to Pilot Earphone) once the call is established.

• XC1 (Frequency coupling time): a timing parameter specifying the time taken for a VCS (or
other device) to couple one frequency to another. In practical terms this is the time taken for
an A/C Call (Squelch) signal as an input to the VCS to be converted to a Push-To-Talk (PTT)
signal as an output from the VCS. (Refer to Figure 7).

• XC2 (Cross-coupled Push-To-Talk Inhibition Period): a timing parameter specifying a

period imposed by a VCS (or other device) during which retransmission is inhibited after any
transmission (within the cross-coupled group) via the VCS has ended.
This inhibition is a technical solution necessary to prevent either cross-coupling oscillation
and/or blocking behaviour in cross-coupled mode.

• X-Couple (Cross-Coupling 2 or more radio frequencies): frequency cross-coupling is a

CWP selected function causing automatic retransmission of one received signal on other pre-
selected radio frequencies. With Cross-Coupling it is possible to merge a number of physical
radio frequencies into a kind of logical frequency.

© EUROCAE, 2009
 9

2.2 INTRODUCTION
The EUROCAE WORKING GROUP 67, SUB-GROUP 1 had the task of specifying requirements
relating to Air-Ground Radio. In order to progress this task it was found essential to produce a
Baseline Model of the current systems (how they are configured today) underpinned by an agreed
common set of terms and definitions. The model produced covers all the known system configurations:

• ‘Basic’ air-ground radio communications

• Multi-carrier (Climax) operations
• Frequency Cross-Coupled operations
• Best-signal selection
• Combinations of these may also be modelled, for example:- Combined Frequency Cross-
Coupled & Multi-Carrier operations

The model, covering all the above configurations, is expanded by a series of figures defined in section
2.2.1 below, in which each process (timing element) is labelled such that all those that contribute to
signalling and speech delays (latency effects) are clearly identified. It must be noted, however, that
some systems might not contain every element or that the effective latency is either negligible or nil.
Equally some elements may be combined into a single process so that the model would have to be
adapted accordingly.

Where some timing elements are subject to defined Standards these have been included in the model
as ‘given’ parameters. For the remainder it is necessary to include data from other sources such as
technical specifications or actual measurements. As a separate exercise EUROCAE Sub-Group 1 has
obtained measurement data from a number of European Air Navigation Service Providers (ANSPs)
such that ‘real-life’ data is available. It is this actual baseline data that Sub-Group 1 has taken as
guidance when formulating some of the Air-Ground Radio Requirements.

Sub-Group 1 are also aware of similar activities which have taken place in relation to the joint
EUROCONTROL/FAA Study “Communications Operating Concept and Requirements (COCR) of the
Future Radio System”. Whereas Sub-Group 1 is not concerned with Future Radio Systems it is
considered highly-desirable that all the parties concerned share a common view of current baseline
system characteristics and (of utmost importance) that the same terms and definitions are used.

2.2.1 Baseline model configuration diagrams

The following configuration diagrams have been defined:

• Figure 2: Call establishment controller –pilot (Ground – Air)

• Figure 3: Call establishment pilot –controller (Air – Ground)
• Figure 4: PTT- A/C call indication (Round-trip) delay
• Figure 5: Call establishment Pilot – Pilot (Air-Air)
• Figure 6: Call establishment Controller – Pilot(s) (Ground–Air with Frequency Cross Coupled)
• Figure 7: Call establishment Pilot – Controller – Pilot (Air–Ground with Frequency Cross
Coupled)
• Figure 8: Call establishment Controller–Pilot (Ground – Air with
Multi-carrier/Climax)
• Figure 9: Call establishment Pilot – Controller (Air–Ground with
Best Signal Selection)

Note 8: The signalling and speech paths have been broken down into small components so that all
the individual timing elements can be identified. It is acknowledged that some components may be
combined within a single piece of equipment.

Note 9: . The box entitled “A/C TxRx” within the following diagrams, provides functionality for handling
all the audio onboard the aircraft.

© EUROCAE, 2009
 10

F ig ur e 2 : Ca l l es t a bl ish me n t con t r o l le r – p i lo t ( Grou n d – A i r)

© EUROCAE, 2009
 11

F ig ur e 3 : C a l l es t a b l ish me nt p ilot – cont ro ller (A ir – Ground)

© EUROCAE, 2009
 12

Fig ure 4 : PTT- A/C call indication (Round-trip) delay

© EUROCAE, 2009
 13

Fig ure 5 : Ca ll establishment Pilot – Pilot (A ir-A ir)

© EUROCAE, 2009
 14

F ig u r e 6 : C a l l es t a b l ish me n t C o n t r o l le r – Pilot( s) (Gro und–A ir with Frequency C ro ss

C o u p le d)

© EUROCAE, 2009
 15

Fig ure 7 : Ca ll establishment Pilot – Cont ro ller – Pilo t (A ir–Gro und w it h F re qu en cy

C ros s Cou pl e d)

© EUROCAE, 2009
 16

F ig ur e 8 : Ca ll es tab lish me nt Co ntro ller–Pilot ( Gro und – A ir with

M u lt i - ca r rie r /C l i ma x )

© EUROCAE, 2009
 17

F ig ur e 9 : Ca ll es tab lish me nt P ilot – Cont ro ller (A ir– Ground with

Best S igna l Select ion)

© EUROCAE, 2009
 18

2.3 RADIO SYSTEM PERFORMANCE REQUIREMENTS

This following defines the performance requirements of a radio system.

Note 10: The term ‘Radio System’ includes all the ground and aircraft components noting that the
terms of reference for WG-67 apply up to the radio station only. Performance characteristics for
components outside the scope of WG-67 will be stated as ‘given’ items.

1 [REQ RADIO PERFORMANCE] Speech Signalling Integrity necessary

The integrity of the association between signalling and speech for each individual transmitted
/ received message SHALL be preserved, totally, by the Radio System.

2 [REQ RADIO PERFORMANCE] End-to-End signalling integrity necessary

The Integrity of end-to-end signalling and addressing between the ground components of the
Radio System SHALL be assured in addition to the logical connection for the entire duration
of each transmission and reception.
E.g a Push-To-Talk (PTT) action, keys the intended Transmitter and nothing else.

3 [REQ RADIO PERFORMANCE] 100ms max Transmitter Activation Delay

The Transmitter Activation Delay (TAD) SHALL have a maximum value of 100mS.
Given: 20ms maximum for Transmitter Activation Time (TAT) is included within the 100ms
(refer to Figure 10 below)

F ig u r e 1 0 : S ig n a l l in g D e la y R eq u i r e me n t

© EUROCAE, 2009
 19

4 [REQ RADIO PERFORMANCE] 100ms max Aircraft Call Indication Delay

The Aircraft Call Indication Delay (ACD) SHALL have a maximum value of 100mS.

Given #1: The A/C Indication Device activation/display time is excluded from this time but is
expected to be within the range 20 – 50 ms.

Given #2: 50ms maximum for Receiver Activation Time (RAT) is included within the 100ms.
(refer to Figure 10 above).

5 [REQ RADIO PERFORMANCE] 250ms max Cross-coupled PTT inhibition

period, XC2

The Radio System SHALL be capable of operating cross-coupled frequencies with a

maximum Cross-coupled Push-To-Talk (PTT) Inhibition Period, XC2 (see Note 13) of
250ms.

6 [REQ RADIO PERFORMANCE] 130ms max Ground Transmission Voice delay

The voice delay for ground transmission components SHALL be a maximum of 130ms.

Given: Voice delay in the ground transmitter is 10ms and this is included in the 130ms.
(Refer to Figure 11 below)

F ig ure 11 : Vo ice Delay R eq u irement (gro und compon ents )

© EUROCAE, 2009
 20

7 [REQ RADIO PERFORMANCE] 10ms max Voice delay differential for Climax
operation

In Multi-Carrier/Climax operation the difference between the longest and the shortest voice
latencies for ground transmission components SHALL be a maximum of 10mS.

8 [REQ RADIO PERFORMANCE] 130ms max Ground reception voice delay

The voice delay for ground reception components SHALL be a maximum of 130 ms.
Given: Voice delay in the ground receiver is 10ms and this is included in the 130ms.
(Refer to Figure 11 above)

9 [REQ RADIO PERFORMANCE] Transmit signal speech clipping <64ms

For the speech signal transmitted from ground to air, clipping at both the start and end of
each transmitted voice message, SHALL not exceed 64 ms.

10 [REQ RADIO PERFORMANCE] Receive signal speech clipping <64ms

For each radio signal received at the CWP, clipping at both the start and end of each air to
ground received voice message, SHALL not exceed 64 ms.

© EUROCAE, 2009
 21

2.4 RADIO SYSTEM FUNCTIONAL REQUIREMENTS

1 [REQ RADIO FUNCTIONAL] Radio Access Modes of Operation

Radio access at a CWP SHALL be activated by the operation of a key (the term ‘key’ is used
to refer to a single activation device such as a key, switch, button or icon), associated with a
particular frequency and an appropriate visual/audio indication SHALL be given to indicate
the selection made. The key enables a particular radio frequency to be in one of four basic
modes:
• Off/Deselected;
• Receive only (Rx);
• Transmit and Receive (Tx/Rx);
• Cross-coupled.
Additional modes could be used in special cases.

2 [REQ RADIO FUNCTIONAL] Transmit Configuration description

The normal operational situation is when only one controller transmits (PTT) on a given
frequency at any time. The following provisions apply:

a) It SHALL be possible for a mentor to override the transmission of a student by the

mentor operating his/her own PTT key specially enabled to do this. The student
and mentor usually employ a common CWP, but other configurations such as
separate CWPs are also possible.

b) Two or more (up to a maximum of seven) controllers (not necessarily co-located)

may share access to a common transmitter. By multi-party agreement, each
controller should be assigned one of three possible transmit access priority (TAP)
levels:
Emergency (highest)
Priority
Normal (lowest)

In the event of simultaneous PTTs the controller with the highest overall TAP
SHALL seize the transmitter for exclusive use - even if it was already in use by
another controller.

c) In the event that two or more controllers, with equal TAPs, attempt to transmit
simultaneously on the same transmitter, the system SHALL transmit the
summation of all voice signals; this is an exceptional safety-related situation - for
example in SAR situations.

3 [REQ RADIO FUNCTIONAL] Speechless communications necessary

The system SHALL facilitate speechless communications (silent PTT and silent SQL
signalling). This entails the pilot and the Air Traffic Controller pressing their transmit button a
certain number of times using carrier wave only transmission to exchange information.

4 [REQ RADIO FUNCTIONAL] Remote Control Equipment functionality

In situations where transmitters (Tx) and receivers (Rx) are remote from the main VCS
equipment, some form of Remote Control Functionality is required. This Remote Control
Functionality could be provided by separate Remote Control Equipment (RCE) or

© EUROCAE, 2009
 22

incorporated into the IP Radio Gateway.

Depending on the Ground Radio Station architecture, transmission and reception facilities
may be located on separated sites and interconnected with different type of links (radio-link,
copper cables, optic fibre). Therefore, these various types of architecture SHALL be taken
into account in the radio gateway specification and in the medium term in the IP-compatible
transmitters (Tx) and receivers (Rx) specifications.

Table 1 below defines common requirements for two sets of facilities and services.

T a b l e 1 – C o m mo n f a c il i t y a n d s erv i ce r eq u ire m en t s
Tx / Rx SERVICES SITE MANAGEMENT INFORMATION
Voice Door contacts
Push-to-talk (PTT) Fire alarm
A/C call or Squelch Intruder alarm
Automatic Gain Control / signal
Power failure
strength
Equipment status

5 [REQ RADIO FUNCTIONAL] Radio Gateways backwards compatible with

legacy systems

The IP radio gateway’s input and output SHALL be backwards compatible with any legacy
remote control systems.
Remote Control Functionality SHALL support and prioritise the essential functions of Audio,
PTT, Squelch and Automatic Gain Control / signal strength whereas other functions such as
equipment status, site management and info processing are optional and MAY be
supported.

6 [REQ RADIO FUNCTIONAL] No voice distortion when simultaneous reception

on different frequencies

Simultaneous reception of the same message on several different frequencies SHALL not
be distorted at the CWP.
The situation where one CWP (N°2) simultaneously receives (Rx) several frequencies that
are also in operation on a different CWP (N°1) (in Tx/Rx or cross-coupled modes) SHOULD
be considered carefully in a VoIP concept. The existing constant delays on a TDM network
may vary as a consequence of re-routing (neglecting the effects of jitter) and could render
the audio on CWP n°2 unintelligible. (Refer to Figure 12 below).

© EUROCAE, 2009
 23

CWP 1 CWP 2
F1 Tx F1 Rx
F2 Tx F2 Rx
F3 Tx F3 Rx

Tx Controller voice Rx Controller voice F1

Rx Controller voice F2
Tx Controller voice
Rx Controller voice F3
Tx Controller voice

Time line

Delay in excess of 10ms

induces echo

F ig ure 12 : Examp le of echo indu ct ion ca us ed by d e lay ed recept io n of sa me

m e ssag e o n d if f er ent f r e qu en c ie s F1 , F2 a n d F3 .

7 [REQ RADIO FUNCTIONAL] Reception Delay differential at a CWP resulting

from simultaneous transmissions from another CWP

The delay differential, as shown in Figure 12 above, SHALL NOT exceed 10ms.

8 [REQ RADIO FUNCTIONAL] Parameters for CWP info display

A Radio Panel (or similar facility) at the CWP SHALL display the following information:

a) the current operating mode (see 1 [REQ RADIO FUNCTIONAL] Radio Access
Modes of Operation above);
b) Main or Standby radio selection;
c) an aircraft call (A/C) indication on the incoming frequency (or frequencies in case
of retransmission in cross-coupling mode).

9 [REQ RADIO FUNCTIONAL] Frequency technical state info display

The CWP Radio Panel SHALL display the technical state of each frequency (Out of service,
Degraded, Maintenance).

10 [REQ RADIO FUNCTIONAL] 300ms max frequency key activation response

© EUROCAE, 2009
 24

time

Within permitted operational conditions any key activation to change the current assigned
frequency mode, on a CWP, SHALL result in the change being fully effective within 300mS.

Examples:
• when a frequency is selected in Rx mode any received audio from an on-going
aircraft transmission is presented to the controller within 300ms;
• when a frequency is selected in Tx/Rx mode the frequency is usable for Tx
operation within 300ms.
Note 11: Current assigned frequency is one that has already being configured for
operational service at the CWP.

11 [REQ RADIO FUNCTIONAL] 300ms max frequency key status change

response time

The CWP radio panel SHALL display any change of status of assigned frequencies within
300ms.

12 [REQ RADIO FUNCTIONAL] Facility isolation/disconnection warning

The controller SHALL be alerted, by means of distinctive and prominent visual and audible
alarms, in the event of the system undesirably isolating/disconnecting any facility.

Examples:
• an operational frequency;
• a CWP Radio Panel;
• a frequency in a Cross-Coupled group.

13 [REQ RADIO FUNCTIONAL] Frequency blocking prevention

Each element of the system SHALL incorporate measures to ensure that any frequency is
not blocked (PTT, SQL, selection), undesirably, from being used by any authorized/permitted
user.

14 [REQ RADIO FUNCTIONAL] Simultaneous multiple frequency selections for

transmission and reception

The Controller SHALL be provided with the facility to select two or more (up to a maximum
of 28) air-ground communication frequencies simultaneously. When the Push-To-Talk (PTT)
action is performed, communications SHALL be transmitted on all Tx/Rx-selected
frequencies to the aircraft.

When the Push-To-Talk (PTT) key is released, the Controller SHALL be provided with the
combined/mixed audio signals from all selected frequencies (except cross-coupled
frequencies).

15 [REQ RADIO FUNCTIONAL] Cross-coupling facility to be implemented

© EUROCAE, 2009
 25

Duplex and Simplex Cross-coupling facilities SHALL be provided (see Annex D).

Note 12: Frequency cross-coupling is a CWP-selected function causing automatic

retransmission of one received signal on other pre-selected radio frequencies. With cross-
coupling it is possible to merge a number of physical radio frequencies into a kind of logical
frequency.
The purpose of frequency cross-coupling is to help the Controller to work in merged roles.
This makes it easier to split and merge roles, and it improves the Controller’s efficiency,
avoiding simultaneous calls of pilots using different frequencies.

16 [REQ RADIO FUNCTIONAL] Quantity of Frequencies in a cross-coupled

frequency group

The controller SHALL be able to select two or more (up to a maximum of 28) radio
frequencies in a cross-coupled group.

17 [REQ RADIO FUNCTIONAL] Two Cross-Coupled frequency mode

When an aircraft transmits on frequency ‘F1’ and is received on the ground, it SHALL be re-
transmitted on frequency ‘F2’. For the User on the ground at the CWP where coupling has
been enabled, when the user transmits on either frequency ‘F1’ or ‘F2’ transmissions SHALL
occur on both frequencies at the same time.

The original aircraft transmission on frequency ‘F1’ only SHALL be fed to the User at the
CWP where the cross-coupling has been enabled – not the received signal by re-
transmission on any other frequencies. The received transmission on frequency ‘F1’ is
termed the “incoming frequency”.

18 [REQ RADIO FUNCTIONAL] Three Cross-Coupled frequency mode

When an aircraft transmits on F1, retransmission SHALL occur on F2 and F3. Should an
aircraft call also occur on F2 during the retransmission, the corresponding voice signal (F2)
SHALL NOT be retransmitted so long as a voice signal on incoming frequency F1 is present.
At this time the incoming voice signal F2 SHALL always be presented to all other CWPs with
F2 selected.
As soon as there is no voice signal on F1 and after the Cross-coupled PTT Inhibition
Period “XC2” (see Note 13 below), cross coupling SHALL operate with F2 as the incoming
frequency.

Note 13: A definition of Cross-coupled PTT Inhibition Period “XC2” is given in 2.1
DEFINITIONS, its maximum value is defined in 5 [REQ RADIO PERFROMANCE] as 250ms.
XC2 is also shown in the radio parameter timing diagram Figure 7.

19 [REQ RADIO FUNCTIONAL] Clear cross-coupled frequency indications

Users SHALL be given clear indications of which frequencies are being employed in cross-
coupled mode.

20 [REQ RADIO FUNCTIONAL] Identical frequencies not allowed in two cross-

coupling sessions

In order to prevent cross-coupling chains, means SHALL be provided to ensure that a

particular frequency can only be included in one cross-coupling session.

21 [REQ RADIO FUNCTIONAL] Cross-Coupling frequency selection refusal

indication

© EUROCAE, 2009
 26

In the event that a frequency is already cross-coupled on one CWP the system SHALL
prevent it being cross coupled at another CWP – regardless of its location (except if the
other CWP is on the same Sector Suite – depending on ANSP implementation). The system
SHALL also present clear information, on the CWP of the Controller being prevented from
cross coupling the frequency, that the cross-coupling procedure has been refused and thus
not executed.

22 [REQ RADIO FUNCTIONAL] PTT precedence over Cross-coupling

transmission

When Cross-Coupling has been enabled at a CWP, the controller’s PTT SHALL take
precedence over any signals that are currently being re-transmitted (cross-coupling
retransmission is disabled for the duration of the controller’s PTT action plus the Cross-
coupled PTT Inhibition period “XC2” (see Note 13).

23 [REQ RADIO FUNCTIONAL] Aircraft call/cross-coupled frequency distinction

In cross-coupling mode, the display of the aircraft call /squelch at the CWP SHALL enable
the Controller to clearly distinguish between those calls received direct from the aircraft and
those arising from cross-coupling (re-transmission).

24 [REQ RADIO FUNCTIONAL] First received A/C call used as cross-coupled

group’s incoming frequency

In the event of several aircraft transmitting simultaneously on cross-coupled frequencies,

only the voice signal associated with the first squelch received by the system SHALL be
heard by the controller and retransmitted on the other frequencies. In the event that the
system is unable to determine which frequency was received first, the system SHALL select
one as the “incoming frequency” and this selection SHALL be maintained until the end of
that reception. The CWP at which the frequencies are cross-coupled is the only CWP where
just the voice signal associated with the first squelch (or “incoming frequency”) is heard. On
other CWPs, all voice signals SHALL be heard on the frequencies selected.

25 [REQ RADIO FUNCTIONAL] Climax operation to be implemented

Multi-carrier offset transmission operation (CLIMAX) function SHALL be implemented in the

system.

Definition of Multi-carrier operations (CLIMAX):

Multi-carrier operation in the ground to air direction is achieved by using the off-set carrier or
Climax system. This technique allows up to 5 separate radio stations to simultaneously
transmit the same audio signal using a single frequency assignment, but each using a
discrete carrier frequency that is off-set from the assigned frequency. As part of the Climax
methodology, different offsets are applied to the assigned channel frequency of each
transmitter to prevent the heterodyne frequency (audible) distorting the demodulated signals
received by aircraft transceivers.

© EUROCAE, 2009
 27

26 [REQ RADIO FUNCTIONAL] Echo prevention for Climax operation

When employing the Multi-carrier operation (CLIMAX) function, time delay differences in
excess of 10ms, due to the transmission of signals to different radio sites, may result in
echoes on board aircraft. The System SHALL provide compensation so as to keep time
delay differences within the 10ms limit. The means of compensation SHALL not in itself
result in degradation of voice quality.

Climax compensation time is included in “Ground transmission voice delay”, see Chapter
2.3.

27 [REQ RADIO FUNCTIONAL] Best Signal Selection functionality to be

implemented

Best Signal Selection (BSS): A “Best Signal Selection” function SHALL be implemented in
the system to handle multi receiver frequencies. This function SHALL take into account the
audio signal quality and the relative delay between the incoming signals.

28 [REQ RADIO FUNCTIONAL] Best Signal Selection Functionality Manual

de-selection

It SHALL be possible for Best Signal Selection (BSS) functionality for each nominal
frequency (see paragraph 2.1 DEFINITIONS) to be manually deselected at the CWP,
supervisor position or engineering management system.

29 [REQ RADIO FUNCTIONAL] Manual De-selection of Best Signal Selection

individual receiver(s)

It SHALL be possible to deselect one or more individual receivers from Best Signal Selection
(BSS) at the CWP, supervisor position or engineering management system.

30 [REQ RADIO FUNCTIONAL] No signal degradation on Best Signal Selection

receiver changeover

In the event that a change of receiver is permitted after original Best Signal Selection (BSS)
operation, the intelligibility and integrity of the received signal to the controller SHALL not be
degraded.

E.g. 1) Intelligibility will be degraded if the delay between two received signals is sufficient to
cause syllable clipping or repeating.

E.g. 2) Integrity will be compromised in the event of reception from one aircraft being
replaced by the reception of another aircraft.

31 [REQ RADIO FUNCTIONAL] BSS time delay difference compensation

In situations where Best Signal Selection (BSS) is used, Time delay differences due to the
reception of the same signal received from different radio sites (see BIDD parameter in
timing diagram Figure 9) SHALL be compensated for if greater than BIDD Max.

© EUROCAE, 2009
 28

32 [REQ RADIO FUNCTIONAL] Mixed received signal echo compensation

In situations where mixed received signals are used in preference to Best Signal Selection
(BSS), time delay differences due to the reception of the same signal received from different
radio sites may result in echoes at CWP that SHALL be compensated for if greater than 10
ms.
A variation of differential delay SHALL not affect voice quality of the message received.

33 [REQ RADIO FUNCTIONAL] PTT & A/C call locked-on condition prevention

Avoidance of Press -To-Talk (PTT) and Aircraft Call (A/C Call) -Locked-On Conditions

Disregarding the permitted system latency effects, jitter and permitted transient delays: a
secure mechanism SHALL be implemented in the protocol between IP components so as to
ensure that the occurrence of abnormal PTT and A/C Call conditions, as described below is
rendered impossible by design. In case of such abnormal conditions, due to other reasons,
the terminal Equipment SHALL detect and correct these automatically.

1. Normal Conditions
PTT
A PTT action (press and hold) at a Controller Working Position results in the keying
(activation) of a transmitter at a remote radio station for the same duration as the original
PTT action.

A/C Call
The arrival of a continuous radio signal, of sufficient field strength, causes the operation of a
receiver mute/squelch device resulting in the activation of the A/C Call indicator at the
Controller Working Position for the same duration as the radio signal.

Note 14: In some cases the A/C Call indication at the CWP MAY be extended deliberately,
by some seconds, in order to reduce the possibility that an A/C Call of short duration is not
observed by the controller.

2. Abnormal (Locked-On) Conditions

PTT
Ceasing the PTT action does not result in the remote transmitter being un-keyed (de-
activated) so that the duration of transmitter operation exceeds that of the original PTT. In
severe cases the transmitter MAY remain activated for an indefinite period - a condition
termed “Locked-On”.

A/C Call
When the field strength of the received radio signal falls below the level for receiver
mute/squelch device operation the A/C Call at the Controller Working Position remains
activated so that the duration of the A/C Call condition exceeds that of the received radio
signal. In severe cases the A/C Call MAY remain activated for an indefinite period – a
condition termed “Locked-On”.

34 [REQ RADIO FUNCTIONAL] Off-air side tone generation

When transmitting, Side Tone is the User’s own speech fedback, at reduced level, into the
User’s ear-piece in Headsets (or other audio devices). Side tone can be generated locally by
the VCS or from speech received “off-air” via a receiver. The latter method has the
advantage of proving, to some extent, that the system is working but complexities associated
with audio delays, phase shifts and multiple receiver operation often precludes its use.

Local side tone MAY be a suitable solution if associated with a test of the “off-air” reception.

© EUROCAE, 2009
 29

In this respect a self-proving mechanism (system loop check) SHALL be provided.

E.g. 1) PTT out results in an “off-air” Squelch being returned.

E.g. 2) Voice out results in “off-air” Voice being received.

35 [REQ RADIO FUNCTIONAL] Duplex and Simplex Cross-coupling functionality

support

The system SHALL support both duplex and simplex cross-coupling functionality. Definitions
of duplex and simplex cross-coupling are as follows:-

Duplex Mode
All received frequencies in Duplex Mode MAY be re-transmitted on all the other frequencies
in the Cross-Coupled Group - but only one at a time. The received frequency re-transmitted
is always presented at the CWP.
This mode would be used, for example, when Sectors are combined to be controlled from a
single position.

Simplex Mode
Received frequencies in Simplex Mode are never re-transmitted on other frequencies in the
Cross-Coupled Group.
This mode would be used, for example, when a Tower frequency (VHF) is re-transmitted
on a Ground Mobile frequency (UHF) so that mobiles MAY be aware of aircraft
manoeuvres in progress and intended.
Another application would be the re-transmission of a Civil Frequency on a Military
Frequency but not the other way round.

Further details on Cross Coupling are provided in the information paper attached as
ANNEX D - CROSS-COUPLING MODES OF OPERATION.

The following Requirements [36 to 40] will also be affected by those contained in ED-136
9 [REQ RADIO FUNCTIONAL] Frequency technical state info display, 10 [REQ RADIO
FUNCTIONAL] 300ms max frequency key activation response time and 11 [REQ RADIO
FUNCTIONAL] 300ms max frequency key status change response time.

36 [REQ RADIO FUNCTIONAL] Receiver Status Notification

When a User selects (see Note 15) a frequency (see Note 16) on a CWP or other terminal,
in receive mode, the system SHALL have the capability to make available to the User
certain information about the Rx status. The Information provided SHALL include (but not
necessarily be limited to) the following:

• Confirmation that the Rx is available and ready for use – including the existence or
failure of the logical link to the Rx site;

• The identity of the Rx selected.

To meet the individual requirements of ANSPs the availability of this facility, and its
associated attributes, SHALL be fully configurable by means of the System Management
facility.

Note 15: The action of ‘selecting’ pre-supposes that the frequency has already been
configured for use at the CWP by means of the System Management (or other) facility.

Note 16: In the case of receiver selection the term ’frequency’ may either refer to a single
receiver or a group of receivers where one is selected by means of BSS. As an example 36

© EUROCAE, 2009
 30

[REQ RADIO FUNCTIONAL] RECEIVER STATUS NOTIFICATION above has been written
as for a single Rx, for simplicity, but must be interpreted so as to include a group of receivers
as appropriate.
Similarly in the case of transmitter selection the term ’frequency’ may either refer to a single
transmitter or a group of transmitters. As an example 37 [REQ RADIO FUNCTIONAL]
TRANSMITTER STATUS NOTIFICATION below has been written as for a single Tx, for
simplicity, but must be interpreted as to include a group of transmitters.

37 [REQ RADIO FUNCTIONAL] Transmitter Status Notification

When a User selects a frequency, in transmit mode, the system SHALL have the capability
to make available to the User certain information about the Tx status. The Information
provided SHALL include (but not necessarily be limited to) the following:

• All items as per 36 [REQ RADIO FUNCTIONAL] Receiver Status Notification

above;

• Confirmation that the Tx is available and ready for use – including the existence of a
logical link to the Tx site;

• The identity of the Tx selected;

• The identity of other Users who may also have the same transmitter selected at that
time with this information being up-dated should the User community, with the
transmitter selected, change.

To meet the individual requirements of ANSPs, the availability of this facility, and its
associated attributes, SHALL be fully configurable by means of the System
Management facility.

38 [REQ RADIO FUNCTIONAL] Selected Transmitter Rejection Notification

In the event of a frequency selection action (as per 37 [REQ RADIO FUNCTIONAL]
Transmitter Status) being rejected Users SHALL be informed as to the cause of that
rejection. Possible causes for rejection SHALL include (but not necessarily limited to) the
following:

• The total number of Users with that transmitter selected would exceed the total
permissible (in accordance with ED-136 2 [REQ RADIO FUNCTIONAL] Transmit
Configuration description);

• The transmitter is not available.

It is assumed that the unavailability of a logical link (Tx and/or Rx) would be notified in
accordance with 36 [REQ RADIO FUNCTIONAL] Receiver Status Notification and 37
[REQ RADIO FUNCTIONAL] Transmitter Status Notification and 16 [REQ SYS
ENG] Detection of End-to-End Connection Loss.

39 [REQ RADIO FUNCTIONAL] PTT failure notification

Users executing a PTT on a selected frequency, in transmit mode, SHALL be informed in

the event of that PTT failing and the cause of this. Possible causes SHALL include (but not
necessarily be limited to) the following:

• An Automated radio loop check activation in accordance with 36 [REQ SYS

ENG] Automated Radio check during PTT, that achieves a negative result;

© EUROCAE, 2009
 31

• PTT is blocked due to the presence of another PTT by another User.

40 [REQ RADIO FUNCTIONAL] PTT identity notification

A User who has already selected a radio frequency, in either Tx or Rx mode, SHALL be
informed as to the identity of other Users with access to the same frequency, when any of
those Users execute a PTT on that frequency. This information SHALL be maintained for
either the duration of the PTT or sustained for a minimum duration as set by the ANSP.

To meet the individual requirements of ANSPs, the availability of this facility and its
associated attributes, SHALL be fully configurable by means of the System Management
facility.

Note 17: The facilities provided in response to 40 [REQ RADIO FUNCTIONAL] PTT
identity notification above are in addition to the Aircraft Call indication (see ED-136 Chapter
2.1 DEFINITIONS- A/C Call Indication). One application of this is to provide means by which
Users may distinguish between transmissions originating from aircraft and those originating
from other Users.

© EUROCAE, 2009
 32

2.5 DETECTION OF SIMULTANEOUS RADIO TRANSMISSIONS

2.5.1 Description
Situations arise when two or more radio transmissions occur, simultaneously, on the same frequency.
In this context ‘simultaneous’ is defined as two or more transmissions that overlap in such a way that
the controller is not aware that more than one transmission has occurred leading to a potential safety
hazard. Following the two notes below are several descriptive Cases with associated
Recommendations.

Note 18: Technological progress in digital signal processing enables radio manufacturers to offer fully
digitized receivers. It is, in fact, expected that such receivers could be installed today as part 8,33kHz
radio channel spacing implementation. Thus future radio systems are expected to cope with the
recommendations contained in this section of the requirements whereas existing analogue radios may
not offer even the possibility of being modified to cope to either a small or large extent.

Note 19: The Recommendations following each descriptive case below have never (to best
knowledge) been proposed for implementation - let alone subject to Operational deployment for ATM.
For this reason no performance criteria – such as a successful detection ratio - has been defined. As a
first step, a “best effort” algorithm is awaited here from the radio and VCS manufacturers.

2.5.2 Principal Requirement – Safety Warning

1 [REQ RADIO SIMULTANEOUS] Simultaneous Transmissions

No solutions to the detection of Simultaneous Transmissions SHALL in themselves

contribute to an increased probability of these going undetected as compared with the status
quo.
Implementations SHOULD be implemented on the basis that some tangible benefit will be
obtained but, never-the-less with controllers remaining cautious that no solution is perfect
and that safety hazards will still exist.

2.5.3 Case 1 – Two Frequencies F1 and F2 in Cross-Coupled Mode

Two pilots transmit at same time on the different frequencies F1 and F2 but only F1 is re-
transmitted on F2. During this time only F1 is fed to the controller working position with F2
being suppressed (normal Duplex Cross-Coupling). The controller is not aware of the
transmission on F2.

Case 1 can be illustrated as follows:

Tx F1
Case 1

Rx F1

Cross
coupling
Audio from active
F1 (which
was received
first)

VCS Tx F2

Rx F2

F ig ur e 13 : S imu lta neou s Tran sm is s ion s wit h t wo fr eq uen c i es

in Cro ss-Coupled mo de.

The incoming signal on Rx F1 will be re-transmitted on Tx F2. As Rx F2 is normally located

© EUROCAE, 2009
 33

quite close to Tx F2, Rx F2 will receive the re-transmitted signal with high signal strength. The
aircraft subsequently transmitting on F2 will “step on” the re-transmitted signal.

The cross coupling function (Duplex Mode) defines that only audio from RxF1 is be forwarded
to the controller. In this case, the controller will not be aware of the aircraft calling on Rx F2.

Recommendation:
Receivers SHOULD include functionality to detect if two or more transmissions are present
on the same nominal frequency* at the same time. A message SHOULD be sent to the VCS
producing a warning indication at controller working position (CWP).

Note 20: This functionality SHOULD be pursued in future ground receivers and all other
associated system components

* The expression 'Nominal Frequency' is used to indicate that a numerical value is not
necessarily the precise frequency being used (see paragraph 2.1 DEFINITIONS)

2.5.4 Case 2 – One Ground Receiver

Two pilots transmit on the same nominal frequency* and both signals are received by one
ground receiver. The controller hears only one transmission and is unaware of the second
transmission.

* (see paragraph 2.1 DEFINITIONS)

Case 2 can be illustrated as follows:

Case 2
Tx F1

Audio from Rx F1
strong signal
only

VCS
F ig ure 14 : O ne gro und receiver det ects both signa ls of a S imu lta neou s Tran smis s ion

Two aircraft are transmitting to the controller simultaneously. The difference in signal strength
makes the stronger signal suppress the weaker in the receiver. The result is that the controller
will hear only the strong signal and be unaware of the presence of another aircraft call.

Recommendation:
Receivers SHOULD include functionality to detect if two or more transmissions are present
on the same nominal frequency* at the same time. A message SHOULD be sent to the VCS
producing a warning indication at the controller working position (CWP).

Note 21: This functionality SHOULD be pursued in future ground receivers and all other
associated system components

* The expression 'Nominal Frequency' is used to indicate that a numerical value is not
necessarily the precise frequency being used (see paragraph 2.1 DEFINITIONS).

© EUROCAE, 2009
 34

2.5.5 Case 3 – Two Ground Receivers

Two pilots transmit on the same frequency and each individual signal is detected, separately,
by two ground receivers. After the Best Signal Selection system has operated (BSS Delay)
only one transmission will be presented to the controller working position (CWP).

Case 3 can be illustrated in two ways (Case 3a & Case 3b) as follows:

2.5.5.1 Case 3a- Ground receivers each detect different signals of simultaneous transmission

Tx1 F1
Case 3a

Rx1 F1

Audio from
Best voted
only

VCS Tx2 F1

Rx2 F1

F ig u r e 1 5 : T w o g ro u n d r e ce iv er s e a c h d et ec t d if f er ent sig n a l s
of a Simultaneous Transmissio n

In this example the frequency is detected by two radio stations and the VCS uses Best Signal
Selection to determine the best received signal and present this to the controller. In the
example two aircraft try to call the controller at the same time – the special case is that each
aircraft call is only received by one receiver.

In many implementations of BSS, one signal is voted the best and presented to the controller.
The other signals from the other receivers are muted. In this situation, an aircraft call may be
lost.

Recommendations:
The VCS SHOULD employ one or more of the following methods:

Method 1: Audio from receivers not selected by BSS SHOULD be attenuated by 15dB and
presented to the controller mixed with the voted audio

Method 2: There will normally be a slight time difference between two aircraft calls reaching
the receivers. The VCS SHOULD implement a function to detect additional aircraft calls by
diagnosing the time difference between two signals on two radio stations as follows:

New calls detected on a new radio station more than (configurable delay Xms) after the first
aircraft call, is assumed to be a new aircraft and this signal will also be presented un-
attenuated to the controller mixed with the voted signal. This method only applies when an
aircraft call was received by a receiver that did not receive the call from the first aircraft. This
is illustrated in Figure 16 below:

Method 3: The VCS SHOULD do a correlation analysis between the signals received at the
various receivers to determine whether it is the same aircraft call

© EUROCAE, 2009
 35

VOTING
Leg 1 voted.

1 Strength 3

2 Strength 2

3 Strength 2

New Aircraft call

added at full strength

300m s

Aircraft call 1 sec 2 sec

F ig ur e 16 : D ete ct io n of a dd it io na l a ir craf t calls th roug h t ime d iff e re n ce d iagnos is

bet ween 2 signa ls f rom 2 ra dio stat ions

2.5.5.2 Case 3b-- Ground receivers each detect both signals of simultaneous transmission
This case is a slight variation of Case 3a and can be illustrated as follows:

Tx1 F1
Case 3b

Rx1 F1

Audio from
Best voted
(+ the other
added?)

VCS Tx2 F1

Rx2 F1

F ig u r e 1 7 : T w o g ro u n d r e ce iv er s e a c h d et ect both signals of a Simulta neo us

T ra ns m is s io n

In this case aircraft calls from all aircraft are received by both receivers on the frequency
(which is normally the case in a Terminal Control environment) and the situation becomes
similar to Case 2.
The same recommendations as for Case 2 – One Ground Receiver apply.

© EUROCAE, 2009
 36

2.5.6 Case 4– Simultaneous Pilot-Controller transmission

A pilot and a controller transmit on the same frequency

Case 4 can be illustrated as follows:

Case 4
Tx F1

Controller hears: Rx F1
1) local sidetone,
or
2) off-air sidetone

VCS

Fig ure 18 : Simulta neous Transmission by Pilot a nd Cont ro ller transmission

on th e same f re qu en cy

In this case an aircraft tries to call while the controller is transmitting. As local sidetone will
most probably be used in a VoIP environment, the controller will only hear his/her own voice
as it is looped back within the VCS. In other words, the controller will not be able to detect the
aircraft call by the audio.

The receiver’s ability to detect this situation is very similar to Case 1 – Two Frequencies F1
and F2 in Cross-Coupled Mode.

Recommendation:
Receivers SHOULD include functionality to detect that two transmissions are present on the
same nominal frequency at the same time. A message SHOULD be sent to the VCS
producing a warning indication at the controller working position (CWP).

Note 22: This functionality SHOULD be pursued in future ground receivers and all other
associated system components

© EUROCAE, 2009
 37

CHAPTER 3

TELEPHONE BASELINE REFERENCE CHAPTER

This chapter lists functional requirements applying to Ground-Ground voice communications services.

3.1 DEFINITIONS
The following terms apply within this chapter:

• Air Traffic Service Unit (ATSU): includes any location where the business of air traffic
management is conducted including airports, ACCs and Flight Information Units

• Bi-lateral Agreement: the term 'Bi-lateral Agreement' refers to the appropriate authorities
within the 'A'-party and 'B'-party ANSPs;

• Busy:
Terminal Busy: The condition that arises when an incoming call has reached the 'B'-party
CWP but there is no resource available to present the call to the User (refer to section 2.1
DEFINITIONS for User definition). The Terminal busy condition should not arise on a DA call
(refer to 3.3.2 ) or an IA call (refer to 3.3.3), but is possible for an IDA call (refer to 3.3.4) in the
event that the incoming call queue is full.

Note 23: The condition of "User busy" in the sense of the User being occupied with other calls
in progress while the call queue is not full, is not relevant to these Requirements and is
considered to be a matter of local operational procedure.

Network Busy: The condition that arises when there is no spare capacity within the network
that is providing connectivity between one VCS and another. This may arise as a
consequence of either network congestion or (exceptionally) as a result of a command from a
System Management Terminal. Throughout these Requirements, the term "congestion" is
used synonymously with "network busy".

• Call parties: The terms 'A'-party, 'B'-party and 'C'-party are used throughout these
requirements to identify the users involved in a telephone call, as follows:
o 'A'-party: the user who initiates a telephone call – the calling party;
o 'B'-party: the user who first receives the telephone call – the called party;
o 'C'-party: any other party involved in an established call.

• Dynamic display: A device used for the visual presentation of operational information such
as caller identities, call status and programmable touch-keys.

• External Facility: A supplementary telephone service or feature that is used between two or
more Air Traffic Services Units (ATSUs).

• Facility: The term 'facility' is used to describe the function to be carried out and the term
'Feature' gives further details or the particular attributes of the Facility.

• Feature: Refer to Facility definition.

• Internal Facility: A supplementary telephone service or feature that is used within the
boundary of a single Air Traffic Services Unit (ATSU).

• Key: Throughout these Requirements, the term 'key' is used to refer to a single activation
device such as a key, switch, button or an icon

© EUROCAE, 2009
 38

• Monitor/Monitoring: The Audio Monitor Facility is a means by which it is possible for one
Controller to be able to listen to the audio/voice activities at the Working Position of another
Controller who is usually not physically adjacent. The primary purpose of Monitoring is to
enable the Controller who is doing the monitoring to be able to gain real-time situational
awareness of the tasks being carried out by the controller being monitored.

• Normal/Abnormal: The terms 'normal' and 'abnormal' refer to when the Performance criteria
defined for each Facility are either met or infringed respectively.

3.2 GROUND-GROUND VOICE COMMUNICATION SERVICES

Ground-Ground voice communications services between a range of locations are essential for the
purposes of Air Traffic Management. The following lists illustrate the diversity of applications.

1 [REQ TEL SERVICES] Ground-Ground voice communication services

The system SHALL be capable of providing ground-ground voice communications services

within a Flight Information Region (FIR) between all the Air Traffic Service Units (ATSUs)
detailed in 3.2.1 below.

3.2.1 Communications within a FIR between ATSUs

Flight Info Centre to:

• Area control centre (ACC)
• Approach control units
• Aerodrome control towers

Area Control Centre to:

• Approach control units
• Aerodrome control towers
• Air traffic Services reporting offices (if separate)

Approach Control Unit to:

• Aerodrome control tower(s)
• Air traffic Services reporting offices (if separate)

Aerodrome Control Tower to:

• Air traffic services reporting offices (if separate)

3.2.2 Communications within a FIR between ATSUs and other Units

Flight Info Centre and an Area Control Centre to:
• Appropriate military units

Approach Control Unit and an Aerodrome Control Tower to:

• Appropriate military Units
• Rescue and emergency services
• Met Office serving the Unit

Note 24: Interfaces to all of these locations are outside the scope of these requirements, but
are included for information.

© EUROCAE, 2009
 39

Flight Info Centre and an Area Control Centre to:

• Met office serving the centre
• Aeronautical telecom stations serving the centre
• Appropriate operator's offices
• Rescue co-ordination centre or appropriate emergency service
• International NOTAM office serving the centre

Approach Control Unit and an Aerodrome Control Tower to:

• Aeronautical telecom stations serving the Unit
• Unit apron management service (when separately established)

Note 25: Interfaces to all of these locations are outside the scope of these requirements, but
are included for information.

3.2.3 Communications between Flight Information Regions (FIRs)

Flight Info Centres and Area Control Centres to adjacent Flight information Centres and Area
Control Centres

Between Area control centres serving contiguous control areas (unless otherwise prescribed
by RAN agreements)

Adjacent ATS Units (under special operational circumstances)

Note 26: Interfaces to all of these locations are outside the scope of these requirements, but
are included for information.

3.2.4 Communications out of the ATS community

Communications to Civil Defence, Police (even political powers) to address terrorism and
hijack, which are inherently trans-national.

Note 27: Interfaces to all of these locations are outside the scope of these requirements, but
are included for information.

© EUROCAE, 2009
 40

3.3 PRIMARY USER GROUND TELEPHONE FACILITIES

This section describes the primary user ground telephone facilities required by Air Traffic Controllers
and other operational personnel in order to carry out their duties of Air Traffic Management.
Performance criteria as demanded by such personnel are included where such information is
available.

3.3.1 Supervisory tones

1 [REQ TEL FUNCTIONAL] Supervisory tones

The various supervisory tones and announcements as detailed in the following table SHALL
apply.

Tab le 2 – Su perv iso ry to ne def in ition

Tone Purpose Frequency Period
(Hz)
Dial Returned to a user when that user indicates 425 continuous
to the system readiness to dial (for
example, taking the telephone set off-
hook).
Ringing Returned to the 'A'-party after successful 425 (1 s on,
call establishment and prior to call 4 s off), repeated
acceptance.
Terminal busy Returned to the 'A'-party if there is no 425 (0.5 s on,
resource available at the ‘B’-party CWP to 0.5 s off), repeated
present an incoming call.
Congestion Returned to the 'A'-party if a call cannot be 425/1000 (0.5 s each)
completed to the required 'B'-party due to repeated
all appropriate inter-VCS links being
occupied or otherwise unavailable.
Number Returned to the 'A'-party if a terminal is 1000 (0.5 s on,
Unobtainable "Out of Service" or the 'B'-party address is 0.5 s off), repeated
(Note 28) unassigned.
Interrupt Injected into the voice path to warn a party 1000 (40ms, 0.5s off) repeated
warning of the imminent priority interruption of an for up to 15s prior to
(Note 28) established call. forced disconnection
Intrusion Injected into the voice path to warn a party 1000 1 s on
warning of the imminent priority conferencing of an
(Note 28) established call
Conference Injected into the voice path to all 1000 0.5 s on (one time)
notification conference participants to indicate a new
(Note 28) participant is joining the conference.
Note 28: Not specified in ITU-T Recommendation E.180 [25]

The tones in Table 2 conform to those specified in ITU-T Recommendation Q.35/E.180. Regional

© EUROCAE, 2009
 41

variations in the tones generated by a VCS are possible where:

• the tones are generated by the local VCS;

and/or
• tone information is exchanged with another VCS.

3.3.2 Direct Access (DA)

DA is a means of ‘setting up’ (i.e. presented ringing/alerting to the ‘B’-party) a telephone
communication between two Users where there is an operational requirement for this.

2 [REQ TEL FUNCTIONAL] Direct Access Calls

The need to make DA calls should be established by bi-lateral agreement, but SHALL be
supported as both Internal and External Facilities – including across ANSP/national borders.

3.3.2.1 Facility Description

The following facilities SHALL be provided:

(a) With this facility the operation of a single key by the 'A'-party is all that is required to
initiate a call.

(b) The 'B'-party address is assigned and configured (by means of system management),
in the 'A'-party VCS and is thus uniquely associated with a particular key labelled with
the ‘B’-party’s identity .

(c) Dial tone and out-going signalling tones are not given to the 'A'-party.

(d) Ringing tone should be given (and / or visually indicated).

(e) Busy tone shall be given if appropriate.

(f) Terminal Out-of-service shall be given should the call fail for any reason other than
Busy.

(g) The 'B'-party is alerted to the presence of the incoming call by audio and or visual
means as determined by the 'B'-party VCS.

(h) The 'A'-party identity is indicated to the 'B'-party either by association with a key
assigned and fixed semi-permanently in the 'B'-party VCS or by means of a dynamic
display.

(i) The 'B'-party must accept the incoming call by means of a single action associated
with a key or dynamic display.

(j) Due to either the exclusive, one-to-one, assignments of the keys between the 'A' and
'B' - parties or reserved capacity in the 'B'-party dynamic display, it is abnormal for the
'A'-party to encounter the 'B'-party busy; this is a fundamental attribute of the Direct
Access Facility.

(k) Under normal conditions the 'B'-party can receive one or more Direct Access calls and
by observing the identities of the respective 'A'-parties, together with defined
operational procedure or (more likely) operational experience, the 'B'-party will deal
with each call appropriately in the appropriate sequence.

© EUROCAE, 2009
 42

(l) At the end of a call either the 'A'-party or the 'B'-party may be required to de-
select/clear.

3.3.2.2 Performance Criteria

1 [REQ TEL PERFORMANCE] Direct Access Performance Criteria

(a) Direct Access is designed to meet the requirements for Direct Controller-Controller
Voice Communication (DCCVC) which stipulates that communication be established
between controllers within 2 seconds in 99% of the time (See Note 29: ).

(b) The interval of 2 seconds is the delay between the 'A'-party initiating the call and the
'B'-party receiving the call alert/indication.

(c) DA SHALL be clearly distinguishable from IA (refer to section 3.3.3) in any signalling
protocol.

Note 29: It is known however that in case of ATS-R2 and ATS-No.5 analogue signalling
protocols, this establishment time is not achievable.

3.3.3 Instantaneous Access (IA)

IA is a means of ‘establishing’ (i.e. ready for voice communications) a telephone communication
between two Users where there is an operational requirement for this.

3 [REQ TEL FUNCTIONAL] Instantaneous Access Calls

The need to make IA calls should be established by bi-lateral agreement, but SHALL be
supported as both Internal and External Facilities – including across ANSP/national borders.

3.3.3.1 Facility Description

The following facilities SHALL be provided:

(a) With this facility the operation of a single key by the 'A'-party is all that is required to
initiate a call; some ANSPs prefer, however, that it is necessary for the 'A'-party to
sustain the key operation for the duration of the call.

(b) The 'B'-party address is assigned and configured (by means of system management),
in the 'A'-party VCS and is thus uniquely associated with a particular key and labelled
with the ‘B’-party’s identity.

(c) Dial tone and out-going signalling tones are not given to the 'A'-party.

(d) Ringing tone is not given to the 'A'-party.

(e) 'Terminal Out-of-Service' tone is given to the 'A'-party should the call fail for any
reason including any busy conditions encountered.

Note 30: The above is the condition as specified in the “EUROCONTROL Voice
Communication System Procurement Guidelines” [13], but ANSPs may specify
‘Terminal Busy’ or ‘Congestion’ in response to Operational Requirements.

(f) The arrival of the call from the 'A'-party to the 'B'-party causes, simultaneously, the
events detailed in paras (g) to (n) inclusive.

© EUROCAE, 2009
 43

(g) The 'A'-party identity is indicated to the 'B'-party either by association with a key
assigned and fixed semi-permanently in the 'B'-party VCS or by means of a dynamic
display. Due to the usually urgent nature of Instantaneous Access calls any visual
(and/or audible) alerts should be distinctive from other types of call.

(h) An audible alert is generated at the 'B'-party VCS in accordance with the following
options:

• no audible alert;
• an alert of fixed duration;
• a continuous alert requiring a silencing action by the 'B'-party.

(i) The 'B'-party VCS automatically accepts the incoming call without any intervention
required by the User; this occurs regardless of the 'B'-party being engaged on any
other type of call. Thus 'B'-party busy is totally abnormal and should result in Terminal
Out-of-Service tone being given to the 'A'-party. At this stage the speech channel from
the 'A'-party to the 'B'-party is established. The 'B'-party ANSP may decide to have
any speech from the 'A'-party handled in one (or more) of the following ways:

• connected in conference with other speech at the 'B'-party CWP;

• directed to a loudspeaker;
• directed to one side of a split-working headset;
• any other arrangement appropriate to the local operational procedures.

(j) The establishment of the call as detailed in para (a) above may also result in the
'A'-party having some Monitoring facilities of the 'B'-party's Controller Working Position
including ground - ground and air-ground radio communications. This enables the
'A'-party to exercise discretion before passing the message. Monitoring will require the
prior establishment of a bi-lateral agreement if two ANSPs are involved.

(k) If monitoring is enabled the ‘A’-party’s CWP may hear any active ground and radio
voice calls at the ‘B’-party’s CWP. Details of which parties in the active ground and
radio calls are monitored is ANSP-specific.

(l) If monitoring is disabled, the ‘A’-party’s CWP SHALL NOT hear any active ground and
radio voice calls at the ‘B’-party’s CWP.

(m) The 'B'-party may respond to the 'A'-party by activation of a key associated with the
incoming call. This action enables the return speech path if it occurs during the current
call; otherwise, it is treated as a new Instantaneous Access call.

(n) If the 'B'-party responds during the current call, this has the effect of preventing the
call from being cleared until both parties clear the call; without B-party response, the
call is cleared when the 'A'-Party terminates the IA-call.

(o) Call clearing has no effect on other calls in progress at either the 'A'-party or the
'B'-party.

3.3.3.2 Monitoring Controller’s sidetone

To prevent either echoing or audio feedback Controller ‘A’’s sidetone SHOULD always be
generated locally and never included in the monitor from Controller ‘B’.

© EUROCAE, 2009
 44

3.3.3.3 Prevention of Eavesdropping

4 [REQ TEL FUNCTIONAL] Prevention of Eavesdropping

The only time controller ‘B’s speech (microphone) SHALL be directly fed to controller ‘A’ is
when controller ‘B’ responds to an IA call by activating his reciprocal IA key; this is now
‘conversing’ and no longer ‘monitoring’.

In the event of no calls (radio & telephone) being active at the CWP of Controller ‘B’, and an
IA call is made from Controller ‘A’, Controller ‘A’ SHALL NOT hear whatever may be being
‘picked up’ by the microphone of Controller ‘B’.

3.3.3.4 Performance Criteria

2 [REQ TEL PERFORMANCE] Instantaneous Access Performance Criteria

(a) Instantaneous Access is designed to meet the requirements of Instantaneous

Controller-Controller Voice Communication (ICCVC) which stipulates that two-way
direct communication be established between non-physically adjacent controllers
within 1 second or less in 99% of the time.

(b) The interval of 1 second is the delay between the 'A'-party initiating the call and the
'A'-party to 'B'-party speech path being established.

(c) IA SHALL be clearly distinguishable from DA (refer to section 3.3.2) in any signalling
protocol.

(d) The maximum limit for incoming simultaneous IA calls to a single CWP SHALL be set
to 3. The ANSPs SHALL have the possibility to reduce this maximum limit. Any
attempted IA call beyond the third IA call SHALL result in a busy condition.

3.3.4 Indirect Access (IDA)

5 [REQ TEL FUNCTIONAL] Indirect Access calls

The Indirect Access (IDA) facility as described below SHALL be supported as both Internal
and External Facilities using, where required, both private (AGVN) and public (PSTN)
telephone services.

3.3.4.1 Facility Description

(a) The Indirect Access facility enables a 'A'-party to enter a complete 'B'-party
address on a telephone dialling keypad (or equivalent device) in order to select a
network and to cause a call attempt to be made to the supplied address. This is
equivalent to normal dialled telephone operation.

(b) Ringing tone and busy tone are given to the 'A'-party as appropriate. A suitable
mechanism (i.e., Terminal Out-of-service tone) shall be provided to inform the
'A'-party, should the call fail for any reason other than Busy.

(c) It may be possible for calls from more than one 'A'-party to be presented to a
'B'-party simultaneously. In such cases, the selection of the next call to be
answered by the 'B'-party is determined either directly by the 'B'-party or on the
basis of an operational parameter such as longest waiting time or the Priority of
the incoming call (see section 3.3.5)

(d) It is possible for either the 'B'-party or the 'A'-party to terminate an established
Indirect Access call.

© EUROCAE, 2009
 45

(e) In addition to dialling the 'B'-party address in full (see ‘a’ above) the following
PBX-type Facilities are also used to establish Indirect Access calls:
• Abbreviated Dialling
Entering a short code (up to four digits, a character string of unrestricted
length or a specific labelled key) on a telephone dialling keypad (or equivalent
device), shall cause a call attempt to be made from the 'A'-party to a
predefined 'B'-party associated with the supplied code;
• Last Number Redial
The operation of a key, shall cause a call attempt to be made from the
'A'-party to the 'B'-party to which the most recent previous call attempt
(successful or unsuccessful) was made;

3.3.5 Call Priority

6 [REQ TEL FUNCTIONAL] Call Priority

The Call Priority facility as described below SHALL be supported for deployment as both
Internal and External Facilities – including across ANSP/national borders.

3.3.5.1 Description
The call priority facility is a means of attaching an indicator (or flag) to a telephone call to show that it
is "urgent" as opposed to "routine". It is intended for use when it is necessary to make an urgent call
concerning the safety of aircraft (i.e. an emergency situation). Thus calls can be made with or without
priority so that there are two types as follows:

• Priority Calls;
• Routine Calls.

The ultimate decision and responsibility as to whether a call is a Priority rests with the ‘A’-party in
accordance with local operational procedures.

3.3.5.2 Making a Priority Call

There are 2 ways in which a priority call can be made:

• Manually before the call is first placed: Before making the call, operation of a priority key
will set the call to "Priority". This method is used when the call is already known to be urgent;

• Automatic setting of priority: Calls from either a particular CWP or individual keys are pre-
configured "Priority" in the VCS. This configuration would be established as a contingency for
use in special situations only. It is recommended that this type of configuration SHOULD be
an easily-selectable option by means of the System Management Terminal.

3.3.5.3 Receiving a Priority Call

At the CWP receiving a Priority Call the following sequence of events should take place:-

i) Distinctive and prominent audible and/or visual alerts clearly indicate to the ‘B’-party that a
priority call has been received.

ii) The ‘B’-party applies discretion as to how the priority call is dealt with, but normally it would be
answered as quickly as the prevailing operational circumstances allow.

© EUROCAE, 2009
 46

3.3.6 Instantaneous Access (IA) and Priority Call comparison

For further information, and improved clarity of distinction between two independent user facilities,
Table 3 – below compares an IA Call and a Priority Call.

7 [REQ TEL FUNCTIONAL] Instantaneous Access / Priority Call comparison

The System SHALL cater for all the conditions as described in Table 3 below.

Table 3 – Instantaneous Ca ll- Prio r ity Ca ll comparison

Instantaneous Access Call
Definition An "Instantaneous Access Call" is a call
with automatic call establishment that
enables audio transmission from the
calling party to the called party only,
without the called party having to
perform any acceptance action at the
called party’s terminal. Once the IA call
is established, the called party can also
transmit to the calling party by pressing
their IA key. The Instantaneous Access
call remains while there is at least one
party transmitting to the other.
(Refer to section 3.3.3 for an enhanced
description of IA)
Priority Call
The priority facility is a means of
attaching an indicator (or flag) to a DA
or IDA telephone call to show that it is
"Priority" as opposed to "Routine". It is
intended for use when it is necessary to
make a call concerning the safety of
aircraft (i.e., an emergency situation)
and to enable, if necessary, the
interruption of active routine (ordinary)
calls at the time.
In the event that the called party
encounters busy, automatic intrusion
may be permitted thus enabling the
calling user to establish communication
with a busy called user by intruding into
an established call between the called
user and a third user (unwanted user).

Priority calls and IA calls could occur Priority calls and IA calls could occur
simultaneously simultaneously.

Application An individual IA call may only take
place, exclusively and on a point-to-
point basis, between two pre-defined
parties and the ‘System’ shall
incorporate facilities to both establish
and control this so as to ensure that the
integrity of the call is never
compromised. Furthermore each
individual IA call facility will be
permitted across ANSPs borders only
by bi-lateral agreement.
Priority call status can be given before
call initiation or before the call is
answered.
Upon receipt of an incoming Priority
Call, the called party VCS will govern
how this is presented to the controller.
ANSPs are currently free to specify this
in the absence of any agreed common
operational procedure.

Specification The operational requirements for the The operational requirements for the
“Instantaneous Access Facility” are “Intrusion by a Priority Call” are specified
specified in section 3.3.3. in section 3.3.8.

© EUROCAE, 2009
 47

Instantaneous Access Call Priority Call

Establishment IA facility available in the VCSs involved Priority call facility available in the VCSs
conditions and IA key present on both user involved and Priority key present on the
terminals. calling user terminal.

Called party may be free or involved in
another active call (e.g. IA, Radio,
DA/IDA routine or DA/IDA priority call),
the actual status of the called party is
irrelevant.
Intrusion takes place only in the event
that the called party is already involved
in an active DA/IDA routine call
between the called party and a third
user (unwanted user).

The called party cannot be protected Intrusion is independent of any active IA

against IA call. or Radio calls.

The called party can be protected

against intrusion.

Audio Once established, if monitoring is Once established, calling user, called

enabled, the calling user may hear any user and unwanted user are connected
active ground & radio voice calls at together in conference.
called user CWP.

The called user hears audio transmitted

by the calling user.

Third user (if any) is unaware of the IA

call (because this is monitoring and not
conference).

Simultaneity It is possible to have more than one Only one intrusion to a CWP at a time.
incoming IA call to a CWP and all The first Priority call is connected and
incoming IA calls have to be further incoming Priority calls are put in
established. alerting state on the called CWP.

3.3.7 Typical call handling behaviour of new call events to CWP in pre-defined states
Table 4 illustrates typical VCS call handling behaviour of new call events to a CWP while the CWP is
in a pre-defined state. The table is provided for information and guidance.

Tab le 4 – Ca ll hand ling behav iour fo r p r e-def in ed C WP sta tes on n e w ca ll

events

Pre-defined CWP state New Call Event Call handling behaviour

Free (no calls) Routine DA/IDA call DA/IDA call is presented.

Free (no calls) Priority DA/IDA call Priority call is presented.

Free (no calls) IA call IA call is handled as detailed in IA facility

description 3.3.3.1

Routine DA/IDA call answered New Routine DA/IDA call New DA/IDA call is presented.

Routine DA/IDA call answered Priority DA/IDA call Intrusion occurs, if allowed by ANSP

If Intrusion is not allowed by ANSP the new

Priority call is presented.

© EUROCAE, 2009
 48

Pre-defined CWP state New Call Event Call handling behaviour

Routine DA/IDA call answered IA call IA call is handled as detailed in IA facility
description 3.3.3.1

Priority DA/IDA call answered Routine DA/IDA call New DA/IDA call is presented.

Priority DA/IDA call answered New Priority DA/IDA call New Priority DA/IDA call is presented.

Priority DA/IDA call answered IA call IA call is handled as detailed in IA facility

description 3.3.3.1

IA call in progress Routine DA/IDA call New Routine DA/IDA call is presented.

IA call in progress Priority DA/IDA call New Priority DA/IDA call is presented.

IA call in progress IA call IA call is handled as detailed in IA facility

description 3.3.3.1

Routine DA/IDA call New Routine DA/IDA call New Routine DA/IDA Call is presented.
+ Priority DA/IDA call answered

Routine DA/IDA call New Priority DA/IDA call New Priority DA/IDA Call is presented.
+ Priority DA/IDA call answered

Routine DA/IDA call IA call IA call is handled as detailed in IA facility

+ Priority DA/IDA call answered description 3.3.3.1

Routine DA/IDA call answered New Routine DA/IDA call New DA/IDA call is presented.
+ IA call in progress

DA/IDA call answered Priority DA/IDA call Intrusion occurs, if allowed by ANSP
+ IA call in progress
If Intrusion is not allowed by ANSP
the new Priority call is presented.

DA/IDA call answered IA call IA call is handled as detailed in IA facility

+ IA call in progress description 3.3.3.1

3.3.8 Call Intrusion

8 [REQ TEL FUNCTIONAL] Call Intrusion

The Call Intrusion facility as described below SHALL be supported:

3.3.8.1 Call Intrusion description

Call Intrusion is a variation in the sequence of events described in section 3.3.5.2 (Making a
Priority Call) above and SHALL apply only when a busy condition is encountered.

Call Intrusion should be established by bi-lateral agreement, but SHALL be supported for
deployment as both Internal and External Facilities – including across ANSP/national
borders.

3.3.8.2 Receiving A Priority Call with Intrusion Permitted and Enabled

At the CWP receiving a Priority Call, the following sequence of events SHALL take place:

i) The ‘B’-party receives, immediately, a pre-defined warning tone, via their telephone
equipment, that an intrusion is imminent as a consequence of a Priority Call being
received. The characteristics of the Intrusion warning tone SHALL be 1000Hz for a

© EUROCAE, 2009
 49

duration of 1 second (see section 3.3.1). If the call is not accepted this tone may be
repeated, periodically, after a time interval specified by the ANSP.
ii) The ‘B’-party applies discretion whether or not to release resources to permit the Priority
Call to be answered; the ‘B’-party may do this by either clearing a call already in progress
or by placing a call on hold.
iii) In the event that the ‘B’-party releases resources, as described above, the Priority Call
SHALL be either answered automatically or presented as a Priority Call (see section 3.3.5
above) as specified by the ‘B’-party ANSP.
iv) In the event that the ‘B’-party does not release resources within the pre-defined time
interval the ‘A’-party SHALL be connected in telephone conference at the CWP and the
warning tone stopped.

3.3.8.3 Preventing Call Intrusion

It SHALL be possible for any user to be protected against Call Intrusion by other users. This
protection SHALL be selectable either individually on a B-party, user-by-user basis, or as a
single parameter for all users connected to a VCS.

Note 31: For information Recommendation 7 of the CROBOCOM Task Force Conclusions
[21], states that Call Intrusion should be permitted at the CWP wherever possible.

3.3.9 Call Interruption

9 [REQ TEL FUNCTIONAL] Call Interruption

The Call Interruption facility as described below SHALL be supported:

3.3.9.1 Call interruption description

Call interruption is a facility whereby a Priority Call may interrupt a Routine Call in
circumstances when congestion is encountered on the interconnecting telephone links. Such
congestion may arise as a consequence of link failures – non ‘normal’ levels of telephone
traffic – and Call Interruption occurrences should thus be of low probability.

Call Interruption has been implemented by some – but not all – ANSPs and those that have
should ensure that any neighbouring ANSPs, likely to have their cross-border calls affected,
are advised accordingly and a bi-lateral agreement established concerning its application. In
present day systems Call Interruption may occur in both local and transit VCSs.

The foregoing description applies to the current circuit-based networks and might not be
applied directly to IP networks.

In IP networks appropriate measures SHALL be taken to assure the establishment of

priority calls.

Also in the event that Call Interruption does occur in any part of the system all parties
engaged in a call to be interrupted SHALL receive the current indications, by way of an
interrupt warning tone (see section 3.3.1) before the established routine call is interrupted.

3.3.10 Simultaneous Calls

10 [REQ TEL FUNCTIONAL] Simultaneous Calls

The occurrence of Simultaneous Calls SHALL be supported as detailed below:

A Simultaneous Call (SC) occurs when two Users call each other at exactly (or very nearly exactly) the

© EUROCAE, 2009
 50

same time. Simultaneous calls may arise as a result of any type of call (IA, DA and IDA) but the
outcome will vary depending upon the specific situation prevailing at the time.

3.3.10.1 Overriding Principles

In all cases of simultaneous calls the following overriding principles will apply:

a) Indeterminate call states and/or VCS conditions shall not arise

b) Users shall not receive false, ambiguous or misleading indications

c) Notwithstanding the specific situations described below the guaranteed outcome for both
Users shall be a “User Busy” indication.

Note 32: ‘User Busy’ is recommended in the VCS Procurement Guidelines [13].
ANSPs may, however, prefer ‘Number Unobtainable’ in response to Operational
Requirements.

3.3.10.2 Specific Situations

There are two specific simultaneous call situations that apply as follows:

Situation #1 – Each User connected to the same VCS

In this situation, within the performance criteria stipulated for Direct Access and
Instantaneous Access, a simultaneous call attempt SHOULD result in both Users being
connected.

Situation #2 – Each User Connected to a Separate VCS of any type

In this situation, within the performance criteria stipulated for Direct Access and
Instantaneous Access calls, a simultaneous call attempt SHOULD result in one of the
following outcomes:

a) Busy tone presented to the Users.

b) An automatic re-dial by each VCS after an interval of random length not

exceeding 3s. If this attempt is also unsuccessful, the re-dial sequence should
be repeated. If, after the second attempt, the re-dial sequence is unsuccessful,
Busy tone should be presented to the User and the re-dial sequence stopped.

Note 33: By bi-lateral agreement the outcome (a-b) for simultaneous call attempts should
be defined for each access method (IA, DA, IDA).

3.3.11 Call Queuing Facility

11 [REQ TEL FUNCTIONAL] Call Queuing Facility

The Call Queuing facility as described below SHALL be supported:

The Call Queuing facility provides a means for a User to have a number of incoming calls
placed in a queue so that the order of their arrival and some means of identifying their origin
can be easily determined.

Although the means of indicating the order of arrival is implementation specific, it is common
for some form of stacking arrangement to be used. Consideration needs to be given to the
maximum size of queue that would be considered manageable. Typically, a queue would be
5 or 6 calls deep.

© EUROCAE, 2009
 51

In pursuance of Recommendation 5 in the CROBOCOM Task Force Conclusions [21] the specific
Calling Party Identity SHOULD be provided to controllers wherever possible. In the event that it is not
possible to provide the specific Calling Party identity, it is recommended that a general identity
SHOULD indicate the generic source of the call.

Some examples are given in the Table 5 below:

Table 5 – Examples of g eneric identit ies

Identity indicated Origin
AGVN Another user on the ATS network but
without the means to indicate the AGVN
number.

PSTN A PSTN user without 'A'-party identity.

The basic attributes of the Call Queuing facility are as follows:

• all calls in the queue are in a calling (ringing) condition until answered;

• a manual process may be used for selecting the next call to be answered but this does not
preclude some form of first-in-first-out automatic selection;

• additional indications should be used to identify Priority Calls that have arrived in the queue.
Such indications might include a unique flag against the queue entry, a different display
attribute (e.g. flashing characters or a unique colour) and a distinctive audible alert.

Although it will usually be IDA calls that are directed to the Call Queuing facility, in some exceptional
circumstances (most commonly fault or call diversion conditions), DA calls may also be placed in a call
queue. In these cases, it is recommended that some additional means of identifying the call as a DA
call is given.

© EUROCAE, 2009
 52

3.4 SUPPLEMENTARY TELEPHONE SERVICES

3.4.1 Inter-ATSU Supplementary Telephone Services

12 [REQ TEL FUNCTIONAL] Inter-ATSU Supplementary Telephone Services

The following Supplementary Telephone Services, as described below, SHALL be supported

between ATSU’s within the Network.

3.4.1.1 Call Transfer

The Call Transfer facility SHALL enable a user involved in an active call to establish a new call
between the other user in the active call and a third party.

3.4.1.2 Call conferencing

Any CWP SHALL be able to initiate and manage a Conference. The Conference facility SHALL
enable a minimum of three Users and a maximum of 7 Users to speak together. Conferences
including external users may be established via external lines of varying types. The system SHALL
support conferences with a maximum of 7 Users, up to 6 of which may be external users connected
via external lines.

At any stage, any of the Users may leave the conference by de-selecting a key (i.e. hanging up). In
such cases the remaining Users SHALL stay interconnected.

A conference may be established in the following two ways – both of which SHALL be supported:

a) Broadcast
The conference initiator may sequentially call the other Users to establish the conference.
Both DA and IDA calls may be made. All Users in an established conference SHALL hear a
notification tone when a new participant joins the conference.
b) Meet Me
At an agreed time, Users call a pre-determined conference number. Both DA and IDA calls
may be made.
.
3.4.1.3 Position Monitor
For the future this internal facility (defined in para. 3.4.2.8 below) may be implemented as an external
facility and this situation SHALL also be catered for by the system.

3.4.2 ATSU Internal Supplementary Telephone Services

The Supplementary Telephone Services described below have been included for
completeness but have been labelled as Internal and thus deemed to be outside the scope of
this requirements document.

3.4.2.1 Common Appearance

The Common Appearance is an Internal facility that allows a number of users to be logically grouped
for the purpose of receiving calls. Calls to a Common Appearance Group are presented to all
members simultaneously for anyone to answer. It should be noted, however, that ‘B’ Party identity
may be ambiguous if the signalling system used supports this.

Outgoing calls may be made, individually, by each Group member.

3.4.2.2 Broadcast Call

A Broadcast call is an internal facility that provides direct and immediate Communications from a

© EUROCAE, 2009
 53

single supervisor position to two or more predefined Controller Working Positions. The speech is
unidirectional and without a monitoring facility. In some cases Broadcast Calls and their Origin are
indicated at the Controller Working Position.

3.4.2.3 Call Hold

Call Hold is an Internal facility that allows a user to disconnect temporarily from an established call in
order to carry out other telephony functions before returning to the original established call.

3.4.2.4 Call Pick-Up

Call Pickup is an internal facility that enables a user to answer a call that is in the alerting phase
(ringing) at another user's terminal.

3.4.2.5 Call Diversion

Call Diversion is an internal facility that enables a user to re-route all incoming calls to another user /
CWP in the following circumstances:

• unconditionally;

• if a busy condition is detected at the 'B'-party;

• if the 'B'-party fails to answer an incoming call within a predetermined time (no reply).

3.4.2.6 Hunt Group

This is an internal facility whereby a group of users is defined so that any of them may be called by a
common number (target AVGN group number). When that number is called the system hunts through
the group of users until it finds one which is free and available to take the call. Users will retain their
normal numbers which may be called individually. A Hunt Group may be provided in the following
forms:-

• Sequential: first free user following a pre-defined sequence in the Hunt Group

• Cyclic: the system will start searching from the last user accessed via the Hunt Group

• Longest Free: the system will search for the user which had the greatest elapsed time since
being accessed via the Hunt Group

A user may belong to more than one Hunt Group.

3.4.2.7 Group Call

A group call is defined as a VCS internal call which allows one or more users in the one group
(typically 3 users – 1 sector) to be connected to one or more users in another group. It is possible for
members of either group to join a call in progress and for any user to leave a group without closure of
the call. It is possible for a user to be part of more than one group call at the same time.

3.4.2.8 Position Monitor

Position Monitor is currently an internal facility whereby, in its basic form, the communications of one
user position may be monitored at another user position. Monitoring includes all incoming and
outgoing ATS audio (but not the deliberate monitoring of room ambient noise). A more complex
situation may arise where monitoring requirements may include one or more complete controller
working positions as may be defined by a specific role.

3.4.2.9 Redial
Redial is an internal facility that allows the dialling of a previously-used destination number again.

© EUROCAE, 2009
 54

3.5 ADDRESSING AND NUMBERING SCHEMES

3.5.1 Numbering Schemes

13 [REQ TEL FUNCTIONAL] Numbering Schemes

A VCS SHALL support the following existing user numbering and addressing schemes:

- Numbering Scheme as defined in:

o “ICAO Manual on ATS Ground–Ground Voice Switching and
Signalling” (Chapter 2 Section 2.3) [1]
o EUROCONTROL document "ATS Ground Voice Network
Implementation and Planning Guidelines”. [14]
o EN 300 189 "Private Integrated Services Network (PISN);
Addressing" [26]

- IP Addressing Scheme:
o Compliant with EUROCONTROL IPAX (Internet Protocol for
Aeronautical Exchange) address structure [20].

- Mnemonic Addressing Scheme

o Based on relevant ATS information (User, ATS sector, ATS radio
frequency, ATS radio site, ATSU, ICAO site identifier, ANSP or ATS
Organisation).

3.5.2 Number or Address Assignment

14 [REQ TEL FUNCTIONAL] Number assignment

Each end user SHALL be allocated one or more unique addresses or numbers within the
scope of the VCS addressing scheme.

3.5.3 Global Numbering Schemes

15 [REQ TEL FUNCTIONAL] Global numbering schemes

Compatibility with the current recommended ICAO numbering plan as specified in

ICAO doc. 9804 SHALL apply [1]
The global PSTN numbering scheme SHALL comply with ITU-T E.164 [24]

© EUROCAE, 2009
 55

3.6 EXTERNAL CONNECTIONS AND PROTOCOLS

16 [REQ TEL FUNCTIONAL] External connections and protocols

The interfaces and associated protocols as described below SHALL be supported:

3.6.1 Signalling in an IP AGVN

Signalling and audio of ATS calls SHALL be handled using specific protocols that permit the
establishment, termination and modification of speech media sessions of the Ground Telephone
Service in an IP Air Traffic Services Ground Voice Network (IP AGVN).

3.6.2 External Connections and associated Protocols

The VCS SHALL support the following connections and associated protocols as selectable
options:

• ATS-SIP VoIP interface;

• ATS-R2 interface;
• Basic Access Euro ISDN interface (2 B+D);
• Primary Rate Euro ISDN interface (30 B+D);
• Foreign Exchange Office (FXO) or PSTN/PBX Ring-in/Dial-out (RIDO)
interface (see Note 34);
• Foreign Exchange Station (FXS) or Central Battery (CB) Dial-in/Ring-out
(DIRO) interface
• ATS-No 5 interface;
• ATS-QSIG interface;
• PSS1 (QSIG) interface;
• Local Battery (LB) Ring-in/Ring-out (RIRO) interface;
• E&M interface.

Supporting documents:

Tab le 6 – In te rfa ce and P roto co l s up port doc um en ts

INTERFACE REFERENCE (not exhaustive)

EUROCAE ED-137 “INTEROPERABILITY STANDARDS FOR VoIP ATM

VoIP
COMPONENTS PART 2 : TELEPHONE” [22]

“PRIVATE INTEGRATED SERVICES NETWORK – ECMA-312 ed.3

ATS-QSIG (06/03): “Private Integrated Services Network (PISN); Profile Standard for
the Use of PSS1 (QSIG) in Air Traffic Services Networks” [28]

EUROCONTROL “ATS R2 and ATS No.5 protocol specification” Edition

ATS-R2
1.0; EATM Info centre Reference: 05/01/12-04 [15]

EUROCONTROL “ATS R2 and ATS No.5 protocol specification” Edition

ATS-No 5
1.0; EATM Info centre Reference: 05/01/12-04 [15]

ETSI ES 203 021 [37] and ETSI Advisory Notes EG 201 121 [42]
CB ITU-T Rec. Q.23 [58] ITU-T Rec. Q.24 [59] and ITU-T G.224 [52]
ETSI EN 300 659-1 [34] /EN 300 659-2 [35]

ETS 300 012-1 (ITU-T Rec. I.430 modified) [31]

Euro ISDN
ETS 300 402-2 (ITU-T Rec. Q.921 modified) [32]
(2B+D)
ETS 300 403-1 (ITU-T Rec. Q.931 modified) [33]

© EUROCAE, 2009
 56

INTERFACE REFERENCE (not exhaustive)

ETS 300 011-1 [30]

Euro ISDN
ETS 300 402-2 (ITU-T Rec. Q.921 modified) [32]
(30B+D)
ETS 300 403-1 (ITU-T Rec. Q.931 modified) [33]

ECMA-143 ed.4: Private Integrated Services Network (PISN) - Circuit

PSS1 (QSIG) Mode Bearer Services - Inter-Exchange Signalling Procedures and
Protocol (International Standard ISO/IEC 11572) [29]

ETSI TBR 021 [40]

ETSI TBR 038 [41]
FXO (RIDO)
ETSI ES 203 021 [37] and ETSI Advisory Notes EG 201 121 [42]
ITU-T Rec. Q.23 [58] ITU-T Rec. Q.24 [59] and ITU-T G.224 [52]
EN 300 659-1 [34]/EN 300 659-2 [35]

ETSI ES 201 970 [38]

FXS (DIRO)
ITU-T Rec. Q.23 [58] ITU-T Rec. Q.24 [59] and ITU-T G.224 [52]

ETSI TBR 015 [39]

LB
ITU-T Rec. Q.1 [55] Q.2 [56] and Q.8 [57]

E&M ANSI T1.409-2002 (R2006) [62]

Note 34: The terms FXO and FXS are commonly used in North America while the terms RIDO
(PSTN/PBX) and DIRO (CB) are used more often in Europe. This document considers FXS to be
equivalent to DIRO (CB) and FXO to be equivalent to RIDO (PSTN/PBX). The DIRO/FXS interface is
used to connect analogue terminal/stations to the VCS, allowing address information to be Dialled-In
from the terminal/station to VCS and providing a Ring-Out Voltage towards to terminal/station. The
RIDO/FXO interface is also used to connect analogue terminal/stations to the VCS, but allows Ring-in
voltage from terminal/station to the VCS and then triggers address information to be dialled out from
the VCS towards another VCS.

3.7 INTERWORKING WITH ATS LEGACY SYSTEMS

17 [REQ TEL FUNCTIONAL] Interworking with ATS Legacy Systems

The IP AGVN systems SHALL interwork with ATS-R2/ATS-QSIG based AGVN systems in
order to support calls originating in one environment and terminating in the other.

The VoIP VCSs SHALL guarantee call interworking with appropriate mapping of the call
signalling (i.e. user identification, terminal status, priority, call intrusion, call protection etc.)
and also necessary voice transcoding required between legacy circuit-switched AGVN
systems and IP AGVN systems and vice versa. The Table 7 below defines whether
interworking between the various signalling protocols and voice codecs is Mandatory
(SHALL) or Recommended (SHOULD).

Interworking with ATS-No.5-based AGVN systems is RECOMMENDED.

T a b l e 7 – C i r c u it - S w it c h ed a nd Pa ck et - S w it ch ed C a l l int er wo rk i ng

From/To VoIP ATS-QSIG ATS-R2 ATS-No5

VoIP SHALL [a] SHALL [a] SHALL [a] SHOULD [a]

ATS-QSIG SHALL [a] SHALL [c] SHALL [d] SHALL [e]

ATS-R2 SHALL [a] SHALL [d] SHALL [b] SHALL [b]

© EUROCAE, 2009
 57

From/To VoIP ATS-QSIG ATS-R2 ATS-No5

ATS-No5 SHOULD [a] SHALL [e] SHALL [b] SHALL [b]

The use of “tunnelling” signalling over an IP network, which means replacement of dedicated
(analogue or digital) links by an IP network using two “converters” (that encapsulate, for instance,
analogue signalling in RTP frames) connected at opposite ends of the IP network to interconnect two
legacy VCSs, instead of using the interworking function (refer to CHAPTER 3 telephone section) is
NOT RECOMMENDED.

Supporting documents:

[a] EUROCAE ED-137 “INTEROPERABILITY STANDARDS FOR VoIP ATM COMPONENTS,

PART 2 : TELEPHONE” [22]

[b] EUROCONTROL “ATS-R2 AND ATS-No5 SIGNALLING PROTOCOL SPECIFICATION” [15]

[c] ECMA 312 “PRIVATE INTEGRATED SERVICES NETWORK – PROFILE STANDARD FOR
THE USE OF PSS1 (QSIG) IN AIR TRAFFIC SERVICES NETWORKS” [28]

[d] EUROCONTROL “INTERWORKING BETWEEN ATS-QSIG AND ATS-R2 SIGNALLING

SYSTEMS”, [17]

[e] EUROCONTROL “INTERWORKING BETWEEN ATS-QSIG AND ATS-No5 SIGNALLING

SYSTEMS” [16]

within the framework of the EUROCONTROL “ATS GROUND VOICE NETWORK IMPLEMENTATION
AND PLANNING GUIDELINES”.[14]

3.8 CONNECTIVTY WITH PRIVATE AND PUBLIC TELEPHONE NETWORKS

18 [REQ TEL FUNCTIONAL] Private & Public Telephone network connectivity

The IP AGVN systems SHALL enable users to establish external voice connections to both
PBX terminals and PSTN trunk lines.

Following ICAO Annex 10, Vol. II, Chap 2.2 “Telecommunication access” [5], all aeronautical
telecommunication stations, including end systems and intermediate systems SHALL be
protected from unauthorized direct or remote access.

3.9 INCOMING CALL BARRING AND RESTRICTION

19 [REQ TEL FUNCTIONAL] Incoming call barring & restriction

When the VCS has connections to external networks it SHALL be possible to restrict or
block unwanted callers. For that purpose the VCS shall employ a way to either block (bar)
calls or re-route calls based on their Calling User Identity (CUI) in accordance with the
following requirements:-

1. The VCS SHALL be able to bar or restrict incoming calls based on their CUI.

2. The VCS SHALL be able to bar or restrict incoming calls without CUI.

3. The VCS SHALL employ a barring and restriction capability. Means SHALL be
available to define actions in respect with CUI (e.g. barring, restriction).
Wildcard designators SHALL be accepted in the CUI .

© EUROCAE, 2009
 58

4. Calls that are defined to be barred SHALL be treated as calls to a busy or non-
allocated subscriber depending on network specification.

5. Calls that are defined to be restricted SHALL be routed according to a specified

action

3.10 HANDLING OF OUTGOING CALLS / ROUTING CRITERIA

When either the VoIP Gateway (GW) or VCS employ connections to external networks such as the
PSTN, it is necessary to have the possibility of controlling how the external networks are used for
outgoing calls. Many VCS systems employ an independent numbering scheme, and most external
networks employ their own independent numbering schemes. It is therefore necessary to provide a
means of translation (or mapping) between the internal numbering scheme and those employed by
external networks.

20 [REQ TEL FUNCTIONAL] Outgoing Calls/Routing Criteria

The following requirements SHALL apply:-

1. A VCS user SHALL be able to initiate a call to any available external telephone network.

2. Where the VCS & GW include several external links to the same network (e.g. ATS-R2
network), the VCS & GW SHALL be able to route the external call to the correct link
based on the called number (B party number). The VCS & GW management system
SHALL in this case include means for maintenance personnel to define the routing
tables.

3. The VCS & GW SHALL include definitions on both main and alternate (detour) links for
specific destinations. If the main link is not available the VCS &GW SHALL automatically
route the call on the alternate link.

4. The VCS & GW SHALL be able to automatically transit an incoming call from one
network to another link in the same network or to another network based on the called
number (B party number). The VCS & GW management system SHALL include means
for maintenance personnel to define whether incoming calls to a specific number are
terminated within the VCS or transited to another link/network.

© EUROCAE, 2009
 59

CHAPTER 4

SAFETY AND AVAILABILITY

4.1 DEFINITIONS
The following terms apply within this chapter:

• Back-up / Standby:

Technical: A system that is either totally or substantially independent of the Main system. It is
used in the event of severe degradation of the Main system such that it no longer provides an
acceptable level of service to the user. Back-up may also be used as a planned and agreed
alternative during maintenance of the Main system.

Operational: A system that is ready and available when the Main system has either become
severely degraded due to either unexpected failures or planned maintenance. Back up
systems may have known reduced functionality.

• Fall-back:

Technical: A system that is either totally or substantially independent of the Main system to
be used in the event of failure of the Main system and any Back-up system. Fall-back is not
used as an alternative during maintenance of the Main or Back-up systems. Fall back systems
usually provide basic functionality.

Operational: A system that is used when the Main (and Back-up if provided) system has
failed unexpectedly. Fall-back systems usually have limited functionality requiring that
adjacent ATS Units be notified and increased separation with reduced flow procedures
implemented.

Example: PSTN may be used as a Fall-back to direct point-to-point telephone links or the
ATS Ground Voice Network.

4.2 INTRODUCTION
Responsibility for Safety, with regards to those parts of the ATM System for which they have
managerial control, rests with the ANSPs. The ANSPs are currently subject to a Safety Regulation
Authority.

This Chapter does not touch upon Safety from a Regulatory perspective but seeks to address those
issues where Safety may be affected by Availability.

4.3 ASSUMPTIONS
a) The provision of Back-up* / Standby* ATM facilities is an ANSP responsibility.
b) The provision of Fall-back* ATM facilities is an ANSP responsibility.
c) The provision of ATM facilities where there is a known inter-dependency between
systems (i.e. where one is used as Back-up* to another) is an ANSP responsibility
(including any cross-border Agreements).

* Definitions of these terms are included in section 4.1.

© EUROCAE, 2009
 60

4.4 SAFETY ASPECTS ASSOCIATED WITH DIFFERENT TYPES OF VOICE

SERVICES
4.4.1 Introduction
It is almost certain (for purely economic reasons) that voice services will have to share IP Network
resources with other services. Leaving aside any discussions about comparative priorities in terms of
which is the most important from a safety perspective, voice messages have to be conveyed in real
time if they are to retain intelligibility. On the other hand some types of data messages will not lose
their usefulness if they are delayed due to either queuing or the need for re-transmission. The
availability of voice services is thus significantly influenced by the priority of the voice packets as they
either enter/exit gateways or transit the network.

4.4.2 Call type discrimination during call establishment phase

1 [REQ SAFETY] Call type discrimination during call establishment phase

In order to discriminate between different types of voice services (radio and telephone, for
example) during the call establishment phase, the following association between call types
and the SIP Priority Header field SHALL be provided.

T a b l e 8 – A s so c ia t ion b et w ee n C a l l t y p e s a n d t h e S IP P ri o r it y H ea d e r f ie l d

Tactical/Strategic/ SIP Priority header field

Type of call Neither (IETF RFC 3261)
(see Note 35)

Priority Direct / Indirect Access call Tactical/Strategic emergency

Radio Tactical emergency/urgent/normal

Instantaneous Access call Tactical urgent

Routine Direct / Indirect Access call Tactical urgent

Routine Direct / Indirect Access call Strategic normal

General Purpose Routine Direct / Indirect

Support non-urgent
Access call

Note 35: The term “SIP Priority header field” as defined in Table 8 is different from the term “Priority
Call” as used in 3.3.5.1. A Priority call according to 4.4.2 is classed as an operational tactical or
strategic call having its SIP Priority Header field set to “emergency”, while a Routine call is classed as
a tactical, strategic or support call having its SIP Priority Header field set to “Urgent”, “Normal” or “Non-
Urgent” respectively depending on ANSP requirement.

4.4.3 Precedence of Voice services

2 [REQ SAFETY] Precedence of voice services on transport infrastructure

Functionality to discriminate between different operational types of voice services (radio and
telephone, for example) SHALL be provided at the link/network/transport OSI layers. Fifteen
types of service SHOULD be available.

© EUROCAE, 2009
 61

The ANSPs are responsible to assign a precedence level to each type of voice service, but there is a
potential Safety hazard where there is no common scheme applied by all the ANSPs. There is,
therefore, a need for the ANSPs to agree on the setting of precedence levels for all services to be
carried on the IP network. An example of such a precedence scheme for voice services is as follows:

Tab le 9 – Exam p le of Vo ice S erv ic e s p r ec ed en c e s ch e me

Precedence Level Type of Voice Service

(in descending order)
1 Emergency telephone call

2 ATC Tactical radio Transmission

3 ATC Tactical radio Reception

4 Instantaneous Access (IA) telephone call

5 Tactical telephone call

6 Aircraft re-transmission (in cross-coupled mode)

7 Legal Voice Recording

8 Strategic telephone call

9 ATIS / VOLMET radio transmission

10 Technical radio check

11 -15 Reserved for other future voice services

4.4.4 IP-voice packets priviliged

3 [REQ SAFETY] IP-voice packets privileged

Packets containing IP-voice or IP-voice related signalling SHALL always be privileged while
passing through the network.

4.4.5 IP-voice / IP-data packet flow separation

4 [REQ SAFETY] IP-voice / IP-data packet flow separation

IP-based networks carrying data and voice in a common network infrastructure SHALL
implement means to separate IP encapsulated voice packets from other IP-encapsulated
user applications in order to assure that voice is not affected by data traffic. The separation
MAY be performed by the physical or the logical network infrastructure.

4.4.6 No QoS degradation of IP-voice

5 [REQ SAFETY] No QoS degradation of IP-voice

There SHALL be no QoS degradation of IP-voice by non-voice-IP data flows on the

transport infrastructure.

© EUROCAE, 2009
 62

4.4.7 Precedence Level assignment of Voice Services

6 [REQ SAFETY] Precedence level assignment of voice services

Each ANSP is responsible to define a precedence scheme identifying the precedence levels
assigned to voice services and the system SHALL facilitate this.

Each ANSP SHOULD coordinate with adjacent ANSPs so as to ensure that their precedence
schemes are compatible. The meaning of “Compatible” is that there are no conflicts that could impact
on either safety or security.

4.4.8 Precedence of Voice packets during Congested or degraded network operation

7 [REQ SAFETY] Precedence of voice packets during Congested or degraded

network operation

In degraded network operation, IP-based networks carrying digital data and digitized voice in
a common network infrastructure SHALL implement means to assure precedence is always
given to voice packets and to prioritize the voice service with highest precedence given to
voice packets.

4.5 AVAILABILITY: ISSUES, GUIDANCE AND MAIN PRINCIPLES

4.5.1 Introduction
This sub-chapter has been compiled to:

• highlight the issues concerning availability;

• provide some guidance as to how high levels of availability may be achieved for
individual ATM facilities;

• detail the main principles to achieve high levels of availability.

The above approach is an alternative to specifying actual performance figures for either individual
systems or entire services. The reasons for this approach may be summarised as follows:

• The concept of when a service is “unavailable” (taken to mean “declared unfit for its
intended purpose”) varies widely amongst ANSPs.

• The true boundary of what is encompassed by a precise availability figure is not always
clearly defined and understood – and again will vary amongst ANSPs.

• Theoretical prediction of availability may prove to have a wide margin of error.

• Specification of availability figures (for both individual systems and complete services) is
often done in a cautious manner such that the tendency is to over, rather than under
specify. System suppliers will often respond to this by over-engineering with consequential
costs.

The definition of service availability requirements is outside the scope of this ED-136 document.

4.5.2 Availability Issues

• It is, ultimately, the responsibility of each ANSP to determine what constitutes safe

© EUROCAE, 2009
 63

practice, which includes the use of safe systems. The ANSP Regulatory Authorities will
demand evidence of safety analysis ‘cases’ being established. At a lower level,
responsibility rests with the ‘service provider‘ (see Note 36 below), who has to comply with
prescribed availability requirements using the facilities that are available to them.

Note 36: In this context the term ‘service provider’ implies the Authority responsible for the
provision of individual services – E.g.: Air-Ground Radio, Approach Radar

• In the short-medium term it is assumed that CWPs and VCSs will continue to be used
without any major changes in system architecture and software, other than those that
arise through technological/commercial developments. Therefore the current availabilities
of these items will either be maintained or improved.

• The item which will be introduced in the short-medium term will be a new IP-based
network that provides connectivity between remote sites. It is this network which will
introduce a significant change in architecture replacing services that previously would
have been provided by the Public Telecommunications Operators (Telcos). The
availability of the IP-based network, used for voice, is therefore the main point of concern
as are the newly developed and implemented ‘gateways’ which will provide IP interfaces
to the legacy systems.

• Should the assumptions above be valid, the IP-based network including any gateway
interfaces, will have to achieve an end-to-end availability that at least matches that of a
Telco for standard analogue and digital private circuits (i.e. in the order of 99.8%).

• The ‘service provider’ recognises that a Telco is a common point of potential failure and
takes steps to mitigate this where alternatively-routed, back-up circuits are judged to be
necessary. In a similar manner, the IP-based network, including any gateway interfaces,
would need to equal the total availability of two independently-routed circuits (one of which
need not necessarily be via a Telco), by employing for example a private microwave link
etc.

4.5.3 Points of Guidance

• Both the ‘service providers’ and the IP Network Provider recognise that the IP Network is
a common point of potential failure, such that back-up services SHOULD be adequately
protected. Ground telephone for example is often the designated back-up to be used in
the event of an OLDI link failure. Steps need to be taken therefore to avoid common points
of potential failure.

• For radio applications the current practice of providing a standby radio system (possibly
with reduced functionality when compared with the ‘main’ radio system) SHOULD
continue.

• The IP Network SHOULD be designed so as to meet the requirements of Radio

applications (that have the most stringent criteria), taking into account the standby radio
systems that SHOULD also be provided.

• Some ANSPs and Safety Regulatory Authorities have adopted the Risk criteria for radio
as illustrated below:

Event
Sudden inability to provide any degree of air traffic control (including contingency
separation measures) within one or more airspace sectors for a significant period of time.

Tolerability
Unacceptable.

Probability of Occurrence
Extremely improbable (i.e. Extremely unlikely, if not inconceivable to occur)

© EUROCAE, 2009
 64

Quantitative Value per operational hour per sector < 10-7.

4.5.4 Illustrative Case Examples

Given below are two practical cases illustrating how the operational environment and the architectural
choices made by an ANSP will influence the required availability of the VoIP system and/or of one of
its components.

Case 1: The ANSP policy is to cover one ATC sector with one frequency using 2 radio
locations (main and back-up), each location containing two sets of redundant
transmitters/receivers. Thus 4 sets of transmitters/receivers are available to cover
the sector.

Case 2: Only one transmitter and one receiver are available to cover an ATC sector.

Conclusion: In case 2, the availability requirements of the single transmitter and receiver
equipment must be higher than in case 1 in order that the intended service
availability for both cases is the same.

It is an ANSP responsibility to ensure that the combination of operations, technical architecture and
availability of individual equipment deployed complies with Regulatory Requirements such as
EUROCONTROL Safety Regulatory Requirement (ESARR) 4 “Risk Assessment and Mitigation in
ATM” [18].

The Figure 19 below is included as an example of a methodology to ensure this compliance.

© EUROCAE, 2009
 65

F ig u r e 1 9 : O p e ra t ion s, T ec h n i ca l a rc h ite ct ure an d Ava ilab ility co mp lia nc e

met hodo logy

© EUROCAE, 2009
 66

CHAPTER 5

RECORDING

5.1 BACKGROUND
Given that recording of Controller Voice communications, the methodology employed in their
management and the quality of service requirements to be applied etc, are currently subject to well-
established ANSP practices, the following requirements relate only to the possible impact of
introducing IP-based technology.

Emphasis has therefore been placed on defining requirements to comply with existing ICAO SARPs
and what is foreseen in order to comply with National Regulatory requirements.

5.2 RECORDING REQUIREMENTS’ ASSERTIONS

This section drafts out a framework of assertions under which recording SHALL be undertaken.

Assertion #1
Only those requirements applicable to voice recording will be considered.
(e.g. radar data recording etc is outside the scope of WG-67)

Assertion #2
Only those requirements relating to the recording of voice communications associated with Air
Traffic Services Units (ATSUs), refer to Note 37 below, will be considered i.e. all Operational
Voice interactions (within and to/from the Operations Room) as follows:-

• ATSU – ATSU communications;

• ATSU – radio stations;
• All communications within an ATSU relating to Air Traffic Management;
• All communications between the ATSU and the military units;
• All communications related to the management of emergencies;
• All communications to/from the Operational Areas;
• Controller working positions using local radios and standby facilities.

Note 37: The term ATSU is used to include any location where the business of air traffic
management is conducted including airports, ACCs and Flight Information Units etc.

Assertion #3
The legal boundary within which recording will be performed is that of the ATSU. Recording at
other locations may be an ANSP specific requirement and outside the scope of these
requirements.

Note 38: ‘Legal’ Recording responsibilities rest within each individual ATSU – subject to specific
regulatory requirements.

© EUROCAE, 2009
 67

5.3 RECORDING REQUIREMENTS

Within the framework stipulated in the section above this section details the actual ‘legal’ recording
requirements. Reference is made to ICAO –Annex 10, Volume II, Chapter 3.5 relating to recording of
ATC communications [6].

The following requirements SHALL apply to IP components hereafter referred to as the ‘IP system’

1 [REQ RECORDING] True and faithful representation of audio signal

The IP system SHALL, at all times, provide a means for recording voice which is a true and
faithful representation of the audio signals being presented at the points detailed in 4 [REQ
RECORDING] ENTITIES FOR VOICE RECORDING AND LOCATION IDENTIFICATION
below. (Audio quality SHALL neither be degraded nor improved).

2 [REQ RECORDING] Provision for 2 identical autonomous voice recordings

The IP system SHALL provide a means by which two autonomous voice recordings can be
made. Both recordings SHALL be identical in all respects.

Note 39: The assumption here is that two recording devices would be required for
redundancy, maintenance purposes etc.

3 [REQ RECORDING] Date & Timestamp Synchronization

For the purposes of imprinting date and timestamp information with the recorded voice (in
order to enable the time and date of re-played voice messages to be precisely identified), the
IP System SHALL be synchronous with the date and time data source utilised by the
associated ATSU. (This is assumed to be Universal Time, Coordinated (UTC) to the
accuracy specified by ICAO [11]

4 [REQ RECORDING] Entities for voice recording and location identification

The IP system SHALL provide a means by which recordings SHALL be made of voice
messages at the following entities:

• a specific controller working position;

• a specific radio receiver;
• a specific radio transmitter;
• a specific 3rd party.

The exact location of the entities above SHALL be identifiable and demonstrable with high
integrity during replay of the recordings.

5 [REQ RECORDING] Voice recording all communications at CWP

Provisions SHALL be made to enable the recording of all communications at position level.

5.3.1 Short Term recording at CWP

To facilitate an instant re-play facility the system SHOULD provide a “short term recording”
functionality at the controller working position level for radio communications.

© EUROCAE, 2009
 68

CHAPTER 6

VOICE QUALITY

6.1 INTRODUCTION
The speech quality using VoIP in an ATM environment is an important aspect and the requirements
are presented from the user perception as well as technical requirements on transmission
characteristics.

The key requirement within this document is that of the subjective measurement required. There are
no requirements placed on items such as the speech coding algorithm, jitter and packet loss although
all of these things may affect the voice quality. EUROCAE Document ED-137 ‘Interoperability
Standards for VoIP ATM Components’ [22] includes details as to how these items should be managed
by the G/G segment in order that compliance to key subjective measurement requirements can be
achieved.

6.2 REFERENCES
The following references defined in ANNEX A REFERENCES are applicable to this chapter.

• E67-WP-DGAC-08-V01 Version 3 (06/06) DSNA Reference Paper: Requirements for “Voice

Quality” [47]

• ITU-T Recommendation G.109 (09/99): Definition of categories of speech transmission quality

[48]

• ITU-T Recommendation G.114 (05/03): Transmission Systems and Media, Digital Systems
and Networks - International telephone connections and circuits – General Recommendations
on the transmission quality for an entire international telephone connection- One-way
transmission time [49]

• ITU-T Recommendation G.116 (09/99): Transmission performance objectives applicable to

end-to-end international connections [50]

• ITU-T Recommendation G.131 (11/03): Talker echo and its control [51]

6.3 REQUIREMENTS
6.3.1 Voice Transmission Quality

1 [REQ VOICE QUALITY] Mean Opinion Score of A/G & G/G communications >4

The system SHALL achieve a Mean Opinion Score (MOS) > 4.0 (This is equivalent to
80 ≤ R < 100) for all air-ground and ground-ground communications.

Table 10 – ITU -T G.109- Relat io nship bet ween E-mo del (R) , MOS and Speech
T ra ns m is s io n qua l it y c a t eg o ry

Speech transmission
R-value range User satisfaction MOS
quality category

90 ≤ R < 100 Best Very satisfied 4.3

80 ≤ R < 90 High Satisfied 4.0

© EUROCAE, 2009
 69

6.3.2 Talker-Echo tolerance

2 [REQ VOICE QUALITY] Talker-echo tolerance compliant with ITU-T G.131

The system SHALL ensure that during any communication, the User’s own echo is within
the acceptable area of the ITU-T G.131 [51] recommendation as illustrated in Figure 20
below, for both telephone (reflected echo) and radio (sidetone).

Fig ure 20 : ITU -T G.131 – Ta lker echo to lerance curves

© EUROCAE, 2009
 70

6.3.3 One-Way Voice delay (Telephone)

3 [REQ VOICE QUALITY] One-way voice delay (telephone)<150ms

The one-way voice delay for ground-ground communication between CWPs located within
the same or different ATSU’s SHALL be less than 150 ms, in compliance with ITU-T
recommendation G.114 (05/03) [49]

Note 40: ITU-T G.114 (05/03) Appendix II – Guidance on one-way delay for Voice over IP
states that for many intra-regional routes (e.g., within Africa, Europe, North America) within
the range of 5000 km or less, users of VoIP connections are likely to experience mouth-to-
ear delays <150 ms.

6.3.4 One-Way Voice delay (Radio)

4 [REQ VOICE QUALITY] One-Way voice delay (radio) <130ms

The system SHALL comply with the RADIO SYSTEM PERFORMANCE REQUIREMENTS
as defined in 6 [REQ RADIO PERFORMANCE] 130ms max Ground Transmission Voice
delay.

6.3.5 Syllable Clipping

Clipping in a speech network is when parts of a word are cut from a section of speech. This
normally occurs at the start and end of a section of speech but may also occur during active
speech.

6.3.6 Clipping Speech Segments

5 [REQ VOICE QUALITY] Speech Clipping segments ≥64ms avoided,<64ms

within 0.2% of active speech

Clipping of speech segments ≥ 64ms SHALL be avoided, in compliance with ITU-T

recommendation G.116 [50].

Clipping segments < 64ms SHALL be kept below 0.2% of active speech, in compliance with
ITU-T recommendation G.116 [50].

6.3.7 Voice Transmission Characteristics

6 [REQ VOICE QUALITY] Voice transmission characteristics

The voice transmission characteristics requirements SHALL apply to the voice channel only
and do not include microphone and headset characteristics.

The end to end transmission characteristic parameters SHALL be shared evenly between
the encoding end and the decoding end.

The requirements for transmission characteristics MAY not be realistically met if legacy
analogue lines/trunks (i.e. ITU-T M.1030 [54]) are used within the network.

© EUROCAE, 2009
 71

6.3.8 Voice Frequency Response

7 [REQ VOICE QUALITY] Ground-Ground voice frequency response

The frequency response of any ground-ground connection SHALL be such that the gain at
any frequency between 300Hz and 3.4 kHz SHALL be within +1dB and -3.0dB of the gain at 1
kHz.

Note 41: The minimum frequency response of any air-ground connection should be such that
the gain at any frequency between 300Hz and 2.8 kHz should be within +0.7dB and -3.0dB of
the gain at 1 kHz.

6.3.9 Cross-Talk

8 [REQ VOICE QUALITY] Cross-Talk level <-60dBm0 for 1KHz test tone

The Crosstalk level on any voice circuit SHALL not exceed -60dBm0 when a 1 kHz test tone
is injected into any other voice circuit at a level of 10dB above nominal test tone level, with
all voice circuits correctly terminated. (The nominal test tone level is -10dBm0)

6.3.10 Noise and Hum

9 [REQ VOICE QUALITY] Noise and Hum

The residual noise and hum on any correctly terminated idle voice circuit SHALL not exceed -
60dBm0p.

6.3.11 Total Distortion, including quantizing distortion

10 [REQ VOICE QUALITY] Total Distortion, including quantizing distortion

The Total Distortion, including quantizing distortion SHALL comply with ITU-T G.712 [53].

© EUROCAE, 2009
 72

CHAPTER 7

SYSTEM ENGINEERING AND MANAGEMENT

7.1 MANAGEMENT AND MONITORING

7.1.1 Basic Definitions and Considerations
Throughout this document Management combines two different types of activities into one term.

• Configuration/Control
• Supervision/Monitoring

Configuration/Control: Configuration/Control allows a Controller (i.e. ATS Controller or a technician)

to prepare and change part of or all attributes relative to a certain entity of the system.

Supervision/Monitoring: Supervision/Monitoring allows a Controller (i.e. ATS Controller or a

technician) access to visualize the current status and configuration of single attributes or collections
and aggregations of attributes.

In addition, Management has to be considered in relation to the system to be managed and its
associated entities. As the focus of this document relates to IP-based voice services, the following
differentiation may apply:

Element Management facilities allow configuration and monitoring of single physical and logical
entities (e.g. interfaces, servers, switches, clusters etc.);

Network Management facilities allow configuration and monitoring of the communications

infrastructure virtually as a single entity;

Service Management facilities allow configuration and monitoring of the different services within the
system. Services typically are SW. Therefore Service Management may be considered as the SW
management;

User Management facilities allow configuration and monitoring of users and roles and their related
privledges and access rights.

The Figure 21 illustrates the differentiation of the various capabilities required and referred to with
Management.

Note 42: It is important to keep in mind that management is a co-operation concept. Hence,
requirements have to be considered from the side of the managed perspective (i.e. what provisions
are required in the voice services infrastructure) and the side of the managing perspective (i.e. what
provisions are required for the management system).

1 [REQ SYS ENG] MANAGEMENT PROVISIONS BASELINE

All entities in a voice services infrastructure SHALL maintain provisions to configure/control

and to supervise and monitor this entity.

Note 43: Entity refers to each single different pure and aggregated, physical and logical
component of the system. E.g. interfaces, switches, boards, services, resources (i.e. User,
Role etc).

© EUROCAE, 2009
 73

2 [REQ SYS ENG] Management Provision Levels

A voice services infrastructure SHALL provide management capabilities according to

1 [REQ SYS ENG] Management Provisions Baseline for the following entity levels:

• Element Management: configuration and monitoring of single physical components

(i.e. boards, cards, interfaces, servers, switches, routers etc.);

• Network Management: configuration and monitoring of the transport infrastructure

(as long as it is not managed by another communication service provider):

• Service Management: configuration and monitoring of services (i.e. SW elements

that provide or deploy functionality within the voice service infrastructure);

• User Management: configuration and monitoring of access rights and privileges,

which may be arranged as Users, Roles or Missions.
.

F ig ure 21 : U ser a nd Serv ice Manag ement

© EUROCAE, 2009
 74

A topology view is provided in Figure 22. It illustrates the fact that even HMI elements have to be
considered separate entities providing management capabilities.

Fig ure 22 : Illustrat io n of Radio and/or Telepho ne Sy stem

© EUROCAE, 2009
 75

7.1.2 Management Interfaces related to the Vienna Agreement

The Vienna Agreement identifies the three interfaces that are to be targeted within EUROCAE-67
activities. The Figure 23 shows the same 3 interfaces with respect to Management Capabilities.

F ig ur e 23 : Manag em en t S erv ic es wh en a p p l ie d t o V ie n n a A g r ee me n t

3 [REQ SYS ENG] Management Service on the VCS Interface IfRadio/Telephone

At the IfRadio/Telephone interface the following services categories SHALL be provided as a

minimum:

• Component HW/SW Configuration: identify and address a single HW component

and configure;

• Component HW/SW Status: identify and address a single HW component, register

for status notification and provide status information on request;

• Service Configuration: identify and address a single service and configure

In addition it SHOULD support the following:

• Service Availability: identify and address a single service, register for status
notification and provide status information on request

• User/Role/Mission Configuration: exchange User/Role/Mission information

including access rights

© EUROCAE, 2009
 76

4 [REQ SYS ENG] Management Service on the Radio Interface IfRadio

At the IfRadio/ interface the following services categories SHALL be provided as a minimum:

• HW/SW Configuration: identify and address a single HW component (e.g.

transmitter, receiver) and configure;

• HW/SW Status: identify and address a single HW component (e.g. transmitter,

receiver), register for status notification and provide status information on request;

• Audio Status: identify and address a single HW component (receiver), register for
status notification and provide status information on request;

• Radio Service Configuration: identify and address service and configure;

In addition it SHOULD support the following:

• Radio Service Availability: identify and address a radio service, register for status
notification and provide status information on request;

• User/Role/Mission Configuration: exchange User/Role/Mission information

including access rights.

5 [REQ SYS ENG] Management Service on the VCS Interface IfRecording

At the IfRecording interface the following services categories SHALL be provided as a minimum:

• HW/SW Configuration: identify and address recording component and configure;

• HW/SW Status: identify and address recording component, register for status
notification and provide status information on request;

• Recording Service Configuration: identify and address the recording service and
configure.

In addition it SHOULD support the following:

• Recording Service Availability: identify and address a single service, register for
status notification and provide status information on request;

• User/Role/Mission Configuration: exchange User/Role/Mission information

including access rights.

6 [REQ SYS ENG] Interface Standards

Management activities SHALL use industry standards in minimum on the Vienna Agreement
Interfaces IfRadio, IFRecording and IFRadio/Telephone:

7 [REQ SYS ENG] Management System

A management system SHALL support industry standards and SHOULD integrate the
different management capabilities into a single framework.

© EUROCAE, 2009
 77

7.2 SYSTEM ENGINEERING GENERAL REQUIREMENTS

7.2.1 Redundancy

8 [REQ SYS ENG] No single points of failure

The design of the system SHALL ensure that no single point of failure can lead to a
complete outage of the whole system.

7.2.2 Statistics / General

9 [REQ SYS ENG] Call Detail Records/System Performance statistical reporting

& analysis

The VCS system SHALL have integrated and sophisticated capabilities to collect and report
on statistical data both for incoming and outgoing calls as well as the system performance. It
will be comprehensive/flexible and SHOULD allow all data to be freely defined, processed
and arranged in any format. Comprehensive reporting facilities SHOULD be managed within
the system without need for extensive data processing outside the system.

7.2.3 Statistics / Incoming calls

10 [REQ SYS ENG] Statistical analysis of incoming calls

For Incoming Calls it SHALL be possible to make detailed statistical analysis per CWP, per
group of CWPs, per calling number, per date, per week, per month etc.

Data for all the following fields SHALL be recorded in order that analysis can be made relative to a
date, time and CWP for each circumstance..

• The hourly, daily, weekly, monthly list of calls with time and date stamps;

• List of numbers called, together with the corresponding calling number (ATS-R2, PSTN/ISDN
or ISDN);

• The exact duration of each call in seconds;

• The exact time elapsed in seconds prior to an incoming call being answered;

• Time stamps for call transfers together with the number to which the call is transferred

• Maximum time to answer a call

• Mean time to answer a call.

• Maximum call duration prior to call termination.

• Number of unanswered calls with a detailed list showing the called and calling numbers
together with the alerting time period and the time elapsed before the call was terminated by
the originator.

• Telephone/ATS-R2 number of calling number.

• Name of position that answered the call.

© EUROCAE, 2009
 78

• For unanswered calls, it SHALL be possible to distinguish the reason from the following
circumstances:

o Normal calls lost

o Calls to engaged CWPs
o Calls diverted to voice mail.
o Maximum time to call termination.

7.2.4 Statistics / Outgoing calls

11 [REQ SYS ENG] Statistical analysis of outgoing calls

For Outgoing calls it SHALL be possible to make detailed statistical analysis per CWP, per
group of CWPs, per destination, per date, per week, or per month etc.

Data for all the following fields SHALL be recorded in order that analysis can be made
relative to a date, time and CWP for each circumstance..

• The hourly, daily, weekly, monthly list of calls made per CWP with time and date
stamps.
• The exact duration of each call in seconds

7.2.5 Maximum number of CWPs

12 [REQ SYS ENG] No architectural limit of active CWPs

There SHALL be no architectural limitation of the total number of active CWPs.

7.2.6 Operational use of system functionalities

13 [REQ SYS ENG] Simultaneous use of any system functionality combination

It SHALL be possible to use all system functionalities in any combination, simultaneously

with any number of CWPs, frequencies and radio channels

7.2.7 Hardware architecture

14 [REQ SYS ENG] Redundant components in separate locations

The system architecture SHALL permit the installation of redundant components in separate
locations.

7.2.8 System Circuit Check

15 [REQ SYS ENG] System Circuit Check

The system SHALL provide means to automatically ensure all telephone and radio
interconnections are operational and ready for use by the end terminals (local battery lines
excluded).

© EUROCAE, 2009
 79

7.2.9 Detection of End-to-End Connection Loss

16 [REQ SYS ENG] Detection of End-to-End Connection Loss

The system SHALL check, continuously, that both telephone and radio call setups are
possible to all ATSU and Transmitter/Receiver locations that have been configured, such
that any end-to-end connection loss (i.e. caused by broken links, no bandwidth availability,
significant packet loss…) to these locations SHALL be detected within 3 seconds and the
event noted by the System Management facility within that time.

It is also expected that an occurrence of this event would be indicated to the User but, in
order to meet the individual requirements of ANSPs, the actual characteristics of this SHALL
be fully configurable by means of the System Management facility.

Note 44: This Requirement applies where digital links are used and is not intended to
introduce new line checking procedures, beyond those currently deployed, where (legacy)
analogue circuits are used.

7.2.10 Transit

17 [REQ SYS ENG] Transit Capabilities

The VCS SHALL have the ability to route an incoming call from one VCS (Preceding VCS)
to another VCS (Subsequent VCS).

7.2.11 Classes of Service

18 [REQ SYS ENG] Classes of Service

In order to differentiate between several operational types of voice services (radio and
telephone), system engineering SHALL provide the functionality to create different classes
of service. In the event of a failure inside the network resulting in a loss of bandwidth, the
system management SHALL provide the functionality to allow the call to proceed, or to
cancel the call, according to the available bandwidth and the class of service associated with
a radio or telephone call priority.

Each ANSP is responsible for assigning each existing priority call associated with a class of service to
a particular operational service type.

7.2.12 VCS on-line reconfiguration

7.2.12.1 Introduction

An Air Traffic Services Unit (ATSU) operates under constantly changing traffic loads and operating
conditions. It also has to deal with a number of different types of emergency situation.

Predictable changes in traffic load are managed by appropriately combining certain “sectors” and
“user roles” during periods of low traffic and separating them during periods of heavier traffic.

Sometimes one or more elements of an ATC CWP may be “out of service” due to maintenance or
technical problems. Such problems must be solved without any disruption to air traffic control by
transferring operation to another unused ATC CWP or “sector suite”.

Such circumstances can be managed by an ON-LINE RECONFIGURATION feature and the dynamic
labelling address information.

© EUROCAE, 2009
 80

7.2.12.2 Requirements

19 [REQ SYS ENG] VCS on-line re-configuration

The VCS on-line Reconfiguration SHALL be one or both of the following:

• Centralised: Controlled from the terminal of an Operational Supervisor and/or a VCS

Technical Supervisor;

• Non-centralised: Controlled by authorised users who will split or merge their own roles to
another CWP.

20 [REQ SYS ENG] VCS on-line re-configuration without impacts on neighbouring

centres

On-line Reconfiguration within a centre SHALL NOT have technical or operational impact on
adjacent centres.

21 [REQ SYS ENG] VCS on-line re-configuration without impacts on established

calls

On-line Reconfiguration within a centre SHALL NOT have impact on calls that are already
established;

22 [REQ SYS ENG] Routing method to establish calls during on-line

re-configuration

Incoming and outgoing telephone calls, being established during an on-line reconfiguration,
SHALL be routed to either the original destination or the new destination (after re-
configuration).

The following is an example of telephone online reconfiguration implementation, provided only as

information. Each ANSP remains responsible for the specification of its own implementation.

© EUROCAE, 2009
 81

User “A” User “B”

BA CA AB
(CWP1 keyboard) (CWP2 keyboard)
DA EA DB EB FB
HA IA GB IB

User “A+B”
CA
(CWP3 keyboard)
DA EA FB
GB HA IA

F ig ur e 24 : Te lep hon e O n- lin e re con fig ura t ion exa mp le

7.2.13 Audio-mixing capabilities

23 [REQ SYS ENG] Audio-mixing capabilities

The system SHALL have an audio mixing capability in order to handle simultaneous
telephone and radio calls. This functionality SHALL be available on each CWP. The choice of
what is heard by the controller is ANSP-specific, but SHALL be enabled through configuration
by means of the system management facility.

7.2.14 Loss of Power

In case of power loss, the Ground Telephone and Radio functions SHOULD be capable of
normal operation within 2 minutes of power recovery.

7.3 RECORDING SYSTEM ENGINEERING REQUIREMENTS

7.3.1 Voice Recording
Connection points for the voice recorders SHOULD include 600 Ohm analogue, ITU-T G.703 TDM,
and IEEE802.3 Ethernet IP terminations.

For technical investigation purposes an IP recorder SHOULD provide the functionality to record, in
addition to voice, the following events:

a) PTT operation from each individual CWP for each frequency.

b) Incoming squelch plus signal quality information from each individual receiver.

All this event data SHOULD be time-stamped with correlation to the timestamp source being
employed by the voice recorder.

24 [REQ SYS ENG] End to End System Check

© EUROCAE, 2009
 82

A convenient and ready means SHALL be provided whereby an engineer can perform a
routine end-to-end system check. This involves the ability to make radio transmission and
listen, in real time, to the output of the recording system for the radio channel under test.

7.4 TELEPHONE SYSTEM ENGINEERING REQUIREMENTS

7.4.1 Conference

25 [REQ SYS ENG] No limit for number of simultaneous activated conferences

There SHALL be no restriction in the number of simultaneous activated conferences.

7.4.2 Public Network Security

26 [REQ SYS ENG] Public Network Security

The VCSs SHALL have interfaces to the “Public Switched Telephone Network” (PSTN),
permitting calls to be made to destinations outside the ATS Ground Voice Network in order
to provide link fall-back or simply as an alternative to the leased line scenario. This
functionality SHALL be restricted and controlled to ensure that unwanted external callers are
prevented from gaining access to trunk lines used for operational air traffic management.

7.5 RADIO SYSTEM ENGINEERING REQUIREMENTS

27 [REQ SYS ENG] Radio Gateway of IP transmitter/receiver spec to define

different physical layer architectures

Depending on the Ground Radio Station architecture, transmission and reception facilities
could be located on separated sites and interconnected with different type of links (i.e. radio
link, copper cables, optic fibre etc)
These various types of architecture SHALL be covered by the radio gateway specification
and by the IP compatible transmitter/receiver specification.

28 [REQ SYS ENG] System to operate all frequencies simultaneously

An IP system (VCS and WAN) SHALL be designed to operate all the frequencies
simultaneously, whatever their operational mode. (with no access and bandwidth limitations).
There SHOULD be no architectural limitation on the total number of Frequencies and radio
channels possible.

29 [REQ SYS ENG] Transmitter/Receiver selection options

The VCS SHALL support the following 3 options for Tx/Rx selection:

• Option 1: Individual transmitter and receiver selection is either a VCS or RCE

configurable parameter. The User has no means of selection available at the CWP.

• Option 2: The User selects at the CWP which transmitter and receiver combinations are
in use on each frequency. The quantity of transmitters and receivers locations and
permissible combinations, including default settings are specified by the ANSP.

• Option 3:The User selects at the CWP which transmitter and receiver locations SHOULD
be active. Best Signal Selection (BSS) MAY be used to automatically select the specific

© EUROCAE, 2009
 83

receiver signal transferred to loudspeaker/headset.

30 [REQ SYS ENG] Maximum of 7 channels assigned to a frequency

The maximum number of channels assigned to a frequency SHALL be 7.

31 [REQ SYS ENG] Quantity of frequencies in a cross-coupled group

By design the system SHALL provide the facility to use 28 radio frequencies in each cross-
coupled group. A system management configuration, the system SHALL provide the facility
to set this number between 2 and 28.

32 [REQ SYS ENG] No limit on number of cross-coupled groups

There SHALL be no limitation in the number of active cross-coupling groups at CWP level
and at VCS level.

33 [REQ SYS ENG] Maximum of 7 channels in a Climax group

The maximum number of Radio Channels in one Multi-carrier/Climax group operation

SHALL be 7.

34 [REQ SYS ENG] Maximum of 7 channels for BSS operation

The maximum number of Radio Channels involved in a BSS operation SHALL be 7.

35 [REQ SYS ENG] Speech Activity Detector with Pseudo Squelch signal
generation

A Speech Activity Detection (SAD) device SHALL be provided to safeguard against the
possibility that a voice signal is received without any squelch. In this eventuality, a “SAD
active” condition SHALL ensure that the speech is presented at the CWP in the same
manner as if the squelch had been received normally. The system management facility
SHALL provide means to activate the SAD functionality, set the SAD sensitivity, noise
immunity, reaction time and minimum operation time.

36 [REQ SYS ENG] Automated Radio check during PTT

During each PTT activation, the VCS SHALL perform TX/RX-loop check by automatically
comparing outgoing TX-activation and audio with the activation of associated RX and
received off-air audio in order to detect any malfunctioning.

Note 45: In case of only local side tone being provided to the User, the test shall be suitably
designed in order that the received audio being checked is in reality the received off-air
audio.

© EUROCAE, 2009
 84

37 [REQ SYS ENG] Automatic or manual channel check

The VCS SHALL provide the capability to regularly perform an automated (or manual)
TX/RX loop check on each configured radio channel, in order to detect any malfunctioning
prior to its operational use.

Some parameters MAY be configurable in order to allow the ANSP to minimize channel
load: for instance it is possible that the automated frequency check is performed during low
frequency usage i.e. during night time operation.

If automated, this check SHALL NOT interfere with any active radio call in progress.

Note 46: At the time of publication of this ED-136 document, this check is usually performed
by transmitting a 1 kHz tone in the air, which differs from the check defined in the ICAO
ANNEX 10, Vol. II, Ch. 5.1.3 [7] recommendation stating that the check should be performed
by transmitting a voice message containing the frequency text, the locator and the
expression “frequency check”.

Note 47: This test may be started automatically on each frequency (key) selection by the
Controller, depending on the operational and technical procedures employed by the ANSP.

38 [REQ SYS ENG] VCS switching capabilities at Ground Radio Station

In case of failure of any transmitters and/or receivers, the VCS SHALL provide the following
switching capabilities:

• Automatic switching to alternative transmitters and/or receivers which could be in

different locations to those that have failed.

• Manual switching or Manual switching inhibition of any transmitters and/or receivers.

In both cases, the need for switching SHALL be triggered by the VCS, based on alarm
conditions coming from the Ground Radio Station (GRS).

The system management facility SHALL provide means by which any round-trip propagation
delay may be taken into account to trigger an alarm. This delay SHALL be configurable by
maintenance personnel.

39 [REQ SYS ENG] Alarm for non-selected frequencies

The system SHALL detect if certain frequencies (as configured by the System Management
Terminal) are not selected at any CWPs. If this is the case, at least an alarm SHALL be
generated. Further reaction is ANSP specific but MAY include Automatic re-selection.

40 [REQ SYS ENG] Automatic Gain Control for Tx & Rx speech levels

An “Automatic Gain Control” (AGC) device SHALL be implemented in both the VCS Tx and
Rx paths, the Tx equipment and the Rx equipment. The activation and de-activation of the
AGC SHALL be configurable.
It is recommended for an ANSP to use only one AGC device in each path.

AGC SHALL be implemented in the VCS in order to control the speech levels sent towards
transmitters and speech levels once received from receivers. AGC SHOULD also be
provided in both the transmitter and receiver equipment. The system management facility

© EUROCAE, 2009
 85

SHALL be able to control all of these AGC facilities including levels, range, activation and
de-activation.

It is recommended that ANSPs activate only one AGC from the VCS to the antenna and one
AGC from the VCS to the CWP.

41 [REQ SYS ENG] Easy access to monitor VCS signalling

For maintenance purpose, the VCS SHALL enable easily access in order to display any
output/input signals such as: Call signalling, PTT, SQUELCH….

42 [REQ SYS ENG] Headset Operation

Regardless of whether the VCS is either a combined (both radio and telephone) type or
separated (radio or telephone) type, it SHALL employ a mixer function that permits the
controller to use their Headset device for both radio and telephone communications.

The Headset and Boom microphone interface SHOULD be ARINC 535A compliant [60]

The Hand-Held microphone interface SHOULD be ARINC 538 compliant.[61]

43 [REQ SYS ENG] Date and Time reference source

All the peripherals SHALL have direct access to a date & time reference source.

44 [REQ SYS ENG] Evolution (Modification/Upgrade) capability

The system SHALL be designed so that any hardware or software modifications/upgrades

can be performed in a safe manner ensuring continuity of service provided to the Users by
the system. These modifications/upgrades include the following:

• Software revision procedure

• Changing parameters
• On-line ATS configuration
• Hardware extensions
• All maintenance operations

© EUROCAE, 2009
 86

CHAPTER 8

SECURITY

8.1 INTRODUCTION
The concept of security has to be clearly separated from the concept of safety and availability (for
details regarding those aspects, refer to CHAPTER 4 of ED-136). The ANSP should define and
analyse the typical scenarios concerning system configuration and system environment to meet their
security requirements. Based on this appropriate threat scenarios may be analysed (threats, risk,
measures). The resulting security requirements should address all security aspects (confidentiality,
integrity, availability, authenticity, non-repudiation) and should comprise all system layers as integral
parts of the whole concept. Security approach should consider use of best practices and approved
security mechanisms for the lower layers and then define any necessary special requirements which
should be realised in the application layer.

In this chapter, security has the following meaning:

- A condition that results from the establishment and maintenance of protective measures that
ensures that the risk of violability, from hostile acts or consequences of human errors, has
been reduced to an acceptable level. Each ANSP has the responsibility of determining this
level and ensuring that it is, as a minimum, maintained.

- The condition that prevents unauthorized persons from having access to a specific resource in
the IP system

8.2 ASSUMPTIONS

a) Voice communications will be carried on a ‘private’ network (see ‘e’ below) used
only for the purposes of Air Traffic Management (ATM) and is not a public
network. (This does not preclude the possible use of out-sourcing of network
provision and management).
b) Security in terms of adequate control of third parties (provision of out-sourced
network) is the responsibility of the ANSP.
c) Security in terms of physical access controls to the voice system and network
equipment is the responsibility of the ANSP.
d) Security in terms of ensuring that only competent staff may use or modify the
behaviour of the voice system and network is the responsibility of the ANSP.
e) EUROCONTROL member states will establish an IP network for data applications
known as the Pan-European Network Service (PENS). The core architecture of
PENS will be an ANSP Backbone, the Service Specifications of which include
Security Requirements. For information some details of these security
requirements are included in ANNEX C to this document. It is assumed that all of
the security aspects detailed in ANNEX C will be covered under the PENS
implementation.

© EUROCAE, 2009
 87

8.3 SECURITY REQUIREMENTS

8.3.1 Integrity of IP-voice packets
Means SHOULD be applied to guarantee the integrity of packets carrying IP-voice or IP-voice
related information. As a minimum, corrupted or unauthorized modified information elements
SHOULD be detected.

8.3.2 Confidentiality of IP-voice information

Means SHOULD be applied to guarantee the confidentiality of IP-voice and IP-voice related
information exchanged via the network. As a minimum, confidentiality compromises SHOULD
be detectable by the application.

8.3.3 Authenticity of IP-voice packet originator

Means SHOULD be applied to guarantee the authenticity of the IP-Voice packet originator. As
a minimum any uncertainties as to authenticity SHOULD be detectable by the application.

8.3.4 Authenticity of Radio and Telephone IP-voice packet origin

1 [REQ SECURITY] Radio and Telephone IP-voice packet authenticity

Packets addressing radio resources SHALL solely be accepted when originated by radio
resources. Packets addressing telephone resources SHALL solely be accepted when
originated by telephone resources. As a minimum, any uncertainties regarding authenticity
SHOULD be detectable by the application.

© EUROCAE, 2009
 88

ANNEX A

REFERENCES

[1] ICAO “Manual on ATS Ground-Ground Voice Switching and Signalling“ (Doc 9804 AN/762)

[2] ICAO Convention on International Civil Aviation, Annex 10, Volumes I to V , Chapter 1:
"Definitions”

[3] ICAO Convention on International Civil Aviation, Annex 10, Volume I, Attachment F: "Guidance
material concerning reliability and availability of radio communications”

[4] ICAO Convention on International Civil Aviation, Annex 10, Volume I, Chapter 2.9: "Secondary
power supply for communication systems”

[5] ICAO Convention on International Civil Aviation, Annex 10, Volume II, Chapter 2.2:
“Telecommunication access”

[6] ICAO Convention on International Civil Aviation, Annex 10, Volume II, Chapter 3.5: "General
Procedures for Recording of ATC communications”

[7] ICAO Convention on International Civil Aviation, Annex 10, Volume II, Chapter 5: "Aeronautical
Mobile Voice Communications”

[8] ICAO Convention on International Civil Aviation, Annex 10, Volume III, Part II, Chapter 4:
"Aeronautical Speech Circuits”

[9] ICAO Convention on International Civil Aviation, Annex 11, Chapter 1: "Definitions”

[10] ICAO Convention on International Civil Aviation, Annex 11, Chapter 6: "Air Traffic Services
Requirements for Communications”

[11] ICAO Convention on International Civil Aviation, Annex 5: “Units of Measurement to be Used in
Air and Ground Operations”

[12] EUROCONTROL ASM.ET1.ST18.1000-REP-01-00: "Guidelines for the application of the ECAC

Radar Separation Minima" Edition 2

[13] EUROCONTROL “Voice Communication System Procurement Guidelines” Edition 2.0; EATM
Info centre reference: 05/01/12-03

[14] EUROCONTROL: “ATS Ground Voice Network Implementation and Planning Guidelines”
Edition 1.0; EATM Info centre Reference: 05/01/12-02

[15] EUROCONTROL “ATS R2 and ATS No.5 protocol specification” Edition 1.0; EATM Info centre
Reference: 05/01/12-04

[16] EUROCONTROL “Interworking between ATS QSIG and ATS No.5 signalling systems Edition
1.0; EATM Info centre Reference: 05/01/12-06

[17] EUROCONTROL “Interworking between ATS QSIG and ATS R2 signalling systems” Edition
1.0; EATM Info centre Reference: 05/01/12-05

[18] EUROCONTROL Safety Regulatory Requirement (ESARR) 4 “Risk Assessment and Mitigation
in ATM”

[19] EUROCONTROL Action Plan for Air Ground Communications Safety” Ed 1.0 (05/06)

[20] EUROCONTROL iPAX/PM/DE-02 (11/04)

© EUROCAE, 2009
 89

[21] CROBOCOM Task Force Conclusions Ed 1.0 (02/05): EUROCONTROL EATM Info centre
Reference 05/01/12-01

[22] EUROCAE ED-137 “INTEROPERABILITY STANDARDS FOR VoIP ATM COMPONENTS,

PART 2 : TELEPHONE”

[23] EUROCAE ED-23B (03/95): “Minimum Operational Performance Specification for Airborne VHF
Receiver – Transmitter operating in the Frequency Range 117.975 – 136.975 MHz”

[24] ITU-T Recommendation E.164 (1997): “The International Telecommunication Numbering Plan

[25] ITU-T Recommendation Q.35/E.180: "Technical characteristics of tones for the telephone
service

[26] ETSI EN 300 189 (11/99): "Private Integrated Services Network (PISN); Addressing"

[27] ETSI EN 301-846 (07/01): Private Integrated Services Network (PISN) – Profile Standard for
use of PSS1 (QSIG) in Air Traffic Services Networks

[28] ECMA-312 ed.3 (06/03): “Private Integrated Services Network (PISN); Profile Standard for the
Use of PSS1 (QSIG) in Air Traffic Services Networks”

[29] ECMA-143 ed.4 (12/01): Private Integrated Services Network (PISN) - Circuit Mode Bearer
Services - Inter-Exchange Signalling Procedures and Protocol (International Standard
ISO/IEC 11572)

[30] ETSI EN 300 011-1 (05/00): "Integrated Services Digital Network (ISDN); Primary rate User
Network Interface (UNI); Part 1: Layer 1 specification"

[31] ETSI EN 300 012-1 (05/00): "Integrated Services Digital Network (ISDN); Basic User-Network
Interface (UNI); Part 1: Layer 1 specification"

[32] ETSI EN 300 402-2 (11/95): "Integrated Services Digital Network (ISDN); Digital Subscriber
Signalling System No. one (DSS1) protocol; Data link layer; Part 2: General protocol
specification

[33] ETSI EN 300 403-1 (11/99): "Integrated Services Digital Network (ISDN); Digital Subscriber
Signalling System No. one (DSS1) protocol; Signalling network layer for circuit-mode basic call
control; Part 1: Protocol specification"

[34] ETSI EN 300 659-1 (01/01): “Access and Terminals (AT);Analogue access to the Public
Switched Telephone Network (PSTN);Subscriber line protocol over the local loop for display
(and related) services; Part 1: On-hook data transmission

[35] ETSI EN 300 659-2 (01/01): "Access and Terminals (AT);Analogue access to the Public
Switched Telephone Network (PSTN);Subscriber line protocol over the local loop for display
(and related) services; Part 2: Off-hook data transmission

[36] ETSI EN 300 676-1 (04/07): "Electromagnetic compatibility and Radio spectrum Matters
(ERM);Ground-based VHF hand-held, mobile and fixed radio transmitters, receivers and
transceivers for the VHF aeronautical mobile service using amplitude modulation; Part 1:
Technical characteristics and methods of measurement”

[37] ETSI ES 203 021-3 V2.1.2 (01/06): Access and Terminals (AT);Harmonized basic attachment
requirements for Terminals for connection to analogue interfaces of the Telephone Networks;
Update of the technical contents of TBR 021, EN 301 437, TBR 015, TBR 017;Part 3: Basic
Interworking with the Public Telephone Network

© EUROCAE, 2009
 90

[38] ETSI ES 201 970 V1.1.1 (08/02): Access and Terminals (AT);Public Switched Telephone
Network (PSTN);Harmonized specification of physical and electrical characteristics at a 2-wire
analogue presented Network Termination Point (NTP)

[39] ETSI TBR 015 (01/97): “Business TeleCommunications (BTC); Ordinary and Special quality
voice bandwidth 2-wire analogue leased lines (ASO and A2S; Attachment requirements for
terminal equipment interface

[40] ETSI TBR 021 (01/98) “Terminal Equipment (TE); Attachment requirements for pan-European
approval for connection to the analogue Public Switched Telephone Networks (PSTNs) of TE
(excluding TE supporting the voice telephony service) in which network addressing, if provided,
is by means of Dual Tone Multi Frequency (DTMF) signalling

[41] ETSI TBR 038 (06/96): “Public Switched Telephone Network (PSTN); Attachment requirements
for a terminal equipment incorporating an analogue handset function capable of supporting the
justified case service when connected to the analogue interface of the PSTN in Europe.

[42] ETSI EG 201 121 V1.1.3 (02/00): “A guide to the application of TBR 21”

[43] IETF RFC 3261 (06/02): “SIP: Session Initiation Protocol”

[44] IETF RFC 2119 (03/97): "Key words for use in RFCs to Indicate Requirement Levels", BCP 14

[45] ITU-T. Rec. G.711 (11/88): “Pulse Code Modulation (PCM) of Voice Frequencies”

[46] ITU-T. Rec. G.728 (10/92): “Coding of Speech at 16 Kbit/s Using Low-delay Code Excited
Linear Prediction”

[47] E67-WP-DGAC-08-V01 Version 3 (06/06) DSNA Reference Paper: Requirements for “Voice
Quality”

[48] ITU-T Recommendation G.109 (09/99): Definition of categories of speech transmission quality

[49] ITU-T Recommendation G.114 (05/03): Transmission Systems and Media, Digital Systems and
Networks - International telephone connections and circuits – General Recommendations on
the transmission quality for an entire international telephone connection- One-way transmission
time

[50] ITU-T Recommendation G.116 (09/99): Transmission performance objectives applicable to end-
to-end international connections

[51] ITU-T Recommendation G.131 (11/03): Talker echo and its control

[52] ITU-T Recommendation G.224 (11/88): Maximum permissible value for the absolute power
level (power referred to one milliwatt) of a signalling pulse

[53] ITU-T Recommendation G.712 (11/01): Transmission performance characteristics of pulse code
modulation channels

[54] ITU-T Recommendation M.1030 (11/88): "Characteristics of Ordinary Quality International

Leased Circuits Forming Part of Private Switched Telephone Networks'

[55] ITU-T Recommendation Q.1 (11/88): Signal receivers for manual working

[56] ITU-T Recommendation Q.2 (11/88): Signal receivers for automatic and semi-automatic
working, used for manual working

[57] ITU-T Recommendation Q.8 (11/88): Signalling systems to be used for international manual and
automatic working on analogue leased circuits

© EUROCAE, 2009
 91

[58] ITU-T Recommendation Q.23 (11/88):Technical features of push-button telephone sets

[59] ITU-T Recommendation Q.24 (11/88): Multi-frequency push-button signal reception

[60] ARINC standard 535A “Lightweight Headset and Boom Microphone” (03/72): Standard for a
lightweight headset with integral boom microphone suitable for pilot use in conventional
airborne radio installations.

[61] ARINC standard 538B-1 “Hand-Held Microphone” (02/83): Standard for a hand-held
microphone for use with airborne radio installations.

[62] ANSI standard: T1.409-2002 (R2006) Network-to-Customer Installation Interfaces - Analogue

Voice grade Special Access Lines Using E&M Signalling.

© EUROCAE, 2009
 92

ANNEX B

ACRONYMS

A/C Aircraft
A/C TxRx Aircraft combined Transmitter/Receiver “Transceiver”
ACC Area Control Centre
ACD Aircraft Call indication Delay
AGC Automatic Gain Control
AGVN Air Traffic Services Ground Voice communications Network
A/G Air/Ground
AM Amplitude Modulation
ANSI American National Standards Institute
ANSP Air Navigation Service Provider
APP Approach
ARINC Aeronautical Radio Inc
ATC Air Traffic Control
ATIS Automatic Terminal Information Services
ATM Air Traffic Management
ATS Air Traffic Services
ATS-No.5 Air Traffic Services – No.5 signalling system
ATS-QSIG Air Traffic Services – Q reference point SIGnalling system
ATS-R2 Air Traffic Services – R2 signalling system
ATSU Air Traffic Services Unit

BIDD Best Signal Select Input Delay Differential

BSS Best Signal Selection

CB Central Battery
CED Call Establishment Delay
CFT Call For Tender
CLIMAX Multi-carrier Offset Transmission System
COCR Communications Operating Concept and Requirements
COMT Communications Team
CROBOCOM CROss BOrder COMmunications
CUI Calling User Identity
CWP Controller Working Position

DA Direct Access
DCCVC Direct Controller-Controller Voice Communication
DFS Deutsche Flugsicherung GmbH
DIRO Dial-In / Ring-Out
DSNA Direction des Services de la Navigation Aérienne
DSS1 Digital Subscriber Signalling No.1 (ISDN)

EC European Community
ECAC European Civil Aviation Conference
ECMA European Computer Manufacturers Association
E&M Earth and Mark (Ear and Mouth)
EN European Norm
ESARR EUROCONTROL Safety Regulatory Requirements
ETSI European Telecommunications Standards Institute

FAA Federal Aviation Administration

FHA Functional Hazard Assessment
FIR Flight Information Region
FXO Foreign Exchange Office
FXS Foreign Exchange Station

© EUROCAE, 2009
 93

G/G Ground/Ground
Gnd Rx Ground Receiver
Gnd Tx Ground Transmitter
Gnd Ground
GPS Global Positioning System
GRS Ground Radio Station
GW Gateway

HMI Human Machine Interface

HW HardWare

IA Instantaneous Access
ICAO International Civil Aviation Organization
ICCVC Instantaneous Controller-Controller Voice Communication
IDA InDirect Access
IETF Internet Engineering Task Force
IP Internet Protocol
ISDN Integrated Services Digital Network
ISO International Standards Organization
ITU-T International Telecommunication Union – Telecommunication standardization sector

LAN Local Area Network

LB Local Battery
LCD Liquid Crystal Display

MIB Management Information Base

MOS Mean Opinion Score
MTBF Mean Time Between Failures
MTTR Mean Time To Restore

NoK Not OKay

OK OKay
OLDI On-line Data Interchange

PBX Private Branch eXchange

PCM Post Code Modulation
PEN Pan-European Network
PENS Pan-European Network Services
PISN Private Integrated Services Network
PSS1 Private Signalling System no. 1
PSSA Preliminary System Safety Assessment
PSTN Public Switched Telephone Network
PTT Push-To-Talk
PTTD Push-To-Talk Delay

QoS Quality of Service

QSIG Q-reference point signalling (PSS1)

RAT Receiver Activation Time

RCE Radio Control Equipment
RCE-L Radio Control Equipment – Local
RCE-R Radio Control Equipment – Remote
RDAT Receiver De-Activation Time
Rec. Recommendation
REQ Requirement
RFC Request For Comments
RIDO Ring-In / Dial-Out
RIRO Ring-In / Ring-Out

© EUROCAE, 2009
 94

RRAT Receiver Recovery After Transmission

RTP Real-time Transport Protocol
RX Receiver

SAD Speech Activity Detection

SAR Search and Rescue
SARPs Standards and Recommended Practices
SC Simultaneous Call
SIP Session Initiation Protocol
SNMP Simple Network Management Protocol
SqD Squelch Delay
SQL Squelch
SS Supplementary Service
SSA System Safety Assessment
SW SoftWare

TAD Transmitter Activation Delay

TADD Transmitter Activation Delay Differential
TAP Transmit Access Priority
TAT Transmitter Activation Time
TDAT Transmitter De-Activation Time
TDM Time Division Multiplexing
Telco Public Telecom Operator
TWR Tower
TX Transmitter

UHF Ultra-High Frequency

UTC Universal Time, Coordinated

VAD Voice Access Delay

VCCS Voice Communication System
VCS Voice Communications System
VCSD Voice Channel Setup Delay
VHF Very High Frequency
VoIP Voice over the Internet Protocol
VOLMET VOLume METeorological (aviation); Meteorological information for aircraft in flight

WAN Wide Area Network

X-couple Cross-Couple

© EUROCAE, 2009
 95

ANNEX C

PAN-EUROPEAN NETWORK SERVICES (PENS)

Security Requirements

Re: PENS ANSP Backbone Service Specification, Security

EUROCONTROL Edn 1.0, Date 30/01/07

Section 6.2 of the reference document (classification General Public) includes the following Security
Requirements in an open Call For Tender (CFT):

a) The PEN SHALL be isolated from other customers’ of the Contractor (assumes an out-
sourced facility)
b) The Tenderer SHALL describe which mechanisms and measures will be deployed to
ensure that other customers of the Contractor cannot gain access to the PEN nor see
resources assigned to the PEN.
c) Any denial of service attack against the Contractor’s network resources SHOULD not
result in loss of performance or quality of service on PEN.
d) No PEN Customer traffic or routing information SHALL be divulged to any third party.
e) All data transported over the PEN network service SHALL be delivered unmodified.
f) The Tenderer SHALL describe which mechanisms and measures have been deployed
to prevent the duplication, deletion or modification of Customer data.
g) The Tenderer SHALL describe which mechanisms and measures have been deployed
to prevent the insertion of spoofed Customer data.
h) The Tenderer SHALL describe which mechanisms and measures have been deployed
to prevent the unauthorised recording and replay of Customer data over the PEN.
i) The Tenderer SHALL indicate which traffic flows need to be recorded for the purposes
of PEN QoS reporting, PEN network management duties or legal requirements.
j) The Tenderer SHALL describe whether specific transport ports and/or communication
protocols (EG ICMP) are blocked by default and whether these can be enabled for the
needs of the customer.

© EUROCAE, 2009
 96

ANNEX D

CROSS-COUPLING MODES OF OPERATION

Introduction

This Information Paper has been produced in order to clarify how the terms ‘Simplex’ and ‘Duplex’
Cross-Coupling SHOULD be interpreted.

Main Attributes of Cross-Coupling Modes

The Cross-Coupled Group

Two or more frequencies MAY be assigned to an individual Cross-Coupled Group. A Cross-Coupled
Group MAY consist of both Simplex Mode and Duplex Mode frequencies.

‘Suppressed’ Received Frequency

When a received frequency in a Cross-Coupled Group is said to be ‘suppressed’ it means that it is not
presented at the Controller Working Position (CWP) where the Cross-Coupled Group is active, only.
The frequency will be presented at other CWPs as required.

Basic Principle for the suppression of a Received Frequency

A received frequency in a Cross-Coupled Group will only be suppressed at a CWP when it could
cause an echoing effect thus making any understanding either difficult or impossible for the controller.
This effect MAY be due to the delay arising from re-transmission in the case of Cross-Coupling – but
MAY also occur when Multi-carrier/Climax radio systems are in operation.

Frequencies Received at a Controller Working Position (CWP)

When two or more frequencies are received, the first frequency to be received and detected by the
Voice Communication System (VCS) is presented at the CWP the other(s) being suppressed.

In the extremely unlikely event of two or more frequencies being received, simultaneously, only one
frequency is presented at the CWP. The determination of which frequency is presented to the CWP is
ANSP/VCS specific and thus outside the scope of this Information Paper.

Re-Transmission of Received Frequencies

Simplex Mode
Received frequencies in Simplex Mode are never re-transmitted on other frequencies in the Cross-
Coupled Group.

Duplex Mode
All received frequencies in Duplex Mode MAY be re-transmitted on all the other frequencies in the
Cross-Coupled Group - but only one at a time. The received frequency re-transmitted is always
presented at the CWP.

Table 11, Table 12, Table 13 on the following pages provide some further illustrations.

© EUROCAE, 2009
 97

Tab le 11 – I llus trat io n of Cro s s-cou p ling mod e s fu nc tiona lity

MODE DESCRIPTION / ILLUSTRATION WHAT IS HEARD BY THE

CONTROLLER
Pre-Configuration
a) Frequency F1d is cross-coupled with
Frequencies F2d and F3d in a cross-
coupled group. All frequencies are
configured as ‘Duplex’
DUPLEX /
SYMMETRICAL Mode of Operation
a) Reception on F1d will be re- a) Only reception on F1d is sent to
(Most Common transmitted on F2d and F3d. the controller (to avoid echo)
Mode) b) Reception on F2d will be re- b) Only reception on F2d is sent to
transmitted on F1d and F3d. the controller (to avoid echo)
c) Reception on F3d will be re- c) Only reception on F3d is sent to
transmitted on F1d and F2d. the controller (to avoid echo)

This mode would be used, for example,

when Sectors are combined to be
controlled from a single position.
Pre-Configuration
a) Frequency F1d is cross-coupled with
Frequencies F2d and F3s in a cross-
coupled group.
b) Frequencies F1d and F2d are
configured as ‘Duplex’
c) Frequency F3s is configured as
‘Simplex’
SIMPLEX/
ASYMMETRICAL Mode of Operation

a) Reception of F1d is re-transmitted on a) Only reception on F1d is sent to

F2d and F3s. the controller (to avoid echo)
b) Reception on F2d is re-transmitted on b) Only reception on F2d is sent to
F1d and F3s. the controller (to avoid echo)
c) Reception on F3s is NOT re- c) Reception on F3s will be
transmitted. presented to the controller (but
only if either F1d or F2d are not
This mode would be used, for example, received first –Refer to “Cross-
when a Tower frequency (VHF) is re- Coupling Combinations”
transmitted on a Ground Mobile frequency following).
(UHF) so that mobiles MAY be aware of
aircraft manoeuvres in progress and
intended.
Another application would be the re-
transmission of a Civil Frequency on a
Military Frequency but not the other way
round.

© EUROCAE, 2009
 98

Cross-Coupling Combinations

Pre-Configuration
Frequencies F1d, F2d and F3s are in a Cross-Coupled Group. F1d and F2d are in Duplex Mode. F3s
is in Simplex Mode.

Tab le 12 – C ros s- coupling co mb inat ion s- F req ue ncy F1d r ec e ive d f ir st

Active Frequencies Due to Aircraft Transmissions
F1d (1st received) F2d
0 0
0 0
0 1
0 1
1 0
1 0
1 1
1 1
What is heard at What is
F3s the CWP Re-transmitted
0 Silence Nothing
1 F3s Nothing
0 F2d F2d on F1d and F3s
1 F2d F2d on F1d and F3s
0 F1d F1d on F2d and F3s
1 F1d F1d on F2d and F3s
0 F1d F1d on F2d and F3s
1 F1d F1d on F2d and F3s

© EUROCAE, 2009
 99

Tab le 13 – C ros s- coupling co mb inat ion s- F req ue ncy F3 s r ec e ive d f ir st

Active Frequencies Due to Aircraft What is heard What is Re-
Transmissions at the CWP transmitted
F1d F2d F3s (1st received)
0 0 0 Silence Nothing
0 0 1 F3s Nothing
0 1 0 F2d F2d on F1d and F3s
0 1 1 F2d and F3s Nothing
1 0 0 F1d F1d on F2d and F3s
1 0 1 F1d and F3s Nothing
1 1 0 F1d or F2d Either F1d on F2d
depending upon and F3s or F2d on
1st detected F1d and F3s
(depending upon1st
received)
1 1 1 See Note 48 Nothing
below

Note 48: The determination of which frequency is presented to the CWP is ANSP/VCS specific and
thus outside the scope of this information paper.

© EUROCAE, 2009
 100

ANNEX E

LIST OF EUROCAE WG-67 SUB-GROUP 1 CONTRIBUTORS

SURNAME NAME COMPANY

BESLANOVICS Siegfried AUSTROCONTROL

CLEGG Chris EUROCONTROL

DOWSETT Paul NATS

HASSELKNIPPE Martin PARK AIR SYSTEMS

HECKMANN Patrick INEO

KNAEPS Bart BELGOCONTROL

MANCEBO DIAZ Jose Luis AENA

MARTUSCELLI Albino ENAV

NILSSON Alf SAAB Communication

PALMER John JSP Teleconsultancy

POPESCU Liviu EUROCONTROL

PRINZ Johannes FREQUENTIS

ROCCIA Patrick C&S

STEUNOU Franck DSNA

TABET Michele SCHMID Telecom AG

VAN ROEMBURG Vincent LVNL

ZURR Gernold DFS

© EUROCAE, 2009