Вы находитесь на странице: 1из 235

Next Generation ICAO 9896 VoIP interfaces

for ATS Ground Voice Network - Part 1

Training Documentation

Copyright 2014 JSP-Teleconsultancy

Copyright 2014 JSP-Teleconsultancy

Copyright Notice
2014 JSP Teleconsultancy . All rights reserved.
JSP Teleconsultancy has the exclusive rights to present Air Traffic Services Ground Voice Network Communication courses, including ATSQSIG courses under a Licence Agreement (L/01/03-JSP/QSIG) with EUROCONTROL Institute of Air Navigation Services. This
documentation has been produced by JSP Teleconsultancy and may only be used in the framework of the Licence Agreement and/or in
relation with the pertinent Eurocontrol courses, workshops and seminars. The reproduction of this material is permitted for personal and noncommercial purposes only. This is subject to the material being reproduced accurately and not used in a misleading context. This document
or CD-ROM may be copied to third parties under the same restrictions, provided the source is acknowledged.
Any other use is subject to prior written consent by JSP Teleconsultancy.
Requests

shall

be

addressed

to:

JSP

Teleconsultancy,

Via

Produced by JSP Teleconsultancy

Gorizia,

11

FOLIGNANO,

63040,

Ascoli

piceno,

Italy.

Copyright 2014 JSP-Teleconsultancy

Table of Contents
1.

INTRODUCTION ............................................................................................................................. 7
Introduction to course ..................................................................................................................................... 8
Course Objectives - Part 1 ............................................................................................................................. 8
Course Objectives - Part 2 ........................................................................................................................... 10
Course Objectives - Part 3 ........................................................................................................................... 10

2.

ATS GROUND VOICE NETWORK OVERVIEW .......................................................................... 13


Telephone network infrastructure overview .................................................................................................. 14
Circuit switched connections and TDM transport efficiency .......................................................................... 18
Direct Access Call operation......................................................................................................................... 20
Instantaneous Access Call operation ........................................................................................................... 22
Priority DA Call operation ............................................................................................................................. 24
Telephony features ....................................................................................................................................... 26
Radio network infrastructure overview .......................................................................................................... 28
Radio Access Modes of Operation ............................................................................................................... 32
Push-To-Talk (PTT) ...................................................................................................................................... 34
Incoming Aircraft Call detection/Squelch signal ............................................................................................ 36
Radio features - Cross Coupling (Retransmission)....................................................................................... 38
Radio features - Best Signal Selection (Rx Voting) ...................................................................................... 40
Best Transmitter Selection (Transmitter Voting) ........................................................................................... 42
Radio features - Multicarrier Offset Transmission (Climax) .......................................................................... 44
Stepped-on radio transmissions (1) .............................................................................................................. 46
Stepped-on radio transmissions (2) .............................................................................................................. 48
Stepped-on radio transmissions (3) .............................................................................................................. 50
Main/Standby Radio switchover ................................................................................................................... 50
Sunset dates for analogue & digital leased lines .......................................................................................... 52

3.

EUROCAE WORKING GROUP 67 .............................................................................................. 55


What is EUROCAE? ..................................................................................................................................... 56
EUROCAE Working Group 67 background .................................................................................................. 58
WG67 Mission Statement ............................................................................................................................. 60
The Vienna Agreement ................................................................................................................................. 62
ED deliverables ............................................................................................................................................ 64
ICAO ACP WG-I consideration of EUROCAE ED docs ................................................................................ 66

4.

VOICE OVER INTERNET PROTOCOL FUNCTIONALITY ......................................................... 69


What is Voice over IP? ................................................................................................................................. 70
Packet switched connections........................................................................................................................ 72
Packet Transport Efficiency .......................................................................................................................... 74
IP Core Network ........................................................................................................................................... 76
Voice over IP deployed in Corporate Networks ............................................................................................ 80
Signalling in an IP ATS Ground Voice Network ............................................................................................ 82
How is Voice Transported over an IP network? ............................................................................................ 84
Example- Voice Transport over an IP Network ............................................................................................. 86
Why IP version 6? ........................................................................................................................................ 88
IPv6 Packet Header Fields ........................................................................................................................... 90
IPv6 Packet header field structure ................................................................................................................ 90
User Datagram Protocol (UDP) .................................................................................................................... 92
Real-time Transport of Voice using RTP ...................................................................................................... 94

Produced by JSP Teleconsultancy

RTP Media Streams ..................................................................................................................................... 98


What is the Session Initiation Protocol (SIP)? ............................................................................................ 100
SIP History.................................................................................................................................................. 102
Why SIP signalling?.................................................................................................................................... 104
What is Session Description Protocol (SDP)? ............................................................................................ 106

5.

VOIP IN AERONAUTICAL COMMUNICATIONS ...................................................................... 111


Circuit to Packet switching interworking ..................................................................................................... 112
Working towards end-to-end VoIP .............................................................................................................. 116
Example of SIP Telephone technology today ............................................................................................. 120
Functional Airspace Blocks (FABs) ............................................................................................................ 122
Today no sector delegation between ACCs ............................................................................................... 124
Sector delegation between ACCs now possible ......................................................................................... 124
Today ACCs configured with adjacent ACCs addresses only ................................................................... 128
Sector Delegation between ACCs now possible......................................................................................... 128
Last Resort communications between ACCs ............................................................................................. 130
What are Roles / Missions? ........................................................................................................................ 132
What is Sector Delegation? ........................................................................................................................ 132
Mission applied to CWP=Role(s) + Sector(s) ............................................................................................. 134
Example of Role and Sector combination to form mission applied to a CWP ............................................. 134
Configuring addresses for sector delegation .............................................................................................. 136
Example of Sector delegation from ACC1 to ACC2.................................................................................... 142
IP network impacts for Telephone calls ...................................................................................................... 146
Communication between VCS's ................................................................................................................. 148
FAA Override Call operation ....................................................................................................................... 150
FAA OVR call Audio loop detection ............................................................................................................ 152
Impacts of VoIP on Radios ......................................................................................................................... 154
IP network impacts for Radio calls.............................................................................................................. 156
Communication between VCS's and Radios .............................................................................................. 156
What is Remote Radio Control Equipment? ............................................................................................... 158
FAA Radio Gateway Overview ................................................................................................................... 160
Impacts of VoIP on Recorders .................................................................................................................... 162
Improved Access to Real Time Information (Subscriptions) ....................................................................... 164
Migration to IP through Telephone Gateways............................................................................................. 166
Migration to IP through Radio Gateways .................................................................................................... 166
CFMU Migration to PENS ........................................................................................................................... 168

6.

EUROCONTROL & FAA VOIP INITIATIVES............................................................................ 171


EUROCONTROL VoIP in ATM test specifications ..................................................................................... 172
EUROCONTROL VoIP in ATM Test Suite development ............................................................................ 174
FAA Addendums ........................................................................................................................................ 176
European Single Sky Implementation (ESSI) Objective COM11 .............................................................. 178
VoIP in ATM implementation & Transition Expert Group ............................................................................ 184

7.

NETWORK OVERVIEW ............................................................................................................. 187


Network Domain Concept ........................................................................................................................... 188
Pan European Network Services - Core network & services ...................................................................... 190
Guaranteeing IP network availability - Built-in redundancy......................................................................... 190
PENS network architecture......................................................................................................................... 192
PENS - a shared infrastructure ................................................................................................................... 192
PENS User Status ...................................................................................................................................... 194
Virtual Private Networks available on PENS............................................................................................... 196
Multiprotocol Label Switching (MPLS) ........................................................................................................ 196

Copyright 2014 JSP-Teleconsultancy

VPNs over SITA MPLS Backbone .............................................................................................................. 198


MPLS path establishment through network ................................................................................................ 198
Layer 2 Virtual Leased Line (VLL) over MPLS Core network ..................................................................... 200
Layer 2 Virtual Private LAN service (VPLS) over MPLS Core network ....................................................... 200
Guaranteeing Real Time Voice over network ............................................................................................. 202

8.

SESAR WP 15.2.10 VOIP VALIDATION WORK ....................................................................... 205


SESAR Programme.................................................................................................................................... 206
SESAR Master Plan for CNS activities ....................................................................................................... 208
SESAR Work packages .............................................................................................................................. 210
Validation of VoIP in ATM part of SESAR JU 15.2.10 ................................................................................ 212
SESAR JU Work Programme 2009-2014 ................................................................................................... 214
SESAR JU Description of Work- WP 15.2.10- VoIP Validation .................................................................. 216
SESAR members & WP 15 members ........................................................................................................ 218
WAN test bed network topology ................................................................................................................. 220
SESAR 15.2.10 VoIP related deliverables .................................................................................................. 222
SESAR 15.2.10 D11 Tests ......................................................................................................................... 224
VoIP validation activities (SESAR 15.2.10) ................................................................................................ 226

GLOSSARY ........................................................................................................................................ 229

Produced by JSP Teleconsultancy

Next Generation ICAO 9896 VoIP


interfaces for ATS Ground Voice Network
- Part 1

Copyright 2014 JSP-Teleconsultancy

Introduction

1. Introduction

Produced by JSP Teleconsultancy

Introduction to course

Course Objectives - Part 1

Copyright 2014 JSP-Teleconsultancy

Introduction

Produced by JSP Teleconsultancy

Course Objectives - Part 2

Course Objectives - Part 3

10

Copyright 2014 JSP-Teleconsultancy

Introduction

Produced by JSP Teleconsultancy

11

Next Generation ICAO 9896 VoIP


interfaces for ATS Ground Voice Network
- Part 1

12

Copyright 2014 JSP-Teleconsultancy

ATS Ground Voice Network overview

2. ATS Ground Voice Network overview

Produced by JSP Teleconsultancy

13

Telephone network infrastructure overview


Todays Telephone Network Infrastructure Overview
Todays ATS Ground Voice network (AGVN) is comprised of a mix of Local Battery 2W/4W circuits (using
M.1030), analogue leased lines (M.1030) used to establish calls using either ATS_R2 (MFC-R2) or ATS-No.5
analogue signalling, 64kbps co-directional digital leased lines (EN 301 288/289) with octet integrity used to
establish calls using ATS-QSIG. Sometimes E1 leased lines are used to connect E1 CAS interfaces (digital
transport of ATS-R2 protocol) or to connect E1 Multiplexers at both endpoints in order that the E1 timeslots can
be used to transport different traffic types.
The Local Battery lines are dedicated point-to-point lines, while the analogue lines used for ATS-R2/ATS-No.5
are switched lines while the 64kbps and 2Mbps digital lines allow channel switching.
The current network is designed to have direct routes (between 2 VCSs nodes only) through which calls are
normally routed and indirect routes (going via one transit VCS node maximum) through which calls are routed
in case of direct route failure or line/channel congestion. The normal number of analogue circuits or digital
channels available between two VCS nodes is proportional to the voice traffic between them. There should be
sufficient lines/channels available in order to ensure that congestion is not experienced by controllers (even
during the busiest peak traffic hour of the peak season).
In case of an emergency situation arising concerning the safety of aircraft or in the case of network congestion
when calls cant be made, it is possible to make a priority (emergency call). This has the scope of reaching the
desired end-user and has the capability of interrupting other less important calls in progress in order to free-up
circuits/channels and intruding into a call-in-progress if the desired end-user is busy with a call already inprogress.
The ATS 6-digit numbering plan exists in the switched ATS network. Every CWP is identified by a unique 6digit number. It is therefore important to ensure that routing tables are correctly updated in order to make
contact with the desired CWP.
A mix of VCS systems from different VCS suppliers are in operational use across Europe in ATC centres,
Approaches and Towers. The main common interface in use today is still the ATS-R2 analogue signalling
interface. ATS-QSIG digital signalling interface has started to be adopted by some ANSPs in some European
States (13 States that have signed the EUROCONTROL ECIP objective COM06), but in reality there are a
minimal number of ATS-QSIG operational lines today across Europe.

Analogue interfaces to dedicated analogue leased lines


Local Battery (LB)
Interface: 2 and 4 wire versions are available. Connected to analogue leased lines compliant with ITU -T
M.1030 and ITU-T M.1040. The lines are dedicated point-to-point lines (i.e. they are not switched by
the VCS). This interface is also nominated Ring In/Ring Out.
ATS-R2 (MFC-R2)
Interface: ATS R2 analogue interface compliant with EUROCONTROL ATS R2 and ATS No.5
protocol specification, is frequently used in the analogue part of the European AGVN. This 4 -wire
interface is connected to an analogue leased line with characteristics as defined in ITU -T
recommendation M.1030. This interface allows the lines to be switched by the VCS.
ATS-No.5 (ITU.T No.5)
Interface: ATS No.5 analogue interface compliant with EUROCONTROL ATS R2 and ATS No.5
protocol specification, are also used in the analogue part of the European AGVN. This 4 -wire interface
is connected to an analogue leased line with characteristics as defined in ITU -T recommendation
M.1030.
Central Battery (CB)
Interface: 2 wire versions are available. Connected to analogue leased lines or to standard LD/DTMF
telephones. This interface is also nominated Dial In/Ring Out.

14

Copyright 2014 JSP-Teleconsultancy

ATS Ground Voice Network overview

Telephone network infrastructure overview


VCS/

VCS
CWP

LB
Recorder

ATS-R2
ATS-No5

VCS
Maintenance/
Configuration

ATS-QSIG

Local Battery M.1030 (2w, 4w)


Dedicated point-to-point leased lines
Switched analogue leased lines (M.1030)

LB
ATS-R2

ATS-R2

ATS-No5

ATS-No5

ATS-QSIG

ATS-QSIG

E1 CAS

E1 CAS

Switched analogue leased lines (M.1030)


64kbps (EN 300 288/289) codirectional
digital leased line
E1 digital leased line (EN 300 418/419)

E1 CAS

VCS configuration
DA, IDA to ATC centres (DA call Performance <2S)
IA calls between ATC/App or App/Twr (IA call Perf.<1s)
DA/IDA Priority calls
Many supplementary services work only locally
Network features limited: call intrusion + Call interruption
6-digit number plan + Routing Table Configuration
Direct (2 VCSs) /Detour routes (via 1 transit VCS)
Main common I/F today is still ATS-R2
ATS-R2/No.5 to ATS-QSIG gateways
Digital VCS synchronized to common clock source

Lines
LB Point-to-point dedicated
ATS-R2: switched line
ATS-QSIG switched lines/channels.
Qty proportional to peak traffic
Direct & Detour route architecture
E1 CAS used for ATS-R2
Switched lines: imply congestion

PSTN/PABX
Interface: 2 wire interface to connect to the PSTN, PABX or to another VCS. This interface is also
nominated Ring In/Dial Out. It emulates a standard telephone set.
Loop start
Interface: 2 wire interface to connect to a telephone without a dial pad. This interface is also nominated
Loop In/Ring Out.
Digital interfaces to digital leased lines
ATS-QSIG (64kbps: 3B+D)
Interface: Is defined by the ECMA 312 and ETSI EN 301 846 standards. ATS-QSIG uses an ITU-T
G.703 co-directional interface as defined by EN 300 290. It is connected to 64kbps digital unrestricted
leased line with octet integrity as defined Standards EN 300 288/289. It can send an octet timing signal
on its transmit path and requires an octet timing signal on its receive path. The 64kbps bearer is used
to transport four 16kbps sub-channels as defined by the ECMA 253 standard. Three of these channels
are used to transport compressed voice (ITU-T G.728 LD-CELP) while one is used as a signalling
channel.
2Mbps E1 CAS
Interface: Some VCS suppliers have developed the standard E1 Interface for their VCS for c onnection
to the PSTN, PABX or another VCS. This uses a 64kbps signalling channel (D) and thirty 64kbps media
channels (30B). These use the unstructured ITU-T G.703 interface (D2048U) with the G.704 structured
frame format superimposed on the signal. This allows timeslot 0 to be used for synchronization
purposes. The channel 16 is used as the D signalling channel and channels 1 -15 and 17-31 for audio.
Using G.704 frame structure, the interface is normally synchronized to the leased line supplied by the
Telecom Operator.

Produced by JSP Teleconsultancy

15

2Mbps ISDN Primary Rate Access (30B+D)


Interface: Some VCS suppliers have developed the standard ISDN Primary Rate Interface for their
VCS, for connection to the PSTN or a PBX. This uses a 64kbps signalling channel (D) and up to thirty
64kbps media channels (30B). These use the unstructured ITU-T G.703 interface (D2048U) with the
G.704 structured frame format superimposed on the signal.
144kbps ISDN Basic Rate Interface (2B+D)
Interface: Some VCS suppliers have developed the standard ISDN Basic Rate Interface (U-interface)
for their VCS, for connection to the PSTN. This uses a 16kbps signalling channel (D) and two 64kbps
channels (2B) for the transport of voice or data. These interfaces are often used for back -up in case of
leased line failure enabling calls to be established via the PSTN.
64kbps X.21 digital interface
Interface: Some VCS suppliers offer a X.21 data communication digital interface for their VCS. This is
an interface for public data networks, but can be used to send 64kbps voice over a private data network
using a 2Mbps E1 leased line.

Instantaneous Access (IA) interfaces


This is Instantaneous Controller-to-Controller communication between controllers within same ACC or between
an ACC and Approach or between Approach and Tower, through dedicated Instantaneous (Hot-line or
Intercom) keys or selection of a HOT function key prior to DA key establishment; IA calls have an automatic
one-way voice path to the called user.
Interface: These have dedicated proprietary IA interfaces and lines.
Signalling: The signalling between the CWP and VCS for an Instantaneous Access call is proprietary.

VCS architectures
Most VCS architectures today are distributed, decentralised and fully redundant systems using PCM
switching technology. They have been developed to prevent any critical or centralised points of failure.
A distributed processing architecture design ensures that a fault occurring in one system module does
not effect the continued operation of other parts of the syste m and prevents the danger of a complete
system failure. VCSs tend to have a modular design, with the number of interfaces per module kept to a
minimum (i.e. normally a maximum of two).
A decentralised switching methodology is often used in todays VCSs. V CSs which use a duplicated
Switch card philosophy have one switch card as a back-up for the other (in hot stand-by) which enables
a seamless changeover in the case that one develops a fault. The line interfaces and CWPs have access to
each of these switch cards for increased resilience.
Normally all primary equipment and devices within the VCS are duplicated. This can also include the
main core operating system of the VCS that is designed to work in parallel. Any non -duplicated
equipment (i.e. peripheral line interface modules) can easily be substituted in the case of failure. These
modules can be swapped while the VCS is in operation without any effects.
Most VCSs use a non-blocking switching architecture which permits all VCS internal and external po rts
(i.e. CWP and leased lines) to have simultaneous access through it. This implies that any external
interface and CWP in the system can be connected to all other CWPs at all times and never experience a
switch blocking condition as a result of call processing or control limitations. With all internals and
external VCS ports configured, the switch matrix should not experience blocking .
Todays VCSs have their Call control either centralised or decentralised. Centralised implies that there
is one central unit responsible for call control, which is normally duplicated in case of software failures.
If call control is de-centralised implies that each peripheral interface has its own call control, reducing
the risk in case of software failures. The overall picture of which calls are currently in progress within a
VCS may not be possible however.

16

Copyright 2014 JSP-Teleconsultancy

ATS Ground Voice Network overview

Three different architectures are used within todays VCSs, these have been nominated Star, Ring and
Ethernet/LAN type architectures.

Access Methods
Within the ATS network, there are three types of Primary Telephone Facilities by which calls can be
made known as "Access Methods"; these are:

Direct Access;

Instantaneous Access;

Indirect Access.

The VCS systems in a European AGVN should be able to make and receive network calls using these
access methods.

VCS Ground Telephony supplementary services (features)


Todays VCSs offer a range of supplementary services (features) to its users. Many of these however
have been developed using proprietary signalling methods or have been customized to satisfy customer
requirements. This makes interworking of supplementary services between different VCS suppliers
impossible. Many of the following supplementary services offered by a VCS however are today utilized
only within the VCS domain.

Common appearance / Ring group A call alerts at many CWPs simultaneously

Call Hold Places a call on hold

Call Transfer Transfer a call to another CWP or to an external CWP/terminal via an external line.

Conference - With a number of internal CWPs and an external line. Many VCS allow a conference
of up to 5 users;

Call Pick-up Answer a call alerting at another CWP

Call Diversion (Forwarding) Divert calls to another CWP

Group hunting A call alerts at a single CWP defined in group. If not answered after a preset time,
call is directed to next CWP.

Call completion/call back on busy Allows caller to complete call to a user found to be busy, by
calling them when that user is available.

Some important supplementary services relating to Priority (Emergency) calls however have been
defined in recommendations and standards in order to guarantee interoperability between different
suppliers.

Call Intrusion Attempts intrusion into a call in progress if called user is busy. This is u sed by an
emergency call in order to communicate with the called user in the fastest way possible.

Call Priority Interrupt Attempts to interrupt an existing lowest protected call when there is network
congestion and the emergency call lacks the resources to arrive at its destination.

The Eurocontrol ATS-R2 and ATS-No.5 signalling protocol specification originally defined the
signalling required for these supplementary services and later the ECMA 312 standard for ATS -QSIG
went further by defining them at international level.

Produced by JSP Teleconsultancy

17

Circuit switched connections and TDM transport efficiency


Circuit Switched Connections
A circuit switched network is one that establishes a circuit (or channel) between nodes and terminals before the
users may communicate, as if the nodes were physically connected with an electrical circuit.
The bit delay is constant during a connection, as opposed to packet switching, where packet queues may cause
varying packet transfer delay. Each circuit cannot be used by other callers until the circuit is released and a new
connection is set up. Even if no actual communication is taking place in a dedicated circuit that channel remains
unavailable to other users. Channels that are available for new calls to be set up are said to be idle.

TDM transport efficiency


Time Division Multiplexing (TDM) is the means by which multiple digital signals (or analogue signals carrying
digital data) can be carried on a single transmission path by interleaving portions of each signal in time. This
enables digitally encoded speech signals to be transmitted and switched optimally within a circuit-switched
network. A circuit switched network establishes dedicated connection(s) between the two nodes for their
exclusive use for the duration of the communication.
The slide illustrates the use of TDM circuit switched technology to transport different applications (i.e. Voice,
Legacy, LAN and video) over a single WAN link. Each application is assigned one or more timeslots within the
TDM frame structure. TDM allocates a fixed dedicated bandwidth to establish an end-to-end connection for
each medium type and this bandwidth is reserved for the medium even when it is not being used.
If an application has no data to send during its pre-established timeslot(s), the bandwidth is wasted as no useful
data is transmitted. In the case of a voice for example, there are periods of silence between phrases when the
time slot is used to transmit just silence. Also a video signal is normally transmitted as bursts of data, with no
transmission between the bursts.
Due to each application having its own dedicated timeslots allocated for transmission, there is no congestion
experienced by any of the applications.
The utilization of the overall bandwidth of a TDM transmission system is inefficient and is calculated at
between 50 and 60%.

18

Copyright 2014 JSP-Teleconsultancy

ATS Ground Voice Network overview

Circuit switched connections and


TDM transport efficiency
A circuit (analogue) or channel (digital) dedicated to a call from
end to end;
Signal passed digitally through the core network, analogue in
the access network;
Local
Switch

Core Network

Access
Network

Local
Switch

Access
Network

Routers
Trunk Switches

Types of Traffic

Utilization

Voice

PBX

Wasted Bandwidth

Legacy

5060%

LAN
Video

Single WAN Link


Time Slot Assignments

Produced by JSP Teleconsultancy

19

Direct Access Call operation


Direct Access Basic Call Type
All Ground Telephone Basic call types comply with the Primary user Ground Telephone facilities as defined in
ICAO Doc 9804 Manual on Air Traffic Services (ATS) Ground-Ground Voice Switching and Signalling
edition 2002. A detailed description of the Direct Access facility is defined in ICAO document 9804.
The Direct Access (DA) Facility is one of the most important features of a VCS. It is most commonly used
between ACCs, but can be used between ACCs and Approaches and between Approaches and Towers.
DA facility operation
The operation of the Direct Access facility is described as follows:
1.

The operation of a single key by the A-party is all that is required to initiate a call to the B-party. The Bparty address is assigned and fixed semi-permanently in the A-party VCS. It is, thus, uniquely associated
with a particular key and each key is labelled as such.

2.

Dial tone and outgoing signalling tones are not given to the A-party. Ringing/ringback tone is optional by
bilateral agreement between the A-party and B-party administrations. Busy tone shall be given, if
appropriate. However, due to either the exclusive, one-to-one assignments of the keys between the A- and
B-parties or the 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.

3.

A suitable mechanism (i.e. number unobtainable/ reorder tone) shall be provided to inform the A-party,
should the call fail for any reason other than because the B-party is busy.

4.

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. 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. The B-party accepts the
incoming call by means of a single action associated with a key or dynamic display.

5.

Once the call has been answered, speech can be exchanged between the A and B-parties.

6.

Under normal conditions the B-party can receive one or more direct access calls simultaneously and by
using the A-party identities, together with a defined operational procedure or experience, the B-party will
deal with each call appropriately.

7.

At the end of a call, either the A-party or the B-party shall be required to deselect/clear the call. Some
implementations may require both parties to deselect/clear the call.

Implementation of the DA facility across an IP network has been included by EUROCAE WG67 in
Interoperability Standard for Voice over IP ATM components: Part 2: Telephone and its functionality also
complies with the ICAO document 9804 description.
DA call routing
A DA call can be routed on a Direct Point-to-Point Route or Direct Network route or can be switched to a
Detour route in the case that the Direct Route is congested or is out-of-service.
DA calls can however be performed using Local Battery signalling method over dedicated point-to-point
circuits, ATS QSIG digital signalling protocol, ATS R2 and ATS No.5 analogue signalling protocols in Circuit
Switched Networks.

DA call performance
The Direct Access Call Performance Criteria in a Network as defined in the ICAO Doc 9804:
a)

Direct Access should meet the requirements for Direct Controller-Controller Voice Communication
(DCCVC) which stipulates that communication be established between radar controllers within
2 seconds in 99% of the time.

b) The interval of 2 seconds is the delay between the calling user initiating the call and the called user
receiving the call alert/indication.
c)

20

The interval of 2 seconds applies to DA calls on a Direct Route.

Copyright 2014 JSP-Teleconsultancy

ATS Ground Voice Network overview

Direct Access Call operation


VCS B

VCS A
B

DA call signalling exchange

A
CR

Two-way speech

CR

DA Panel

DA Panel

Outgoing scenario: Press DA key on DA panel to make call to labelled


destination;
No Dial tone; Ringing tone through bi-lateral agreement; Busy tone
and number unobtainable mandatory;
Incoming scenario: DA call indicated by audio or visual means; Calling
Identity shown on key; Call accepted by pressing DA key;
Many DA calls can be received simultaneously;

Calling or called party can clear call;


Performance (ICAO 9804): DA calls should be established within 2
seconds or less for 99% of call attempts. This is delay between caller
initiating call and called party being alerted to its presence.

Produced by JSP Teleconsultancy

21

Instantaneous Access Call operation


Instantaneous Access Basic Call Type.
All Ground Telephone Basic call types comply with the Primary user Ground Telephone facilities as defined in
ICAO Doc 9804 Manual on Air Traffic Services (ATS) Ground-Ground Voice Switching and Signalling
edition 2002. A detailed description of the Instantaneous Access facility is defined in ICAO document 9804.
The IA facility is most commonly used between ACCs and Approaches and between Approaches and Towers.
Today it is not used over international circuits.
The operation of the Instantaneous Access facility is described as follows:
1. The operation of a single key by the A-party is all that is required to initiate a call to the B-party. The Bparty address is assigned and fixed semi-permanently in the A-party VCS. It is thus uniquely associated
with a particular key and each key is labelled as such.
Note. Some administrations may prefer that it be necessary for the A-party to sustain the key operation
for the duration of the call.
2.

Dial tone and outgoing signalling tones are not given to the A-party. Ringing/ringback tone is not given to
the A-party. Number unobtainable/reorder tone is given to the A-party if the call fails for any reason,
including any busy conditions encountered.

3.

The arrival of the call from the A-party to the B-party causes, simultaneously, the events detailed in a) to d):
a) The A-party identity is indicated to the B-party either by association with a key assigned and fixed semipermanently 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 calls.
b) An audible alert is generated at the B-party VCS in accordance with the following options:
1) no audible alert;
2) an alert of fixed duration; or
3) a continuous alert requiring a silencing action by the B-party.
c) The B-party VCS automatically accepts/answers 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 an abnormal situation and should result in number unobtainable/reorder tone being given to the A-party.
At this stage the speech channel from the A-party to the B-party is established. How speech from the Aparty is managed (i.e. conferenced with other speech at the B-party working position, switched to a
loudspeaker or to a split-headset) is a matter for the B-party administration to decide.
d) By bilateral agreement, the establishment of the call as detailed in c) may also result in the A-party having
some monitoring facilities of the B-partys working position, including ground-ground and air-to-ground
radiotelephony. This enables the A-party to exercise discretion before passing the message.

4.

The B-party may respond to the A-party by activation of a key associated with the incoming call. This action only
enables the return speech path and is not a new instantaneous access call. The call is cleared by the A-party only
with no effect on other calls in progress at the B-party.

Implementation of the IA facility across an IP network has been included by EUROCAE WG67 in
Interoperability Standard for Voice over IP ATM components: Part 2: Telephone and its functionality also
complies with the ICAO document 9804 description.
IA call routing
It is recommended that an IA call within an AGVN should only be routed on a Direct Point-to-Point Route
dedicated to IA calls, in order to achieve the fastest possible call establishment time. Ideally a speech path
should be rapidly established after IA key depression in order to prevent speech clipping of the first syllable of a
message. Detour Routes should not be used for IA calls.

22

Copyright 2014 JSP-Teleconsultancy

ATS Ground Voice Network overview

Instantaneous Access Call


operation
VCS A
B

IA Panel

VCS B
IA call signalling exchange

One-way speech
Monitoring- Radio & Tel. Speech at B

A
IA Panel

Outgoing scenario: Press IA key on IA panel to automatically


establish speech path to loudspeaker, split headset; Option to monitor
ground and radio calls in progress at called CWP before speaking;
No Dial or Ringing tone; Number unobtainable tone mandatory;
Incoming scenario: IA call arrival can be indicated by audio or visual
means; automatically answered regardless of ground or radio calls in
progress;
Called CWP can return speech by pressing its IA key;
Performance (ICAO 9804): IA calls should be established within 1
second or less for 99% of call attempts.
This is delay between caller initiating call and speech path being
established.
In todays VCSs based on TDM architectures, IA call signalling between VCSs has not been standardized to
date, implying that IA call interoperability between VCSs from different suppliers is improbable. WG67 ED137
doc has defined IA signalling between VCSs for the first time, implying that in the future IA call interoperability
will be possible.
The cross-border use of the IA facility should be subject to a bilateral agreement between respective ANSPs.

IA call performance
Instantaneous Access Call Performance Criteria in a Network (as defined in the ICAO Doc 9804):
a)

Instantaneous Access should 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 calling user initiating the call and the speech path
being established.
c)

In practice however a network should seek the fastest call establishment time possible. Connection
times should be as fast as possible if speech clipping is not to be witnessed by the called user.

Produced by JSP Teleconsultancy

23

Priority DA Call operation


Operation of Priority (Emergency) calls
The 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) and to enable, if necessary, the interruption of less urgent calls in progress
at the time. The use of priority is generally agreed by bilateral agreement between administrations. The ultimate
decision and responsibility as to whether a call has priority rests with the A-party in accordance with local
operational procedures.
A description of the Priority call facility is defined in ICAO document 9804.
There are two ways in which priority can be set:
a) manually, before the call is made: before making the call, a priority key is operated on the VCS to
set the priority of the call to urgent. This method is used when the call is already known to be urgent;
b) automatic setting of priority: the priority of all calls from a particular CWP or set of keys is
pre-programmed in the VCS to be emergency. This method can be used for operational reasons when
calls made from a particular CWP or key are always to be treated as urgent. An example of this is to use the
priority facility to distinguish between instantaneous access and direct access calls.
Equally, the B-party VCS should react to an incoming priority call in the following manner:
a) provide some means of indicating that a priority call has been received (e.g. special visual and/or audible
indications); and
b) allow the priority call to intrude in a call already established preceded by a warning indication.
If a priority call cannot proceed due to congestion (all available circuits, links or channels are busy), the priority
call should interrupt an established routine call (should one exist), thus allowing the priority call to proceed.
Before the established routine call is interrupted, all parties engaged in that call should receive an interrupt
warning tone.
Implementation of the Priority call facility across an IP network has been included by EUROCAE WG67 in
Interoperability Standard for Voice over IP ATM components: Part 2: Telephone and its functionality also
complies with the ICAO document 9804 description.

24

Copyright 2014 JSP-Teleconsultancy

ATS Ground Voice Network overview

Priority DA Call operation


Call Priority Interrupt - Allowed by ANSP
Call Intrusion Allowed by ANSP
Hears interrupt
warning tone<10s
(Rec. 5s)

Hears interrupt
warning tone<10s
(Rec. 5s)

Priority Level 1 call


Routine call (Priority Level 3)
Routine call (Priority Level 2)
Routine call (Priority Level 2)

Wanted
user

Hears intrusion
warning tone of 1s
Emergency !
Priority Call

Some ANSPs isolate


unwanted user during
Call intrusion, others
allow 3-party conference

Produced by JSP Teleconsultancy

Unwanted
user

25

Telephony features
VCS Ground Telephony supplementary services (features)
Todays VCSs offer a range of supplementary services (features) to its users. Many of these however
have been developed using proprietary signalling methods or have been customized to satisfy customer
requirements. This makes interworking of supplementary services between different VCS suppliers
impossible. Many of the following supplementary services offered by a VCS however are today utilized
only within the VCS domain.

Common appearance / Ring group A call alerts at many CWPs simultaneously

Call Hold Places a call on hold

Call Transfer Transfer a call to another CWP or to an external CWP/terminal via an external line.

Conference - With a number of internal CWPs and an external line. Many VCS allow a conference
of up to 5 users;

Call Pick-up Answer a call alerting at another CWP

Call Diversion (Forwarding) Divert calls to another CWP. Temporarily inhibited incoming
telephone calls from arriving at a position. All incoming calls will be routed to the specified
destination.

Group hunting A call alerts at a single CWP defined in group. If not answered after a preset time,
call is directed to next CWP.

Call completion/call back on busy Allows caller to complete call to a user found to be busy, by
calling them when that user is available.

Position Monitor: Allows authorised supervisors to listen in to telephone calls and incoming and
outgoing radio traffic at another position. The monitored position usually receives no indication that
it is being monitored and there is no degradation in audio level or voice quality.

Some important supplementary services relating to Priority (Emergency) calls however have been
defined in recommendations and standards in order to guarantee interoperability between different
suppliers.

Call Intrusion Attempts intrusion into a call in progress if called use r is busy. This is used by an
emergency call in order to communicate with the called user in the fastest way possible.

Call Priority Interrupt Attempts to interrupt an existing lowest protected call when there is
network congestion and the emergency call lacks the resources to arrive at its destination.

The Eurocontrol ATS-R2 and ATS-No.5 signalling protocol specification originally defined the
signalling required for these supplementary services and later the ECMA 312 standard for ATS -QSIG
went further by defining them at international level.

26

Copyright 2014 JSP-Teleconsultancy

ATS Ground Voice Network overview

Telephony features

Following proprietary features used in VCS domain:

Common appearance / Ring group (Call alerts many CWPs


simultaneously)
Call Hold, Call Transfer, Conference, Call Pick-up,
Call Diversion (Forwarding), Call Completion,
Group hunting (Call alerts single CWP defined in group & if
unanswered is directed to next CWP).

Following features standardized (interoperability possible in


AGVN):

Call Intrusion (Attempts Intrusion into call in progress if called


user is busy).
Call Priority Interrupt (Attempts to interrupt existing lowest
protected call when there is network congestion).
A priority call uses both Call Intrusion & Call Priority Interrupt
supplementary services

Produced by JSP Teleconsultancy

27

Radio network infrastructure overview


Todays Radio Network Infrastructure Overview

Todays ATS Ground Voice Network (AGVN) is comprised of a mix of analogue and digital point -topoint leased lines that connect each VCS directly to Remote Control Equipment (RCE) located at a
series of Remote Radio Sites where its associated Radio Transceivers, Transmitters and Receivers are
positioned. Some Ground Radio Stations have the RCE built-in its architecture. The RCE therefore
bridges the gap between the VCS and the GRS equipment.
Each Ground Radio Station is configured to operate at a set frequency. GRS Transceivers able to
transmit and receive on the same frequency, GRS Transmitters are only able to transmit w hile GRS
Receivers are only able to receive. Separated Transmitters and Receivers can be located at the same or
different locations.
A VCS will have a pre-defined number of frequencies covering its sectors and will hence have access to
the same pre-defined number of Ground Radio Stations, which can be doubled in the case of a redundant
architecture with Main/Standby Radios.
In the case of analogue lines, one line is required per frequency. In the case of fully redundant solutions
with Main/Standby Radios configured for same frequency, two lines are required with the Main/Standby
switching performed at the VCS side.
In the case of 64kbps or 2Mbps digital lines with the capability of transporting multiple channels
between VCS and Remote Control Equipment at the Remote Radio sites is possible, with each Tx and or
Rx channel being associated with a GRS Transmitter and/ or GRS Receiver at a pre -set frequency. In
this case the RCE acts like a Digital Access Cross-connect switch (DACS) and switches the channels
through to the individual GRS at the Remote Radio Site. In the case of fully redundant solutions with
Main/Standby Radios configured for same frequency, two digital lines are required with the
Main/Standby switching performed at the VCS side.
For analogue and digital interfaces no international body has defined a common Radio Interface and
signalling standard to be used for communication between VCSs and Ground Radio Stations
(Transceivers/Transmitters/Receivers). The analogue E&M tie -line interface has been adopted as a
common radio interface due to its simplicity and due to most GRS equipment manufacturers also having
this as its common interface.
With the migration to digital radio interfaces, although common interfaces have been used by the VCS
suppliers (i.e. E1 CAS and G.703 64kbps) for their connection to a remote RCE, the signalling methods
they employ can generally be classed as proprietary.
Due to proprietary signalling methods in use over these links, it is likely that the Remote RCE
equipment at the Ground Radio site is also supplied by the same VCS supplier. Through the RCE, a
radio interface within a VCS not only has the capability of transmitting and receiving audio, but also has
the capability to monitor and control the Radios remotely through either serial interfaces, separate
signalling/channels in the 2Mbps frame.
It is however more common to monitor and control single or multiple remote radio sites from a VCS
side, using a serial data interface (i.e. RS485, RS422 or RS232). Some radios allow monitoring and
control via an Ethernet/LAN interface. Application programs running on PCs or workstations act as the
user interface for the monitoring and control of the single and multiple GRSs at remote radio sites.
These can be used for example to control Power settings, Selected Channels, Frequency Tuning, handle
Main/standby changeover and monitor Status information etc.
Today analogue/digital radio interfaces and leased lines are usually configured on a point -to-point basis
for a permanent connection between VCSs and Remote Control Equipment (RCE) at the Remote Radio
sites. It is generally not possible to switch the connection of a Radio interface within the VCS to another
Ground Radio Station (pre-set to a different frequency) at the same or a different Remote radio site.
Likewise it is not possible for more than one VCS (in a Multi -supplier network) to access the same
Remote Control Equipment/Ground Radio Station. The GRS today therefore do not have call control or
switching functionality and its pre-configured frequency cant be identified by an address. Without an
address scheme in operation for GRSs, it is not possible to establish connections to GRS on demand.

28

Copyright 2014 JSP-Teleconsultancy

ATS Ground Voice Network overview

Radio network infrastructure overview


VCS

GRS (E&M)

CWP
Analogue leased line (4w, 6w)

E&M

f1

PTT/squelch Inband tones, Outband signals

RCE

Recorder

G.703
64kps

E1 CAS
VCS
Maintenance/
Configuration

PTT/squelch layer2, layer 3, inband

f1
f2
f3

64kps
RCE
RCE

2Mbps (30B+D) co-directional digital leased line

GRS
f1
f2

PTT/squelch Ch.16

Lines
Point-to-point dedicated
VCS configuration
No Switched lines
Radio Access Modes: Silent, Redundant lines to
Rx-only, Tx/Rx and Coupling; Standby GRSs
Best Signal Selection (Rx Voting)
Cross-coupling (local frequencies only), some
proprietary network solutions allow local/remote
frequency mix
Best Transmitter Selection or
Climax (Multi-carrier off-set transmission);
M&C performed through Serial or Ethernet I/F;
Main/Standby GRS switchover etc, Power Levels etc

GRS

4 wire
E&M

64kbps (3B+D) co-directional digital leased line

E1RCE
CAS

f3

RCE
Normally from VCS supplier
Common GRS i/f=E&M 4w
M&C methods proprietary

..
f30

GRS
Used only by 1 VCS (or multi-VCSs from same supplier)
No call control or address scheme
No on-demand connections
No knowledge of coupling state
Transmission cut when no PTT signal
Some have E1 CAS I/F
Transceivers or Transmitters/Receivers

The network topology in use today can lead to a VCS having many point -to-point connections to many
remote radio sites. Up until now there has never been a requirement for the VCS to gain access to GRSs
at Remote Radio Sites that were not its own.
The point-to-point infrastructure in operation today within the AGVN can indirectly e xplain why there
has not been a need for a common interface and signalling system to be defined for Radio interfaces
between all the VCS and GRS suppliers. This point-to-point infrastructure however implies that a VCS
suppliers radio interface will work with the RCE from the same VCS supplier, but will probably not
interoperate with RCE from different suppliers.
Independent of the fact that interfaces between the VCS and RCE are analogue or digital, the interface
between the RCE and GRS equipment is still nearly always implemented through E&M interfaces, the
most common being the 4-wire E&M interface.
Today many ANSPs using VCSs from different VCS suppliers are tied to adopting different solutions for each
of their VCSs when designing their radio network topologies, with interoperability between the solutions usually
being unachievable.
Current Radio Interfaces
The current methods of radio signalling interoperability between VCSs and GRS sites employed within todays
AGVN, identifies only the analogue E&M tie-line interface and the digital E1 interface using CAS as common
radio interfaces. Three 64kbps (ATS-QSIG similar) interfaces being employed as Radio Telephony interfaces
were identified, but although identical at the physical and data link layers and employing the same voice
compression algorithm, the methods employed by the individual suppliers for PTT and Squelch transportation
all differ and hence interoperability between them is impossible.
Within the present ATS Ground Voice Network, each radio frequency can either be served by:

a single radio interface (i.e. E&M, E1 CAS or 64kbps (3B+D)), providing access to a single
transmitter and a single receiver, via an RCE;

a single radio interface (i.e. E&M, E1 CAS or 64kbps (3B+D)), providing access to d uplicated
transmitters and receivers, via an RCE. These can either be in a main/standby configuration or

Produced by JSP Teleconsultancy

29

in a Best Signal Selection (receiver voting) configuration. The main/standby switching or


Best Signal Selection is performed at the remote radio si te, either controlled by the RCE itself
or initiated from the VCS;

a number of radio interfaces (i.e. E&M, E1 CAS or 64kbps (3B+D), each providing access to
different radios operating on the same frequency, either in a main/standby configuration or a
Best signal selection (Receiver Voting) configuration. The later is used in order to obtain wider
radio coverage, with selection taking place at the VCS;

PTT & Squelch transportation methods


Also the method used to transport PTT and Squelch signals between VCS and GRS also differs between the
various solutions available. E&M using inband tones or out-of-band signals to transport PTT on Tx path and
Squelch on Rx path. 64kbps interfaces using bits in Layer 2 frames, Layer 3 messages or inband bits robbed
from the compressed audio stream. The 2Mbps CAS E1 interface using Channel associated signalling in channel
16 to periodically transport the PTT ON/OFF bit towards the GRS on the Tx path and to receive SQUELCH
ON/OFF bit from the GRS on the Rx path.

30

Copyright 2014 JSP-Teleconsultancy

ATS Ground Voice Network overview

This page is intentionally blank.

Produced by JSP Teleconsultancy

31

Radio Access Modes of Operation


Radio access enables a user to transmit and receive voice communications on selected radio frequencies.
Radio access at a CWP is activated by the operation of a key associated with a particular freque ncy. The
key enables a particular radio frequency to be in one of the following five modes:
Off/Idle
The Frequency has not been allocated at the CWP, hence transmission or reception are not possible.
There is however usually an unmonitored channel alarm ge nerated by the VCS, if no other CWP is
monitoring or transmitting on this frequency.
Silent/Deselected
A Frequency has been allocated at the CWP but has not been selected. There is a visual indication at the
key configured for that frequency, if it is selected for PTT transmission at another CWP. There is a
different visual indication at that key, if a Squelch signal arrives on that same frequency, but no audio is
heard however. Many CWPs are able to watch the same frequency while in Silent mode. A single CWP
can watch different frequencies while in silent mode.
Receive only (Rx) or Monitor
When Rx or Monitor mode has been selected the User can hear any transmissions that are made on the
selected frequency. At the same time the presence of the carrier f requency, regardless of speech
modulation, will also cause the A/C call (Squelch) visual indication at the key configured for that
frequency. The CWP can select whether transmissions received from aircraft are directed to either a
headset, handset or loudspeaker at the CWP.
Simultaneous reception on more than one frequency or on all frequencies assigned to a CWP is normally
possible; It is also possible for more than one CWP to monitor the same frequency.
A CWP must have audio device (headset, handset or loudspeaker) selected and physically plugged-in,
prior to being able to select a Frequency. Any frequency that has been enabled at the VCS is normally
monitored (Rx selected) by at least one (typically a supervisors) CWP.
Transmit and Receive (Tx/Rx)
When both receive and transmit (Tx/Rx) mode has been selected the user can transmit on the
frequency by operating a Push-To-Talk (PTT) key. It is not possible to transmit on a frequency without
receive also being selected. When a CWP transmits on a part icular frequency, besides the CWP
indicating the frequency is in use, all other CWPs with that the same frequency allocated have an
indication that the frequency is in use. Simultaneous transmission on more than one frequency is
normally possible by firstly selecting the desired frequencies for transmission and then activating the
PTT key. A frequency being used for transmission normally cant be used by other CWPs.
Some VCSs allow definition of priority levels to CWPs for frequency access, in which case if two
CWPs select the same frequency, only the CWP with the higher priority will be able to transmit. A
Priority level hierarchy is sometimes also applied to the PTT switch, such that a supervisor can take over
transmission on a selected frequency, cutting off the previous user. The PTT delay quoted by many VCS
suppliers is <50ms; this is the time taken to activate transmitter into a usable condition from when the
PTT key is pressed.
Frequency Cross-coupling (Retransmission)
Refer to following slide

32

Copyright 2014 JSP-Teleconsultancy

ATS Ground Voice Network overview

Radio Access Modes of Operation

Radio access activated by key assigned a particular frequency. Key has one
of following five modes:
OFF / IDLE: Frequency unallocated (Tx & Rx not possible). Unmonitored
channel alarm generated if no CWP monitors/transmits on this frequency.
Silent Deselected: Frequency allocated but unselected. Visual indication if
PTT pressed at another CWP or if Squelch signal arrives on frequency. No
audio heard however.
Receive only/Monitor (Rx): User hears all transmissions on selected
frequency. Presence of carrier frequency causes A/C call (Squelch) visual
indication. Audio device (headset, handset or loudspeaker) must be pluggedin, prior to being able to select a Frequency;
Transmit and Receive (Tx/Rx): Allows user to transmit on frequency by
pressing PTT key. Receive must also be selected. Other CWPs receive
frequency in use indication. Simultaneous transmission on multiple
frequencies is possible. A frequency used for Tx normally cant be used by
other CWPs. Priority hierarchy can be applied to CWP to gain access to
frequency (e.g. Supervisor takes over transmission from controller)
Frequency Cross coupling (Retransmssion):

Produced by JSP Teleconsultancy

33

Push-To-Talk (PTT)
Push-To-Talk (PTT)
When both receive and transmit (Tx/Rx) mode has been selected the User can transmit on the
frequency by operating a Push-To-Talk (PTT) key. It should not be possible to transmit on a frequency
without receive also being selected. The PTT operation is performed by a mechanical key which can be
either:

integrated into hand microphones

desk-mounted

floor/foot mounted switches

free or clip-on lapel switches integrated into a Headset cable

As a means of preventing the Remote Radio Transmitter from being left in a permanently on condition,
caused by the failure of the Radio interface or leased line, the PTT ON signal is normally repeated
periodically during a transmission. On interface or line failure, the PTT ON signal would therefore no
longer be sent and a pre-set timer within the RCE would expire, causing transmission on the selected
frequency to be stopped.
Performance parameters for PTT
The PTT delay parameter defined by many VCS suppliers is <80ms. This is the de lay that occurs from
the instant the User activates the PTT key to the moment PTT signal arrives at the transmitter. PTT
delays worse than 80ms can lead to speech clipping. The PTT delay parameter defined by many VCS
suppliers over point-to-point 64kbps and 2048kbps E1 digital leased lines is sometimes even better than
80ms.
The Transmitter activation delay is the delay that occurs from the instant the User activates the PTT
key to the moment the transmitter (or transmitters) have been activated into a us able condition. Allowing
20ms for Transmitter Activation time the Transmitter activation delay should not be greater than 100ms.
This delay is comprised of several components in series including VCS Radio interface activation, Link
transmission, RCE processing, Transmitter activation etc. The VCS radio interface activation within the
VCS (i.e. time between detecting PTT selection and the activation of the line interface) is defined in
EUROCONTROL guideline documents as <10ms. The signalling used by E&M in terfaces is able to
satisfy this requirement.
Side Tone
Side Tone is the Users own transmitted speech fed back, at reduced level, into the Users ear -piece at
Handsets or Headsets. Side tone may be generated locally by the VCS or from speech received o ff-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.

34

Copyright 2014 JSP-Teleconsultancy

ATS Ground Voice Network overview

Push-To-Talk (PTT)

Press PTT key to transmit on selected frequency (Tx/Rx mode only). PTT
signal sent from VCS to RCE-R to activate Ground Radio Transmitter.
PTT key integrated into hand microphones, desk-mounted, floor/foot mounted
switches or integrated in Headset cable.
PTT delay (sum of GTx1 to GTx5) should be <80ms as longer can cause
speech clipping; Digital systems & networks can achieve faster times.
PTT signal sent out-of-band (i.e. M wire or D-Channel) or sent Inband (Tones
or channel Bit-robbing); PTT signal sent periodically as Radio transmitter
Keep
alive signal.
If VCS Radio I/F
or line fails,
transmitter switches
OFF if RCE-R
receives no keep
alive signal.

Produced by JSP Teleconsultancy

35

Incoming Aircraft Call detection/Squelch signal


A/C call (Squelch) Detection

The term Aircraft call (A/C) or Squelch is used to signify that the ground radio receiver has detected the
presence of a carrier signal above the background noise level. Most Ground Radio receivers can provide
a signal indicating squelch. If available, a VCS will use this signal to indicate the presence of squelch at
the CWP and switch the received audio through to the audio device (i.e. handset, headset or
loudspeaker). Various types of squelch signals may be used (e.g. ground, DC voltage).
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.
Performance parameters for Aircraft Call (Squelch)

The Squelch delay is the delay between the recognition of a Squelch signal by the RCE -R equipment
(output by the ground radio receiver) to the lifting of any muting signal on that frequency by the VCS,
such that audio can be heard at the CWPs that have the same frequency selected.
When Silent, Receiver (Monitor) or Cross Coupling modes are being used at a CWP, the audio channel
is always active and the CWP is able to receive on the selected frequency or frequencies, even if a
Squelch signal is not present. The Squelch signal is therefore used to:

Remove (Lift) any mute signal enabled at the CWP for that frequency;

Provide a visual indication at the CWP that an Air Craft call has been received on that
frequency.

The delay is therefore is not as critical as the PTT delay.


The VCS radio interface activation within the VCS (i.e. time between detecting squelch signal generated
as a result of an Air Craft Call and lifting any mute on the frequency is defined in Eurocontro l guideline
documents as <10ms.
Voice Activity Detection (VAD)
This can be configured at some VCSs in the case that a A/C (Squelch) signal cant be supplied by the
remote radio. The VCS monitors the level of audio received on the frequency. If the audio l evel exceeds
a nominal threshold, then a pseudo-squelch signal is generated which controls the A/C (squelch)
indication at the CWP and switches the audio through to the audio device. The voice detection threshold
can normally be configured. Due to the extra processing time involved to detect the speech and generate
the Pseudo-squelch signal, this method results in being slower when compared to A/C call (Squelch)
detection.

36

Copyright 2014 JSP-Teleconsultancy

ATS Ground Voice Network overview

Incoming Aircraft Call


detection/Squelch signal

Incoming call from aircraft at Ground Radio receiver (i.e. presence of carrier
signal above background noise level) generates Squelch signal sent to VCS.
Squelch delay: Delay to recognise signal at RCE-R, send to VCS (where
muting signal on frequency is lifted) and provide visual indication at CWP so that
audio can be heard at CWPs with frequency selected.
Squelch signal sent out-of-band (i.e. E wire or D-Channel) or sent Inband (Tones
or channel Bit-robbing);
When Silent, Rx only or
Cross Coupling modes
used- Squelch signal
not used as audio
channel is always active.
CWP able to receive on
selected frequency
or frequencies, even
if a Squelch signal
is not present.

The delay is therefore is not as critical as the PTT delay.

Produced by JSP Teleconsultancy

37

Radio features - Cross Coupling (Retransmission)


Frequency Cross-coupling (Retransmission)
The Cross-coupling function causes incoming audio received on any one of the frequencies in a defined
cross-coupled group (minimum 2 frequencies) to be retransmitted on the other frequencies in the group.
Listeners who are tuned-in to one frequency can hear what is being said on other frequencies. This
function can be very useful for pilots in busy airspace. With cross-coupling it is possible to merge a
number of physical radio frequencies into a kind of logical frequency.
The purpose of frequency coupling is to help the controller to work in merged roles. This makes it easier
to split and merge roles, and it improves the controllers efficiency, avoiding simultaneous calls of pilots
using different frequencies.
A Cross coupling group can be set up directly from the CWP. Unless prohibited by a restriction set in
the VCS, any frequency that has been allocated to the CWP can be included in a Cross -coupling group
unless the frequency is already in use within another cross-coupling group. A CWP indicates if it
has selected a frequency for Cross-coupling. There is a different indication at the CWP, if the frequency
has been selected by another CWP.
Any transmission by a CWP on any frequency in the group will be transmitted on all frequencies in the
group. If the key of a frequency within the group is selected while audio is being received on another
frequency in the group, the transmission usually has the higher priority and will interrupt retransmission
of the audio being received at the receiver.
The ANSP decides how many frequencies can be cross-coupled in total, the number of cross-coupling
sessions at a single CWP and for the VCS as a whole. The means of selection and control of cross coupling is decided by the ANSP but the following are typical options:

At any CWP

At a specified supervisor CWP

By means of the system management terminal

Cross-coupling may be applied to two or more frequencies but the principles may be illustrated with
reference to two cross-coupled frequencies A and B as follows. If an aircraft transmits on frequency
A it is received on the ground and cross-coupled to be re-transmitted on frequency B. For the user
on the ground at the CWP where coupling has been enabled, when he/she transmits on either frequency
A or B both transmitters will be activated at the same time.
The original aircraft transmission on frequency A only is fed to the User on the CWP where the cross coupling has been enabled. The signal received by re-transmission on any other frequency in the crosscoupling group is not fed to the user. The received transmission on frequency A is termed the
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 is heard by the controller and
retransmitted on the other frequencies. In the event that the system is unable to determine which
frequency was first received, the system normally selects one as the incoming frequency and this
selection shall be maintained until the end of that reception.
Example of 3 frequencies F1, F2, F3 cross-coupled at a CWP:
In the event of an aircraft call on F1, retransmission is operated 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. However as soon as there is
no voice signal on F1 and after a delay, cross coupling shall operate with F 2 as the incoming frequency.
The incoming voice signal F2 shall, however, always be transmitted to all CWPs with F2 selected.

38

Copyright 2014 JSP-Teleconsultancy

ATS Ground Voice Network overview

Radio features - Cross Coupling


(Retransmission)

Incoming audio received on any one of


frequencies in pre-defined cross-coupled
group (minimum 2 freq.) is retransmitted on
other freq. in group. Listeners tuned-in to one
freq.can also hear other frequencies. Function
useful for pilots in busy airspace.
Tx by CWP on any frequency in group is
transmitted on all frequencies in group. This
interrupts retransmission of any audio being
received.
2nd Incoming radio call not retransmitted until
first terminated;
Activated by each controller independent of
other controllers;
Single frequencies can be disconnected from
the group;
Duplex or Simplex retransmission can be
defined;

Produced by JSP Teleconsultancy

118.100
124.750

VCS

39

Radio features - Best Signal Selection (Rx Voting)


Best Signal Selection (Receiver Voting)

Within todays AGVN when a single frequency covers a large geographic area or where the terrain
causes radio signal shadows, it may be necessary to deploy several radio receivers over the area in order
to obtain satisfactory signal strengths for all aircraft positions.
Most VCSs allow a Best Signal Selection facility to be enabled (also known as Receiver Voting). This
makes it possible to automatically select the best signal available at any time.
Each receiver in a Receiver Voting group is presented at the CWP with its own frequency key. A visual
indication displays the frequency key of the receiver voted as having the best signal when signals are
received on the frequency, based on signal/noise ratio comparison. Some VCS suppliers only present the
best signal at any time to a single CWP frequency key.
The Receiver Voting function can usually be toggled on and off locally at each CWP. Whether the
function is activated or deactivated causes no effect at the other CWPs. When Receiver Voting is
deactivated at a particular CWP, all selected receivers are monitored. Some VCS suppliers offer
customised methods of controlling and presenting the Receiver Voting function at the CWPs.
However the main parameters today that are employed for monitoring the quality of the received signal
are listed below:

RSSI: The Received Signal Strength Indication is a measure of the energy of carrier, it is normally
expressed in dBm and a dedicated circuit measures it. This circuit outputs an electrical signal or a
numerical value proportional to the Received Signal Strength.
The RSSI can be used also for providing indications about the presence of activity on a Radio Channel.
This functionality is used in CSMA/CA (802.11) algorithm in order to check if a channel is free for
starting a transmission.
The RSSI is normally evaluated at the IF stage within the RX equipment. When there is no IF stage the
measurement is made directly in base-band level, where the DC level is proportional at the carrier
amplitude.
With modern Receivers, that include microprocessors, DSP and Ethernet connectivity, the processing
power is powerful enough to calculate the RSSI in real Time.
Giving the RSSI directly, in dBm, no scale calibration is requested and consequently the provided value
is absolute and manufacturer-independent.

C/N Ratio: The C/N ratio is measured in a manner similar to the way the signal -to-noise ratio (S/N) is
measured, and both specifications give an indication of the quality of a communications channel.
However, the S/N ratio specification is more meaningful in practi cal situations. The C/N ratio is
commonly used in satellite communications systems to point or align the receiving dish; the best dish
alignment is indicated by the maximum C/N ratio.
The C/N is specified in dB, it is the ratio between the power of the car rier of received signal and the
total received noise power. If the incoming carrier strength is Pc and the noise level is Pn, then the
carrier-to-noise ratio, C/N, in dB is given by the formula
C/N = 10 Log10 (Pc/Pn)
If the RSSI value is available, estimating the noise power in IF band, allows the calculation of the C/N
ratio in a direct way. Like the RSSI measurement, the provided value is very accurate, normally within

40

Copyright 2014 JSP-Teleconsultancy

ATS Ground Voice Network overview

Radio features - Best Signal


Selection (Rx Voting)

Sometimes wide areas or areas with signal shadows


deploy several receivers to obtain good signal
strengths for all aircraft positions.
BSS group of channels using same frequency
defined by Admin terminal; Contoller can sometimes
remove single channels from group;
Best signal -calculated on S/N ratio comparison or
signal strength.
Manual: each receiver in BSS channel group shown
at CWP with its own frequency key. Receiver with
best signal indicated on key.
Automatic: Only best signal shown on single freq.
key at any time.
BSS can be toggled ON/OFF by each controller
independent of others;
Customised methods of controlling & presenting
Receiver Voting function at CWPs possible;

Strong
Signal

Weak
Signal

VCS

S/N Ratio: The SNR is defined as the ratio between the amplitude of a signal and the amplitude of noise
in audio band. It is defined for a specific frequency (e.g., 1 kHz test tone) and for a well -specified noise
band.
The SINAD (Signal to Noise Ratio and Distortion) could be generally used instead of SNR. This is a
relationship in which the distortion of the in band signal is also considered with noise.
It is easier to perform a S/N calculation in a laboratory, where a reference signal is normally available.
In a Radio receiver or in a VCS is becomes more complicated to perform this calculation in real time.
AGC voltage: In the old AM receivers, with diode demodulation, the mean value of demodulator output
voltage was normally used to drive the Automatic Gain Control (AGC) circuit. This voltage is
proportional to the carrier amplitude.
The relationship between AGC voltage and the carrier amplitude usually isn't linear, and it depends on
the circuit employed.
Moreover, the AGC voltage trend isn't absolute and it depends on the manufacturer implementation and
on the receiver model. This behaviour can be a problem and it requires the definition of a reference
table.
Therefore, this parameter is considered the least reliable to be employed in order to implement BSS
schemes.
PSD: The Power Spectral Density estimation is another method for detecting the quality of received
signal. Using the Fast Fourier Transform algorithm, the PSD can be computed easily; this is possible by
the high processing power available in modern RTX and VCSs.
Partitioning the audio band in many sub-bands, and setting a weighting for each sub-band in function of
its importance to other bands, improves the quality information provided by PSD measure.
An example of weighting in audio band filtering is the psophometric filter (defined by ITU -T), where
the frequency response is proportional to the sensibility of the human ear.

Produced by JSP Teleconsultancy

41

Best Transmitter Selection (Transmitter Voting)


Automatic Transmitter Selection (Transmitter Voting)

Some VCSs allow a transmitter to be associated with each receiver in a Receiver Vot ing group. The
appropriate transmitter can therefore be automatically selected as the selected receiver changes. At any
time the frequency key on the CWP indicates which transmitter is currently selected.
With this functionality however an override function normally allows the transmitter to be manually
selected.
Some VCS suppliers offer customised methods of controlling and presenting the Transmitter voting
function.
This function is not used when Climax operation is employed.

Climax (off-set transmission)

It is possible to pre-configure several combinations of transmitter groups of a radio frequency channel


for parallel transmission. This feature can be used for a large area coverage with transmitters working
with frequency offset.
The CWP can manually select between transmitting on the climax transmitter groups or individual
transmitters working on the related radio frequency channel.
This function is not used when Automatic Transmitter selection is employed.

42

Copyright 2014 JSP-Teleconsultancy

ATS Ground Voice Network overview

Best Transmitter Selection (Transmitter


Voting)

Transmitter associated with each receiver in a


BSS (Receiver voting) group. Appropriate
transmitter is selected automatically as
selected receiver changes. Frequency key on
Rx
CWP indicates which transmitter currently
selected.
Tx
Group of channels configured for same
frequency defined by Admin. Terminal - for both
Tx & Rx.
VCS selects the best transmitter paired with
the voted best receiver.
BTS enabled by each controller independent of
others;
Not necessary when using climax operation.
Override function allows transmitter to be
manually selected.

Produced by JSP Teleconsultancy

Strong
Signal

Rx

Weak
Signal

Tx

VCS

43

Radio features - Multicarrier Offset Transmission (Climax)


Multi-carrier operation (CLIMAX or off-set carrier transmission)
CLIMAX is also known as Multi-carrier operation or Off-set carrier transmission is currently the only
Air-Ground Voice Communication solution to provide extended co verage beyond the inherent line of
site horizon limitation of VHF communications.. It is possible to pre -configure several combinations of
transmitter groups of a radio frequency channel for parallel transmission. This feature can be used for a
large area coverage with transmitters working with frequency offset. The CWP can manually select
between transmitting on the climax transmitter groups or individual transmitters working on the related
radio frequency channel.
The main reason for using climax is to provide adequate coverage for large and often low sectors. In
addition, climax systems are used to overcome local terrain problems (e.g. mountains) and reliability
problems.
Many en-route control frequencies are transmitted from up to 4 remote locations to r ender the coverage
as wide as possible. To eliminate the characteristic screech, known as heterodyne, when more than one
station transmits simultaneously, an offset carrier system is used. The offsets are +/ - 5 kHz for a twocarrier system, +/- 7.5 kHz and 0 kHz for a three-carrier, and +/- 7.5 kHz and +/- 2.5 kHz for a fourcarrier system.
Today, CLIMAX operation is limited to 25 kHz channel spaced environment and therefore is a limiting
factor for the deployment of 8.33 kHz channel spaced environment. The spectrum mask for an 8.33kHz
carrier has a reduced bandwidth, when compared to that of a 25 kHz carrier however. Consequently, the
classic CLIMAX operation cannot be used in an 8.33 kHz environment.
Current development work proposes that in an 8.33KHz channel spacing environment, carriers shall be
offset at plus and minus 2.5kHz from the channel centre frequency, so limiting climax to two -carrier
systems. The frequency stability of the individual offset carrier must not vary more than plus or minus 1
part per million.
Progressive decreases in sector size and the increased availability of landlines has reduced the need for
climax systems. Also the use of better transmitter locations with improved coverage has also reduced the
need for the use of Climax.
Some States are using the Best Signal Selection (BSS) facility as an alternative or compliment to
Climax. In effect this means that the VCS system chooses the best signal received from an aircraft via a
variety of receivers and only that signal is presented to the Controller for use.
Climax is not used when Automatic Transmitter selection is employed.

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.
Requirements
Time delay differences in excess of 10ms, due to the transmission of signals to different radio sites, may
result in echoes on board aircraft. In this situation the System must provide compensation so as to keep
time delay differences to within the 10ms maximum.
A variation of differential delay shall not affect voice quality of the message received.

44

Copyright 2014 JSP-Teleconsultancy

ATS Ground Voice Network overview

Radio features - Multicarrier Offset


Transmission (Climax)

Only Air-Ground Voice Communication solution to provide extended coverage


beyond line of site horizon limitation of VHF communications.
Several transmitters each transmit same radio frequency channel (parallel
transmission). To eliminate screech (heterodyne) when multiple transmissions
occur, each has frequency offset.
2-carrier system offset: +/-5 kHz
3-carrier system offset: +/-7.5 kHz & 0 kHz
4-carrier system offset: +/-7.5 kHz & +/-2.5 kHz

Used for large area coverage, large and often low sectors, to overcome local
terrain problems (e.g. mountains).
System must compensate to ensure voice delay<10ms to avoid echoes on
board aircraft.
8.33 kHz channel spacing, carrier spectrum has reduced bandwidth w.r.t 25
kHz. New 2-carrier system offset: +/-2.5kHz being developed for 8.33
Smaller sector sizes, increased landline availability, use of better transmitter
locations with improved coverage has reduced need for climax systems.
Best Signal Selection (BSS) used as alternative or compliment to Climax.
Climax is not used when Automatic Transmitter selection is employed.

Produced by JSP Teleconsultancy

45

Stepped-on radio transmissions (1)


Simultaneous Radio Transmissions (Stepped-on or Double Transmissions)
These may involve:

simultaneous transmission on the same frequency from two aircraft or

simultaneous transmission on the same frequency from an aircraft and ATC.

The transmissions interfere with each other, "blocking" both signals.


Also it should be noted that if frequencies are coupled in a Cross-coupled group by a Controller, stepped-on
transmissions of two simultaneous VHF signals on different frequencies can also occur.
A controller will recognise that a stepped-on transmission has occurred only in the following two cases:

The transmissions from two pilots reach the ground receiver with either the same field intensity or a
difference of up to 6dB. The controller will hear a mixture of the two transmissions.

The Transmission times of the two pilot transmissions do not entirely overlap. The controller will hear
the first transmission for an few seconds, then a mixture of both followed by the second transmission
for a few seconds.

A controller will not recognise that a stepped-on transmission has occurred in the following two cases:

The weaker signal of the two pilot transmissions (>6 dB difference) lies entirely within the time period
of the stronger signal. This is known as the capture effect.

Frequencies are coupled in a Cross-coupled group at the Controller position and the pilot makes a
transmission on a coupled frequency while the Controller is transmitting to frequencies in the crosscoupled group.

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.

The incoming signal on Rx F1 will be re-transmitted on Tx F2. As Rx F2 is normally located 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.
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.
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).
This functionality SHOULD be pursued in future ground receivers and all other associated system components
46

Copyright 2014 JSP-Teleconsultancy

ATS Ground Voice Network overview

Stepped-on radio transmissions (1)


Two or more transmissions occur, simultaneously, on same frequency.
Case 1 Two Frequencies F1 and
F2 in Cross-Coupled Mode
TxF1
Audio from
F1 received
first

RxF1
Cross
coupling
active

TxF2

Controller will not be


aware of the aircraft
calling on Rx F2.
Rx F2 will receive the
re-transmitted signal
with high signal strength.

RxF2

Case 2 One Ground Receiver

Audio from
strong
Signal only

Controller unaware of
presence of another
aircraft call.

Recommendation:
Receivers SHOULD include
functionality to detect if 2 or
more transmissions are
present on same nominal
frequency at same time.
A message SHOULD be sent
to VCS producing a warning
indication at CWP.

TxF1

RxF1
Stronger signal suppresses
weaker in the receiver.

* The expression 'Nominal Frequency' is used to indicate that a numerical value is not necessarily the precise
frequency being used

Produced by JSP Teleconsultancy

47

Stepped-on radio transmissions (2)


Case 3a- Ground receivers each detect different signals of simultaneous transmission
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 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

Case 3b-- Ground receivers each detect both signals of simultaneous transmission
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.

48

Copyright 2014 JSP-Teleconsultancy

ATS Ground Voice Network overview

Stepped-on radio transmissions (2)


Case 3a Ground receivers each
detect different signals of
Tx1 F1
simultaneous transmission
Audio from
Best Voted
only

Rx1 F1

Tx2 F1

Each aircraft call


only received
by one receiver.

2nd aircraft call muted by BSS


Controller unware of presence of
2nd aircraft call
Rx2 F1
Case 3b Ground receivers each
detect both signals of
Tx1 F1
simultaneous transmission
Audio from
Best Voted
(+the other
added?)

Rx1 F1

Tx2 F1

Each aircraft call


received by
both receivers.

Controller maybe unaware


of presence of another
aircraft call.
Rx2 F1

Produced by JSP Teleconsultancy

Recommendation:
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 controller mixed
with 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 2
radio stations. (Next slide)
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

49

Stepped-on radio transmissions (3)


Case 4 Simultaneous Pilot-Controller transmission
A pilot and a controller transmit on the same frequency

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 receivers ability to detect this situation is very similar to Case 1 Two Frequencies f1 and F2 in CrossCoupled 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).

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

Main/Standby Radio switchover


Main/Stand-by switching
Todays Main/Standby Radio Switching infrastructures within the AGVN normally allow the following
two possibilities for main/standby switching of radio equipment.

50

Local switching with separate radio lines: Two separate leased lines are used to connect the
two separate Radio interfaces within the VCS to two radios at the remote radio site. This
improves resilience in the case of line failure. The switching between the Main and Standby
Radio is performed locally at the VCS. This can be configured to either have:
o

two frequency keys configured at the CWP (hence providing Main and Standby Radio
Coverage for each frequency), each able to access a different r adio but using the same
frequency;

or just one frequency key programmed, with Main or Standby selection being
performed manually at the CWP or System admin terminal or automatically by the VCS
in the case of leased line failure.

Remote switching over a common radio line: One leased line connects the VCSs Radio
Interface with the Remote Radio Site containing the two radios. A Main -Standby changeover
switch situated at the remote radio site is controlled from the CWP. The CWP has a facility to
toggle between the two remote radios. The frequency key indicates which of the remote radios
is currently selected.

Copyright 2014 JSP-Teleconsultancy

ATS Ground Voice Network overview

Stepped-on radio transmissions (3)


VOTING

.
Leg 1 voted
1

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.

Strength 3

Strength 2

3
Strength 2

New Aircraft call


added at full strength

300ms
Aircraft call

1 sec

2 sec

Case 4 Simultaneous Controller


Pilot Transmission
Controller hears their
own voice by either:
1. Local sidetone
Or
2. Off-air sidetone

Recommendation:
Receivers SHOULD include
functionality to detect if 2 or
more transmissions are
present on same nominal
frequency at same time.
A message SHOULD be sent
to VCS producing a warning
indication at CWP.

TxF1

Controller will not hear aircraft call during


their own transmission

RxF1

Main/Standby Radio switchover

Main/Standby changeover on Radio failure either performed by equipment


at Remote Radio site (requires one radio interface and one line/channel
per Main/Standby Radio);
VCS1

RCE

Radio
1,3 or 30 circuits/chan
interface

Main

Radio
interface

Standby

Or performed locally at VCS side using a separate Radio interface,


circuit/channel for Main and Standby Radios; More resilience.
VCS1

RCE
1,3 or 30 circuits/chan

Radio
interface

Radio
1,3 or 30 circuits/chan
interface

Radio
interface

Radio
interface

Main

Standby

Produced by JSP Teleconsultancy

51

Sunset dates for analogue & digital leased lines


SUNSET DATES FOR ANALOGUE AND DIGITAL LEASED LINES
A high proportion of European ANSPs rely on their TELCOs to provide them with analogue or digital
leased lines.
The Universal Service Directive 2002/22/ECArticle 18 defines a minimum set of leased lines that have
to be provided by all European TELCOs. This stated that national regulatory authority shall impose
obligations regarding the provision of the minimum set of leased lines, as identified in the list of
standards published in the Official Journal of the European Communities in accordance with Article 17
of Directive 2002/21/EC (FrameworkDirective)
However a COMMISSION DECISION of 21 December 2007 amended the previous decision
2003/548/EC and has now deleted 2W/4W analogue leased lines, 64kbps digital leased lines and E1
digital leased lines from the Minimum Set of Leased Lines published in the Official Journal of the
European Communities.
Deleted analogue leased lines include:
Ordinary quality voice bandwidth - 2 wire: ETSI EN 300 448
Ordinary quality voice bandwidth - 4 wire: ETSI EN 300 451
Special quality voice bandwidth - 2 wire: ETSI EN 300 449
Special quality voice bandwidth - 4 wire: ETSI EN 300 452
Deleted digital leased lines include:
64 kbit/sETSI EN 300 288ETSI EN 300 289
2 048 kbit/sE1 (unstructured) ETSI EN 300 418ETSI EN 300 247
2 048 kbit/sE1 (structured) ETSI EN 300 418ETSI EN 300 419

Analogue circuits, (e.g. 4W E&M) are becoming difficult to order and are also becoming very
expensive as they are supported by obsolete technology. Furthermore in some situations, maintenance is
not guaranteed. In very near future, all analogue (2 wires and 4 wires) circuits will no longer be
provided by TELCOs. TELCOs clients are being informed, TELCOs shall continue to maintain the
service for a limited number of months until all such lines are disconnected.
Wide area analogue will be available till 2010. Local (within the range of a PSTN HUB) analogue will
be available till 2012.
Digital circuits: E1/2Mbps trunks will be disconnected within the next 5 years. E1 (TDM based real
time connections) will be provided over packet switched technologies (MPLS, Ethernet link etc) . In
these situations specific technical solutions shall be developed and applied to not degrade the initial real
time connectivity. In some States, E1/2Mbps trunks are provided only for Official State institutions
(aviation, military, governmental) and the terminal equipments have to be maintained by the user. Some
ANSPs own and maintain their SDH/PDH Equipment.
64k circuits For the medium term, two to three years, the digital sub -rates of 64kbps will be
discontinued. Wide area digital trunks smaller than 2 Mbit/swill be available till 2010. Local digital
trunks smaller than 2 Mbit/swill be available till 2012.
In the case the ANSP owns their SDH/PDH Equipment, the SDH/PDH infrastructure guarantee to
support 64k interface for the whole live time of their current VCS. It is expected that cost effectiveness
and eventually the availability of 64k and E1 leased lines will decline.

52

Copyright 2014 JSP-Teleconsultancy

ATS Ground Voice Network overview

Sunset dates for analogue & digital


leased lines
EC has removed from the Minimum set of leased lines the
following analogue and digital leased lines, making their
supply by Telecom operators no longer mandatory;

Ordinary quality voice bandwidth: 2 wire: ETSI EN 300 448 and 4 wire: ETSI EN 300 451
Special quality voice bandwidth: 2 wire: ETSI EN 300 449 and 4 wire: ETSI EN 300 452
64 kbit/s: ETSI EN 300 288 and ETSI EN 300 289
2 048 kbit/s: E1 (unstructured) ETSI EN 300 418 and ETSI EN 300 247
2 048 kbit/s:E1 (structured) ETSI EN 300 418 and ETSI EN 300 419

Sunset dates: analogue: 2010, 64k: 2010-2012, E1:2015-2019

Produced by JSP Teleconsultancy

53

Next Generation ICAO 9896 VoIP


interfaces for ATS Ground Voice Network
- Part 1

54

Copyright 2014 JSP-Teleconsultancy

EUROCAE Working Group 67

3. EUROCAE Working Group 67

Produced by JSP Teleconsultancy

55

What is EUROCAE?
EUROPEAN ORGANISATION for CIVIL AVIATION EQUIPMENT (EUROCAE)
EUROCAE, the EUROPEAN ORGANISATION for CIVIL AVIATION EQUIPMENT is a non-profit
making organisation which was formed at Lucerne (Switzerland) in 1963 to provide a European forum for
resolving technical problems with electronic equipment for air transport.
EUROCAE deals exclusively with Aviation standardization (Airborne and Ground Systems and Equipment) and
related documents as required for use in the regulation of aviation equipment and systems. EUROCAE has
extended its activity from airborne equipment to complex CNS/ATM systems including their ground segment.
EUROCAE is an association composed of members who are all specialized in one of several technical fields of
Aeronautics and many of them are considered to be among worlds leaders in the domain.
These members include Equipment and Airframe Manufacturers, Regulators, European and International Civil
Aviation Authorities, Air Navigation Service Provider (ANSP), Airlines, Airports and other users.
To develop EUROCAE Documents (ED), EUROCAE organises Working Groups (WGs) where members
provide experts working on a voluntary basis. In general the WG members come from the association
membership but others may be accepted under specific conditions regarding the organisation they are belonging
to and their particular expertise.
EUROCAE is governed by a Constitution and functions according to procedures resulting from more than 43
years experience in the development of aviation standards.
The EUROCAE structure includes:

56

A General Assembly of members representatives who elect each year the President of the Association
and the Council Members. In addition, budget strategy and other important decisions (such as
Constitutional amendments) may be submitted to the ballot of the General Assembly.

A council composed of between 8 and 20 members (presently 19) nominated from the EUROCAE
membership and elected at the General Assembly. Council Members are sponsored by their
organisations. The main tasks of the Council are to discuss and to decide on the creation or the closing
down of WGs, the approval of the EUROCAE strategic plan, the WGs objectives and the publication of
the completed EDs

A Technical Advisory Committee composed of 12 members appointed by the council, each of them
specialising in a specific technical domain. The main tasks of the Technical Advisory Committee are to
conduct studies regarding the creation of new WGs, including the definition of their objectives, and to
prepare the Technical Work program, both being used to advise and support the Council in its
decisions.

A General Secretariat, composed of salaried staff, which is in charge of the administration of


EUROCAE. It reports to the EUROCAE council through the Secretary General.
The Secretary General attends the Council where it assumes the secretarial tasks and is member of the
technical advisory committee.

Copyright 2014 JSP-Teleconsultancy

EUROCAE Working Group 67

What is EUROCAE?
EUROPEAN ORGANISATION for CIVIL AVIATION
EQUIPMENT: non-profit making organisation founded in
1963 in Lucerne (Switzerland) as European forum for
resolving technical problems with electronic equipment for
air transport.
Today deals with development of technical Aviation
standards for Airborne, Ground Systems and Equipment.
Members include Equipment, Airframe Manufacturers,
Regulators, European and International Civil Aviation
Authorities, ANSPs, Airlines, Airports and other users
Working Groups/Sub-groups formed in order to achieve
effective standardisation framework in Europe through
development of relevant ED docs. Members provide
experts on a voluntary basis.

Produced by JSP Teleconsultancy

57

EUROCAE Working Group 67 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 (WG67) 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.

EUROCAE WORKING GROUPS


The primary tasks of working groups are to prepare performance specifications and similar documents that may
be adopted as standards by the aviation industry.
These standards are often referenced by the Aviation Authorities or International Organisations. They are most
frequently Minimum Operational Performance Specifications (MOPS) or Minimum Aviation System
Performance Specifications (MASPS), although User Guides and other advisory material are also developed.
The EUROCAE council is responsible for approving the establishment of new Working Groups (WGs) and for
the definition of their work programmes, taking account of submissions made by any aviation stakeholder and in
particular EUROCAE members. The Council reviews and approves all documents prior to their publication.
The General Secretariat monitors the WGs activities.
EUROCAE WG 67 Voice Over IP protocol for ATM
WG67 was tasked to developed ED documents related to VoIP for ATM. This group analysed the situation
regarding operational and technical Air-Ground (A/G) and Ground-Ground (G/G) ATM voice system
requirements in the new context of voice and data convergence into one multi-media network using the
capability of Voice over Internet Protocol (VoIP) technology. WG67 has developed a technical specification of
an IP Voice ATM system for G/G ATM communications and for the G/G segment of A/G communications.
Four Sub-groups (SG1 to SG4) were created to perform the work of WG67.
The first meeting was held in March 2004 and was attended by VCS, Radio, Recorder, Network equipment
suppliers and ANSPs. The WG67 Terms of Reference (ToR) were approved by the EUROCAE COUNCIL on
July 2004. The Group had several meetings per year during which technical issues were discussed and
resolutions agreed to by participants. A major amount of the work was performed between meetings by
participating WG67 companies and ANSPs on a voluntary basis. Several draft ED documents were produced
and periodically underwent updates, modifications and additions in order to obtain a common consensus from
all participating companies

58

Copyright 2014 JSP-Teleconsultancy

EUROCAE Working Group 67

EUROCAE Working Group 67


background
EUROCAE council started Working Group 67 tasked to
develop ED documents related to VoIP for ATM.
To analyse situation regarding operational & technical A/G
and G/G ATM voice system requirements in new context of
voice & data convergence into one multi-media network
using VoIP technology with the high level of safety required
for ATM-related communications
To developed technical specification of an IP Voice ATM
system for G/G ATM communications and for the G/G
segment of A/G communications. Four Sub-groups (SG1 to
SG4) were created to perform the work of WG67.
First meeting held in March 2004 in Paris;
Attended by VCS, Radio, Recorder vendors, ANSPs,
Eurocontrol, VoIP infrastructure suppliers etc,

Produced by JSP Teleconsultancy

59

WG67 Mission Statement


The following tasks were identified to fulfil the WG67 mission:
Define ATM Systems and identify their components (Voice Communication System,
Ground Radio Station, Recording equipment, System Supervision etc)

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;

Interoperability requirements between IP components of the VoIP ATM system;

Minimum performance requirements of an IP Network to support ATM Voice services;

Guidelines for qualification tests of VoIP ATM systems and their components.

The bodies participating in the EUROCAE Working Group 67 included:

Equipment Manufacturers
ATIS, CS COMMUNICATION and SYSTEMES, FREQUENTIS, INDRA SISTEMAS, NUCLEO, PARK AIR
SYSTEMS-UK, PARK-AIR-SYSTEMS-Norway, ROHDE & SCHWARZ, SAAB communication, SCHMID
TELECOM, SELEX OTE SpA, SITTI, TELERAD, THALES-AS, THALES-NO, TOPEX, INEO,
Air Navigation Service Providers:
AENA, AUSTROCONTROL, BELGACONTROL, DFS, DSNA, ENAV, LVNL, NATS, ROMATSA
Telecom Equipment Infrastructure Manufacturers
CISCO, NORTEL
European Organisation for the Safety of Air Navigation
EUROCONTROL
United States Federal Aviation Administration
FAA
Global Air Transport Industry Network Provider
SITA

60

Copyright 2014 JSP-Teleconsultancy

EUROCAE Working Group 67

WG67 Mission Statement

Define ATM Systems & identify their components (VCS, GRS, Recording
equipment, Gateways, System Supervision etc)
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:
Minimum performance & safety/security requirements for the system and, if
appropriate, for components;
Interoperability requirements between IP components of the VoIP ATM
system;
Minimum performance requirements of an IP Network to support ATM Voice
services;
Guidelines for qualification tests of VoIP ATM systems and their
components.

Produced by JSP Teleconsultancy

61

The Vienna Agreement


The contents of all EUROCAE ED documents are premised on the Vienna Agreement which defines the
different components of a VoIP ATM system and their mutual interfaces as depicted in the Slide.
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, 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.

62

Copyright 2014 JSP-Teleconsultancy

EUROCAE Working Group 67

The Vienna Agreement


Define IP Voice ATM Systems and identifies their components:
Voice Communication Systems (VCS);
Ground based Radio Station (GRS)
Recording

Produced by JSP Teleconsultancy

63

ED deliverables
EUROCAE WG67 Specifications
The following series of EUROCAE documents have now been developed by WG67:
ED-136 VoIP ATM System Operational and Technical Requirements This document defines a series of
high level Telephone, Radio, Recorder interface requirements plus supervision requirements.
ED-137B Interoperability Standards for VoIP ATM Components This document is now defined in the
following 5 volumes (nominated edition B) and replaces the previous ED-137A, published in September 2010.
1. ED-137B Interoperability Standard for VOIP ATM Components Volume 1: Radio:
This volume for Radio Interoperability defines Audio, SIP signalling procedures, R2S-Keepalive protocol,
RTP procedures as well as management procedures to be employed between VCS and Remote Radios
and/or FAA Remote Radio Gateway Equipment in order to achieve complete radio functionality over a
private ATS- IP network.
2. ED-137B Interoperability Standard for VOIP ATM Components Volume 2: Telephone:
This volume for Telephone Interoperability defines Audio and SIP-SIP signalling procedures in order to
achieve complete telephone functionality over a private ATS-IP network.
3. ED-137B Interoperability Standard for VOIP ATM Components Volume 3: European Legacy
Telephone Interworking
This volume defines SIP ATS-QSIG telephone gateway signalling procedures, SIP-ATS MFC-R2
telephone gateway signalling procedures, SIP ATS No.5 telephone gateway signalling procedures in order
to achieve complete telephone functionality interworking with a private ATS-IP network.
4. ED-137B Interoperability Standard for VOIP ATM Components Volume 4: Recording:
The volume for Recording Interoperability defines a profile standard for the use of RTSP to establish,
terminate and modify recording sessions of the Ground Telephone Service and the Radio Service in an Air
Traffic Services Ground Voice Network (AGVN).
5. ED-137B Interoperability Standard for VOIP ATM Components Volume 5: Supervision:
This volume for Supervision System Interoperability defines a centralized system capable to perform
supervision and monitoring tasks of several components involved in the Voice Communications System for
Air Traffic Services.
The ED-137B edition of the document represents the minimum specification required for Vendors and ANSPs
to assure Interoperability between VoIP ATM Radio Components. EUROCAE WG67 has updated the previous
ED-137A and created ED-137B in 5 volumes that replace ED-137A.
Volume 1 Radio and Volume 2 Telephone replace the previous Part 1 Radio and Part 2 Telephone referenced in
ICAO document 9896. ED-137B update has been achieved:
1. Following a series of interoperability events, performed by many vendors in Arlington in May 2011
improving ED-137 concerning the understanding of interoperability requirements between the ATM VoIP
components,
2. Following discussions with FAA for taking into account US requirements agreeable within the European
context.
3. Following publication of the EUROCONTROL VoIP in ATM Test Case Specifications.
ED-138 Network Requirements and Performances for VoIP ATM Systems. This document specifies the
technical requirements and capabilities of network services - including IP Addressing and Security - that are to
provide the necessary high levels of availability, integrity, performance and Quality of Service (QoS) for VoIP
in ATM applications.

64

Copyright 2014 JSP-Teleconsultancy

EUROCAE Working Group 67

Produced by JSP Teleconsultancy

65

ICAO ACP WG-I consideration of EUROCAE ED docs


The EUROCAE COUNCIL through their Technical Advisory Committee originally reviewed and approval of
WG67 ED-136, 137 and 138 documents in February 2009 and they were published by EUROCAE in August
2009.
Following a series of recommendations following Interoperability events in 2010 and a 1 st set of FAA
recommended updates to satisfy FAA requirements also in 2010, the ED-137 Part 1 Radio and Part 2 Telephone
were updated during 2010 and a new document nominated ED-137A that gained EUROCAE council approval
in September 2010.
Following the FAA VoIP Interoperability Event held in Arlington, Virginia in May 2011, the development of a
series of FAA addendum documents for FAA OVR call specification, FAA RRC equipment interface
specification and the FAA addendum for Recording and Event logging as well solutions relating to a Dynamic
delay compensation mechanism for Climax systems and Definition of a basic set of VoIP monitoring and
control messages between VCS and Radio defined by VOTE subgroups EUROCAE executed an update of the
interoperability standards, producing ED-137B in the following 5 volumes:
1. ED-137/1 Interoperability Standard for VOIP ATM Components Volume 1: Radio
2. ED-137/2 Interoperability Standard for VOIP ATM Components Volume 2: Telephone
3. ED-137/3 Interoperability Standard for VOIP ATM Components Volume 3: European Legacy
Telephone Interworking
4. ED-137/4 Interoperability Standard for VOIP ATM Components Volume 4: Recording
5. ED-137/5 Interoperability Standard for VOIP ATM Components Volume 5: Supervision.
The ED-137B documents were approved by the EUROCAE council in January 2012 and replaced the existing
ED-137A documents.
The task of developing new SARPs and guidance material for VoIP is being undertaken by the ICAO
Aeronautical Communications Panel WG-I. The ICAO WG-I have the task of making recommendations into the
ICAO SARPs for support of VoIP for aeronautical communications. This working group has the scope of
defining the best way forward for implementing the necessary applications over the ATN/IPS. They have
developed the ICAO manual for the Aeronautical Telecommunications Network (ATN) using the Internet
Protocol Suite (IPS) standards and Protocols (Doc 9896). The first edition of the nominated ICAO Doc 9896)
manual. was issued in February 2009. The material in this document is to be considered in conjunction with the
relevant Standards and Recommended Practices (SARPs) as contained in Annex 10, Volume III, and Part 1
Chapter 3.
The ICAO Manual for the ATN using IPS Standards and Protocols is divided into the following parts:

Part I Detailed Technical Specifications:


This part contains a general description of ATN/IPS. It covers the network, transport and security
requirements for the ATN/IPS.

Part II Application Support:


This part contains a description of applications supported by the ATN/IPS. It includes convergence
mechanisms and application services that allow the operation of legacy ATN/OSI applications over the
ATN/IPS transport layer.

Part III Guidance:


This part contains guidance material on ATN/IPS communications including information on
architectures, and general information to support ATN/IPS implementation.
EUROCONTROL presented the EUROCAE WG67 ED documents to the ICAO ACP WG-I with the scope of
having the documents referenced within the second edition of ICAO manual for the ATN using IPS standards
and Protocols (Doc 9896). In May 2010 agreement that ED-137A Part 1 Radio and Part 2 Telephone would be
reference in Part I- Detailed Technical Specification section following EUROCAE council approval of the
updated ED-137A document (integrating the ETSI Plugtests and FAA recommendations). It was agreed that the
EUROCAE ED-136, ED-138 and ED-137A Part 3 (Recording) and Part 4 (Supervision) as well as Parts 2A, 2B,
2C (legacy interworking) would be included in Part III Guidance.
Following approval of the ED-137B Volumes in January 2012, containing the European and FAA additions and
updates, it is expected that Volumes 1 and 2 will now be cited in Part I Detailed Technical Specifications of the
ICAO 9896 document, replacing the Parts 1 and 2 previously cited.

66

Copyright 2014 JSP-Teleconsultancy

EUROCAE Working Group 67

The WG-I agreed that Volume 3-European Telephone Interworking, Volume 4-Recording and Volume 5Supervision as well as ED-136-Requirements and ED-138-Network will be cited in Part III-Guidance material
of the ICAO 9896 document.
With the citing of the EUROCAE ED-137B Volume 1 -Radio and Volume 2-Telephone documents within the
ICAO 9896 document, it will lead to their adoption as an international recommendations following approval by
the ICAO Secretary General.

Produced by JSP Teleconsultancy

67

Next Generation ICAO 9896 VoIP


interfaces for ATS Ground Voice Network
- Part 1

68

Copyright 2014 JSP-Teleconsultancy

Voice over Internet Protocol functionality

4. Voice over Internet Protocol functionality

Produced by JSP Teleconsultancy

69

What is Voice over IP?


Voice over IP
Voice over Internet Protocol (VoIP) or Voice over IP is the term used to describe various technologies and
applications for transporting and setting up voice and multimedia calls over an Internet Protocol (IP) based
packet switched data network instead of the traditional dedicated circuit switched telephone transmission lines.
Internet telephony refers to communications services voice, facsimile, and/or voice-messaging
applications that are transported via the Internet, rather than the public switched telephone network (PSTN).
The basic steps involved in originating an Internet telephone call are conversion of the analog voice signal to
digital format and compression/translation of the signal into Internet protocol (IP) packets for transmission over
the Internet; the process is reversed at the receiving end.
Although Voice over IP can refer to Voice Over Internet using web conferencing and Internet telephony
applications, this course uses the Voice over IP term to imply Voice over Intranet or Private Networks which
allow more control on Quality of Service parameters and can be used for Multimedia calls and IP Telephony.
In particular the course will examine Voice over IP, its influence on the future Voice Communication
Systems (VCSs) and its application in a future AGVN.
Voice over IP technologies have been emerging these last years as an alternative to the traditional voice
switching technologies based on circuit switching TDM (Time Division Multiplexing) or analogue
communication networks. Initially it was thought that the main interest of this technology was to provide lowcost voice channels through the Web. However nowadays it is recognised that Voice over IP technologies
are mature and supported by both traditional PBX suppliers and network switching equipment suppliers through
specific business applications merging voice and data such as call-centre systems or through multimedia
conference services.
Voice is converted into digits in such a way that it can be broken down into packets.

70

Each packet represents a brief snatch of voice

If one packet is lost (there is little point repeating it), it will then not completely disrupt ongoing
communication

Requires specifically tailored voice encoders/decoders

Copyright 2014 JSP-Teleconsultancy

Voice over Internet Protocol functionality

What is Voice over IP?


Term used to describe various technologies and applications for
transporting and setting up voice and multimedia calls over an
Internet Protocol (IP) based packet data network (instead of circuit
switched network);
Voice over IP can refer to Voice Over Internet using web
conferencing & Internet telephony applications
This course uses Voice over IP term to imply Voice over Intranet
or Private Networks which allow more control on Quality of
Service parameters and can be used for Multimedia calls and IP
Telephony.
Voice converted into digital signal and broken down into packetsEach packet represents a brief snatch of voice
If a packet is lost, there is no point in repeating it as this will
disrupt the ongoing communication

Produced by JSP Teleconsultancy

71

Packet switched connections


Packet switching is a digital network communications method that groups all transmitted data irrespective of
content, type, or structure into suitably-sized blocks, called packets. Packet switching features delivery of
variable-bit-rate data streams (sequences of packets) over a shared network.
Two major packet switching modes exist; connectionless packet switching, also known as datagram switching,
and connection-oriented packet switching, also known as virtual circuit switching. In the first case each packet
includes complete addressing or routing information. The packets are routed individually, sometimes resulting
in different paths and out-of-order delivery. In the second case a connection is defined and preallocated in each
involved node before any packet is transferred. The packets includes a connection identifier rather than address
information, and are delivered in order.
A packet is a unit of data that is transmitted across a packet-switched network. A packet-switched network is
an interconnected set of networks that are joined by routers or switching routers. The most common packetswitching technology is TCP/IP, and the Internet is the largest packet-switched network.
The concept of a packet-switched network is that any host connecting to the network can, in theory, send
packets to any other hosts. The network is said to provide any-to-any service. The network typically consists of
multiple paths to a destination that provide redundancy. Packets contain header information that includes a
destination address. Routers in the network read this address and forward packets along the most appropriate
path to that destination. When traversing network adapters, switches, routers and other network nodes, packets
are buffered and queued, resulting in variable delay and throughput depending on the traffic load in the network.
Routers run routing protocols to discover neighbouring routers and the networks attached to them. These
protocols let routers exchange information about the network topology as it changes due to new or failed links.
The Internet and all IP networks are fundamentally connectionless datagram networks. A datagram is a packet
formed at the network layer in the Internet protocol suite. In this context, a packet is either a full datagram or a
fragment of a datagram (a datagram that has been split into multiple smaller pieces to comply with size
restrictions on some networks). A connectionless network provides no end-to-end delivery guarantees. No
connection is set up to track and guarantee packet deliveries, nor do network routers maintain any sort of state
about a packet flow between sender and receiver (virtual circuits).
However, TCP does provide these services if they are needed. End systems can use TCP to set up connections
and track packet deliveries. The recipient uses TCP to acknowledge packet receipt. Unacknowledged packets
are retransmitted by the sender.
The advantage of the connectionless packet model is that packets are forwarded independent of other packets.
Packets are forwarded on-the-fly by routers, based on the most current best path to a destination. If a link or
router fails, packets are quickly diverted along another path. Since routers don't maintain information about
virtual circuits, their job is greatly simplified. In contrast, ATM and frame relay networks are connection
oriented. A virtual circuit must be established between sender and receiver across the network before packets
(cells or frames, respectively) can start to flow. One reason the Internet has scaled so well is that there is no need
to build virtual circuits for the millions of flows that cross the network at any one time. Routers simply forward
packets along the best path to the destination. However, in the interest of speed and QoS, virtual circuits are
being implemented on the Internet by using protocols such as MPLS (Multiprotocol Label Switching).
Packet switching contrasts with another principal networking paradigm, circuit switching, a method which sets
up a limited number of dedicated connections of constant bit rate and constant delay between nodes for
exclusive use during the communication session. In case of traffic fees, for example in cellular communication,
circuit switching is characterized by a fee per time unit of connection time, even when no data is transferred,
while packet switching is characterized by a fee per unit of information.
Packets have a header and a data area. The header holds address and routing information. Think of a packet as
an envelope in which the destination address is written on the outside of the envelope and data goes inside.
A single transmission may require hundreds or thousands of packets-for example, a large file is broken up into
many small pieces that are inserted in the payload area of packets. This scheme helps overcome transmission
problems. If a glitch occurs, only one packet may be affected. Then it is only necessary to retransmit that one
packet rather than the entire file.

72

Copyright 2014 JSP-Teleconsultancy

Voice over Internet Protocol functionality

Packet switched connections


Data is broken down into packets
Each packet is sent individually
Labelled with from, to and a
sequential identifier
Routed from one end to the
other by a number of routers which forward the packet to the
most appropriate point
Connectionless -Route taken can vary
Connection Orientated (Virtual circuit) Route is pre-fixed
Reliable delivery service - Recipient checks that all sequential
data has been received and can request missing data to be resent (however not used for time critical data like voice).

In relation to the OSI protocol model, packets are formed in the network layer and passed down to the data link
layer, where they are encapsulated into the frames of the underlying network. Frames cross a single point-topoint link between network devices, while packets cross multiple router-connected links. In other words, frames
are isolated to a single link, while packets are envelopes for delivering data across internetworks. Packets are
broken up into frames for delivery across a network; but, when the frames reach the next router, the packet
information is examined by the router and a decision is made about how to forward the packet across the next
link.
Packet-switched networks use multiplexing principles. Packets from multiple sources can traverse links and
routers in an interleaved fashion. In fact, a single host can establish multiple simultaneous sessions that transmit
packets across the same link. For example, you can open two Web browsers and connect to two different Web
sites at the same time. The packets from both connections are interleaved across the link. When compared to
dedicated leased-line circuits, packet-switched networks use bandwidth efficiently. The network is shared by
many users who generally keep the pipe full. Leased lines, in contrast, use TDM (time division multiplexing),
which can waste bandwidth by reserving time slots for data even when there is no data to send.
Packet-switched networks have been called networks of queues. Packets arriving on a link are pushed into
buffers and queued up for processing. The router figures out where to forward the packets and pushes them into
an appropriate outgoing queue. The problem is finding the right buffer size. Small buffers drop packets, while
large buffers may cause excessive delays as packets wait in line for processing (input) or transmission (output).
A single host can saturate a router with a burst transmission, blocking other users and causing congestion.
Therefore in an IP network Congestion Control Mechanisms and Prioritization of Network Traffic are important
in order to guarantee the expected quality of service to the end user.

IETF RFC 791 (Internet Protocol, September 1981)

IETF RFC 793 (Transmission Control Protocol, September 1981)

Produced by JSP Teleconsultancy

73

Packet Transport Efficiency


Packet switching is the now-dominant communications method, in which packets are individually routed
between nodes over data links, which might be shared by many other nodes. This contrasts with circuit
switching which sets up a dedicated connection between the two nodes for their exclusive use for the
duration of the communication.
Packet switching is used to optimize the use of the bandwidth available in a network, to minimize the
transmission latency (i.e. the time it takes for data to pass across the network), and to increase the
robustness of communication.
The slide illustrates the use of Packet switched technology to transport different applications or media (i.e.
Voice, Legacy, LAN and video) over a single WAN link. Each application has its data encapsulated in
packets, each with its own header indicating its destination before being placed into queues prior to being
routed. In the packet multiplexing of IP network, the bandwidth is shared by the media, thereby improving
line usage efficiency and reducing communication costs. Packets are sent over the same link respecting the
bandwidth requirement needed by each application.
For example a real time video application would have its packets sent in bursts, while a real time voice
application would send packets at a constant rate only when an audio signal is present. Non-real time Data
applications would use up any spare bandwidth over the link not being used for the Video or Voice
applications.
With a packet transport method, no bandwidth resources are used unless traffic is present. More flexible
pricing, based on actual traffic carried is possible. When providing services with bandwidth guarantees, a
packet transport should be able to emulate the circuit-based mesh in that a defined minimum bandwidth can
be allocated between any pair of nodes. However, unused bandwidth should be made available to other
flows in a dynamically shared fashion so that a flow can opportunistically exceed its minimum.
Statistical multiplexing (i.e. Packet Switching) is an "on-demand" service rather than one that pre-allocates
resources for a transmission link. The transmission capacity of the link will be shared by only those users
who have packets.
Statistical multiplexing ensures that bandwidth will not be wasted (whereas TDM can waste slots).
Due to all applications sharing the same bandwidth for transmission, bandwidth can become scarce leading
to congestion during periods of heavy traffic. Congestion management is therefore required to guarantee
sufficient bandwidth for all real time and non-real time applications.
The utilization of the overall bandwidth of a Packet transport system is more efficient and is calculated at
between 90 and 95%.

74

Copyright 2014 JSP-Teleconsultancy

Voice over Internet Protocol functionality

Packet Transport Efficiency


Types of Traffic

Utilization

Voice

Legacy

9095%

LAN

PBX

Q
U
E
U
E
Cells/Frames/Packets

Video

Individual Packets

Media share bandwidth;


High bandwidth efficiency;
Congestion management needed.

Produced by JSP Teleconsultancy

75

IP Core Network
IP Core Network development phases
The development of IP network has gone through three phases in recent years:
In Phase 1 (before 2001), IP network could only provide simple connectivity. In this phase, there was little
diversity in services, and there were few key services. The network mainly carried E-mail, file transfer,
information declaration and other data services, and the data transmitted were mainly text and picture
information. The network just made its best effort to transmit services. Access control could be performed for
services or users, and differentiated service was not possible.
In Phase 2 (about 2001-2004), IP networks enhanced capabilities of access control and user management. In this
phase, IP networks gradually broke away from the simple and extensive developing mode. Technologies of
operability and manageability have made the edge network more intelligent to some extent, but they could not
completely solve those problems that are becoming more and more salient such as QoS, security, reliability and
service management.
In phase3 (2004-), the IP network is developing with the aim of "providing high quality service". With the fast
development of IP network technologies and services, services carried by the network are more and more
diversified, and there are more and more key services. In terms of service type, voice, video and data services
can all be borne by the IP network. Different services have different demands for QoS, security and reliability,
which requires that the IP networks should be capable of differentiated high quality service. Therefore, QoS,
security, reliance, service performance and scalability and service management become the key demands of the
network.

Five essential features of an IP core network


1. High performance of service and scalability
For the IP core network, traditional parameters such as network capacity and performance are the basic
demands. For example, current IP core networks usually deploys 10G/2.5Gbps and other high speed links, and
switching capacity of the core nodes has exceeded 500Gbps, sometimes it even reaches the level of Tbps.
However, the IP core network also entails high performance of service, of course, not only high performance of
IP transmission.
Furthermore, as the development of new services and new technologies are very fast, powerful capability of
scalability is required on the IP core network so as to keep the capacity and performance up to date. On the one
hand, capacity and bandwidth are upgrading and updating rapidly, the IP core network should be capable of
hardware upgrading and expansion to protect customers' investment. On the other hand, new services and new
technologies are emerging every day, which requires the IP core network to be capable of evolution of service.
2. High quality service
High quality service is to solve the QoS. The IP core network can bear a variety of services, including multimedia services such as IP telephony, video conference, IPTV, and data services such as file transfer, E-mail,
WWW and online games. From the point of view of QoS, different services have different demands for such
key parameters as bandwidth, delay, jitter, and error/packet loss rate. IP telephony and video conference are
sensitive to delay and jitter (delay<150ms, jitter<10ms). Data services are not sensitive to delay, but they have
high demand for reliance of network transmission (low packet loss rate). Here the network intelligence is no
longer simply access control and tagging. It is now represented in dynamic awareness of service, guarantee of
network resources (such as CPU resource of Nodes equipment, Buffer, and bandwidth), and dynamic
adjustment of network resources. Dynamic awareness of service is the basis of QoS policy and security policy.
The flow of this process is as follows: the edge devices of the IP core network triggers awareness of a specific
service as per the feature of the traffic flow, flow tagging and the threshold of flow statistics. Service awareness
can be performed by edge node independently or in combination with the system management system. In this
way, overall deployment of policies is facilitated. As new services are emerging constantly, the edge node of the
IP core network should have powerful capability of intelligent processing and service flexibility. Moreover, the
network is in constant changes. Addition of new services or increase of traffic flow often occurs in the network.
This requires that the IP core network should be capable of dynamic adjustment of bandwidth. For example,
when a new service is added, the IP core network may allocate an independent tunnel or dynamically adjust the
LSP bandwidth to reserve some resources for the new service; when the traffic of a certain service is growing to
exceed the planned threshold, the IP core network may dynamically adjust the bandwidth allocated to this
service.

76

Copyright 2014 JSP-Teleconsultancy

Voice over Internet Protocol functionality

IP Core Network

IP Core Network

To end user,
Other Network,
Content Provider

IP Access
Network

Routers

In addition to the bandwidth, the real-time services including video conference and IP telephony also have a
requirement on other parameters such as low delay and low delay jitter. These parameters mainly depend on the
powerful capability of hardware queue schedule by the IP core network. Besides, some key services are
sensitive to packet loss. Solution of this problem will depend overall scheduling provided by the IP core
network. The self-recovery technology of <50ms path can also minimize the number of lost packets caused by
fault in the network as well.
3. High Security of Service
The IP core network is required to implement safe separation on different services and allocate independent
logic networks for them so as to avoid interference from each other. The combination of MPLS VPN, VLAN,
QinQ and other technologies can divide a physical enterprise network into multiple independent "logic
networks", and each type of service can obtain a part of the network resources for use, including address space,
routing forward table, bandwidth, tunnel and QoS. The edge node of the IP core network
can automatically identify services and map them into different VPNs.
4. High reliability of service
Reliability of service depends on reliability of IP core network. With the increase of key services in the network,
the importance of the network reliability has gained weight. On the network level, the IP core network should be
capable of self-recovery of <50ms links and paths. Resilient link technologies can realize self-recovery of 50ms
link. IP/MPLS fast rerouting can realize self-recovery of network paths or tunnels of 50ms.
5. Manageability and optimization of service
Management has always been the weak part of IP network, and is a problem that the high quality IP network
should solve. First, management of the IP core network should be realized, which includes network management
and service management. Though management, the network will be capable of constant optimization.
Service management includes VPN management, QoS management and security management. VPN
management divides a physical network into multiple logic service networks (VPNs) and can allocate network
resources specifically for each VPN. QoS management consists of such parts as QoS deployment, service

Produced by JSP Teleconsultancy

77

performance monitoring and traffic engineer management. It cooperates closely with VPN so as to provide
reliable end-to-end service. Security management mainly involves user access control and security
policy management. Though service management system, service deployment and daily maintenance can be
easily carried out conveniently, and optimization of resource allocation can be conveniently adjusted.

Next Generation IP core


The next generation IP core network will be a comprehensive high quality network based on IPv6. After IPv6
technology is introduced, the security, QoS, system management and capacity of the IP core network will be
farther improved. Nonetheless, the process of evolution from IPv4 network to IPv6 network will continue for
several to more than ten years. In the meanwhile, the IP core network needs to bear IPv4 and IPv6 traffic.
Therefore, it will be a basic requirement for the IP core network devices to support IPv4/IPv6 and various
technologies of transition.

78

Copyright 2014 JSP-Teleconsultancy

Voice over Internet Protocol functionality

This page is intentionally blank.

Produced by JSP Teleconsultancy

79

Voice over IP deployed in Corporate Networks


Corporate Networks Using VoIP
The public IP network is a best-efforts one, so it can be a problem to handle voice signals that require real-time
processing. Measures are needed to prevent situations that may degrade voice quality, such as delay, jitter, and
packet loss, which are not problems in conventional TDM networks.
The ultimate objective of VoIP on the public internet is reliable, carrier-grade high-quality voice service already
offered by the PSTN. At the moment, however that level of reliability and sound quality is not available on the
public Internet, primarily because of bandwidth limitations that lead to packet loss. In voice communications,
packet loss is observed in the form of periods of silence in the conversation, leading to a clipped-speech effect
that is unsatisfactory for most users and unacceptable in business communications.
With advances in VoIP technology, the router can nowadays prevent voice packets from being delayed or
discarded. The VoIP gateway unit can absorb jitter, i.e., variations in the packet arrival times. Its echo canceller
can remove undesired echoes caused by delay.
Corporate enterprises prefer not to use the public internet for their communication needs. VoIP still has some
problems with reliability and sound quality, due primarily to limitations both in Internet bandwidth and current
compression technology. As a result, most corporate enterprises looking to reduce their phone bills today
confine their Internet-telephony applications to their intranets. With more predictable bandwidth available than
the public Internet, intranets can support full-duplex, real-time voice communications. Corporate enterprises
generally limit their public Internet voice traffic to half-duplex asynchronous applications (e.g. voice
messaging).
Corporate enterprises wishing to save communication costs by employing intranets are using Voice over IP
gateways in order to ensure interworking with their existing TDM infrastructures. Todays VoIP Gateways are
able to handle hundreds of simultaneous calls. Eventually the corporate enterprises will shift from a TDM
network infrastructure to an IP network infrastructure able to transport all their voice, data and video
conferencing applications.
IP is an attractive choice for voice transport for several reasons, these include:
o Lower equipment cost
o Lowering operating expense
o Integration of voice and data applications
o Potentially lower bandwidth requirements
o Widespread available of VoIP
Packet based systems obey Moores law which states that Processing power doubles roughly every 18
months, which is a much faster pace of development than we see with traditional circuit-switched systems
quoted as 7 years.

80

Copyright 2014 JSP-Teleconsultancy

Voice over Internet Protocol functionality

Voice over IP deployed in


Corporate Networks
Public IP network is best-effort one - problem to
guarantee real-time voice signal processing. Voice
quality degraded by delay, jitter & packet loss;
Corporate Intranets (private IP networks) use leased
lines, bandwidth can be guaranteed and QoS levels
defined;
Voice over IP gateways ensure interworking with
existing TDM infrastructures;
Migration from TDM to IP networks transporting all
applications (Voice, data & video conferencing);

Produced by JSP Teleconsultancy

81

Signalling in an IP ATS Ground Voice Network


Signalling in an IP AGVN SHALL be based on the Session Initiation Protocol (SIP) (RFC 3261).
SIP is an application-layer transaction protocol that provides advanced signalling and control functionality for a
large range of multimedia communications. SIP is an important component in the context of other protocols to
enable a complete multimedia architecture, as shown in the slide.
In addition to the SIP signalling functionality it is assumed that the IP AGVN components also include the
following functionality:

one or more physical interfaces on the IP network side supporting, through layer 1 and layer 2
protocols, IP as the network layer protocol and UDP (RFC 768) and TCP (RFC 793) as transport layer
protocols, these being used for the transport of SIP signalling messages and, in the case of UDP, also
for media information;

the support of TLS (RFC 4346) as additional transport layer secure protocol on the IP network side,
this being used for the transport of SIP signalling messages; and

a means of transferring media information.

Interworking with ATS Legacy Systems


The SIP environment SHALL need to interwork with ATS-R2/ATS-QSIG-based AGVN in order to support
calls originating in one environment and terminating in the other. Interworking with ATS-No.5-based AGVN is
RECOMMENDED.
Interworking is achieved through gateways. The term Gateway is used in the present document, within the
context of a call, as an entity that performs interworking between one signalling system and another. This
definition is specifically applied here to interworking between the following signalling systems:
SIP vs. ATS-R2
SIP vs. ATS-No.5
SIP vs. ATS-QSIG
This covers all scenarios for incoming gateway calls from legacy circuit-switched AGVN to SIP on a packetswitched IP AGVN. Likewise, it covers all scenarios for outgoing gateway calls from SIP in a packet-switched
IP AGVN to legacy circuit-switched AGVN. The functionality required for the different gateways has been
defined in accordance with the Vienna Agreement to guarantee interoperability between IP components of IP
Voice ATM systems and the current non-IP voice ATM systems.

The use of signalling tunnelling 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, comes outside of the original Vienna
Agreement and, therefore, is outside the scope of the ED 137 Telephone document..
Audio Specifications
The audio transport SHALL be supported by the real-time transport protocol (RTP) (RFC 3550), augmented by
its associated control protocol (RTCP) to allow monitoring of the audio packets delivery.
The Voice SHALL be coded in accordance with ITU-T Rec. G.711 A-law (in Europe) or -law (in USA/Japan)
coding. If compression is needed ITU-T Rec. G.728 (LD-CELP) MAY be used without Packet Loss
Concealment or the ITU-T Rec.G.729 (CS-ACELP).
For interoperation with ATS-QSIG, ITU-T G.728 (LD-CELP) SHALL NOT be transcoded, but forwarded to
avoid codec transcoding losses; in this case, ITU-T G.728 SHOULD be used end-to-end.

82

Copyright 2014 JSP-Teleconsultancy

Voice over Internet Protocol functionality

Signalling in an IP ATS Ground


Voice Network
Application and System Control
Interworking function

SIP Suite
Supplementary Services
(Intrusion, Instantaneous Access, Call hold, Conference)

ATS-QSIG

ATS-No.5

ATS-R2

RTCP
Basic SIP
+ Extension headers
+ Added Methods
+ Message Body (SDP)
TCP/TLS

Audio
coding
functions

RTP
UDP

IP
IP network lower layers

Produced by JSP Teleconsultancy

83

How is Voice Transported over an IP network?


The voice is sampled by the selected codec and a whole series of samples are placed within a voice packet
payload. A Voice packet payload can have a number of different periods (i.e. 20ms, 30ms, 40ms, 50ms, 60ms,
70ms, 80ms or 90ms) The longer the payload duration, obviously the more voice samples it contains. Packet
payloads of longer duration (i.e. 80ms or 90ms) can have seriously negative effects if they are lost in transition
across the network between the endpoints. A series of lost packets can give the effect of voice clipping.
The packet of voice samples in the payload is encapsulated with an RTP header and then passed to the
Transport layer (Layer 4) to be encapsulated within a User Datagram Protocol (UDP) header. The UDP is an
unreliable method of transporting the packets over the network, because lost packets or received errored packets
are just ignored but UDP ensures that they are transported end-to-end without excessive delays in order that
there is sufficient time to re-generate the original voice signal at the receive side within the end-to-end latency
limits for Real Time Voice.
The encapsulated RTP/UDP voice packet is then passed to the IP layer (Layer 3) to be encapsulated within the
Internet Protocol (IP) header.
The encapsulated RTP/UDP/IP voice packet is then passed to Layer 2 and then to Layer 1 for transmission over
the network.
It is therefore possible to say that voice is transported over RTP/UDP/IP, each with their own header attached to
the voice samples contained within the packets payload.
The RTP header size is 12 octets. The UDP header is 8 octets while the IPv4 header is 20 octets. This implies
that for every packet there is a 40 octet (or 40 x 8 =360 bit) overhead of headers attach to it. In the case of large
packet payloads (i.e. 80ms or 90ms) the extra bandwidth required to transport the packets over an IP network is
reduced. Likewise in the case of small packet payloads (i.e. 20ms or 30ms) the extra bandwidth required to
transport the packets over an IP network is increased.
It is possible to perform a calculation in order to determine the equivalent bandwidth required by an TDM
encoded voice stream when sent over the IP network.
For example using the G.711 PCM 64kbps codec with a voice sampling rate of 0.125ms. A 20ms packet
payload can contain 20ms/0.125=160 samples.
20ms packets imply 50 packets per second.
50 packets per second x 360 bit overhead per packet = 16000 bits per second overhead.
A 64kbps TDM voice signal would therefore require 64kbps + 16kps = 80kbps when sent over the IP network.
It is possible to perform Header compression cRTP on the headers which results in a 40 octet overhead being
reduced to just 4 octets.

84

Copyright 2014 JSP-Teleconsultancy

Voice over Internet Protocol functionality

How is Voice Transported over an


IP network?
Voice samples from coder placed in RTP payload (i.e packets
containing 20ms to 90ms of voice);
Encapsulated with RTP header, then UDP header, then IP header;
RTP ensures real time delivery, UDP is unreliable transport service (lost
or errored packets ignored) used for real time applications, IP delivers
packets between endpoints.
Equivalent bandwidth to send TDM voice streams over IP network can
be calculated (i.e. PCM 64kbps becomes 80kbps over IP network)
20 bytes

40 bytes
8 bytes

IP header

UDP header

12 bytes

RTP header

RTP payload

Produced by JSP Teleconsultancy

85

Example- Voice Transport over an IP Network

86

Copyright 2014 JSP-Teleconsultancy

Voice over Internet Protocol functionality

Example- Voice Transport over an


IP Network
APP

APP
RTP

RTP
Header

UDP

UDP
RTP
Header Header

IP
Layer
2

RTP
Header

RTP

UDP
RTP
Header Header

UDP

UDP
RTP
IP
Header Header Header

UDP
IP
RTP
Header Header Header

Layer
UDP
RTP
IP
Header Header Header 2

Layer
IP
UDP
RTP
Header Header Header 2

Core

LAN
Layer
1
Edge

IP
Layer
2
LAN
Layer
1

Edge

IP Network

Produced by JSP Teleconsultancy

87

Why IP version 6?
IPv6 for the ATS domain
Following the initiative of the EUROCONTROL IPAX task force and the airline industry in general, the
EUROCAE working group 67 have also decided that the IP address scheme to be adopted by the ATS
VoIP environment will be IPv6 address scheme. Migration of international-links within the AGVN
towards VoIP according to the EUROCONTROL Communication Strategy is forecast to take place from
2011 onwards. Widespread commercial adoption of IPv6 should be taking place from 2008 -2012.
IPv4 was initially standardized in 1981. As the Internet became ubiquitous, the inherent IPv4 QoS, security,
addressing, and scalability capabilities were pushed to their limit. These deficiencies, as well as new network
services, exacerbated the strain placed on IPv4 technology and its quest to accommodate the global needs for
Internet services. To continue using IPv4 under this load required that new features and capabilities be
developed, standardized, and bolted on. This approach would have been costly, risky, and difficult to
manage. This resulted in the development of a next generation networking protocol IPv6. IPv6 was designed to
overcome the limitations of IPv4 by:

Expanding available IP address space to accommodate future demand

More efficient addressing design and handling at the IP network layer

Improving QoS to minimize packet loss/drops

Operating over greater bandwidths for video conferencing and Voice over IP (VoIP) applications

Enhancing end-to-end security, which is critical for ATM applications

Enabling more granularity and flexibility in message dissemination to individuals and groups

Establishing a plug and play capability for installing devices in an IPv6 network

Providing more robust network management on an enterprise scale

Eliminating the need for network address translation (NAT)

Incorporating a compact base header structure, which expedites packet routing less frequently used
options are relegated to extension headers
There are many vendors offering IPv6 product lines that are often bundled with router and operating system
offerings on the market

As ATM communication services proliferate domestically and internationally, its connectivity


and communications capabilities need to become more robust and scalable. IPv6 is an industrystandard solution that can support such growth in communication demand and geographical
scope.
The key reason of deploying IPv6 is due to the current IPv4 deployments between ANSPs
which have extensive IP address domain overlaps making the use of inter-WAN IPv4 too
complex

The IPv6 address scheme (uses 128 bits) and therefore has a vastly increased address range. This scheme
will allow every telephone, PC, PDA and Mobile phone to eventually have its own personal IP address.
Within the ATS environment it will therefore also allow Contr oller Working Positions and VoIP
Gateways to be assigned a globally unique IP address of their own.
In other words, the theoretical number of hosts that can be connected to the Internet for the two
protocols are as follows:
IPv6 : IPv4 = 2128:232 IPv6 address is 296 times IPv4 address

But as far as routing is considered (IPv6 Host ID is 48bit), the ratio is:
48

32

IPv6 : IPv4 = 2 :2

IPv6 address is 2

16

times IPv4 address

This indicates that IPv6 address space is not as infinite as some people suggest, al though it is
considerably larger than IPv4 address space.

88

Copyright 2014 JSP-Teleconsultancy

Voice over Internet Protocol functionality

Why IP version 6?
WG67 have chosen IPv6 to eventually replace IPv4;
Increases Address space: IPv4 - 32 bits (4 billion addresses) while
IPv6 - 128 bits (216 more addresses than IPv4); permanent
address assignment to end devices.
Compact Header, faster packet routing, options now in header
extensions;
Enhanced end-to-end security, critical for ATM;
Improved QoS support to minimize packet loss/drops;
Allows plug-&-play capability for installing devices;
Provides more robust network management on enterprise scale;
Ensures future compatibility with Airline industry, ICAO, FAA,
NASA etc

Produced by JSP Teleconsultancy

89

IPv6 Packet Header Fields


IPv6 Packet header field structure
The IPv6 header is, surprisingly, less complicated than the IPv4 header and substantially improves functionality
while reducing complexity.
The length of an IPv4 packet's header varies, and thus requires the use of a header length field. IPv6 uses 40
bytes in an eight-field header. A fixed-length header makes it much easier for routers to process the packet.
Three of the fields are the same in both versions:

Version (4 bits) is used to tell routers what protocol is in use; the default is 6.

Source address and destination address (128 bits each) are the IPv6 addresses of the sending and
destination hosts.

The other five fields in the IPv6 header are new.

90

The traffic class field (8 bits) allows devices to differentiate between latency-sensitive traffic (like
video and voice) and low-priority data (like email and Web traffic). There are several groups currently
developing ways to best utilize this field, with the Differentiated Services project currently in the lead.

The flow label field (20 bits) can be used by a host to request special handling from IPv6-compliant
routers. The ability to manage flows -- traffic between end stations -- is important in providing quality
of service. This field allows IPv6 to operate in a manner similar to the IPv4 leader in flow management,
Multiprotocol Label Switching.

The next header field (8 bits) alerts routers about additional headers that need to be examined. While
the IPv6 header's length is fixed, the protocol can add other headers to the main header. These
additional headers provide features such as source routing, encryption, and authentication.

The payload length field (16 bits) describes the length in octets of the payload (data) portion of the
IPv6 packet. The 16-bit field length (2^16) lets version 6 support payloads in excess of 64,000 octets.

The hop limit field (8 bits) specifies the number of routing hops a packet can take before being
discarded. Hop limits provide routing loop protection and keep packets from circulating indefinitely. At
8 bits, this field allows for a maximum of 255 hops, though in today's networks a path would not likely
be that long.

Copyright 2014 JSP-Teleconsultancy

Voice over Internet Protocol functionality

IPv6 Packet Header Fields


IPv6 = 40 byte header
0

IPv4 = 20 byte header


0
VERS

16

19

HLEN SERVICE TYPE


IDENTIFICATION

TIME TO LIVE

24

12

31

24

NEXT
HEADER

HOP LIMIT

SOURCE IP ADDRESS

FLAGS FRAGMENT OFFSET

...

HEADER CHECKSUM

...

SOURCE IP ADDRESS

...

DESTINATION IP ADDRESS

DESTINATION IP ADDRESS

IP OPTIONS (IF ANY)

31

FLOW LABEL

PAYLOAD LENGTH

TOTAL LENGTH

PROTOCOL

16

VERS TRAFFIC CLASS

PADDING

DATA

...
...

...

...

Extension headers
Modified field for IPv6

...

data

Deleted field for IPv6

Increased address space


Built in support for QoS, Mobile IP, Security, Auto-configuration
Upgrades to protocols and processes (e.g.. Neighbour Discovery)

Produced by JSP Teleconsultancy

91

User Datagram Protocol (UDP)


The User Datagram Protocol (UDP) is a minimal message-oriented transport layer protocol that is currently
documented in IETF RFC 768. It is one of the core protocols of the Internet protocol suite. Using UDP, network
applications running between clients and servers can send short messages known as datagrams to one another.
UDP does not provide the reliability and ordering guarantees that TCP does; datagrams may arrive out of order
or go missing without notice. However, as a result, UDP is faster and more efficient for many lightweight or
time-sensitive purposes. Also its stateless nature is useful for servers that answer small queries from huge
numbers of clients.
UDP provides unreliable transport across the Internet. It is a best-effort delivery service, since there is no
acknowledgement of sent datagrams. Most of the complexity of TCP is not present, including sequence
numbers, acknowledgements, and window sizes. UDP does detect errored datagrams with a checksum. It is up
to higher layer protocols, however, to detect this datagram loss and initiate a retransmission if desired.
UDP provides a very simple interface between a network layer below and an application layer above. UDP
provides no guarantees for message delivery and a UDP sender retains no state on UDP messages once sent onto
the network. UDP adds only application multiplexing and transactive, header and data check summing also
found in a TCP header on top of an IP datagram. If any kind of reliability for the information transmitted is
needed, it must be implemented in upper layers.
The UDP header consists of only 4 header fields of which two are optional. The source and destination port
fields are 16-bit fields that identify the sending and receiving process. Since UDP is stateless and a UDP sender
may not solicit replies, the source port is optional. If not used, the source port should be set to zero. The port
fields are followed by a mandatory length field indicating the length in bytes of the UDP datagram including the
data. The minimum value is 8 bytes. The remaining header field is a 16-bit checksum field covering the header
and data. The checksum is also optional, but is almost always used in practice.
Lacking reliability, UDP applications must generally be willing to accept some loss, errors or duplication. Most
often, UDP applications do not require reliability mechanisms and may even be hindered by them. Streaming
media, real-time multiplayer games and Voice over IP (VoIP) are examples of applications that often use UDP.
If an application requires a high degree of reliability, a protocol such as the Transmission Control Protocol or
erasure codes may be used instead.
Lacking any congestion avoidance and control mechanisms, network-based mechanisms are required to
minimize potential congestion collapse effects of uncontrolled, high rate UDP traffic loads. In other words,
since UDP senders cannot detect congestion, network-based elements such as routers using packet queuing and
dropping techniques will often be the only tool available to slow down excessive UDP traffic. The Datagram
Congestion Control Protocol (DCCP) is being designed as a partial solution to this potential problem by adding
end host congestion control behaviour to high-rate UDP streams such as streaming media.
While the total amount of UDP traffic found on a typical network is often on the order of only a few percent,
numerous key applications use UDP, including the Domain Name System (DNS), the simple network
management protocol (SNMP), the Dynamic Host Configuration Protocol (DHCP) and the Routing Information
Protocol (RIP), to name just a few.

92

Copyright 2014 JSP-Teleconsultancy

Voice over Internet Protocol functionality

User Datagram Protocol (UDP)


Transport layer: Provides unreliable transport across the
Internet; Defined by IETF RFC 768
Less complex than TCP;
Small Header-Source port, destination port, length and UDP
checksum;
Doesnt use sequence numbers, acknowledgements, flow
control with window;
Uses checksum to detect errored datagrams.
Used by VoIP to carry actual voice traffic;
Sends packets independent of Packet Loss rate;

Produced by JSP Teleconsultancy

93

Real-time Transport of Voice using RTP


Real-Time Transport Protocol was developed to enable the transport of real-time packets containing voice,
video, or other information over IP. RTP is defined by IETF RFC 3550. RTP does not provide any quality of
service over the IP network RTP packets are handled the same as all other packets in an IP network. However,
RTP allows for the detection of some of the impairments introduced by an IP network, such as:
Packet loss
Variable transport delay
Out of sequence packet arrival
Asymmetric routing
RTP is an application layer protocol that uses UDP for transport over IP. RTP is not text encoded, but uses a bitoriented header similar to UDP and IP. The current RTP version 2 packet header is shown in the slide. RTP was
designed to be very general; most of the headers are only loosely defined in the standard; the details are left to
profile documents. The 12 octets are defined as:

Version (V): This 2-bit field is set to 2, the current version of RTP.

Padding (P): If this bit is set, there are padding octets added to the end of the packet to make the packet
a fixed length. This is most commonly used if the media stream is encrypted.

Extension (X): If this bit is set, there is one additional extension following the header (giving a total
header length of 14 octets). Extensions are defined by certain payload types.

CSRC count (CC): This 4-bit field contains the number of content source identifiers (CSRC) are
present following the header. This field is only used by mixers that take multiple RTP stream and
output a single RTP stream.

Marker (M): This single bit is used to indicate the start of a new frame in video, or the start of a talkspurt in silence-suppressed speech.

Payload Type (PT): This 7 bit field defines the codec in use. The value of this field matches the profile
number listed in the SDP.

Sequence Number: This 16-bit field is incremented for each RTP packet sent and is used to detect
missing/out-of-sequence packets.

Timestamp: This 32-bit field indicates in relative terms the time when the payload was sampled. This
field allows the receiver to remove jitter and to play back the packets at the right interval assuming
sufficient buffering.

Synchronization Source Identifier (SSRCI): This 32-bit field identifies the sender of the RTP packet.
At the start of a session, each participant chooses a SSRC number randomly. Should two participants
choose the same number, they each choose again until each party is unique.

CSRC Contributing Source Identifier: There can be none or up to 15 instances of this 32-bit field in the
header. The number is set by the CSRC Count (CC) header field. This field is only present if the RTP
packet is being sent by a mixer, which has received RTP packets from a number of sources and sends
out combined packets. A non-multicast conference bridge would utilize this header.

RTP allows detection of a lost packet by a gap in the Sequence Number. Packets received out of sequence can
be detected by out-of-sequence Sequence Numbers. Note that RTP allows detection of these transport related
problems but leaves it up to the codec to deal with the problem. For example, a video codec may compensate for
the loss of a packet by repeating the previously received video frame, while an audio codec may play
background noise for the interval. Variable delay or jitter can be detected by the TImestamp field. A continuous
bit rate codec such as PCM will have a linearly increasing Timestamp. A variable bit rate codec, however,
which send packets at irregular intervals, will have an irregularly increasing Timestamp which can be used to
play back the packets at the correct interval.

94

Copyright 2014 JSP-Teleconsultancy

Voice over Internet Protocol functionality

Real-time Transport of Voice using


RTP
Defined by RFC 3550 (July 2003);
Defines end-to-end delivery service for real time applications (i.e.
voice and video);
Runs on top of UDP and IP;
Includes: payload type identification; sequence numbering; time
stamping (to calculate packet interarrival time - jitter) & delivery
monitoring;
Supports unicast and multicast;
Works with Real Time Control Protocol (RTCP), which provides
feedback of quality of received connection;

CC: No. of Content source identifiers


SEQ No.: Of packet
V: Version
M:Marker (new video frame or talk spurt) Timestamp: When payload sampled
P:Padding
SSRO: Random No. Assoc.with sender
X: Extension PT: Payload Type-Codec used

RTP supports Unicast and Multicast methods. Unicast is the sending RTP packets from one source to one
destination, whereas multicast is sending of RTP packets from one sender to multiple receivers. With multicast
each receiver indicates if they want to receive the data.

RTP header timestamp


The R2S Keepalive-packets + RTP audio packets SHALL be sent as one RTP stream. For this reason there
SHALL be only one SSRC and an incrementing timestamp during transitions from R2S-Keepalive packets to
RTP Audio packets and vice versa.
Some RTP protocol stacks require the mandatory use of an incrementing timestamp and will reject a session if
the timestamp is not providing an increasing value.
Correlation of the timestamp to a UTC source is not in line with RFC3550 which states that "If RTP packets are
generated periodically, the nominal sampling instant as determined from the sampling clock is to be used and
not
a
reading
of
the
system
clock.
Unless the sampling clock is directly derived from the UTC source, UTC source SHALL NOT be used for time
stamping RTP packets.
The timestamp generation method SHALL be defined as follows:

RTP audio packets sent from VCS or GRS endpoints SHALL employ an incrementing timestamp value
equal to the number of voice samples in the voice packet interval.
Example for ITU-T G.711 PCM codec
Voice Samples=Packet Duration/Sampling rate =20ms/0.125ms =160 voice samples
Example for ITU-T G.729 ADPCM codec
Voice Samples=Packet Duration/Sampling rate =20ms/10ms =1 voice sample

R2S-Keepalive packets sent from VCS or GRS endpoints SHALL employ an incrementing timestamp
value equal to the equivalent number of voice samples in a R2S-Keepalive period

Example for ITU-T G.711 PCM codec


Produced by JSP Teleconsultancy

95

Voice Samples=R2S-KeepalivePeriod /Sampling rate =200ms/0.125ms =1600 voice samples


Example for ITU-T G.729 ADPCM codec
Voice Samples=R2S-KeepalivePeriod/Sampling rate=200ms/10ms=20 voice samples
Two RTP audio packets followed by two R2S-Keepalive packets when using the ITU-T G.711 PCM codec
would therefore have the following ascending timestamp values:
160
320
1920
3520
Two RTP audio packets followed by two R2S-Keepalive packets when using the ITU-T G.729 ADPCM codec
would therefore have the following ascending timestamp values:
1
2
22
44

96

Copyright 2014 JSP-Teleconsultancy

Voice over Internet Protocol functionality

This page is intentionally blank.

Produced by JSP Teleconsultancy

97

RTP Media Streams


RTP Sessions
Separate RTP sessions are established for each media stream. In the case of a video conference for example,
one RTP session will be established for the Real time transport of voice and a second RTP session will be used
for the video.
When an RTP session is initiated, an application defines one network address and two ports for RTP and RTCP.
If there are several media formats such as video and audio, a separate RTP session with its own RTCP packets is
required for each one. Other participants can then decide which particular session and hence medium they want
to receive.
Overall RTP provides a way in which real-time information can be transmitted over existing transport and
underlying network protocols. With the use of a control protocol, RTCP, it provides a minimal amount of
control over the delivery of the data. To ensure however, that the real-time data will be delivered on-time, if at
all, RTP must be used in conjunction with other mechanisms and / or protocols that will provide a reliable
service.
An RTP session is the association among a set of participants communicating with RTP. For each participant,
the session is defined by a particular pair of destination transport addresses (one network address plus a port pair
for RTP and RTCP). The destination transport address pair may be common for all participants, as in the case of
IP multicast, or may be different for each, as in the case of individual unicast network addresses plus a common
port pair.
In a multimedia session, each medium is carried in a separate RTP session with its own RTCP packets. The
multiple RTP sessions are distinguished by different port number pairs and/or different multicast addresses.

SSRC, Synchronization source.


The source of a stream of RTP packets, identified by a 32-bit numeric SSRC identifier carried in the RTP header
so as not to be dependent upon the network address. All packets from a synchronization source form part of the
same timing and sequence number space, so a receiver groups packets by synchronization source for playback.
Examples of synchronization sources include the sender of a stream of packets derived from a signal source
such as a microphone or a camera, or an RTP mixer. A synchronization source may change its data format, e.g.,
audio encoding, over time. The SSRC identifier is a randomly chosen value meant to be globally unique within
a particular RTP session. A participant need not use the same SSRC identifier for all the RTP sessions in a
multimedia session; the binding of the SSRC identifiers is provided through RTCP. If a participant generates
multiple streams in one RTP session, for example from separate video cameras, each must be identified as a
different SSRC.

98

Copyright 2014 JSP-Teleconsultancy

Voice over Internet Protocol functionality

RTP Media Streams


Separate RTP session for each media stream
Application

Application
Session 1 (audio)

RTP1

port x

RTP1
RTP2

UDP

RTP2
Session 2 (video) port y
UDP

IP
Physical

IP
Control messages
Stream Data

Physical

Network

Produced by JSP Teleconsultancy

99

What is the Session Initiation Protocol (SIP)?


What is the Session Initiation Protocol (SIP)?
SIP was developed at the Columbia University and first entered the VoIP scene in September 1999. Today it is
being widely adopted as the industry standard in VoIP protocols.
The Session Initiation Protocol (SIP) is a signalling protocol used for establishing sessions in an IP network. A
session could be a simple two-way telephone call or it could be a collaborative multi-media conference session.
The ability to establish these sessions means that a host of innovative services become possible, such as voiceenriched e-commerce, web page click-to-dial, Instant Messaging with buddy lists, and IP Centrex services.
Over recent years, the Voice over IP community has adopted SIP as its protocol of choice for signalling. SIP is
an RFC standard RFC3261 from the Internet Engineering Task Force (IETF), the body responsible for
administering and developing the mechanisms that comprise the Internet. SIP is still evolving and being
extended as technology matures and SIP products are socialised in the marketplace.
SIP is an IETF application layer protocol for establishing, manipulating, and tearing down sessions. SIP's main
purpose is to help session originators deliver invitations to potential session participants wherever they may be.
SIP has been developed purely as a mechanism to establish sessions, it does not know about the details of a
session, it just initiates, terminates and modifies sessions. This simplicity means that SIP scales, it is extensible,
and it sits comfortably in different architectures and deployment scenarios.
SIP is a request-response protocol that closely resembles two other Internet protocols, HTTP and SMTP (the
protocols that power the World Wide Web and email); consequently, SIP sits comfortably alongside Internet
applications. Using SIP, telephony becomes another web application and integrates easily into other Internet
services. SIP is a simple toolkit that service providers can use to build converged voice and multimedia services.
Reusing Existing Protocols - SIP was designed to specifically reuse as many existing protocols and protocol
design concepts. For example, SIP was modelled after HTTP, using URLs for addressing and SDP to convey
session information.
Maximizing Interoperability - SIP was also designed so that it would be easy to bind SIP functions to existing
protocols and applications, such as e-mail and Web browsers. SIP does this by limiting itself to a modular
philosophy - just like many other Internet protocols - and focusing on a specific set of functions.
SIP follows a flexible approach, as it uses a wide variety of protocols, each addressing a different aspect of the
problem space. The advantage is the ability to choose from among many competing technologies and move to
newer and better ones as they emerge. This has always been the philosophy behind SIP and this is the approach
of the IETF to IP telephony in general.
SIP is an important piece of this modular approach to IP telephony protocols. SIP addresses the need for a
protocol to deal with generalized sessions. This involves finding potential call participants and contacting them
as they move from place to place, changing their location and the even equipment they are using. Calls may
require the use of multiple streams of various media, and very large numbers of participants might be involved
in a call - and even joining and leaving in a constantly changing topology.
SIP provides four basic functions.
[1] SIP allows for the establishment of user location (i.e. translating from a user's name to their current
network address).
[2] SIP provides for feature negotiation so that all of the participants in a session can agree on the features to
be supported among them.
[3] SIP is a mechanism for call management - for example adding, dropping, or transferring participants.
[4] SIP allows for changing features of a session while it is in progress. All of the other key functions are
done with other protocols.
SIP is not a session description protocol; it does not do conference control. SIP is not a resource reservation
protocol and it has nothing to do with quality of service (QoS). SIP can work in a framework with other
protocols to make sure these roles are played out - but SIP does not do them. SIP can function with SOAP,
HTTP, XML, VXML , WSDL, UDDI, SDP and an whole abundance of other acronyms.

100

Copyright 2014 JSP-Teleconsultancy

Voice over Internet Protocol functionality

What is the Session Initiation


Protocol (SIP)?
Powerful and simple application layer signalling protocol
(RFC 3261) used to establish, manipulate and terminate
multimedia sessions (i.e. audio, video, conferences,
messaging etc) between users as they move around network
&/or change end-user device;
Doesnt care about the session detail itself;
Modelled on HTTP using email style addressing & Session
Decription Protocol (SDP) to convey session info;
Uses Domain Name system (DNS) and email style
addressing;
Leaves other protocols to describe sessions, do conf. control,
reserve resources, perform QoS etc;
Has ability to turn VoIP network into a true IP comms network;

Produced by JSP Teleconsultancy

101

SIP History
SIP was originally developed by the IETF Multi-party Multimedia Session Control Working Group, known a
MMUSIC. Version 1.0 was submitted as an Internet draft in 1997. Its invention is attributed to M. Handley, H.
Schulzrinne, E. Schooler, and J. Rosenberg.
Significant changes were made to the protocol and resulted in a second version (2.0), submitted as an Internet
draft in 1998. The Protocol achieved Proposed Standard status in March 1999 and was published as RFC 2543
in April 1999. In September 1999, the SIP working group was established by the IETF to meet the growing
interest in the protocol. An Internet draft containing bug fixes and clarifications to SIP was submitted in July
2000 and referred to as RFC 2543 bis. This document was eventually published as RFC 3261, which replaces
the original RFC 2543 specification. In addition, several SIP extension RFC documents have been published.
The popularity of SIP in the IETF has lead to the formation of other SIP-related working groups. The Session
Initiation Protocol INvestiGation (SIPPING) working group was formed to investigate applications of SIP,
develop requirements for SIP extensions, and publish best current practice (BCP) documents about the use of
SIP. This working group also publishes SIP event package RFCs. The SIP for Instant Messaging and Presence
Leveraging Extensions (SIMPLE) working group was formed to standardize related protocols for presence and
instant messaging applications. Other working groups that make use of SIP include PSTN and Internet
Internetworking (PINT) working group and Service in the PSTN/IN requesting Internet Services (SPIRITS)
working group.
To advance from Proposed Standard to Draft Standard, a protocol must have multiple independent interworking
implementations and limited operational experience. Since the early days of RFC 2543, SIP Interoperability test
events, called SIPit, have been held a few times per year. Information can be obtained from the SIP forum
website. The final Standard is achieved after operational success has been demonstrated.
SIP incorporates elements of two widely used Internet protocols: Hyper Text Transport Protocol (HTTP) used
for Web browsing and Simple Mail Transport Protocol (SMTP) used for e-mail. From HTTP, SIP borrowed a
client-server design and the use of URLs and URIs. From SMTP, SIP borrowed a text-encoding scheme and
header style. For example, SIP reuses SMTP headers such as To, From, Date and Subject.

102

Copyright 2014 JSP-Teleconsultancy

Voice over Internet Protocol functionality

SIP History
Internet Engineering Task Force (IETF) protocol
Inventors: M. Handley, H. Schulzrinne, E.
Schooler, and J. Rosenberg
Became Proposed Standard and RFC 2543 in
March 1999.
SIPPING (applications) and SIMPLE (presence
and instant messaging) WGs using SIP.
SIP is now specified by RFC 3261

Produced by JSP Teleconsultancy

103

Why SIP signalling?


The EUROCAE WG67 has decided that the future ATS VoIP network will adopt SIP as its signalling protocol.
SIP is an application-layer control protocol used to initiate, negotiate, modify and tear-down multimedia
sessions between users. SIP was developed within the IETF MMUSIC (Multiparty Multimedia Session Control)
working group and is now approved IETF standard RFC 3261. When applied to the AGVN a multi-media
session can be assumed to be a Voice communication between Controllers (although it has the capability of also
being used for other multimedia type like data and video communications).
SIP and H.323 were developed for different purposes by standards bodies with very different
requirements. H.323 was developed by the ITU. Its design and implementation reflects its PSTN
background and heritage, utilizing binary encoding and reusing parts of ISDN signalling. SIP, on the
other hand, was developed by the IETF with an Internet perspective, designed to be scalable over the
Internet and work in an interdomain way utilizing the full set of Internet utilities and functions.
ITU-T based protocols also forced centralized control by prohibiting development of end -to-end
services. SIPs flexibility means that users can build infrastructure with either an end -to-end or
centralized structure.
From the work now in course by EUROCAE WG67, SIP is also likely to become the main signalling
protocol within the AGVN over the next 10 years for both Ground Telephony and Radio Telephony
networks. Some of its advantages which led to it being chosen by EUROCAE WG 67 are as follows:

104

It is a much simpler protocol that its competitors (H.323, Inter Asterisk Exchange (IAX) and
MGCP.

it is a text based protocol like HTTP, allowing it to be easily scripted and requires no tools to
monitor or interpret messages;

it allows simple applications to be written in order to test and simulate SIP traffic;

it allows presence and instant messaging which could be used in new applications within the
future AGVN;

it is being used by mobile operator for the UMTS (3 rd generation) networks, PC and
telecommunications industries;

it has very robust security mechanisms to provide encryption, authentication using certificates
and end-to-end message integrity which were inherited from Internet Security Protocols;

it allows media/capability exchange using SDP;

with its Internet architecture it is gaining momentum with its widespread adoption and is
emerging as the future signalling standard for VoIP communications.

SIP is an Open standard and therefore stimulates developers to innovate through


experimentation. This will lead to market players developing new concepts in their intelligent
end devices etc as customized features, which could eventually be adopted by the whole
industry. Proprietary protocols dont allow this to happen.

Copyright 2014 JSP-Teleconsultancy

Voice over Internet Protocol functionality

Why SIP signalling?


EUROCAE WG67 decided future ATS VoIP network will
adopt SIP
H.323: developed by ITU. Design & implementation
reflects its PSTN background and heritage, utilizing
binary encoding and reusing parts of ISDN signalling.
Centralized control & prohibits end-to-end services
SIP: Open standard developed by IETF with an Internet
perspective, designed to be scalable over the Internet
and work in an interdomain way utilizing the full set of
Internet utilities and functions.
SIP stimulates innovation of customized features for
intelligent end devices leading to possible adoption by
whole industry.

Produced by JSP Teleconsultancy

105

What is Session Description Protocol (SDP)?


The Session Description Protocol (SDP), defined by RFC 2327, was developed by the IETF MMUSIC working
group. It is more of a description syntax than a protocol in that it does not provide a full-range media negotiation
capability. SDP has been applied to the more general problem of describing general multimedia sessions
established using SIP.
SDP contains the following information about the media session:

IP Address;

Port Number (Used by UDP or TCP for transport);

Media type (audio, video, interactive whiteboard, and so forth)

Media encoding scheme (PCM A-law, MPEG II Video, and so forth).

In addition, SDP contains information about the following:

Subject of the session;

Start and stop times;

Contact information about the session

Like SIP, SDP uses text coding. An SDP message is composed of a series of lines, called fields, whose names
are abbreviated by a single lower-case letter, and are in a required order to simplify parsing. The set of
mandatory SDP fields is shown in the table below:
SDP Parameter

Parameter Name

v=0

Version Number

o=Palmer 2890844526 2890844526 IN IP4 jsptelecom.org

Origin containing name

s=Phone call

Subject

c=IN IP4 100.101.103.103

Connection

t=0 0

Time

m=audio 49179 RTP/AVP 8

Media

a=rtpmap:8 PCMA/8000

Attributes

From the above table the following can be deduced:

Connection IP address (100.101.102.103);

Media format (audio);

Port number (49170);

Media transport protocol (RTP);

Media coding (PCM A-law);

Sampling rate (8,000Hz);

The full set of SDP fields is defined in the Table below:

Field

106

Name

v=

Protocol version number

o=

Owner/creator
identifier

s=

Session name

and

Mandatory/optional
M
session

Copyright 2014 JSP-Teleconsultancy

M
M

Voice over Internet Protocol functionality

What is Session Description


Protocol (SDP)?

SDP (RFC 2327) used by SIP to describe SIP session attributes;


Is not a protocol, but a format for describing multimedia sessions;
Minimum SDP fields to establish session are:

v=version number;
o=owner/session identifier;
s=subject
c=Connection information
t=time
m=media
a=attributes

SDP employs Offer Answer model (RFC 3264).


i.e. Caller makes call defining their media capabilities in INVITE
message. Called party the responds with 200OK selecting media
capabilities to be applied to session

i=

Session information

u=

Uniform Resource Identifier

e=

Email address

p=

Phone number

c=

Connection information

b=

Bandwidth information

t=

Time session starts and stops

r=

Repeat times

z=

Time Zone corrections

k=

Encryption key

a=

Attribute lines

m=

Media information

a=

Media attributes

Use of SDP in SIP


The use of SDP with SIP is given in the SDP Offer Answer RFC 3264. The default message body type in SIP is
application/sdp. The calling party lists the media capabilities that they are willing to receive in SDP in either
an INVITE or in an ACK. The called party lists their media capabilities in the 200 OK response to the INVITE.
More generally, offers or answers may be in INVITEs, PRACKs, or UPDATEs or in reliably sent 18x or 200
responses to these methods.

Produced by JSP Teleconsultancy

107

A typical SIP use of SDP includes the version, origin, subject, time, connection, and one or more media and
attribute fields. The origin, subject and time fields are not used by SIP but are included for compatibility. In the
SDP standard, the subject field is a required field and must contain at least one character, suggested to be s=- if
there is no subject. The time field is usually set to t=0 0.
SIP uses the connection, media and attribute fields to set up sessions between user agents. As the type of media
session and codec to be used are part of the connection negotiation, SIP can use SDP to specify multiple
alternative media codecs and to selectively accept or decline those media types. When multiple media codecs
are listed, the caller and called partys media fields must be aligned - that is, there must be the same number, and
they must be listed in the same order. The offer answer specification, RFC 3264, recommends that an attribute
containing a=rtpmap: be used for each media field. A media stream is declined by setting the port number to
zero for the corresponding media field in the SDP response.

108

Copyright 2014 JSP-Teleconsultancy

Voice over Internet Protocol functionality

This page is intentionally blank.

Produced by JSP Teleconsultancy

109

Next Generation ICAO 9896 VoIP


interfaces for ATS Ground Voice Network
- Part 1

110

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

5. VoIP in aeronautical communications

Produced by JSP Teleconsultancy

111

Circuit to Packet switching interworking


Migrating from TDM circuits to an IP architecture
The main components that are available today to migrate an existing circuit switched connections within the
AGVN to a packet switched ATS IP network, include Voice gateways to the IP network and Voice Routers to
the IP network.
Voice gateways to IP networks
These are devices placed between a VCS and the ATS IP network to provide call set-up, call routing and to
convert voice into IP packets. A gateway consists of a media gateway and a signalling gateway.
The Media gateway performs the translation of voice between the circuit-switched and packet formats of the
two different network types.
The Signalling gateways are used as interfaces between an IP and an external network. They perform the
interoperation between different call control protocols.
Voice gateways today are able to connect with the following analogue interfaces: CB, E&M, PSTN etc and have
the E1 as the common digital interface. This E1 interface within the Voice Gateway is also compliant with a
whole series of voice signalling protocols (i.e. Layer 2 datalink, ISDN layer 3 ( Q.931) and QSIG -PSS-1
(Q.931) and the ECMA 143 (QSIG standard) etc. Sometimes an E1 interface using CAS and ISDN Basic Rate
interface is also available.
For ANSPs that desire to keep their existing VCS and its associated digital interfaces, but want to migrate their
current circuit switched networks towards IP, in order to reduce their leased line costs and allow the eventual
convergence of voice and data networks, could seriously consider the use of Voice Gateways as a means to
achieve this objective.
These ANSPs can use the E1 interface within a VCS to access the IP network through a Voice Gateway.
Voice gateways features
The Voice gateway products available in todays market have the following characteristics:

Allow 30 voice calls to be established per E1 interface;

Built-in user selectable codecs for G.711 (64kbps A-Law), G.732.1 (5.3 and 6.3kbps) and G.729a (8kbps)
used to reduce IP bandwidth;

G.168 echo cancellation- this can be enabled if analogue voice is used;

DTMF detection and generation;

Silence suppression and comfort noise- No packet transmission unless speech present. The far end
Voice gateway generates local comfort noise to user when no packets received;

Configurable dejitter buffer used at the receive end to smooth out the delay variability of the
arriving voice packets; If this is configured too short, there is underflow and speech clipping results,
while if they are configured too long, it can cause delay in the voice.

Configurable tones (dial, ringing, busy);

Configurable transmit packet length;

Real Time Protocol (RTP);

Real Time Control Protocol (RFC 1889);

Compliant with a number of layer 3 Voice signalling protocols (including ECMA 143 QSIG);

Tunnelling of ISDN/QSIG call signalling messages for full featured PBX networking over IP;

Also allows tunnelling of QSIG features (i.e. FACILITY messages);

Some Voice Gateways can translate Called party number to IP address;

112

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

Circuit to Packet switching


interworking
VCS A

VCS C
E1 connection
Using Q.931

E1 connection
Using Q.931

Voice Gateway

Voice Gateway

WAN
E1 connection
Using Q.931

E1 connection
Using Q.931

Voice Gateway

Voice Gateway

VCS B
VCS D

Voice Gateways using E1 interface (QSIG) allow dynamic routing of


QSIG calls over an ATS-IP network; BW proportional to traffic.
Signalling channel tunnelling allows full featured networking between
VCSs over the IP network;
Allows codec selection, echo cancellation, silence suppression/
comfort noise, called number/IP address mapping;

Number manipulation functions: Replace numbers, Add/remove digits etc

Interfacing VCS to Voice Gateway using E1 interfaces


An E1 interface within both the VCS and Voice Gateway should be of the Common Channel Signalling
(CCS) type using channel 16 as the D signalling channel. The Voice gateway used should therefore support an
E1 frame format compliant with G.704. Both VCS and Voice Gateway should be running a Layer 2 datalink
protocol compliant with ITU-T Q.921 and the same layer 3 protocol compliant with ITU-T Q.931.
At layer 2 it is usual to configure the Voice gateway as the User side and the VCS as the Network Side.
The method of sending the address information in multiple messages (i.e. SETUP and INFO) is called overlap
sending mode and this should not be enabled in the Voice Gateway or VCS. All address information should be
sent within a single SETUP message which implies that both VCS and Voice Gateway should use Enbloc
mode.
Numbering Plan mapping at Voice gateway
Some Voice gateways allow the configuration of numbering plan mapping. This provides two important
features:

the ability to switch a call anywhere in the IP network;

separates signalling dependencies on either side of the network.

This implies that the voice gateway must understand the dialled digits in order to set up a voice call to the
appropriate destination. In an IP network this amounts to translating the dialled digits to an IP address. To aid
the voice gateway in this mapping, numbering plan mapping can be configured at the voice gateways in the
network, similar to those on VCSs. The voice gateway can therefore have the capability to map between Called
Party Number and IP address and also map between Calling Party Number and IP address.

Produced by JSP Teleconsultancy

113

In the case of an outgoing call from an E1 interface using CCS (Q.931), it is possible for the Voice gateway to
read the Called Party Address information element within a SETUP message. The Voice gateway has a preconfigured look-up tables that allows it to determine the destination IP address of the Called party. Similarly it
can map the Calling Party Address information element and determine the Source IP address.
For an incoming call from the IP network, the Voice Gateway is able to map the IP address back to the relevant
Called Party Number and determine on which E1 interface the call must be routed.
This mapping can be restricted to an internal private numbering plan or can also be used for calls towards the
PSTN. In this case the Voice Gateway has to recognise that the number dialled is a PSTN number (i.e. E.164
numbering plan) and route the call towards the relevant pre-configured IP address.

Tunnelling of Signalling channel by Voice Gateway


Some Voice gateways allow the signalling channel of the E1 interface (i.e. channel 16) to be tunnelled
transparently across the IP network. All the ISDN/QSIG call signalling messages exchanged between VCSs are
therefore passed by the Voice Gateway directly over the IP network. Once the Gateway has determined the
destination IP address of a call, it is able to establish this transparent path for the signalling channel. This allows
full featured networking between VCSs over the IP network.
Audio conversion at Voice Gateway
For outgoing calls from the E1 interface, the Voice Gateway is also capable of reading the Channel
Identification information element within the SETUP message. It can then identify which channel within the E1
interface contains the voice associated with the outgoing call, to be transported over the IP network. The G.711
PCM coded voice can then be sampled on the relevant E1 channel and converted to IP packets by the Voice
Gateway for transportation towards the destination IP address already determined. This transportation occurs in
real time when the Voice Gateway has seen a CONNECT message from the called party side tunnelled through
the signalling channel. If enabled the Voice Gateway can compress the voice prior to transmission in order to
save on bandwidth within the IP network.
When receiving incoming IP packets from the IP network, the Voice Gateway is able to decompress the voice
(if it was sent as compressed voice) and convert the received IP packets back to the original PCM coded voice
signal, sending them on the relevant Voice channel of the E1 interface.

114

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

This page is intentionally blank.

Produced by JSP Teleconsultancy

115

Working towards end-to-end VoIP


SIP communications within the ATS environment through an IP network
With the future introduction of SIP technology within the ATS environment, the following example illustrates
and analyses the different possibilities of how VoIP communication could be implemented within an IP network
between VCSs and between CWPs employing SIP.
VCS - SIP gateways
In the slide, VCS B connects to a stand-alone SIP gateway developed by the VCS supplier for their product.
A SIP gateway would consist of a Media gateway and a Signalling Gateway. The media gateway would be
responsible for translating the voice from a circuit-switched format of the VCS to a packet switched format of
the IP network. A signalling gateway would perform the interworking between existing circuit switched
signalling protocols (i.e. ATS-R2 , ATS-QSIG, PSTN, Radio) and SIP.
This VCS can communicate:
with other VCSs (i.e. VCS A) connected to WAN through SIP network interfaces;
with SIP CWPs (i.e. SIP CWPs 1,2 and 3) connected to the WAN (without going via a VCS);
with VCSs (i.e. similar to VCS B) connected to WAN through a similar SIP gateway.
with a Call Server handling calls to/from CWPs (i.e. CWP4 & 5) connected to an LAN.
This interworking gateway would be developed by VCS suppliers with a signalling gateway for ATSR2, ATS-No.5 analogue signalling protocols and ATS-QSIG digital signalling protocol. The
responsibility of Call control would remain with the VCS. However many inter -VCS features available
today employ VCS supplier proprietary signalling methods which could lead to problems in their
mapping with SIP at a signalling gateway.
It would also contain a Media Gateway responsible for transcoding the voice between the analogue
ATS-R2/ATS-No.5 interfaces on the Circuit Switched side and the speech codec configured in the SIP
network interface on the Packet Switched side. In order not to effect voice quality, voice is ideally
transported end-to-end without any transcoding between codecs at the gateway. If necessary howe ver a
gateway could also be used to transcode speech between different codec types.
A SIP media gateway could contain one or several Voice codecs, however it is likely that the ITU -T
G.711 PCM 64kbps will be the preferred voice codec, while a second lower bandwidth, high quality
voice codec could also be included and utilized in the case that available bandwidth becomes scarce. A
media gateway would also be responsible for functions like Echo cancellation into the circuit switched
networks, Voice Activity Detection (if enabled), Voice Compression, Call progress tone generation
towards the circuit switched network etc.
With this approach a VCS supplier can provide solutions to their ANSP customers wanting to eventually
migrate to VoIP technology and at the same time avoid the need to upgrade the VCS architectural
design.
VCS - SIP network interfaces
In the slide, VCS A has a SIP network interface developed by the VCS supplier for their product. This can
communicate:
with other VCSs connected to WAN through SIP network interfaces;
with SIP CWPs connected to the WAN (without going via a VCS);
with VCSs connected to WAN through a SIP gateway.
with a Call Server handling calls to/from CWPs (i.e. CWP4 & 5) connected to a LAN.
Note: This solution is most likely to be followed by the VCS suppliers. EUROCAE WG67 has defined the
SIP protocol and SIP network interfaces for both Ground Telephony and Radio Telephony parts. The
Ground Telephony and Radio Telephone network interfaces, as SIP User Agents within the V CS, can be
connected directly to a SIP Proxy Server. Pure VCS-to-VCS VoIP Calls using SIP will be possible
between VCS suppliers with common interfaces compliant with the future EUROCAE standard.

116

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

Working towards end-to-end VoIP


SIP Gateway
with SIP
Network interface
ATS-R2
ATS-QSIG
PSTN

Call Server

IP-VCS
CWP5

CWP4

RADIO

SIP CWP1

Ethernet LAN
SIP Proxy
Server
Legacy CWP

VCS A with
SIP Network
interface SIP Proxy
Server

SIP Proxy
Server

SIP CWP3

Ethernet LAN

SIP Gateway with SIP


Network interface

Legacy CWP

SIP CWP2

GRS

WAN

VoIP enabled
VCS

SIP GRS
SIP Proxy
Server

SIP Gateway
with SIP
Network interface

VCS B

Legacy CWP

ATS-R2
ATS-QSIG
PSTN
RADIO

Legacy CWP

With the integration of SIP network interfaces within the ir VCS, a VCS supplier can protect their
existing VCS product and at the same time allow the continued interoperability of many of their inter VCS features. However it would probably need a considerable change to the VCSs functional
architecture and also a major software upgrade to the VCS, which can require considerable investment in
equipment etc. Further costs would be involved in performing backwards compatibility testing of
existing VCS features and functionality. This could lead to VCS suppliers cons idering development of a
new generation of VCS.
SIP Controller Working Positions
In the slide SIP CWPs 1, 2 and 3 have direct access to a private WAN. Many SIP CWPs in a single ATS unit
can be connected to an Ethernet LAN rather than to the VCS user ports. These CWPs will have enhanced
technology on the SIP telephones available today with a number of integrated Voice codecs and the means to
communicate directly with the WAN through SIP. A SIP CWP can communicate:
with other SIP CWPs connected to the WAN (without going via a VCS);
with remote VCSs (i.e. VCS A) connected to the ATS -IP network through SIP network interfaces.
with remote VCSs (i.e. VCS B) connected to WAN through a SIP gateway.
with a Call Server handling calls to/from CWPs (i.e. CWP4 & 5) connected to an LAN.
This will involve the development of a new generation of CWPs by the VCS suppliers with the
integration of SIP User Agent Clients directly within a CWP. The SIP CWPs will have access to the
WAN via a SIP Proxy Server. All Ground telephony calls types (DA, IA and IDA) and supplementary
services would be handled directly from the SIP -CWP. Similar to todays SIP telephone, the CWP would
also be able to handle a number of Voice Codecs. A SIP -CWP could only be used within an WAN.
Hybrid versions of a CWP (i.e. connecting to a SIP Proxy and a VCS) would cause problems in call
management, unless call control was positioned in each CWP.
With this approach it can be argued that with respect to Ground Telephony, there will no -longer be a
need for a VCS for the ground telephony part. Although SIP -CWPs are very specialised equipment, this
market could be penetrated by companies already working with SIP telephone technology.
A SIP CWP will also require a major redevelopment of the CWP archite cture and a major software
upgrade to the CWP which can require considerable investment in equipment etc.

Produced by JSP Teleconsultancy

117

IP-VCS
In the slide, the IP-VCS has been developed for IP networks and has a very different architecture to the present
day VCSs. This can communicate:

with VCSs (i.e. VCS A) connected to ATS-IP network through SIP network interfaces;
with SIP CWPs (i.e. SIP CWPs 1,2 &3) connected to the ATS-IP network (without going via a
VCS);
with VCSs (i.e. VCS B) connected to ATS-IP network through a SIP interworking gateway.
with other IP-VCSs connected to IP network.
with the circuit switched part of its local network through the local SIP gateway;
This approach is very radical and employs a completely new architectural philosophy for handling calls within
an ATS environment. It uses a Call Server instead of a VCS for handling calls and all CWPs are configured in a
LAN (with an Ethernet Switch) have direct access to IP network via the SIP Proxy server. Any calls to the
circuit switched part of the network are routed by the call server through a SIP gateway. Likewise any calls from
the circuit switched part of the network coming from the SIP gateway are routed by call server either the local
SIP-CWPs or to the ATS-IP network through the SIP proxy server.
The Call Server function of an IP-VCS provides all the essential call control and signalling normally provided
by the software of a traditional VCS. The call processing software resides on a dedicated telephony server
connected to the IP network and provides call handling (e.g. routing of internal and external calls) as well as
supplementary services (e.g. call transfer, call forwarding etc). The Call server does not normally switch or
process voice media, although there are exceptions to this, including applications such as multiparty
conferencing.
The voice media is normally transported end-to-end between CWPs. The CWPs have the capabilities of
different Voice Codecs and use SDP within SIP to nominate a codec while exchanging media capabilities for
the communication.
This approach could lead to the ground telephony part of conventional VCSs used today being
completely replaced because the VCS call control, switch matrix and TDM infrastructure are Voice
Coding are no longer needed. By employing SIP signalli ng most of the traditional PBX features can be
provided by the IP-VCS, but with added possibility of many new features to the ATS environment.

118

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

This page is intentionally blank.

Produced by JSP Teleconsultancy

119

Example of SIP Telephone technology today


Voice over IP telephones using SIP connect to the IP network through an Ethernet/LAN connection.
They can also be connected to the Ethernet switch of an IP -PBX.
The following defines the functionality offered by todays VoIP telephones using SIP:
Compliant with IETF SIP 3261 protocol, using open standard SIP call control for integration into
multi-vendor SIP-based telephony environments;
Network interface to an Ethernet LAN;
Power over Ethernet (802.3af) is possible which allows a centralized low voltage battery backup of
all phones connected to the LAN;
A wide range of SIP features are built-in to the telephone (i.e. Call Transfer, Call Forwarding, Call
Hold, Call Waiting, Call Park, Group Pickup etc). These features can only be used if a the SIP
Proxy Server supports these as well;
A web-based application program is used for the initial configuration of the SIP phone. The SIP
Register Server and Outbound SIP Proxy Server addresses can also be set using this application.
New software versions for the phone can be downloaded from an FTP server;
Has built-in voice codecs: These tend to be ITU-T G.711 A-law and -law PCM (64kbps) and ITUT G.729 CS-ACELP (8kbps); Some however also have ITU-T G.723.1 (5.3 and 6.3kbps)
Allows configuration of Quality of Service (QoS) parameters from t he Web application, such as:
o Type of Service field (IP precedence) in the IP header (defines importance of data
being transported);
o IEEE 802.1p/q and DiffServ for priority treatment by QoS enabled IP networks;
Voice Quality functionality includes:
o Voice Activity Detection
o Comfort Noise Generation
o Acoustic Echo Cancellation
o G.168
o Jitter buffer
Allows the following 3 types of call to be made:
o Direct IP call without SIP registration;
o Dial registered number via SIP server;
o Dial URI from phone book/speed dial;
Audible tone definition (i.e. Ringing tone, Dial Tone, Busy Tone etc)
IP address assignment method (i.e. Static IP DHCP PPP)
Supports IP/TCP/UDP/DHCP/RTP/RTCP etc.
It is possible that future Controller Working Positions could have the same technology integrated.
SIP telephone standards;
Todays typical SIP telephone is compliant with the following SIP standards:

120

IETF RFC3261 (SIP :Session Initiation Protocol)


IETF RFC 2976 (SIP INFO Method)
IETF RFC 2327 (SDP: Session Description Protocol)
IETF RFC 3264 (An Offer/Answer Model with the Session Description Protocol)
IETF RFC 1889 (RTP: Real-time Transport Protocol)
IETF RFC 1890 (RTP Profile for Audio and Video Conferences with Minimal Control)
IETF RFC 2833 (RTP Payload for DTMF digits, Telepho ne Tones and Telephone Signals)
Support inband DTMF tone send/receive with RTP
Supports out of band DTMF signalling based on RFC2833
IETF RFC 3489 (Simple Traversal of User Datagram Protocol (UDP) through Network Address
Translators (NATs))
Draft-ietf-sip-refer-06.txt (SIP Refer Method)
IETF RFC 2617 (HTTP Authentication)

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

Example of SIP Telephone technology


today

IETF RFC 3261 SIP protocol; Also supports IP/TCP/UDP/DHCP/


RTP/RTCP etc. IP address assignment (i.e. Static IP DHCP PPP)
Network interface to Ethernet LAN, powered from Ethernet (802.3af);
Built-in SIP features (i.e. Transfer, Forwarding, Hold, Waiting, Park, Pickup
etc). SIP Proxy Server must also supports these;
Web-based application for phone configuration.
New software versions downloaded from FTP server;
Built-in voice codecs: G.711 A/-law PCM & G.729 CS-ACELP; Some
have G.723.1 (5.3 and 6.3kbps)
QoS parameter config from Web application, such as:
Type of Service field (IP precedence) in IP header
IEEE 802.1p/q and DiffServ -priority treatment by IP networks;

Voice Quality functionality includes: VAD, Comfort Noise, Echo canc, Jitter
buffer, G.168
Allows: Direct IP call without SIP registration, Dial registered number via
SIP server, Dial URI from phone book/speed dial;
Audible tone definition (i.e. Ringing, Dial & Busy Tones etc)

With respect to Ground Telephony, it is possible that future CWPs will follow the path of SIP telephones with
the integration of SIP User Agent Clients directly within a CWP. Many SIP CWPs in a single ATS unit can be
connected to an Ethernet LAN rather than to the VCS user ports. The Ethernet LAN would have access to a
local SIP Proxy server in order to access the IP network. The SIP proxy server would also have access to its
local DNS server in order to determine IP addresses called users. The call control functionality would be located
within the CWP itself.

Produced by JSP Teleconsultancy

121

Functional Airspace Blocks (FABs)


Functional Airspace Block (FAB) is defined in the SES-2 legislative package, as follows:
A FAB means an airspace block based on operational requirements and established regardless of State
boundaries, where the provision of air navigation services and related ancillary functions are optimised and/or
integrated.
In the context of the Single European Sky (SES) Regulations of the European Union and in particular in
accordance with Article 8 of the Framework Regulation, the European Commission has issued a mandate to the
EUROCONTROL Agency for support in the establishment of Functional Airspace Blocks (FABs).
Member States shall take all necessary measures in order to ensure the establishment of functional
airspace blocks as soon as possible and at the latest by the end of 2012
SESII Proposal for a REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE
COUNCIL (June 2008) amending regulations:
(EC) No 549/2004,
(EC) No 550/2004,
(EC) No 551/2004 &
(EC) No 552/2004
in order to improve the performance & sustainability of the European aviation system.

Currently following FABs groups are currently underway in Europe:

Baltic FAB (Lithuania and Poland)

NUAC /NEFAB (Estonia, Finland, Norway)

DK-SE FAB (Denmark and Sweden)

UK-Ireland FAB

FAB Europe Central (Belgium, France, Germany, Luxembourg, EUROCONTROL Maastricht Upper
Air Control Centre, Netherlands, Switzerland)

FAB Central Europe (Austria, Bosnia Herzegovina, Croatia, Czech Republic, Hungary, Slovak
Republic, Slovenia)

Danube FAB (Bulgaria-Romania)

South West FAB (Portugal, Spain)

BlueMed FAB (Cyprus, Egypt, Greece, Italy, Malta, Tunisia)

The FAB_EC VCS-TF for example is comprised of 6 States and EUROCONTROL Maastricht UAC with
EUROCONTROL participating as observer to the TF meetings.
The FAB-EC VCS-TF is comprised of :

122

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

Produced by JSP Teleconsultancy

123

Today no sector delegation between ACCs


Today the combining of sectors to form sectors of larger sizes (maybe applied during night time operation or
when traffic levels are low) and the collapsing of sectors to form sectors of smaller sizes (maybe applied during
day time operation or when traffic levels are higher) is possible only within same ACC. The number of sector
suites open and operational is proportional to the number of sectors. Combining 2 sectors into 1 results in a
sector suite being closed, while collapsing 1 sector into 2 results in a new sector suite being open.
Today the control of sectors are not shared between ACCs within the same country or between ACCs in
different countries.. From the slide ACC1 for example cant take control of Sector H, as it has no link to radio
f7.

Sector delegation between ACCs now possible


If ACC1 also had links to radios f7, f9 and f10 it has capability to take over those sectors when necessary.
ACC2 can reassume control.
If ACC2 also has links to radios f6, f11, and f12 it has capability to take over those sectors when necessary.
ACC1 can reassume control
The Slide shows that VCSs (belonging to ACCs) in adjacent centres can establish SIP sessions not only with
the radios in the sectors under its control, but also with the radios in the adjacent sector (s) which it may have to
assume control of. During a sector delegation, the control of a sector could pass from one ACC to another. One
VCS would therefore renounce its control over radios in the shared sector(s) and the other VCS would assume
control of radios in those sector(s) that would pass to another adjacent VCS.

124

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

Produced by JSP Teleconsultancy

125

Last Resort Communications between ACCs


If ACC1 has links to all radios in ACC2 sectors and vice versa, it could be applied to Last Resort
communications.
Without ACC2, all sectors controlled by ACC1.
Without ACC1, all sectors controlled by ACC2
Access to Radio Stations for Last Resort Radio communications
In the case of a disaster (i.e. Terrorist attack, Bomb, Major Fire) at an ATC unit where the Main and Backup
VCS are destroyed, today this could cause a huge problem as all the Radios located at the Remote Radio Sites
will not be contactable. It will therefore no longer be possible to communicate with the aircraft flying in the
concerned sectors. Most ATS units in these situations would place a disaster recovery plan into operation in
order to ensure the availability of critical resources and facilitate the continuity of operations in an emergency
situation in case a Network node or VCS is completely destroyed. This plan normally includes procedures for:
the initial emergency response;
the changeover to Backup, Fallback or Last Resort operations;
the post-disaster recovery phase
The Slide shows that VCSs in adjacent centres can establish SIP sessions not only with the Radios in its own
airspace sectors (ACC1), but also with the Radios in the adjacent airspace sector (s) (ACC2). During a Major
failure of the main and backup VCSs, the VCS would no longer have control over its radios. In these
circumstances an adjacent ATS-unit(s) could assume control of these Radios and Airspace sectors for the time
necessary for the VCS to re-enter in service.

Civil/Military controlling of sectors


Military ACC controls the Military sectors.
Sectors unused by Military can be delegated to Civil ACC1 for pre-set time period. (Civil-Military sector
sharing).
Civil ACC can hand back control to Military at pre-agreed time.

126

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

Produced by JSP Teleconsultancy

127

Today ACCs configured with adjacent ACCs addresses only


Assume Aircraft handover from ACC2 to ACC1 to ACC3 or ACC4.
Today ACC2 configured with adjacent ACC1 Phone addresses only.
No need for ACC2 to talk with ACC3 or ACC4 today as this is performed by ACC1 only.

Sector Delegation between ACCs now possible


Sector Delegation implies each ACC needs Phone addresses of ACCs bordering sectors that it could assume
control of.
Slide shows that if Sectors E & I delegated to ACC2, then ACC2 needs phone addresses of ACC4 & ACC3 for
aircraft handover.

128

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

Produced by JSP Teleconsultancy

129

Last Resort communications between ACCs


If ACC2 takes over all ACC1 sectors, it needs ACC3 & 4 addresses.
If ACC4 takes over all ACC1 sectors, it needs ACC2 addresses.
If ACC3 takes over all ACC1 sectors, it needs ACC2 addresses

130

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

Produced by JSP Teleconsultancy

131

What are Roles / Missions?


What is a Role?: This is an Executive controller, planner (or coordinator), assistant planner working at a sector
suite.
What is a Sector Suite?: A number of CWPs that are co-located so that a number (typically two or three) users
perform the function of managing defined sector(s) of airspace. A typical Sector Suite may have CWPs
performing the Role of Executive Controller, Planner and Assistant respectively.
What is a Mission?: created by combining one or more Roles and linking them to one or more sectors. A Role
becomes a Mission when assigned to a CWP. Mission assignment to a CWP causes its display panels/attributes
(i.e. frequencies, Access modes, cross-coupled frequency groups, DA/IA key panels , features etc.) to be
configured in order to perform the voice communication related operational tasks necessary to handle the
mission.
(e.g. Executive controller/ Planner covering Sectors 1 and 2 would define a mission for example).
What is Mission change?: If sectors within an ATS unit are combined or collapsed, the Mission assigned to
CWPs in the sector suite controlling that airspace will change.

What is Sector Delegation?


Dynamic Resectorization: Airspace sectors within National airspace or within a Functional Airspace Block
(FAB) of airspace can be combined (to form larger sectors) or collapsed (to form smaller sectors) dynamically
according to the changing requirements in order to manage the air traffic situation occurring at the time.
What is Sector delegation?: This is an Offer/accept procedure used to handover control of a sector internally or
to neighbouring ATS unit. Configuration to control the sector (i.e. DA, IA keys, Frequencies etc) must be
identical in both ATS units, but only one assumes control. ATS-unit receiving control of Sector can combine it
with other sector(s) already under its control, link them to Role(s) and assign it to CWP sector suite as a
mission.
Sectors and NOT Roles or Missions are handed over therefore.
Role Server: Each ATS-unit has a local server (sometimes named Role Server) defining required CWP
configuration for each sector or combination of sectors (that it can be controlling at any instant) when applied to
a role or combination of roles. All possible Sector/Role combinations defined.
Mission change: If sectors within ATS unit are combined or collapsed, the Mission assigned to CWPs in sector
suite controlling that airspace will change.

132

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

Produced by JSP Teleconsultancy

133

Mission applied to CWP=Role(s) + Sector(s)


Link Role(s) to Sector(s) to obtain Mission configured at CWP.
Sector X configuration (i.e. DA, frequency keys) linked to either Executive/Planner/Assistant Role and
configured at CWP as a mission.
The slide shows 4 sectors each configured with necessary DA keys and frequencies. Applying sectors
configurations to Exec/Planner/Assistant roles leads to a mission being created that is applied to the CWP.
The following missions are created: Executive Sector 1, Planner Sector 1, Assistant Sector 1, Executive Sector
2, Planner Sector 2, Assistant Sector 2, Executive Sector 3, Planner Sector 3, Assistant Sector 3, Executive
Sector 4, Planner Sector 4 and Assistant Sector 4
A new Mission can be created and activated for a Sector Suite or CWP and this will not have any impact on any
communications in progress at the time of the New Mission activation. It shall be possible to collapse multiple
missions to a single Sector Suite or a single CWP. Each CWP has its current mission name always indicated.
The CWPs within a sector suite will have notification prior to a new mission being activated as it will cause the
Dynamic Display of the CWP to be re-configured. The new mission is offered to the user at the CWP and has to
be physically accepted by the user before the mission change occurs. At any time it is possible to restore the
default Mission after confirmation. After there has been a Mission change, the CWP will indicate the name of its
new mission.
The Air/Ground Radio functionality at a CWP will always be fully operable, even when no Mission has been
assigned to the CWP.

Example of Role and Sector combination to form mission applied to


a CWP
It Sectors 1 & 2 are combined to form Sector1-2, the DA keys +Frequency keys will be automatically updated.
If the new Sector 1-2 has only Exec.and Planner roles available, the Planner/Assistant roles are combined into
one role and applied as a new mission in order to control the newly formed Sectors 1-2. The sector suite
originally controlling Sector 2 can be closed.
Today the collapse as well as the combining of sectors is initiated by the supervisor. The supervisor can also
pull control of a sector from one controller sector suite and push it to another one, maybe also combining it with
other sector(s) before applying it to roles (i.e. Executive/Planner/Assistant) to form a mission loaded on to a
CWP(s). Within a FAB, the sector could also be pushed to or pulled from a neighbouring ACC.
It is necessary for the controller assuming control of the sector(s) to indicate acceptance of the new mission(s)
pushed by the supervisor, prior to sector handover success being indicated to the Network Management. It is
also necessary for a controller renouncing control of the sector(s) to indicate acceptance that the old mission(s)
is pulled by the supervisor, prior to sector handover success being indicated to the Network Management.

134

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

Produced by JSP Teleconsultancy

135

Configuring addresses for sector delegation


Next Steps
Open Standard (VOTE sub-group task) for Sector delegation procedures are needed in order that all players can
design their system architecture and achieve interoperability.
Need common understanding about what defines a sector configuration (ATS numbers, SIP URI, PSTN
number, frequencies etc) to be locally configured in each VCS, maybe in Role Server. (No signalling protocol
foreseen for this).
Each ATS-unit to define its own unique sector address (in standardized format) for each sector it permanently
controls and for each sector it shares control of with its neighbours within a FAB.
Each ATS-unit communicates its shared sector addresses with neighbours that it shares control of sector.
Each VCS registers all its unique sector addresses in its local address plan with its local REGISTRAR server as
well as each unique shared sector address provided by its neighbours.
Need definition of Network Management commands and responses for sector handover between 2 ATS-units;
(NM signalling protocol foreseen for this).
An example of NM commands and responses needed between ACCs.
NM Command OFFER SECTOR X
NM Response ACCEPT SECTOR X
NM Response Confirm control of SECTOR X
NM ACK Confirm control of SECTOR X
Sector X handover Push command from NM will trigger VCS to reprogram its own unique Sector X address
in its local Location DB with that of the Sector X address of its neighbour VCS.
Sector X handover Pull command from NM will trigger VCS to reprogram the Sector X address of its
neighbour VCS in its local Location DB with that of its own local unique Sector X address.
All REGISTRAR server/Location database and Proxy server updates in each ATS-unit seen as part of SIP.
(No additions to signalling protocol foreseen).
Need definition of method & protocol exchanges between Proxies to update current address controlling sector
that follows a sector handover. (Signalling Protocol Definition required?)
Once one VCS has given sector control and one VCS has taken sector control, NM command between ACCs
necessary to Confirm control of SECTOR X and NM Response to Acknowlege Control of Sector X needed.
(Signalling Protocol Definition required)

136

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

Produced by JSP Teleconsultancy

137

VoIP network architecture elements & their functionality


Voice over IP infrastructure applied to AGVN
The introduction of VoIP within the AGVN is likely to cause a major change to the circuit switched and TDM
based VCS communication infrastructures in operation today.
The slide provides an example of a possible VoIP infrastructure when applied to an AGVN using the Session
Initiation Protocol (SIP) to establish media paths between CWPs. These media paths will be used for voice
transportation in real time. It can be assumed that a Domain is a VCS with VoIP capabilities.
SIP User Agents and SIP Proxy Servers
SIP end systems are named SIP User Agents and intermediate elements are known as SIP Proxy Servers.
SIP User Agents can be considered to be either CWPs, a SIP network-side interface within the VCS or a SIP
gateway to existing circuit switched interfaces within the VCS.
A SIP User Agent 1 in VCS domain A wanting to call another SIP User Agent 2 in VCS domain B, would
firstly communicate with the SIP Proxy Server 1 in its own VCS domain. The SIP Proxy Server 1 would
forward the call request to the SIP Proxy Server in the VCS domain of the called party (in this case SIP Proxy
Server 2). The SIP Proxy Server 2 would then forward the call to the called user at SIP User Agent 2.
Within its own domain the SIP Proxy server has access to a Location database defining the present contact
details of all SIP User Agents in the domain. This database is kept up-to-date with all the latest contact details
by a SIP Registration Server and SIP Redirect Server.
Note: SIP Proxy servers can be either stateful or stateless. A stateless proxy server processes each SIP
request or response based solely on the message contents. Once the message has been parsed, processed
and forwarded or responded to, no information about the message is stored. A stateless proxy in fact
never re-transmits a message and never uses timers.
A stateful proxy server on the other hand keeps track of the requests and responses it receives and can
use that knowledge in processing future requests. This is very important within the AGVN as a stateful
proxy could also manage timers, retransmitting requests when there has been no response received etc.
DNS Server
As part of this call flow, SIP Proxy Server 1 needs to determine the SIP Proxy Server to be used for
VCS domain B. In order to do this SIP Proxy server 1 requests the information from a DNS Server 1
probably also located in VCS domain A. The DNS Server basically contains a look -up table and when
receiving a URI interrogation request from a SIP Proxy server is able to supply the actual network
resource description of SIP User Agent 2 (i.e. this includes the IPv6 address, IP -Port number and
preferred transport protocol (UDP or TCP) etc).
Note: It is considered a better approach to have SIP-proxy and DNS server running on different
hardware platforms.
If the DNS server in domain A is unable to provide the information in its local look -up tables, then it
can request the information from a higher level root DNS server probably located and managed by an
approved European entity.
Note: In order to ensure the time to establish the call between the two end -user agents is not subject to
delays, a fast DNS request/response time is necessary. In order to achieve this, a two level DNS
hierarchy is presently proposed. The root-level and the VCS-domain level
Registration Server
At power-up or following a reset, SIP User Agent 1 in VCS domain A has to register itself with the
Registration server in VCS domain A. The same applies for the SIP User Agent 2 in VCS domain B.
This registration process allows the SIP User Agent to identify its presence at a particular CWP/SIP
network interface/SIP gateway within its domain.

138

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

VoIP network architecture


elements & their functionality
Root
DNS
Server

ATS
IP Network
SIP
Proxy
Server
1
Location
database

ATS-R2
ATS-QSIG
PSTN
RADIO

SIP
Gateway
UA 1

SIP
User
Agent
1

DNS
Server
2

SIP
Proxy
Server
2

Registration
and Redirect
Server

Location
database

Registration
and Redirect
Server

SIP CWP
or SIP
Network
interface

SIP
Gateway
UA 2

SIP
User
Agent
2
SIP CWP
or SIP
Network
interface

DOMAIN A

DOMAIN B

ATS-R2
ATS-QSIG
PSTN
RADIO

DNS
Server
1

VCS B

VCS A

To register, it is necessary to send the configured URI address of the CWP/SIP Netw ork Interface/SIP
gateway and the contact URI address of the current CWP/SIP Network Interface/SIP Gateway being
used. Normally in an ATS environment these addresses would be the same, however if equipment was
off-line for maintenance reasons it could occur that the contact URI address would be different from the
configured URI address. The SIP Proxy Server will always use the Registered Contact address defined
as the valid address.
For security purposes the Transport Layer Security (TLS) encryption at th e application layer is used for
this registration process to transport the SIP requests and responses. The SIP Registration Server
requests User Id and Password to be sent for verification.
Within an ATS environment this registration process would occur a utomatically between a SIP user
agent within a CWP/SIP network interface/ SIP gateway and the Registration Server. There is no need
for a Controller to physically enter a user id and password. Once the Registration Server has validated
the response, it registers the Contact address of the SIP user agent (CWP/SIP Network Interface/SIP
gateway) in its database. This database is used by SIP Proxy servers to route the requests it receives.
When a CWP/SIP Network Interface/SIP gateway is closed for maintenanc e purposes it will have to
firstly cancel its registration with the SIP Registration Server. In this case a spare CWP/SIP Network
Interface /SIP gateway devices would register and take -over the role of the closed equipment and
provide a new contact URL address at the SIP Registration Server.
Redirect Server
The infrastructure also contains a Redirect Server. In the case that the SIP User Agent 1 needs to contact
SIP User Agent 2 it could send a request to a Redirect Server that would interrogate the loca tion
database and return all known URI addresses for SIP User Agent 2. The Invite request to the Redirect
Server would use the known URI of SIP User Agent 2. The Response from the Redirect Server would
indicate one or more alternative URIs for SIP User Agent 2.
With this information, SIP User Agent 1 would then automatically start a new call to SIP User Agent 2
using the new URI address supplied by the Redirect Server.
In the Air Traffic environment this function could be applied during night operation when sectors are
collapsed, in order to re-direct (forward) incoming calls to a limited group of CWPs.
Produced by JSP Teleconsultancy

139

SIP Gateway User Agent


A SIP gateway User Agent is an application that interfaces a SIP network to a network using another
signalling protocol. In terms of the SIP protocol, a gateway is just a special type of user agent, where the
user agent acts on behalf of another protocol. A gateway will actually comprise of a SIP signalling
gateway (responsible for interworking between SIP and other signalling proto cols) and a Media gateway
(responsible for converting between the packet switched RTP media (voice) and the voice on the circuit
switched network).
With such a SIP gateway in the AGVN, interworking between SIP and ATS -QSIG, ATS-R2, and E1
using CAS protocols and even the public PSTN, ISDN would be possible.
It is possible that a SIP gateway could support many hundreds of users. Normally only the gateway and
not all the users that it represents have to register with the Registration Server.
Voice Media path establishment
When SIP User Agents have used the SIP protocol to establish an end -to-end media path between CWPs,
it is possible to use this path to transport speech using the Real Time Protocol (RTP) over UDP/IP.
The Speech path between SIP User Agents 1 and 2 can be established as a direct connection between
them through the IP network (without having to go via the SIP Proxy Servers).
The Speech can either be ITU-T G.711 PCM encoded Voice or even compressed voice. SIP User Agents
are pre-configured to know their Voice Codec capabilities. During the call establishment phase, a
calling User Agent is able to inform the called User Agent of its Voice Codec capabilities available,
using the Session Description Protocol (SDP) embedded in the SIP request . The called User Agent is
then able to reply with the selection of a particular Voice codec in a SIP response. The voice codec
negotiated through SDP is that used for the communication and will be the same as the codec defined by
the RTP audio identifier field within the RTP application.
Voice Media path clearing
When the communication between the two SIP User Agents is terminated, SIP requests and responses
are exchanged between the SIP User Agents via the SIP Proxy Servers to release the end -to-end media
path.
A typical SIP Server
In reality a SIP server can consist of a SIP Proxy application (configured as either stateful or stateless), a SIP
Redirect application and a SIP Registration application all integrated on the same platform. It is capable of using
both the User Datagram Protocol (UDP) and the Transport Control protocol (TCP).
The SIP Proxy Server can be configured to use Transport Layer Security (TLS) encryption at the application
layer for transport of SIP requests and responses. Beside this it also transports IPsec for end to end security.
Thirdly it is possible to configured Access Control Lists (ACL) within the SIP Proxy in order to prevent calls
from unrecognised addresses.
With respect to call routing, it can interrogate a DNS servers for addresses, use external Telephone Numbering
Mapping (ENUM) or have its routes statically configured.
With respect to Call Accounting, the SIP Proxy Server can generate records (Call Detail records)
relating to all call attempts.
These are also time stamped and so can be used as Call Detail Records for a VCS.
Extra network resilience and a high availability can be achieved within the AGVN by installing an
active redundant SIP Proxy Server alongside each active main SIP Proxy in case the main fails . These
SIP Proxy Servers can even be configured to share the load.
Regarding the DNS servers, network resilience can also be improved by also installing redundant DNS
servers within each VCS domain. At a Central level the Root Server in the VoIP infrastr ucture would
also have to be duplicated at two different network locations to guarantee high network availability and
avoid single points of failure.
Some of the faster SIP Proxy server platforms with processing speeds in excess of 2GHz are able to
handle 1000 calls per second.

140

Copyright 2014 JSP-Teleconsultancy

Example of Sector delegation from ACC1 to ACC2


SYSTEM A controls Sector X (all calls in network to Sector X address are routed to SYSTEM A)
SYSTEMS A and B are locally pre-configured for Sector X to be able to manage it when under their control.
SYSTEM A receives Network Management (NM) Push command to handover Sector X to SYSTEM B.
SYSTEM A updates Sector X address in its Local Location DB to that of SYSTEM B. Proxy A updated.
SYSTEM B receives Network Management (NM) Pull command of Sector X from SYSTEM A.
SYSTEM B updates Sector X address in its Local Location DB to that of SYSTEM B. Proxy B updated.
All Proxy servers are updated so that calls to Sector X are now routed to B. (Protocol specification required for
this?)
SYSTEM A confirms to NM that it is no longer in control of Sector X.
SYSTEM B confirms to NM that it now controls Sector X. Requires previous controller input to accept Sector
X.
If calls bound for Sector X still arrive at SYSTEM A (because Originating Proxies not updated with new
address), SYSTEM A would re-route calls to SYSTEM B.
Once Proxies updated all calls bound for Sector X would now arrive at SYSTEM B directly.

142

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

Impacts of VoIP on Voice Communication Systems

The introduction of VoIP within the AGVN is likely to cause a major change to the circuit switched and TDM
based VCS communication architectures in operation today.
Although initially VCS suppliers will adapt their existing circuit switched VCSs or develop IP-VCS products
capable of interfacing with both circuit and packet switched networks, the long term future will be a new
generation of pure packet-switched VCSs with IP architectures containing VoIP interfaces for both Telephone
and Radio applications. Any interworking with the old circuit switched networks would then be performed by
circuit-switch interworking gateway products.
With the integration of SIP network interfaces within the VCS, a VCS supplier can protect their existing VCS
product and at the same time allow the continued interoperability of many of their inter-VCS features. However
it would probably need a considerable change to the VCSs functional architecture and also a major software
upgrade to the VCS, which can require considerable investment in equipment etc. Further costs would be
involved in performing backwards compatibility testing of existing VCS features and functionality. This could
lead to VCS suppliers considering development of a new generation of VCS.
The SIP architecture will move away from the centralized control TDM architectures using PCM technology
towards intelligent SIP User Agents at the endpoints. SIP user agents will be able to Register their presence on
the network either automatically at power-up or following maintenance procedures by using Registrar Server.
The new Ground Telephony interfaces as SIP User Agents within the VCS, can either have direct access to the
SIP User Agents in other VCSs or access the network through a SIP Proxy Server. Likewise new Radio
Telephone network interfaces as SIP User Agents within the VCS, can either have direct access to the SIP User
Agents at the Radio Sip User Agent or access the network through a SIP Proxy Server.
Location servers will serve to identify the present location and address of a user when an incoming call is
received.
Due to the number of addresses required in the network being limited, with most calls being made to or received
from adjacent units, it is undecided if every ATS unit should have its own DNS server in order to identify IP
addresses of non-local users.
A VCS supplier will have the choice of either developing VoIP interfaces containing SIP user agents and
keeping their present Legacy user/network interfaces with CWPs or else they may decide to develop a SIP based
CWP.
With respect to Ground Telephony and maybe Ground Radio, it is possible that future CWPs will follow the
path of SIP telephones with the integration of SIP User Agent Clients directly within a CWP. Many SIP CWPs
in a single ATS unit can be connected to an Ethernet LAN rather than to the VCS user ports. The Ethernet LAN
would have access to a local SIP Proxy server in order to access the IP network. The call control functionality
would be located within the CWP itself.
A SIP based CWP however will require a major redevelopment of the present CWP architecture and a major
software upgrade to the CWP which can require considerable investment in equipment. With the introduction of
IP technology the CWPs would probably follow the path taken by SIP telephones available today, but offer
enhanced functionality with respect to SIP telephones.
The structure and appearance of a CWP will be almost identical to todays CWP due to the users being
accustomed to this human machine interface method of working. Their touch sensitive displays would be similar
to those of today with DA panels, IA panels, Dialled Number Display, IDA call keypads and call queues,
common function keys etc. It is possible that through the SIP protocol some new features could be integrated
which dont exist today due to the limitations of present signalling mechanisms.

Produced by JSP Teleconsultancy

143

Impacts of VoIP on Voice


Communication Systems
VoIP integration will have influence on VCS architecture.
Will lead to new generation of VCSs (IP-VCS) using packet
instead of circuit switching based architectures, no longer TDM
based;
Move away from Central control of TDM system to control at
intelligent SIP-UA endpoints (VCS interfaces or even to SIP based
CWPs);
Introduction of SIP Proxy (for network access) , SIP Registration &
Location Servers within ANSP domain (i.e. ATS unit); Undecided if
DNS servers necessary as number of addresses are limited, with
calls to/from adjacent units only;
VCS Gateway or Standalone Gateway may extend VCS life for a
while and guarantee interop. with existing protocols; TDM v SIP
addressing mapping; Voice transcoding at gateway is not
necessary;

144

Copyright 2014 JSP-Teleconsultancy

IP network impacts for Telephone calls


Pure VCS-to-VCS VoIP Calls using SIP will be possible between VCS suppliers with common
interfaces compliant with the future EUROCAE standard . The EUROCAE specifications define the SIP
operation for DA, IDA and IA calls and also a wide range of SIP features (comparable with the range of
supplementary services available in many of todays commercial PBXs).
Its implementation will eventually lead to an AGVN that even enables interoperability of Instantaneous
Access type calls and a wide range of features not possible in todays networks. The interface would
also include one or several Voice codecs, however it is likely that the ITU -T G.711 PCM 64kbps will
be the preferred voice codec, while a second lower bandwidth, high quality voice codec could also be
included, used in the case that available bandwidth is becoming scarce.
SIP signalling protocol used by the various call types (i.e. DA, IDA a nd IA) will be identical. There
should also be no distinction in the protocol between routine and priority (emergency) calls. Identifying
the type of call is performed by a Subject header field (i.e. DA/IDA call, IA call etc). Setting the
urgency of the call request in order to allow the SIP user agent to understand if the call is an IDA/DA
routine call, IA call or IDA/DA Priority call is performed by assigning them different values in a SIP
Priority Header field. The Priority header field is used by a User Agent to set the urgency of a call
request. This header is used to override screening or by servers in loading -shedding mechanisms.
With SIP signalling over IP networks, IA calls could be utilized to a greater extent for international
cross border voice communication between different ATS units. There is also a need for Instantaneous
Access (IA) calls in high density areas with Radar Separation minima less than 5 nautical miles.
Within IP networks IA, DA, IDA calls etc all share the same network resource s.
In terms of signalling and call performance, IA calls are not treated any differently to DA or IDA calls
in an IP network. They shall be assigned the Urgent SIP Priority Header allowing a CWP to direct it
to an IA key.
Todays VCSs offer a range of supplementary services (features) to its users. Many of these however
have been developed using proprietary signalling methods or have been customized to satisfy customer
requirements. This makes interworking of many supplementary services between differ ent VCS
suppliers impossible.
EUROCAE WG67s approach has been to identify existing IETF RFCs standards and draft standards
where possible and apply these to ATC requirements. By having a common standard this will enable
interoperability of the supplementary service across the IP network that previously could not be
achieved in the circuit switched networks. Also a common standard implies that SIP application
software relating to the individual supplementary services could readily be purchased from a softw are
house, reducing development costs and making the task of supplementary service interoperability
testing easier.
Features with existing RFCs include: Call Hold, Call Transfer, Call forwarding, Call Pick -up, Call
completion, conference and many more.
SIP will also allow many new features to be introduced that were not possible using the TDM based
signalling methods. For example Presence and Dialogue packages and a whole series of Event packages.
Location services will make it easier to move Roles perfor med by Sector Suites/CWPs around within
same ATS unit (in case of resectorization) or to different ATS units (in case of FAB control) requires
informing the Registrar Server of the current sector suite address responsible for the Role and new
sector suite address responsible for the Role. The Registrar server will then update the Location database
with this information. This will cause all new incoming calls to be forwarded to the sector suite address
responsible for the Role at any time.

146

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

IP network impacts for Telephone


calls
SIP Telephone User Agent interfaces within VCS allowing
either direct connection to other SIP Telephone User Agents
or through SIP Proxy Servers (following authentication);
Pure SIP-SIP Network calls possible for DA, IDA, IA
(European), OVR (FAA); Priority (Emergency) DA calls are
also possible;
Wide range of features already defined by RFCs to be used
across network;
New features like CWP presence and dialogue status
event package etc could be introduced.
Location services used to allow Role performed by one ATSunit to be moved internally or to another ATS-unit.

Produced by JSP Teleconsultancy

147

Communication between VCS's


The slide has the scope of demonstrating the establishment of a DA and IA call using SIP.
For DA call a SIP session is established on demand by the calling party to the called party by selection of the
DA key on the DA panel. When the DA call is answered by the called party, a two-way RTP speech path is then
established between the parties during which audio packets are exchanged. Either party can clear the DA call
once established.
For IA call a SIP session is established on demand by the calling party to the called party by selection of the IA
key on the IA panel. The IA call is automatically answered at the called party side and a one-way speech path is
then established from calling to called party with monitoring of all Air-ground and Ground-Ground
communications in progress at the called party side by the calling party. Summed audio is therefore sent on the
return path towards the calling party of A/G and G/G communications in progress. IA call monitoring can be
enabled or disabled at the called party side and is a feature that depends on ANSP policy.
Should the Called party now wish to reply to the message from the Calling party, selection of the IA key on the
IA panel will now make a completely independent IA call with a onw-way speech path established from called
to calling party and monitoring of A/G and G/G calls in progress at the Calling party .
In the above case two SIP sessions will have now been established.
In order to prevent Acoustic Feedback it is necessary that the VCS blocks audio received on the forward path
from one call being summed with audio being sent back on the monitoring path of the second call.

148

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

Communication between VCS's


DA call with Voice Activity Detection disabled
VCS B

VCS A
SIP signalling used to establish session

Two-way speech

CR

CR

DA Panel

DA Panel

IA call with Voice Activity Detection disabled


B

VCS A

SIP signalling used to establish IA session

One-way speech
IA Panel

Monitoring- Radio & Tel. Speech at A

VCS B
A
IA Panel

SIP signalling used to establish IA session

One-way speech
Monitoring- Radio & Tel. Speech at B

Produced by JSP Teleconsultancy

149

FAA Override Call operation


FAA Override Calls (OVR)

One of the principal call types used by the Federal Aviation Administration (FAA). It is used in the same
manner in both ACCs (En-route) and Approach environments.
An OVR call can be made between two parties at the same ATS unit (intra-facility call) or between two parties
at different ATS units (inter-facility call).
The FAA OVR Call is call type initiated by an A-party, with automatic answer at B-party side, resulting in twoway audio path establishment between A-party and B-party.
The A-party hears all local B-party Ground-Ground, Air-Ground communications plus B-microphone (Hot
mic) audio plus audio upstream from B-party;
The B-party hears all local A-party Ground-Ground comms plus A-microphone (Hot-mic) audio plus audio
downstream from A-party;
The B-party sends Summed audio stream to A-party containing its local audio (G/G + A/G + B-Mic) plus (in
case it has outgoing OVR call established to C-party) summed audio stream being received from C-party
(G/G +A/G+C-Mic).
The A-party sends Summed audio stream to B-party containing A party local audio (G/G + A-mic) plus in
case A-party has incoming (OVR call(s) from 3rd parties) summed audio stream (G/G + Hot Mic) being
received from these parties.
A-party audio stream not sent on B-partys air-ground uplink.
FAA OVR call operation
OVR calls made using pre-configured Touch keys or via Indirect Access dial pad;
Dial tone and Ringback tone not given to the 'A'-party. Terminal out-of-service tone given if call fails;
A position can make only one outgoing OVR call at a time;
Position is prevented from making OVR call if DA call is already established at position; (unless DA call
placed on hold);
A position can receive multiple incoming OVR calls. Should manage at least 9 up to max system defined
limit; (audible alert given on call connection);
OVR call automatically established independent of actual B-party status (i.e. other active G/G or A/G calls
in progress);
Incoming OVR call to position with no pre-configured key enters call queue (with OVR call indication);
Call performance imposed by FAA is 200ms maximum as an NVS requirement (interval from INVITE to
200OK).
All positions connected by OVR calls (either incoming or outgoing) form one composite conference with
all users able to hear audio from all other users.
A DA call in progress at B-party on incoming call arrival is also conferenced.
The OVR Call can be terminated by either A or B-party;
Forbidden to pre-empt, transfer or place OVR calls on-hold;
OVR call shall not be refused by the B-party.
OVR call that exceeds 'B'-party OVR call limit does not hear busy tone. Instead a 2-party call only is
established, while B-party places original OVR conference On-Hold for call duration. Warning message
forwarded to Supervisor position.

150

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

FAA Override Call operation


VCS A

A-Party

SIP signalling used to establish IA session

VCS B

B-Party

B
2-way speech with mandatory monitoring

of Radio, Tel and Mic at B side


Touch Panel

Touch Panel

Outgoing scenario: Press touch key on panel or dial number to automatically


establish 2-way speech path; A-party hears all local B-party G/G, A/G comms
+ B-microphone (Hot mic) + audio upstream from B-party;
No Dial or Ringing tone; Number unobtainable tone mandatory;

Incoming scenario: OVR call arrival indicated by audio & visual means;
automatic answer regardless G/G or A/G calls in progress; B-party returns
speech without touch key action; B-party hears all local A-party G/G-comms +
A-microphone (Hot-mic) audio+ G/G audio downstream from A-party;
Performance: FAA NVS requirement indicating OVR calls should be
established within 200ms. This is delay between A-party initiating call and
speech path being established.
Audio loop detection/prevention algorithm built into protocol: When loop
detected takes necessary action on summed audio flows to prevent acoustic
feedback.

Produced by JSP Teleconsultancy

151

FAA OVR call Audio loop detection


FAA OVR Audio Loop detection
In order to prevent either echoing or audio feedback, VCS systems SHALL implement an audio loop detection
method in order to avoid possible problems derived from the same audio coming to a partys operator position
through two different RTP paths. This audio loop detection method shall prevent a loop from occurring in a
chain of OVR calls.
For the case that establishment of an OVR call would form a loop (i.e. A calls B, B calls C and then C calls A),
a loop closure detection algorithm SHALL be implemented in the protocol in order to prevent operators from
hearing acoustic feedback. Once an OVR call is made that will cause a loop to occur, then actions SHALL be
taken in order to prevent acoustic feedback caused by audio circulating continuously around a loop of audio
paths formed by establishment of a loop of OVR calls.
This will imply blocking summed audio streams at the point where loop detection has occurred from being
passed on to both the successive and previous VCS systems.

152

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

Produced by JSP Teleconsultancy

153

Impacts of VoIP on Radios


The work being performed by EUROCAE WG67 in the definition of the future VoIP specifications for
an ATS environment, have resulted in the first Common Radio Interface and signalling protocol for the
ATS domain. This defines VoIP radio interfaces at both the VCS, RCE, and the Radio itself.
The fact that a Radio has a VoIP interface, would therefore most probably bypass the need for RCE at
the remote radio site.
The Radios containing SIP User agents become more intelligent. They are able to manage
SIP/SDP/R2S/RTP/UDP/IP etc have built-in call control etc and maybe a range of different audio
codecs.
It is possible to establish up to 7 SIP sessions with the radio from different VCSs and SIP user agents
each identified with a different SIP address. The establishmen t of a SIP session doesnt imply that voice
is being transmitted and received, only that the session is ready to transmit and/or receive voice.
The Radio with built-in SDP is able to negotiate a wide range of parameters with the VCS endpoint that
are to be adopted during the communication. These include Codec type, Best Signal Selection method,
Call type (Radio-Rx, Radio-TxRx, Coupling), Keep-alive packet intervals, Radio Type (Tx/Rx, Tx, Rx).
Frequency Identity check etc
The Radio knows if it is part of a Cross-coupling group. During SIP session establishment a VCS may
request that a Radio becomes part of its Cross-coupling group. A Radio can only be part of one Cross
Coupling group. If the Radio accepts this request then it must reject further requests f rom other VCSs
or User Agents to become apart of their cross-coupling group. This methodology should therefore
prevent a Radio from becoming part of two or more Cross -coupling groups which can lead to the nasty
effects of Cross-coupling chains and loops which can result in frequency blocking at the VCS.
Following SIP session establishment, a Real Time Session Supervision protocol is continuously used
when there are no audio packets being transported to ensure that the remote peer node is always
reachable.
An advantage of packet switched voice is that voice has the capability to be delayed. This is often
perceived as a disadvantage. It can however be an advantage in environments where, PTT needs to be
activated prior to the voice being output. The PTT act ivation command should still arrive at the radio
however within 30ms, but voice output can be delayed as long as the end -to-end delay requirements as
defined by G.114 are met.

154

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

Impacts of VoIP on Radios


WG67 have defined spec for 1st Common Radio Interface &
signalling protocol in ATS domain;
As SIP User Agent is within Radio, bypasses need for RCE at remote
radio site;
Intelligence in Radio -SIP/SDP/R2S/RTP/ UDP/IP, Call control. Can
allow from 2 to 7 SIP sessions to be established from different VCSs
or SIP user agents (ANSP dependent);
Negotiation of Codecs, BSS method, Call type (Radio-Rxonly/ RadioTxRx/Coupling), Keep-alive packet intervals, Radio Type (Tx/Rx, Tx,
Rx), Frequency Identity check etc
Radio knows if its part of Cross-coupling group- prevent cross
coupling chains;
Real-time Session Supervision protocol (R2S) ensures reachability of
radios in real time;
Possible to delay voice packet transmission of first syllables following
PTT activation prior to Transmitter is activated and modulating to
correct level.

Produced by JSP Teleconsultancy

155

IP network impacts for Radio calls


Pure end-to-end SIP signalling between the VCS and GRS endpoints is possible for Radio.
PTT/Squelch/Best Signal Selection (BSS)/Simultaneous Call Transmissions (SCT) /Climax Time Delay
(CLD) are transported inband when PTT/Squelch activated or with the R2S -Keep-alive packets when
PTT/Squelch not activated.
A Radio can be configured for PTT lock-out or PTT summation modes- PTT lockout mode will only
allow the first PTT signal received to transmit its audio, while PTT summation will allow more than one
user with PTT activated to transmit their audio. The radio performs the audio summing functions prior to
transmission.
A hierarchy of different PTT levels has been defined for different situations. Explained later.
A Radio is able to detect simultaneous transmissions on same frequency from two or more aircraft and
send a warning signal to the VCS User agent.
The radio is also able to recognise Off-air squelch due to a transmission.
It is also possible to send different Climax delay values to each GRS transmitter in an effort to reduce
the effects of echo in the cockpit. A feedback mechanism to automatically measure the network
propagation delay in real time to each GRS Transmitter and compensate the Climax Time Delay values
in the transmit path shall be explained later.
Audio would be transmitted as for Ground Telephony networks, using RTP over UDP over IP. The
preferred voice codec between VCS and Radio is ITU-T G.711 PCM A or u-law (Payload Types 8 or 0)
at it allows toll voice quality voice at 64kbps. The optional codec ITU -T G.729 CS-ACELP codec could
also be used providing good quality voice at 8kbps.

Communication between VCS's and Radios

156

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

IP network impacts for Radio calls


Radio User Agent interfaces within GRS allowing direct connection to
SIP User Agents at VCS endpoints. Not expected to have SIP Proxy
Servers at Remote Radio sites;
Pure SIP-SIP Network calls possible for Radio;
Radio responsible for allocating PTT identity to each VCS User
Agent that can activate its PTT.
PTT/Squelch/BSS/Simultaneous Transmission Detection/ Climax
Time Delay signals all transported inband with RTP voice packets
(when PTT/SQU active) and with R2S keep-alive packets (when
PTT/SQU non-active) using an RTP Header Extension;
Radio can be configured for lock-out or summation of audio streams.
Hierarchy of PTT levels defined with Radio switching, blocking or
summing streams according to its configuration;
Can warn of simultaneous transmissions on same frequency

Communication between VCS's


and Radios
STEP 1: Establish SIP session to Radio
STEP 2: Establish R2S protocol with exchange of keepalive
packets every 200ms;
STEP 3: Controller activates PTT, 20ms audio packets sent &
received from radio.
STEP 4: Pilot activates A/C call, 20ms audio packets sent to
VCS, while 200ms keep-alive sent by VCS to Radio;
VCS

Transceiver

Produced by JSP Teleconsultancy

157

What is Remote Radio Control Equipment?

158

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

What is Remote Radio Control


Equipment?
Radio Gateway that enables analog radios/VoIP radios in various
Single (F1)/ Paired Frequency (F1/F2) combinations to interwork
with EUROCAE VoIP Radio i/f at each VCS through one 1 SIP
session & 1 RTP stream.
Handles from 1 session with 1 VCS (Single Channel mode) to
multiple sessions with VCSs (Dual Control mode)
Radio selection commands received from a VCS.
RRCE acknowledges command towards all connected VCS(s)
For Controller to Pilot transmission, directs PTT signal and Voice
towards selected VHF and or UHF transmitters.
For Pilot to Controller transmissions, directs Squelch break signal
and Voice from selected VHF and or UHF receivers and Signal
Quality info related to selected signals.
Handles Main/Standby switchover for VHF and UHF Radio
Transmitters and Radio Receivers. Handles muting of VHF and/or
UHF receiver.

Produced by JSP Teleconsultancy

159

FAA Radio Gateway Overview


Radio Remote Control Equipment (RRCE)
Radio Gateway that enables analog radios/VoIP radios in various Single (F1)/ Paired Frequency (F1/F2)
combinations to interwork with EUROCAE VoIP Radio i/f at each VCS through one 1 SIP session & 1 RTP
stream.
Handles from 1 session with 1 VCS (Single Channel mode) to multiple sessions with VCSs (Dual Control
mode)
Radio selection commands received from a VCS.
RRCE acknowledges command towards all connected VCS(s)
For Controller to Pilot transmission, directs PTT signal and Voice towards selected VHF and or UHF
transmitters.
For Pilot to Controller transmissions, directs Squelch break signal and Voice from selected VHF and or UHF
receivers and Signal Quality info related to selected signals.
Handles Main/Standby switchover for VHF and UHF Radio Transmitters and Radio Receivers. Handles
muting of VHF and/or UHF receiver.
For the Dual Control Configuration only the RRCE can be configured to work in Priority mode or Nonpriority mode. Priority allows 2 levels of PTT (i.e. Normal and Priority), while non-priority mode allows
only one PTT level (i.e. Normal).
Single Frequency configurations

Radio connected to RRCE

Single Frequency Configurations

Main F1 Transmitter (MTxF1) and


Standby F1Transmitter (STxF1)

For VHF Transmitter only

Main F1 Receiver (MRxF1) and


Standby F1 Receiver (SRxF1)

For VHF Receiver only

Main F2 Transmitter (MTxF2) and


Standby F2 Transmitter (STxF2)

For UHF Transmitter only

Main F2 Receiver (MRxF2) and


Standby F2 Receiver (SRxF2)

For UHF Receiver only

For VHF Transmitter and


Receiver

For UHF Transmitter and


Receiver

Paired frequency configurations

Radio connected to RRCE


Main F1 Transmitter (MTxF1) and
Standby F1Transmitter (STxF1)
Main F2 Transmitter (MTxF2) and
Standby F2 Transmitter (STxF2)
Main F1 Receiver (MRxF1) and
Standby F1 Receiver (SRxF1)
Main F2 Receiver (MRxF2) and
Standby F2 Receiver (SRxF2)

Paired Frequency Configurations


For VHF and UHF
Transmitters only

For VHF and UHF Transmitters


and Receivers

For VHF and UHF Receivers


only

Main/Standby Switchover command


Main/Standby Transmitter and/or Receiver switchover occurs as soon as command is received except
during active transmissions.
F1 or F2 Main/Standby transmitter switchover not allowed while transmitter is active (it is receiving a PTTON signal). Switchover occurs as soon as transmission stops (PTT-OFF signal received).
F1 or F2 Main/Standby receiver switchover during reception of an incoming aircraft call or off-air audio is
allowed (by default). If disabled however receiver switchover occurs as soon as reception stops.

160

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

FAA Radio Gateway Overview


GRS-VHF

VCS

MTxF1

RRC

CWP1

STxF1

RCE

GRS-UHF

RTPTx HE Type 3-RRC commands

MTxF2
STxF2

CWP2

GRS-VHF
MRxF1
RTPRx HE Type 3-RRC Ack

SRxF1

CWP3

GRS-UHF
MRxF2
SRxF2

VALUE FIELD for RTP Tx/Rx HE - Type 3 Additional Feature


MSTx
F1

MSRx
F1

0/ 1

0/ 1

MSTx
F2

MSRx
F2

SelTx
F1

SelTx
F2

MuRx
F1

MuRx
F2

0/ 1

0/ 1

0/ 1

0/ 1

0/ 1

0/ 1

Produced by JSP Teleconsultancy

161

Impacts of VoIP on Recorders

WG67 have defined Recording Interoperability Specification (ED137);

SIP User Agent is within Recorder;

Intelligence in Recorder -SIP/SDP/RTSP/TCP/IP, Call control.

Allows multiple sessions to be established from different VCS or GRS SIP user agents sending mixed
incoming and outgoing audio;

Multiple Speech codecs (G.711, G.728, G.729)

Uses Real Time Streaming Protocol RTSP over TCP as reliable delivery service for recording of all voice
packets without losses.

Uses RTSP control messages to Start and Pause recording, Describe a stored session and Play
recorded messages for 3rd parties to hear.

162

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

Impacts of VoIP on Recorders


WG67 have defined Recording Interoperability Specification (ED137);
SIP User Agent is within Recorder;
Intelligence in Recorder -SIP/SDP/RTSP/TCP/IP, Call control.
Allows multiple sessions to be established from different VCS or GRS
SIP user agents sending mixed incoming and outgoing audio;
Multiple Speech codecs (G.711, G.728, G.729)
Uses Real Time Streaming Protocol RTSP over TCP as reliable
delivery service for recording of all voice packets without losses.
Uses RTSP control messages to Start and Pause recording,
Describe a stored session and Play recorded messages for 3rd
parties to hear.
CWP User Agent

OUT

IP Network

IN

OUT

CWP User Agent

IN
VCS
User Agent

VCS
User Agent

IN & OUT

IN & OUT
Tx & Rx

Recorder
User Agent

Rx only

Produced by JSP Teleconsultancy

GRS
User Agent

163

Improved Access to Real Time Information (Subscriptions)


WG67 KEY-IN Event Package
This WG67 KEY-IN event package SHALL be used to inform any SIP User Agent in the network that has
subscribed to the WG67 KEY-IN service about all VCS entities in the network that have established a session
with the GRS Transceiver/Transmitter (i.e. have the capability to activate PTT towards the GRS transmitter).
When the GRS Transceiver/Transmitter accepts a request from a VCS to establish a session, the GRS can
determine the SIP address of the requesting entity (defined in INVITE message) and will acknowledge session
connection by sending a 200OK response that also assigns a PTT-id in the SDP body.
A GRS will therefore know the SIP addresses of all entities that have established sessions to it.
It will be possible therefore for a supervisor to make a subscription to each GRS located in their sectors in order
to determine in real time the SIP addresses of other ATS-units/Users that have also established a session to any
specific GRS.
SUBSCRIBE
The SUBSCRIBE request message is used to request current state and also updates to the state from a remote
node. The Request URI of a SUBSCRIBE request contains enough information to route the request to the
appropriate entity (e.g. GRS Transceiver, Transmitter or GRS gateway equipment). It SHALL include exactly
one "Event" header indicating the event being subscribed. The "Event" header SHALL contain the token
WG67 KEY-IN which is indicating the type of state for which a subscription is being requested.
If a subscription between SIP UAs (e.g. at VCS and GRS Transceiver or Transmitter endpoints) is made, the
process SHALL be implemented according to RFC 3265.
NOTIFY
NOTIFY request messages are sent to inform subscribers of the current state and changes in state to which the
subscriber has a subscription. As with SUBSCRIBE requests, the NOTIFY "Event" header SHALL contain
WG67 KEY-IN as single event package name for which a notification is being generated. The Contenttype header SHALL contain: text/plain.
The GRS Transceiver, Transmitter or GRS gateway equipment SHALL notify all subscribed User Agents
whenever a User Agent at a VCS endpoint either establishes or disconnects a SIP session to the User Agent at
the GRS or GRS gateway equipment. A complete list of bindings between ptt-id and SIP URIs SHALL be
provided.

CWP Presence
Presence information can be thought of as the presence of a user or device within the network at any
particular instant. Within the ATS environment presence information can be used to indicate if a
particular remote CWP is operational or not. Today an ATC supervisor or technical staff may only be
informed of a communication problem when either automatic period test calls have failed or a controller
can no longer make calls to a remote CWP.
Using Presence information an ATC supervisor and
Technical staff working within an ATS unit could be informed in real time of the operational status of
every CWP in their neighbouring ATS units. If a particular CWP was closed down, a message informing
them of the fact could be sent.
It would involve the Supervisor CWP making a subscription (lo ng term relationship) with the Presence
Agent located within all neighbouring ATS units. The Presence Agent is an application running on a
Server (i.e. Presence Server or Proxy Server), capable of identifying the presence status of all the
registered CWPs in that domain. The Subscription would request presence information changes to the
relevant CWPs in that ATS unit. Once a subscription was made, every time a CWP was closed or
opened, notification would be sent to the Supervisor. This could lead to improv ed safety as an ATS unit
would know the present status of the CWPs in all its neighbouring ATS units.
Note: Subscriptions have an expiry period and therefore have to be renewed periodically.
Presence information SHALL be handled as defined by the Presence Event Package
for the Session Initiation Protocol (SIP) (RFC 3856).

164

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

Possible future Dialogue Event package (not defined at present in ED137)


The dialogue package would be an application running within every CWP allowing notification of its
call state to other remote CWPs who need to know this information.
A CWP would be configured to make a dialogue subscription to all the remote CWPs destinations
indicated on their DA panel. This subscription could request that notification is sent if the CWP is in
an active call (confirmed) or Free state for example. From these notifications it would then be possible
for a controller to immediately see the current state of a remote CWP in real time through an indication
on the DA key associated with that destination. If it was seen that the remote CWP already had an active
call in progress, then the calling controller would probably wait until a free state was indicated before
making the call (unless of course the call was an emergency call).
This could even be extended to include the physical presence of a controller at their CWP. Normally
Radio calls can only be made from a CWP when an audio device (i.e. headset, handset or microphone) is
plugged in to the CWP. The presence of an audio device plugged into the CWP could therefore be
assumed to imply the presence of the Controller at the CWP. Notifications could be sent to subscribed
CWPs or supervisors warning them that there is nobody present at that CWP.
An authentication process would be implemented when a CWP subscribes to the dialogue of other
CWPs.
Note: Subscriptions have an expiry period and therefore have to be renewed periodically. It should be
noted however that this service would cause a huge increase in the amount of signalling being
exchanged between systems, especially if every CWP subscribed to the dialogue of all their
neighbouring ATS units.

Produced by JSP Teleconsultancy

165

Migration to IP through Telephone Gateways

Migration to IP through Radio Gateways

166

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

Migration to IP through Telephone


Gateways
Existing
TDM VCS

Telephone
Gateway

VCS Telephone
Gateway

Existing
TDM VCS

IP

VoIP
VCS

IP
IP Network

IP

TDM

Existing
TDM VCS

IP

TDM

TDM

TDM Network

VCS Telephone
Gateway

VoIP
VCS
Telephone
Gateway

Existing
TDM VCS

Eventually TDM Network goes


Telephone GW eventually goes
VoIP VCS introduced

Migration to IP through Radio


Gateways
Existing
TDM VCS

Radio
Gateway

VCS Radio
Gateway

Analogue
Radio

IP
IP
IP Network
VoIP
Radio
IP

TDM

Existing
TDM VCS

IP

TDM

TDM Network

Analogue
Radio

TDM

VCS Radio
Gateway

Radio
Gateway

VoIP
Radio

VoIP Radios Introduced


Eventually TDM Network goes
Radio GW eventually goes
VoIP VCS introduced VCS Radio Gateway goes

Produced by JSP Teleconsultancy

167

CFMU Migration to PENS


CFMU Migration to PENS
Currently the CFMU VCS is connected to the ATS voice Network via multiple old analogue leased-lines.
The CFMU ATS voice network is a star network with Haren as central point.
The Older ATS voice protocols like MFC R2 or ATS-QSIG are used on these lines.
The majority of the remote sites are connected with two leased lines (active/active).
The goals of the CFMU project is to validate and test the transport of Voice through PENS.
To replace the CFMU backup MFC links .
To build a robust Voice over PENS solution able to transport Operational voice traffic.
To reduce the cost of the ATS network in the short / medium term.

168

Copyright 2014 JSP-Teleconsultancy

VoIP in aeronautical communications

CFMU Migration to PENS

To validate and test transport of Voice through PENS.


To replace backup MFC links
To build a robust Voice over PENS solution able to transport
Operational voice traffic.
To reduce cost of ATS network in the short/medium term.

Produced by JSP Teleconsultancy

169

Next Generation ICAO 9896 VoIP


interfaces for ATS Ground Voice Network
- Part 1

170

Copyright 2014 JSP-Teleconsultancy

EUROCONTROL & FAA VoIP initiatives

6. EUROCONTROL & FAA VoIP initiatives

Produced by JSP Teleconsultancy

171

EUROCONTROL VoIP in ATM test specifications


EUROCONTROL have developed a series of VoIP in ATM test case specifications which provide a
comprehensive set of detailed test cases for telephony, radio and recording.
The new proposed versions of the test specifications are now at the second editions and follow the ED-137B
documents. After a consultation/review phase with stakeholders they shall be issued as edition 2.0.

Test Specification
VoIP in ATM Cross-Reference Matrix ed
1.9-Decemeber 2012.pdf
VoIP in ATM Radio interoperability Test
case specification ed 1.9 - December
2012.pdf
VoIP in ATM Telephony interoperability
Test case specification ed 1.9 - December
2012.pdf

VoIP in ATM Recorder and Event logging


interoperability Test case specification ed
1.9 December 2012.pdf

SIP v ATS-QSIG gateway interworking test


specification ed 1.9 - December 2012.pdf

SIP v ATS-R2 gateway interworking test


specification ed 1.9 - December 2012.pdf

VoIP in ATM Test suite - High Level


Description of Conformance Test Cases, ed
2.0 October 2012 .pdf new proposed
version

Detail
Defines cross-references between the ED-136
requirement spec and the ED-137B interoperability
specs.
Defines a series of Interoperability Test case scenarios
between the VCS VoIP Radio interface and the GRS
VoIP radio interface.
Defines a series of Interoperability Test case scenarios
between the VCS VoIP telephone interface and a
second VCS VoIP telephone interface (multi-vendor
interoperability).
Defines a series of Interoperability Test case scenarios
between either VCS VoIP Telephone interfaces, VCS
Radio Interfaces and GRS VoIP radio interface and
the Recorder equipment (RTSP servers).
Defines a series of Interoperability Test case scenarios
between the VCS VoIP telephone interface and a VCS
or VCS telephone gateway with ATS-QSIG telephone
interface (multi-vendor interoperability).
Defines a series of Interoperability Test case scenarios
between the VCS VoIP telephone interface and a VCS
or VCS telephone gateway with MFC ATS-R2
telephone interface (multi-vendor interoperability).
Defines high level test purpose descriptions of the
conformance test cases related to the following
interfaces:
VCS VoIP telephone interface
VCS VoIP radio interface
GRS VoIP radio interface
REC VoIP interface within Recorder
REC VoIP interface within VCS/GRS

The above defined specifications are available on VOTE OneSky Team / Reference documents
The VoIP Test case specifications are intended to be aligned with the EUROCAE EDs. The above test
specifications align with EUROCAE ED-137B volumes published in January 2012.
These test specification now also cover recent updates to the EUROCAE documents from the FAA, VOTE SG1
and SG2 etc.
All draft or updated test specifications are always sent out for comments to Industry (VCS, GRS and REC
suppliers) and to ANSPs voice experts, to obtain their agreement on the updates.
These specifications have been used as an input to SESAR P 15.2.10 validation work that started its testing in
2011 and this work is still in progress until early 2013.

172

Copyright 2014 JSP-Teleconsultancy

EUROCONTROL & FAA VoIP initiatives

Produced by JSP Teleconsultancy

173

EUROCONTROL VoIP in ATM Test Suite development


VoIP Signalling Conformance Test tool

SESAR P 15.2.10 requires as prerequisite to be able to use a VoIP Signalling conformance test tool in order to
facilitate the validation activities over PENS in a cross-vendor environment.
To achieve this target, a VoIP in ATM test suite development will be developed during the first half of 2010.
The Test tool will be based on the EUROCONTROL Test Case Specification for VoIP in ATM (SIP-SIP). This
shall allow conformance testing to be implemented on the following VoIP in ATM SIP interfaces:

SIP Ground Telephone User Agents within a VCS or VCS Gateway;

SIP Ground Radio User Agents within a VCS;

SIP Ground Radio User Agents within a Radio or Radio Gateway;

SIP Ground Radio User Agents within a Recorder ;

Each of the VoIP in ATM Conformance Test Suites will consist of a series of encoded test cases that cover the
differences between EUROCAE ED137 specifications and IETF RFC 3261 in order to test added SIP/SDP
protocol functionality not covered by the RFC3261 test suite.
It is foreseen that the VoIP in ATM conformance test suites for the respective SIP entities will be
complementary to an existing Commercial SIP conformance test suite developed for SIP entities according to
IETF RFC 3261.
A maintenance contract for this tool (evolutive and corrective) is also considered to start as from mid 2010
onwards (and SHALL continue to support the tool through the lifetime of VoIP in ATM).
It is foreseen that the VoIP in ATM Conformance Test Suite shall be used by the following entities:

174

1.

VCS Suppliers to perform conformance testing on the SIP Telephone User Agents and SIP Radio User
Agents within a Voice Communication System or a Gateway.

2.

Radio Suppliers to perform conformance testing on the SIP Radio User Agents within a Radio or Radio
Gateway.

3.

Recorder Suppliers to perform conformance testing on the SIP Recorder User Agents within a
Recorder.

Copyright 2014 JSP-Teleconsultancy

EUROCONTROL & FAA VoIP initiatives

EUROCONTROL VoIP in ATM Test


Suite development
VoIP in ATM Test suite (nominated VOTER) developed for
following VoIP interfaces:
1. SIP Ground Telephone User Agents within a VCS or VCS Gateway;
2. SIP Ground Radio User Agents within a VCS;
3. SIP Ground Radio User Agents within a Radio or Radio Gateway;
4. SIP Ground Radio User Agents within a Recorder;

Runs on a Windows or Linux operating systems and requires


a License agreement with EUROCONTROL/Testing Tech.
Test suite validation task force (VCS, GRS & ANSPs) have
validated suite updating some test cases prior to its first
release.
Test cases defined by Annex A - High Level Description of
VoIP in ATM Test Cases, edition 1.9, Jan 2012 aligned with
ED137A September 2010;
Voter version 1.0.0 was issued in January 2012.

Produced by JSP Teleconsultancy

175

FAA Addendums

176

Copyright 2014 JSP-Teleconsultancy

European Single Sky Implementation (ESSI) Objective COM11


COM11 objectives relative to the Implementation of Voice over Internet Protocol (VoIP) in
ATM
Description and Purpose
Within pre-SWIM evolutions and preparation of SWIM implementation, the purpose of this ESSIP
implementation objective is to ensure that all ECAC States implement ATM-VoIP, which provides the
appropriate signalisation required for ATM voice communication.
The initiative covers inter centre (encompassing all type of ATM Units) voice communication and the links with
the ground radio stations
Inter centres voice communications are currently mainly performed via analogue circuits. In 2003, to implement
digital communications, the ATS-QSIG protocol has been chosen to replace part of these communications. At
present and in order to follow the evolution of the communication technologies, VoIP is identified as being the
medium term standard for ground telephone and ground segment of the Air-Ground voice. Industry has already
developed a standard for ATM-VoIP. The standard shall still be validated as part of SESAR JU WP15.2.10, but
several ANSPs expressed their wish to migrate quickly to ATM-VoIP for ground telephony and the ground
segment of the Air-Ground voice.
Furthermore, a number of Telecommunication Service Providers (TELCO-s) are planning to phase out analogue
and digital 64k circuits that support current analogue and digital ATM voice services. It is expected that current
services will begin to be phased out in a number of the ECAC States. A replacement of current analogue and
digital ATM voice services with a common standard is therefore strongly needed at European level.
The objective forecasts that all ECAC States migrate their ATM voice services to VoIP by the specified Full
Operational Capability (retrofit) dates: 12/ 2018 for inter-centre telephony and 12/2020 for links to the ground
radio stations. Initial Operational Capability
(Forward fit) date is 01/2013 for both inter-centre telephony and the links to the ground radio stations on the
ground segment of the Air-Ground voice.
Applicable area(s): All ECAC States
Operational capability dates FOR THIS OBJECTIVE: Initial operational capability: 01/2013, Full
operational capability: 12/2020

European ATM Master Plan relationship


Enabler - [CTE-C8]-Digital/VoIP for ground telephony
Enabler - [CTE-C9]-VoIP for ground segment of Air-Ground voice

Applicable legislation

Council Decision of 30 March 2009 endorsing the European Air traffic Management Master Plan of the
Single European Sky ATM Research (SESAR) project (2009/320/EC)

Commission Implementing Regulation (EU) N 1034/2 011 of 17 October 2011 on safety oversight in
air traffic management and air navigation services and amending Regulation (EU) N 691/2010 1 8-102011

Applicable ICAO Annexes and other references


1) Covers ICAO Global Plan Initiative GP-22.
2) EUROCONTROL- Strategic Guidance in Support of the Execution of the European ATM Master Plan Ed.
1.0 (05/2009) Annex D (ATM Infrastructure).

178

Copyright 2014 JSP-Teleconsultancy

EUROCONTROL & FAA VoIP initiatives

Stakeholder Lines of Action (SloA )

SloA ref

. Title

Start

Finish

Applicable to
Military

COM11-REG01

Conduct safety oversight of the changes

01/2012

12/2018

COM11-ASP01

Develop safety assessment for the changes

01/2012

12/2018

COM11-ASP02

Notify to the Regulator the planned means


& date of Initial and Full Operational
Capability

01/2012

12/2012

COM11-ASP03

Upgrade and put into service Voice


Communication Systems to support VoIP
inter-centre telephony

01/2013

12/2020

COM11-ASP04

Upgrade and put into service Voice


Communication Systems to support VoIP
links to the ground radio stations

01/2013

12/2020

Description of finalised SLoAs is available on the EIPR website at http://www.eurocontrol.int/articles/essipplan/

Consultation & Approval


Working arrangement in charge:

CNS / COM SG

Outline description approved in:

02/2009

Latest objective review at expert level in:

10/2009

Commitment decision body:

Provisional Council (PC)

Objective approved/endorsed in:

08/2011

Latest change to objective approved/endorsed in: -

Produced by JSP Teleconsultancy

179

Expected performance benefits


Safety :

Maintained or improved by providing enhanced signalisation functions.

Capacity :

Maintained or improved by providing enhanced signalisation functions. Prerequisite of


dynamic sectorisation through dynamic allocation of voice resources.

Cost-effectiveness :

Reduced costs by reusing Internet off the shelf technologies that can be based on
standard hardware.

Environment :

Enabler for dynamic sectorisations in Functional Block of Airspace (FAB).

Security:

N/A

Detailed SloA descriptions


COM11-REG01

Conduct safety oversight of


the changes

Start:01/2012

Finish:12/2018

Action by :

National Supervisory Authorities (NSAs)

Description &
purpose :

Oversee safety of the changes induced by upgrades of voice communication systems to


support VoIP both for intercentre telephony and AG radio communication. The tasks to
be done are as follows:

Analyse the safety case;


Review safety arguments;
Prepare the material for the acceptance of changes.

Supporting
material(s) :

EUROCONTROL - EAM 1 - ESARR 1 - Safety Oversight in ATM - Edition 2.0 / 0212-2009

Finalisation criteria :

1 - Formal acceptance by the NSA of the proposed changes communicated to ANSP.

COM11-ASP01

Develop safety assessment


for the changes

Start:01/2012

Finish:12/2018

Action by :

ANS Providers

Description & purpose


:

Develop safety assessment of the changes, notably upgrades of voice communication


systems to support VoIP both for inter-centre telephony and AG radio
communication. The tasks to be done are as follows:

Conduct hazard identification, risk assessment in order to define safety


objectives and safety requirements mitigating the risks;
Develop safety assessment;
Deliver safety assessment to the NSA, if new standards are applicable or if
the severity class of identified risks is 1 or 2.
This safety assessment shall be based on fully validated/recognised method.
Supporting material(s)
:

EUROCONTROL - EAM 4 - ESARR 4 - Risk Assessment and Mitigation in ATM Edition 1.0 / 05-04-2001
Url : http://www.eurocontrol.int/articles/esarr-4-risk-assessment-and-mitigation-atm

Finalisation criteria :

COM11-ASP02

Action by :

180

1 - The Safety argument for all changes, generated by the deployment of VoIP, has
been delivered by the ANSP to the NSA.

Notify to the Regulator the


planned means & date of Initial
and Full Operational Capability

Start:01/2012

ANS Providers

Copyright 2014 JSP-Teleconsultancy

Finish:12/2012

EUROCONTROL & FAA VoIP initiatives

Description & purpose


:

Notify their National Regulator their plan to migrate to VoIP. In this respect they will
have to:

Supporting material(s)
:

Prepare internal business and safety cases for their National Regulator;
Stipulate the target date for Initial Operational Capability and foreseen date
for Full operational Capability.

EUROCAE - ED-136 - Voice over Internet Protocol (VoIP) Air Traffic Management
(ATM) System Operational and Technical Requirements 28-02-2009
EUROCAE - ED-137B - Interoperability Standards for VoIP ATM Components (Vol.
1: Radio Vol. 2: Telephone Vol. 3: European Legacy Telephone Interworking
Vol.4: Recording Vol. 5: Supervision) Jan 2012
EUROCAE - ED-138 - Network Requirements and Performances for Voice over
Internet Protocol (VoIP) Air Traffic Management (ATM) Systems (Part 1: Network
Specification Part 2: Network Design Guideline) - 28.02.2009

Finalisation criteria :

COM11-ASP03

1 - The National Regulator has been informed by the ANSP of the planned means &
date of Initial and Full Operational Capability.

Upgrade and put into service Voice


Communication Systems to support
VoIP inter-centre telephony

Start:01/2013

Finish:12/2020

Action by :

ANS Providers

Description & purpose


:

Upgrade and put into service voice communication systems which support VoIP intercentre telephony which will enable the deployment of system enablers listed in References- section. The tasks to be done are as follows:

Define requirements which fit with operational/technical context and are


based on relevant standards;
Upgrade voice communication systems to comply with defined requirements;
Implement or purchase IP network services to enable international
communication exchange on IPS based protocol;
Purchase and install VCS equipment and/or gateways able to support VoIP in
ATM;
Implement the necessary IPv4/IPv6 translation device if required;
Test voice required connectivity and performance;
Update VoIP addressing information in the EUROCONTROL AGVN webdatabase;
Verify compliance with Interoperability Regulation(s);
Integrate upgraded voice communication systems into the EATM Network;
Put into service upgraded voice communication systems.
The upgraded voice communication systems and their HMI shall enable the operators
to perform the inter-centre communication using VoIP telephony at all types of ATS
units.
Report yearly the actual achieved performance for implemented VoIP in ATM to the
EUROCONTROL Agency.
Finalisation criteria :

1.
2.

3.
COM11-ASP04

Action by :

Upgraded voice communication systems put into service.


The technical file (TF) with evidences of compliance and the EC declaration of
verification of systems (DoV) has been delivered to the competent National
Supervisory Authority (NSA).
Voice communications systems upgraded.

Upgrade and put into service Voice


Communication Systems to support
VoIP links to the ground radio stations

Start:01/2013

Finish:12/2020

ANS Providers

Produced by JSP Teleconsultancy

181

Description & purpose


:

Upgrade and put into service voice communication systems which support VoIP links
to the ground radio stations which will enable the deployment of system enablers
listed in -References- section. The tasks to be done are as follows:

Define requirements which fit with operational/technical context and are


based on relevant standards;
Upgrade voice communication systems to comply with defined requirements;
Implement or purchase IP network services to enable international
communication exchange on IPS based protocol;
Purchase and install VCS and GRS equipment and/or gateways able to
support VoIP in ATM;
Implement the necessary IPv4/IPv6 translation device if required;
Test voice required connectivity and performance including AG ground
segment voice application;
Updating VoIP addressing information in the EUROCONTROL AGVN
web-database;
Verify compliance with Interoperability Regulation(s);
Integrate upgraded voice communication systems into the EATM Network;
Put into service upgraded voice communication systems.
The upgraded voice communication systems shall enable the operators to perform AG
radio communication using VoIP links between VCS and ground radio stations.
Report yearly the actual achieved performance for implemented VoIP in ATM to the
EUROCONTROL Agency.
Finalisation criteria :

182

1 - Voice communications systems upgraded.


2 - Upgraded voice communication systems put into service.
3 - The technical file (TF) with evidences of compliance and the EC declaration of
verification of systems (DoV) has been delivered to the competent National
Supervisory Authority (NSA).

Copyright 2014 JSP-Teleconsultancy

EUROCONTROL & FAA VoIP initiatives

This page is intentionally blank.

Produced by JSP Teleconsultancy

183

VoIP in ATM implementation & Transition Expert Group


Mission
To address VoIP implementation and transition related issues on case by case situations and to identify solutions
and deliver recommendations to interested parties (i.e. ANSPs, Industry, TELCOs).

Subject Matter and Scope


The subject matter is limited to VoIP implementation and transition from current ECAC legacy voice services
(analogue or digital) related issues. The Scope covers both inter-centre (all type of ATSUs) telephony and
ground component of Air-Ground communications from Voice Communication Systems (VCS) to Ground
Radio Station (GRS).

Composition
Participation is open to all interested parties (group of experts from ANSPs and Industry: TELCOs, VCS and
GRS manufactures) and is based on voluntary contributions. Active participation and contributions (analysis,
review etc) are expected from all members. Non-active participants with interest in the progressed subjects may
be subsequently informed of the progress made under specific for info information sharing arrangements.

General Principles and Methodology


The following principles are established:

Minimize the number of actual meetings (by using a dedicated section of the ATM Voice OneSky Team on
the EUROCONTROL extranet)

Group recommendations are intended to support all interested parties (i.e. ANSPs, Industry, TELCOs) for
VoIP implementation and transition related issues on case by case situations.

The meeting should be flexible to be run in sub-groups and to possibly extend over two days, maximum, to
accommodate experts with several interests;

A EUROCONTROL official will be identified as Rapporteur and will have the following tasks: organise
the sub-group, facilitate discussions, convene meetings, organise the sub-groups e-working environment
through the ATM Voice One Sky Teams of the EUROCONTROL extranet.

A request to initiate a particular subject or to convene a meeting could be made by any group member by
sending the subject matter to the Rapporteur. The meeting shall be subsequently endorsed and report back
to the COMT.

Occurrence of this WA per year


Meetings are convened when face to face discussions are considered beneficial for the sub-groups work.
Timeline
The group is intended to act in order to support VoIP implementation and transition related issues from initial
phase out of current ECAC legacy voice services (analogue or digital) to Initial Operational Capability of VoIP
in ATM corresponding services. A lifetime of 5 years from 2009 to 2014 is currently foreseen to cover its scope.

184

Copyright 2014 JSP-Teleconsultancy

EUROCONTROL & FAA VoIP initiatives

VoIP in ATM implementation &


Transition Expert Group

EUROCONTROL formed VOTE group (today over 100 members).


Mission: To address VoIP implementation & transition related
issues case by case. Identify solutions/deliver recommendations to
ANSPs, Industry, TELCOs etc.
Subject Matter: VoIP implementation & transition from current
ECAC legacy voice services. Find solution for line sunset dates;
Scope: Inter-centre telephony & ground segment of A/G comms
from VCS to GRS;
Participation: All interested parties; Experts from ANSPs, Telcos,
VCS & GRS manufacturers; Based on voluntary contributions.
VOTE SG1: Generic MIB enabling Basic Monitoring and Control
of VoIP radios & VOTE SG2: Dynamic Compensation for Climax
Operation, Both completed objectives by end of 2010;
Other VOTE subgroups formed in 2011. VoIP in ATM Test suite
validation task force + Backup Cross-coupling groups;

Produced by JSP Teleconsultancy

185

Next Generation ICAO 9896 VoIP


interfaces for ATS Ground Voice Network
- Part 1

186

Copyright 2014 JSP-Teleconsultancy

Network overview

7. Network overview

Produced by JSP Teleconsultancy

187

Network Domain Concept


Network Concepts
The following are the definitions of the main concepts that are particular to this course:

188

LAN (Local Area Network) is a network covering a relatively small geographic area.

EDGE is the equipment that serves as the interface to the WAN. This could be one or a combination of
devices (e.g., switches, routers, and firewalls) that deliver the communication service.

WAN shall be understood as being the interconnecting infrastructure of a communications enterprise,


which may be based upon the IP (though not necessarily so), supported by underlying technologies
(e.g., MPLS, Gigabit Ethernet, Frame Relay, TDM). The WAN serves users across a broad geographic
area and often uses transmission devices provided by common carriers. A WAN can be a Providers
Core network, a private network or the combination of both of them.

IP Network means the complete physical and logical mapping and connectivity (up to Layer 3)
between end-system network access points, including the LAN, EDGE and WAN domains.

Copyright 2014 JSP-Teleconsultancy

Network overview

Network Domain Concept

LAN: network covering a relatively small geographic area.


EDGE: equipment that serves as interface to WAN (e.g.,
switches, routers, and firewalls) that deliver the com service.
WAN: interconnecting infrastructure of comms enterprise
serving users in broad geographic area. Use transmission
devices provided by common carriers. Can be a Providers
Core network, a private network or combination of both.
IP Network: complete physical, logical mapping & connectivity
(up to Layer 3) between end-system network access points,
including LAN, EDGE & WAN domains.
IP
IP
IP
IP
IP
IP
IP
IP

LAN

EDGE

WAN

EDGE

Produced by JSP Teleconsultancy

LAN

189

Pan European Network Services - Core network & services


Pan-European Network Service (PENS)
The pan-European network service (PENS) is an international ground/ground communications infrastructure
jointly implemented by EUROCONTROL and the European air navigation service providers (ANSPs) in order
to meet existing and future air traffic communication requirements.
It will provide a common IP-based network service across the European region covering voice and data
communication and providing efficient support to existing services and new requirements that are emerging
from future Air Traffic Management (ATM) concepts.
The PENS philosophy is based on the concept of sharing. All PENS users located at the same site can in fact
share the same infrastructure in a secure way, providing substantial economies of scale. PENS provides a secure
and robust infrastructure for exchanging information between the users connected to it, since the pan-European
network offers fully redundant connectivity.
It will enable its users to exchange critical and common aeronautical information in a seamless and integrated
manner, providing a highly cost-effective common infrastructure for the deployment of emerging ATM
applications. It will significantly reduce the costly fragmented network services implemented under the umbrella
of the outdated X.25 protocol, still in widespread use by some ANSPs.
PENS will be one of the main enablers for the Collaborative Decision Making (CDM) concept that is being
developed in the context of SESAR. It will meet both current needs for the information exchange between air
service navigation providers (ANSPs) and ATM stakeholders, as well as those foreseen by the SESAR
Programme for the System-Wide Information Management (SWIM) initiative.
EUROCONTROL and the ANSPs are working together on the PENS project, improving it in order to turn it
into one of the key elements in the future technical infrastructure of ATM in Europe. PENS mean significant
cost savings and the optimisation for the ATM community in Europe.

Guaranteeing IP network availability - Built-in redundancy


Impacts on VCS and network availability figures
The traditional PBX systems have consistently delivered 99.999% availability that i s now being used as
a standard for VoIP systems. The availability figures often quoted for VoIP networks is 99.999%
uptime, however often this can only be guaranteed by using Backup VCS systems.
Todays VoIP networks are capable of achieving the five 9s availability required by ATS domain, only
if redundancy is designed into their infrastructure. All critical equipment has to be made redundant (SIP
proxy server and DNS servers, Power supplies etc), in order not to have a single point of failure. With
redundancy, (implemented in a 1+1 redundancy configuration) and hot changeovers, the network
resilience can be improved. A VoIP network created from scratch can make use of the inherent
resilience of IP networks.
In a private network with distributed switches and routers and multiple routes configured, the
availability can be further improved, with no single point of failure disrupting the service to its users. It
is important that bandwidth demand has no influence on system availability as seen by the end -user. It is
necessary to perform bandwidth calculations really well and to dimension the network paths such that
congestion never occurs and the situation when call cant be progressed due to lack of bandwidth never
results.
By placing the desired combination of high-availability routing intelligence in the network, the five 9s
availability figures can be achieved.

190

Copyright 2014 JSP-Teleconsultancy

Network overview

Pan European Network Services - Core


network & services

Guaranteeing IP network
availability - Built-in redundancy
Traditional PBX systems have 99.999% availability - now also
applied as benchmark for VoIP systems.
Availability quoted for VoIP networks is 99.999% uptime, is only
achieved by using Backup systems.
Five 9s availability can be achieved in ATS domain, only if
redundancy designed into infrastructure. All critical equipment
made redundant (No single points of failure).
In a private network with distributed switches and routers and
multiple routes configured, the availability can be further
improved, with no single point of failure disrupting the service to
its users.
Bandwidth demand should have no influence on system
availability as seen by the end-user.

Produced by JSP Teleconsultancy

191

PENS network architecture


A PENS node is basically a dual router interface (ANSP BB) to the user LAN. Each PENS user can then
directly interface its own LAN. PENS support both IPv4 and IPv6 protocols, unicast and multicast.
The Virtual Router Redundancy Protocol (VRRP) eliminates the single point of failure inherent in the static
default routed environment. VRRP specifies an election protocol that dynamically assigns responsibility for a
virtual router (a VPN 3000 Series Concentrator cluster) to one of the VPN Concentrators on a LAN. The VRRP
VPN Concentrator that controls the IP address(es) associated with a virtual router is called the Master, and
forwards packets sent to those IP addresses. When the Master becomes unavailable, a backup VPN Concentrator
takes the place of the Master.

PENS - a shared infrastructure

192

Copyright 2014 JSP-Teleconsultancy

Network overview

PENS network architecture


Remote Site
Primary VC

Primary
CE1

P
Router
PE1
Core
Network

Access
VRRP
Connections

PE2
MTN / AGN
Network

Secondary VC

Local Preference
Between
Primary & Secondary
Path

Secondary
CE2

Weight Between
Primary & Secondary
Path

PENS - a shared infrastructure


EAD Main Site

VRRP

ANSP BB Site

If Link Failure

EAD
VPN

Primary
CE

PE

CFMU
Host Site
CFMU VPN
VRRP

Access

VRRP

IPVPN Connections
ANSP
National
Network

ANSP
VPN
Secondary
CE

VRRP
ANSP
National
Network
ANSP BBSite

EAD User
CFMU User
ANSP

Produced by JSP Teleconsultancy

193

PENS User Status


PENS status
The PENS project was initiated jointly by EUROCONTROL, certain ANSPs (Aena in Spain, NAVIAIR in
Denmark and LFV in Sweden) and SITA on 28 October 2009. All EAD clients who decide to connect to EAD
through PENS were supported in their migration activities. Initial services started in mid-2010.
Since then, the number of PENS users has been increasing constantly and a high growth rate is expected in the
future. Negotiations are planned in order to open up the PENS community to airlines, airports, the military,
future aeronautical applications (RIMS, MCC, SATCOM), and other ANSPs which currently do not belong to
PENS, as well as other ATM partners with similar communications needs.
PENS users
The slide indicates the organisations that have already become PENS users or are expected to in the near future.
Benefits of Joining PENS
According to EUROCONTROL and its Member States ANSPs feasibility studies, the establishment of a single
pan-European network service would:
provide more cost effective than fragmented network services;
meet current and future communication needs;
achieve flexibility and speed of deployment by providing a managed international IP (Internet
Protocol) service environment;
provide greater capability for integrated developments involving the whole ATM community by
enabling a rapid and secure exchange of information;
align with Single European Sky implementing rules and industry standard services by supporting IPbased networking.
PENS Management
Management of PENS arrangements are set out in the Governance Document. PENS users are eligible to
participate in the PENS Service Steering Group (PSSG) which sets policy and in the PENS User Group
(PUG) which is a forum for discussion of more technical and operational matters. Day to day oversight of the
contract will be undertaken by the PENS Management Unit (PMU) which is a unit within EUROCONTROL.
Charges will be based on apportionment of NSP and PMU costs between all users in a manner approved by the
PSSG and specified in the document Charging for the PENS
Operational management will be undertaken 24/7 by the NSP Helpdesk, which will liaise directly with ANSP
user management centres and the PMU.

194

Copyright 2014 JSP-Teleconsultancy

Network overview

Produced by JSP Teleconsultancy

195

Virtual Private Networks available on PENS


Quality of Services provided by PENS
PENS can provide different quality of services, depending of the users requirements:

IP-VPNs with Gold Class of Service (three levels of priority)

Dual stack IPv4 / IPv6

IPv4 addresses are provided by PMU/SITA

IPv6 addresses are provided by EUROCONTROL (based on the iPAX Task Force)

Tight SLA with SITA for the service including:


- 24/7 Dedicated PENS Service Desk
- 99,99% availability
- Certificate of physical diversity of the circuits
- Quarterly audit of Single Points of Failures (layer 1/2/3)
- Remote monitoring access for ANSPs
- Monthly reporting.

Multiprotocol Label Switching (MPLS)

196

Used by Network Provider to establish a Virtual Circuit (VC) at Layer 2 between Customer
Edge (CE) endpoint devices through Provider Edge (PE) and Core Network Routers (P)(similar to open pipe);

PE inserts customer labels on Layer 3 packets and sends them to P router. It also removes
customer labels from Layer 3 packets before sending them to CE.

P-routers switches layer 2 labels between inputs and outputs in forward direction to make
path through network.

Bandwidth within VC is reserved for customer application, allows layer 3 packets to follow
same route over VC preserving order of packets, reducing latency, packet loss and jitter.

VC can be permanent or switched

Allows multiple redundant paths in case of main path failure or loss with path switching times
of
50ms.

Copyright 2014 JSP-Teleconsultancy

Network overview

Produced by JSP Teleconsultancy

197

VPNs over SITA MPLS Backbone


MPLS Core network infrastructure
An MPLS core network uses MPLS as its traffic engineering protocol allowing service providers to
create Label Switched Paths (LSP) mapping out the path to be taken by traffic over the network.
Labels allow routers to quickly establish the route to be taken by packets as they traverse the
network, hence improving performance.
Note: Traditional IP routed networks need to examine the IP address as it passes through each
router, using routing tables to determine the path to be taken on each hop, which causes added
delays.
An MPLS core network infrastructure is provisioned over Telcos private network and allows traffic
from each Telco client to be separated. Ethernet over fibre allows access speeds of 10Mbps,
100Mbps, 1Gbps and 10Gbps. Ethernet over copper allows access speeds of 1Mbps to 10Mbps.

MPLS path establishment through network


Layer 3 VPNs over MPLS Core network
Layer 3 VPNs can be configured over an MPLS network and are used by Telco clients that have
mission critical, delay sensitive applications. Network connectivity (i.e. routing configuration, hardware
and management) is provided by the Telco in this case. The Layer 3 VPNs are connectionless and
scale up to hundreds of sites with new site additions applied to the network with ease since MPLS
VPNs are able to run dynamic routing which distributes the addressing of a new site to all sites where
required. In the event of congestion, QoS is available using different priorities to differentiate traffic
and applications.
MPLS based managed service model is a service typically managed by the Telco themselves. An
MPLS architecture allows dynamic routing, is self-healing and automatically reroutes in the event of
optical fibre failures or breaks. In case of hundreds of remote sites that need Voice, data etc to be
transported to all locations the MPLS is more appropriate as its protocol-agnostic and can handle
multiple types of traffic through establishment of VPNs each with their own assigned CoS. MPLS also
allows traffic to be policed within the core network itself.

198

Copyright 2014 JSP-Teleconsultancy

Network overview

Produced by JSP Teleconsultancy

199

Layer 2 Virtual Leased Line (VLL) over MPLS Core network


A Layer 2 VLL solution offers connectivity between sites using either a virtual point-to-point circuit or
virtual point-to-multipoint circuit topology. This is also known as Ethernet pseudowire as it emulates a
wired circuit between two endpoints. Ethernet Line Services (E-line) are used in this case to create a
point-to-point Ethernet Private Line (EPL) or a Point-to-multipoint Ethernet Virtual Private Line (EVPL).
A VLL solution is ideal for Telco clients that want to control their own routing protocols and manage
their own solutions.
Often there is no resilience built-in to these circuits over the network unless resilient options are
offered. No resilience implies that the core MPLS network would not automatically re-connect the
virtual circuit via another route in the case of core network router failures.

Layer 2 Virtual Private LAN service (VPLS) over MPLS Core network
A Layer 2 VPLS solution offers any-to-any full mesh connectivity ensuring that every site appears to
be in the same Local Area Network. VPLS can also carry non-IP traffic without any need for
conversion or encapsulation. The Ethernet Virtual Private LAN Service (E-LAN) is used in this case
to create any-to-any networks. A VPLS solution is also ideal for Telco clients that want to control their
own routing protocols and manage their own solutions.
Often there is no resilience built-in to connectivity over the network unless resilient options are
offered. No resilience implies that the core MPLS network would not automatically re-connect
endpoints via another route in the case of core network router failures.
VPLS allows Telco clients to self-manage their own WAN configuration, IP routing (layer 3) and
CoS assigned to the VPNs. With less than 30 remote s ites, requiring high speed, high
performance and high security it could be argued that a switched Ethernet service like VPLS is
more appropriate as it will allow an ANSP to maintain complete control over their own switching
and routing between endpoints as well as offering easier configuration and debugging/support.
VPLS allows a blank pipe to be established end-to-end using static routing and the client can
then manage the bandwidth in the pipe themselves by configuring VPNs etc.

200

Copyright 2014 JSP-Teleconsultancy

Network overview

Produced by JSP Teleconsultancy

201

Guaranteeing Real Time Voice over network


Differentiated Services (DiffServ)
While IP Precedence marks packets into 6 classes (2 reserved), DiffServ uses 64 classes DSCP retro-compatible.
IP Precedence uses 3 bits in the ToS field of an IP packet while DiffServ uses 6 bits to identify 64 classes.
DiffServ introduces the concept of the DiffServ Code Point (DSCP) that uses the first 6 bits of the ToS field
thereby giving 26 = 64 different values. RFC2474 describes the Differentiated Services (DS) field and the
DiffServ Code Point (DSCP).
DiffServ addresses the issue of scalability by defining QoS mechanisms that operate on aggregates of flows with
similar QoS requirements. Differentiated Services (DiffServ) is an IETF specified QoS architecture [RFC2475]
that was proposed to provide service differentiation by creating service classes using either the ToS field of the
IPv4 or the priority bits of the IPv6 headers [RFC2474].
The DiffServ architecture achieves its scaling properties by defining a small number of simple differentiated
packet forwarding treatments, known as per-hop-behaviours (PHBs). Individual network elements implement
these PHBs through a variety of mechanisms and queuing disciplines. The essence of DiffServ is to combine
these differentiated PHBs with carefully configured traffic policing mechanism at the edge of the network to
provide a variety of services. By concentrating policy enforcement activities at the edge and providing simple
aggregate data handling in the core, a network operator can ensure that new IP services do not require excessive
state information or expensive forwarding decisions in core network routers. Each data packet that enters a
DiffServ ingress router is marked with a DiffServ codepoint (DSCP) in a newly defined IP header field (the DS
field) to indicate which PHB should be applied to the packet. Packets marked with the same codepoint are
considered behaviour aggregate and they all receive the same PHB treatment, regardless of the micro-flow to
which they belong.
DS field
DiffServ defines the use of the ToS byte, now called the DS field, and a base set of packet forwarding
treatments. In IPv6 the DS field would be the Traffic Class field. This field can now be marked, so that
downstream nodes receive information required to handle packets arriving at the respective entry ports and
forward them appropriately to the next hop routers.
In the DS field, six bits are available for present use and two are reserved for future use. By marking the DS
fields of packets differently and handling packets on the DS field, several differentiated service classes can be
created.
Per-Hop-Behaviour (PHB)
Per-hop-behaviour deals with traffic types instead of flows. There are several ways to distinguish traffic types,
but the easiest way is to mark the type of the traffic in the IP-headers of individual packets that belong to a
certain traffic type. This way, intermediate hosts only need to check one field of the IP header to classify the
incoming traffic.
DiffServ Router architecture
In addition to forwarding engines capable of implementing the emerging PHB standards, the DiffServ
architecture requires edge devices that include traffic conditioning components that are able to classify, mark,
shape, and drop packets as they enter and leave the DiffServ domain. Each DiffServ enabled edge router
implements a traffic conditioning function which performs metering, shaping, policing and marking of packets
to ensure that the traffic entering a DiffServ network conforms to the traffic conditioning rules specified within
an SLA.
At the edge of the network or administrative boundary, the classifier sets the values of the DS field for each
incoming flow.

202

Copyright 2014 JSP-Teleconsultancy

Network overview

Guaranteeing Real Time Voice


over network
Classifies packets according to customer Service Level
Agreement (SLA) at network edge using 6 bits (64 classes) in
ToS field (IPv4) or Traffic Class field (IPv6) of an IP packet;
Backwards Compatible with 3 IP precedence bits;
Better classes get higher numbers. Guarantees QoS over WAN;
Simple functions in core, and relatively complex functions at
edge routers (or hosts);
Core function forwards packets only & maintain no states.
Improves scalability greatly;
End host

End host

core routers
edge routers

The classifier selects packets based on the combination of one or more predefined set of header fields. The
mapping of network traffic to the specific behaviours that result in different classes of service is indicated by the
DS field. Each DS field uniquely identifies the per-hop-behaviour or the treatment given to the traffic at each
hop along the network path. Each router sorts the packets into queues based on the DS field. The queues might
get different treatment based on their priority, share of bandwidth, discard policies, etc. As marked packets flow
downstream, they are merged with equally marked DiffServ packets into a behaviour aggregate and all
subsequent traffic conditioning is performed on aggregate traffic. As conforming traffic traverses a DiffServ
domain, it may acquire unacceptable burst characteristics as a side effect of various queuing delays or increased
aggregation. In order to ensure that the burst characteristics of aggregate data conform to the traffic specification
for the provisioned service, each DiffServ domain must have the ability to perform traffic shaping on each
aggregate as it exits the domain, and should shape each aggregate traffic flow as it exits the domain.
The router implementations in the intermediate nodes use the 6-bit PHB field to index into a table for selecting a
particular packet-handling mechanism. This forwarding policy determines how routers will handle the packets
in terms of providing a class of service by combining traffic management functions such as packet queuing,
scheduling, and buffer reservations at each node.
DiffServ expects advance provisioning and reservations made in each of the intermediate nodes along the
network path. If a network path crosses multiple DS domains or multiple ISPs, the ISPs must support the same
PHBs to provide a consistent end-to-end service.

Produced by JSP Teleconsultancy

203

Next Generation ICAO 9896 VoIP


interfaces for ATS Ground Voice Network
- Part 1

204

Copyright 2014 JSP-Teleconsultancy

SESAR WP 15.2.10 VoIP Validation work

8. SESAR WP 15.2.10 VoIP Validation work

Produced by JSP Teleconsultancy

205

SESAR Programme
SESAR is one of the most ambitious and most innovative research and development projects ever launched by
the European Union. The SESAR programme is the operational and technological answer to the major
challenges of European air traffic growth. The aim of the SESAR Joint Undertaking is to ensure the
modernisation of the European air traffic management system by coordinating and concentrating all relevant
research and development efforts in the Community. Partnership, sustainability and user-drive are key concepts
of the SESAR Joint Undertaking approach. Founded by the European Commission and by Eurocontrol, fifteen
companies are members of the SJU: AENA, Airbus, Alenia Aeronautica, the DFS, the DSNA, ENAV,
Frequentis, Honeywell, INDRA, NATMIG, NATS (En Route) Limited, NORACON, SEAC, SELEX Sistemi
Integrati and Thales.
SESAR is the technological pillar of the European Unions Single European Sky legislative package. Given the
complexity of the programme, since it includes the coordination of a wide range of actors, the European Union
created a single management entity: the SESAR Joint Undertaking (SJU). Co-founded by Eurocontrol and the
European Commission, the SJU is a public-private partnership in which 15 industry members perform the work
necessary for the modernisation of the Air Traffic Management (ATM) in Europe.
The SESAR ATM) modernisation programme will combine technological, economic and regulatory aspects and
will use the Single European Sky (SES) legislation to synchronise the plans and actions of the different
stakeholders and bring together resources for the development and implementation of the required
improvements throughout Europe, in both airborne and ground systems.
The first phase of SESAR, the Definition Phase, is co-funded by EUROCONTROL and the European
Commission under Trans European networks. The products of this Definition Phase will be the result of a 2-year
study awarded to an industry wide consortium supplemented by EUROCONTROLs expertise. It has delivered
the SESAR Master Plan covering the period up to 2020 and the accompanying Programme of Work for the first
6 years of the subsequent Development Phase.
The SESAR Definition Phase has produced 6 main Milestone Deliverables (DLM) over 2 years covering all
aspects of the future European ATM System, including its supporting institutional framework. The scope of the
6 Deliverables (Dx) are:

D1: Air Transport Framework the current situation;


D2: Air Transport Framework the Performance Target;
D3: Definition of the future ATM Target Concept;
D4: Selection of the Best Deployment Scenario;
D5: Production of the SESAR Master Plan;
D6: Work Programme for 2009 2014.

The SESAR Consortium has completed the Definition Phase study, which for the first time in European ATM
history has brought together the major stakeholders in European aviation to build the SESAR Master Plan. The
SESAR Consortium draws upon the expertise of the major organisations within the aviation industry. This
includes Airspace Users, Air Navigation Service Providers (ANS Providers), Airport Operators and the Supply
Industry (European and non-European), plus a number of Associated Partners, including safety regulators,
military organisations, staff associations (including pilots, controllers and engineers) and research centres who
work together with the significant expertise of EUROCONTROL.
The deliverable D6 has been approved and accepted by all Project Participants. Work is now under way to
implement the 16 Work Packages.

206

Copyright 2014 JSP-Teleconsultancy

SESAR WP 15.2.10 VoIP Validation work

SESAR Programme

SESAR Joint Undertaking management entity (a public-private partnership) created by EC


to manage SESAR programme;
Scope: Modernisation of European air traffic management system (airborne and ground
systems), by coordinating and concentrating all relevant research and development efforts
in the Community- Uses Single European Sky (SES) legislation to synchronise the plans
and actions of the different stakeholders.
Founded by European Commission and Eurocontrol, following 15 members of SJU
consortium are performing work: AENA, Airbus, Alenia Aeronautica, the DFS, the DSNA, ENAV,
Frequentis, Honeywell, INDRA, NATMIG, NATS (En Route) Limited, NORACON, SEAC, SELEX Sistemi
Integrati and Thales.

The SESAR Definition Phase produced 6 Milestone Deliverables over 2 years covering all
aspects of the future European ATM System:

D1: Air Transport Framework the current situation;


D2: Air Transport Framework the Performance Target;
D3: Definition of the future ATM Target Concept;
D4: Selection of the Best Deployment Scenario;
D5: Production of the SESAR Master Plan;
D6: Work Programme for 2009 2014.

SESAR Master Plan (D5) covers period up to 2020 and accompanying Work Programme
(D6) for the first 6 years of subsequent Development Phase.
The deliverable D6 has been approved and accepted by all Project Participants.
Work is now under way to implement the 16 Work Packages. Only one part of WP 15,
nominated 15.2.10 relates to VoIP validation activities.

Produced by JSP Teleconsultancy

207

SESAR Master Plan for CNS activities


Capability Level 1 Deployment
ADS-OUT (1090): Install Mode S 1090 ground
receiving stations to support ADS-B out based
surveillance.
European IP backbone: Interconnect state data
networks through a European P based backbone

Supports Line of Change


LoC#6 Collaborative Ground and Airborne Decision
Making Tools
LoC#8 New Separation Modes
LoC#10 Airport Throughput, Safety and Environment
LoC#2 Moving from Airspace to Trajectory Based
Operations
LoC#3 Collaborative Planning using the NOP
LoC#5 Managing Business Trajectories in Real Time
LoC#6 Collaborative Ground and Airborne Decision
Making Tools
LoC#7 Queue Management Tools

VoIP: Deployed over IP for ATC Ground-Ground


voice telephony communication
GBAS (CAT I): Implement GBAS ground stations
LoC#10 Airport Throughput, Safety and Environment
to provide Cat I operations
SBAS: Deploy EGNOS system to support SBAS
LoC#10 Airport Throughput, Safety and Environment
APV Cat I (to LPV)
Capability Level 1 required R&D
Develop and validate GBAS Cat I capability, as a stepping stone towards Cat III.
Assess aeronautical spectrum requirements for air, ground and space segments

Capability Level 2 Deployment


Ground/ground IP network: Complete the overall
IP based and integrated European network by
interconnecting all state data networks.

Ground Wake Vortex sensors: implement next


generation ground weather and ground wake vortex
sensors.
VoIP (radio): Deploy Voice over IP between ATC
and radio station on the ground-ground segment.
MSPSR: Implement new Primary Radar with multistatic technology to replace the existing
ones
Link 16: Implement ground gateways to
accommodate Military link16 equipped aircraft
within civil ATM system to provide initial D/L
services.
New airport D/L (802.16): Install new airport
wireless Datalink in protected aeronautical
spectrum (C band) to support ATM communication
services12.
Airport Lighting: Upgrade and or replace airport
lighting with LED technology.
8.33 below FL195: Deployment of 8.33 KHz in
airspace below FL195 if deployment case
is made and accepted.

Supports Line of Change


LoC#2 Moving from Airspace to Trajectory Based
Operations
LoC#3 Collaborative Planning using the NOP
LoC#5 Managing Business Trajectories in Real Time
LoC#6 Collaborative Ground and Airborne Decision
Making Tools
LoC#7 Queue Management Tools

LoC#1 Information Management


LoC#2 Moving from Airspace to Trajectory
Based Operations
LoC#5 Managing Business Trajectories in
Real Time
LoC#10 Airport Throughput, Safety and
Environment

Capability Level 2 required R&D

208

Copyright 2014 JSP-Teleconsultancy

SESAR WP 15.2.10 VoIP Validation work

SESAR Master Plan for CNS activities

Capability Level 1: VoIP (telephony): Deploy VoIP for ATC G/G


voice telephony communication for ATM
Capability Level 2: VoIP (Radio): Deploy VoIP between ATC and
Radio Stations on G/G segment
Identify the detailed operational requirements for Datalink messages to support European operation (e.g. Meteo
and trajectory).
Develop a performance validation demonstrator to identify the capability and the potential risks of MSPSR
technology.
Develop and validate solutions that enable existing military Datalink solutions to interoperate with civil
Datalinks, while safeguarding military classified data.
Identify the detailed operational requirements for new airport Datalink. Develop the air and ground component
technical specifications
and initial standard for the new airport surface Datalink; validate the detailed and overall performance
capabilities and electromagnetic compatibility with other aircraft and airport systems. Propose and consolidate
spectrum allocation at global level (ITU).
Develop and validate ground wake vortex detection radar.
Develop and validate next generation weather radar.
Develop and validate LED technology as an acceptable replacement, while meeting improved signalling and
environment performance.

Produced by JSP Teleconsultancy

209

SESAR Work packages


Operational activities

WP 4 En-Route Operations: provide the operational concept description for the En-Route Operations and
perform its validation.
WP 5 Terminal Operations: manages, co-ordinates and performs all activities required to define and validate
the ATM Target Concept (i.e. Concept of Operations and System Architecture) for the arrival and departure
phases of flight.
WP 6 Airport Operations: refinement and validation of the concept definition, as well as the preparation and
coordination of its operational validation process.
WP 7 Network Operations: Covers the evolution of services in the business development and planning phases
to prepare and support trajectory-based operations including airspace management, collaborative flight planning
and Network Operations Plan (NOP).
WP E: SESAR Long Term and Innovative Research: Addresses long-term and innovative research. It doesn't
have a fixed work programme but solicits proposals from the research community for the formation of networks
of expertise and for project work.

System development activities

WP 10 En-Route & Approach ATC Systems: Designs, specifies and validates the En-route & TMA ATC
Systems evolutions for enhancing Trajectory Management, Separation Modes, Controller Tools, Safety Nets,
Airspace Management supporting functions and tools, Queue Management and Route optimization features.
WP 11 Flight and Wing Operations Centres / Meteorological Services: Deals with the development of the
Airspace Users operations systems required to support the implementation of the various SESAR components.
WP 12 Airport Systems: Encompasses all Research & Development activities to define, design, specify and
validate the Airport Systems needed to support the SESAR ATM target concept.
WP 13 Network Information Management System: Covers the System and Technical R&D tasks related to
the Network Information Management System (NIMS), the Advanced Airspace Management System (AAMS)
and the Aeronautical Information management System (AIMS).
WP 15 Non-Avionic CNS System: Addresses CNS technologies development and validation also considering
their compatibility with the Military and General Aviation user needs.
WP 9 Aircraft Systems: Covers the required evolutions of the aircraft platform, in particular to progressively
introduce 4D trajectory management functions (3 spatial dimensions plus time) in mainline, regional and
business aircraft.

System Wide Information Management

WP 14 SWIM Technical Architecture: The SWIM Work Package is the follow-up of the SWIM SUIT FP6
Commission. It will use as an input the SWIM-SUIT deliverables and aligns them with the SESAR Work
Programme components.
WP 8 Information Management: Has scope of developing SWIM (System Wide Information Management),
the "Intranet for ATM".

Transverse activities

WP 16 R&D Transversal Areas: Covers the improvements needed to adapt the Transversal Area (TA) (safety,
security, environment, contingency and human performance) management system practices to SESAR as well as
towards an integrated management system.
WP 3 Validation Infrastructure Adaptation and Integration: Involves all relevant European ATM
stakeholders to benefit from existing expertise, tools and validation platforms to make available a reference
validation and verification infrastructure to be used during the SESAR Development phase.

210

Copyright 2014 JSP-Teleconsultancy

SESAR WP 15.2.10 VoIP Validation work

SESAR Work packages


Operational activities

WP 4 En-Route Operations:

WP 5 Terminal Operations:

WP 6 Airport Operations:

WP 7 Network Operations:

WP E: SESAR Long Term and


Innovative Research:

System Development activities

WP 10 En-Route & Approach ATC Systems:

WP 11 Flight and Wing Operations Centres /


Meteorological Services:

WP 12 Airport Systems:

WP 13 Network Information Management


System:

WP
WP 15
15 Non-Avionic
Non-Avionic CNS
CNS System:
System:
System Wide Information Management

WP 14 SWIM Technical Architecture:

WP 8 Information Management

Transverse activities

WP 16 R&D Transversal Areas:

WP 3 Validation Infrastructure
Adaptation and Integration:

WP B Target Concept and Architecture


Maintenance.

WP C Master Plan Maintenance

WP 9 Aircraft Systems:

15.02 - Communications
15.03 Navigation
15.04 Surveillance

WP B Target Concept and Architecture Maintenance: Provides strategic and conceptual guidance for the
entire work programme including all threads (operational, technical and SWIM) to ensure the consistent
development of SESAR improvements.
WP C Master Plan Maintenance: Has scope to administrate the up-to-date maintenance of the ATM Master
Plan to monitor the progress of development and of implementation.

Produced by JSP Teleconsultancy

211

Validation of VoIP in ATM part of SESAR JU 15.2.10


WP15 is further organised into 15 projects:
SWP 15.0 Global Co-ordination & Management
SWP 15.1 Common CNS Studies
P 15.1.6 Spectrum Management & Impact Assessment
SWP 15.2 Communications
P 15.2.4 Future Mobile Data Link system definition
P 15.2.6 Future Mobile Satellite Communication
P 15.2.7 Airport Surface Datalink
P 15.2.8 Civil-Military Data Link Interoperability

P 15.2.10 Terrestrial communication infrastructure - SWIM backbone


SWP 15.3 Navigation
P 15.3.1 Navigation technologies specifications
P 15.3.2 Navigation Infrastructure Rationalisation
P 15.3.4 GNSS Baseline study
P 15.3.5 Enhanced SBAS - GNSS Evolution for Aeronautic Aspects
P 15.3.6 GBAS Cat II/III L1 Approach
P 15.3.7 Multi GNSS CAT II/III GBAS
SWP 15.4 Surveillance
P 15.4.1 Surveillance infrastructure rationalisation study
P 15.4.3 ACAS Monitoring
P 15.4.5a Surveillance ground system enhancements for ADS-B
P 15.4.5b Surveillance ground system enhancements for ADS-B (Prototype development)
P 15.4.9a Weather sensing technologies specifications
P 15.4.9b Weather infrastructure requirements Study
P 15.4.9c Ground Weather Monitoring system

212

Copyright 2014 JSP-Teleconsultancy

SESAR WP 15.2.10 VoIP Validation work

Validation of VoIP in ATM part of


SESAR JU 15.2.10

Civil-Military Data Link Interoperability

Future Mobile Satellite Communication

Future Mobile Data Link


system
Airport Surface Datalink

Terrestrial communication
infrastructure
SWIM backbone

Produced by JSP Teleconsultancy

213

SESAR JU Work Programme 2009-2014


WP15 CNS System Thread
WP Objectives:
The objective of the CNS system Work Package is to cover the following main activities:
1) System Definition and Architecture including
Technology constraints identification;
Functional specification;
Architecture and breakdown into elementary sub-systems;
Performance allocation;
Safety analysis and safety requirements allocation; and
Specific civil- military interoperability provisions.
2) For each project within the three CNS domains:
Preliminary System feasibility studies and Modelling;
Detailed definition in terms of functions, performance, interfaces, protocols;
Development of Prototypes;
Technical Integration and validation including:
o Setting up of test bed;
o Technical integration; and
o Validation versus the requirements: functional, interfaces, performances, etc
Specific civil- military interoperability solutions.
The CNS R&D activities will be organised in: System Definition and Architecture activity; and
Three domains, namely Communication, Navigation and Surveillance domains.
It is useful to identify Studies to refine the definition of new CNS functions when these are not mature enough,
before starting projects which will focus on pre development and technical validation. The Studies will be put at
the same level as projects.
The following breakdown into three levels is proposed for System CNS organisation:
1st level: System Definition and Architecture and three CNS Domains.
2nd level: Studies and Functions grouping various projects.
3rd level: Projects including Definition, pre development and technical validation.
The following organisation has been derived for CNS projects to map the Statement Of Work (SOW)
organisation:
Communication domain
Diverse Communication Studies;
Future Air-Ground data- link System;
Air-Air data-link System;
IP-based Ground-Ground communications (voice/data); and
Civil- military data link interoperability.
Navigation domain
Global Navigation Studies;
GNSS (including backup system and compatibility with military systems); and
Lighting.
Surveillance domain
Surveillance Definition Studies;
o ADS-B out;
o Future ADS-B link;
Radar;
Multilateration;

214

Copyright 2014 JSP-Teleconsultancy

SESAR WP 15.2.10 VoIP Validation work

SESAR JU Work Programme 20092014


The SESAR JU Work Programme 2009-2014 (D6) defines
16 Work packages;
WP15 relates to CNS and Communication domain covers:
Diverse Communication studies;
Future Air-Ground data-link system;
Air-Air data-link system;
IP-based Ground-Ground communications
(voice/data);
Civil- military data link interoperability.

Weather and Hazards Detection; and


New traffic awareness, Conflict detection and resolution function to support ASAS.

Produced by JSP Teleconsultancy

215

SESAR JU Description of Work- WP 15.2.10- VoIP Validation


P.15.02.10 -Verification Analysis of VoIP ground networks within PENS/ANSPs networks

The project aims at refining and verifying that a terrestrial communications infrastructure appropriate for ATM
ground/ground communication applications is capable of supporting the existing services (i.e. voice, messaging)
and is also capable of addressing the new concepts to be developed in SESAR such as SWIM (System Wide
Information Management) services.
The scope of the working activities WA10, WA11 and WA12 of Project 15.02.10 is to perform the appropriate
research and development activities, technical assessments and testing necessary to verify that Voice over
Internet Protocol (VoIP) can be provided in suitable manner by the network on an end-to-end basis (ANSPs
networks interconnected through PENS). Another objective is to define the optimal VoIP parameters (RTP
packet size, jitter buffer size, etc.), which should later be implemented.
S-SVC.01

WA10 focused on the following and resulted in a D10 deliverable finalised in Early 2011.

Identify pending issues for standardization and verification of VoIP ground network within the A/G
and G/G voice communications chain of the PENS network

Identify common new service elements/entities that may be required to support A/G voice
communications within the PENS/ANSPs ground network

Define scenarios for the integrated verification and test specifications (voice traffic patterns, loading
and acceptance metrics) for both, laboratory tests and field trials

Produce a detailed verification plan for laboratory tests and field trials using the PENS
infrastructure

WA11 is dedicated to defining and executing VoIP performance tests on Voice over IP communication using
the PENS/ANSPs infrastructure. PENS is provided by SITA as a dedicated Virtual Private Network named
SESAR VPN at 7 sites.

216

Copyright 2014 JSP-Teleconsultancy

SESAR WP 15.2.10 VoIP Validation work

SESAR JU Description of WorkWP 15.2.10- VoIP Validation


WP 15.2.10: Terrestrial communication infrastructure
System Wide Information Management (SWIM) backbone
Task 3: Validation of IP multicast & VoIP services on PENS
IP multicast services will be required to support current and new
applications. IP multicast services have never been used widely in
operation for RADAR applications for instance and will therefore
have to be validated. VoIP needs also to be further validated.

Inputs:
PENS multicast IP services
Application requirements
Outputs:
Guidelines for IP multicast applications on PENS
Validation reports on VoIP

Produced by JSP Teleconsultancy

217

SESAR members & WP 15 members


STAKEHOLDERS
Broad consultation and involvement of SESAR members and stakeholders should help the SESAR programme
to success. Its stakeholders include airspace users, airports, air navigation service providers, the manufacturing
industry, aviation associations and organisations, regulators, the scientific world, regulators and administrations
as well as the general public.
SESAR is all about Partnership and the SJU is constantly liaising with various stakeholders to build a
programme for them and with them.
Airspace users (both civilian and military)
Civilian airspace users include scheduled airlines, charter companies, cargo and air freight service providers, the
business and leisure aviation sectors and all forms of non-military air travel, from hot air balloons through
police helicopters to general aviation pilots. The military, in the form of the air forces of the EU's Member
States, are also users with an interest in SESAR technology developments. Many of these companies and
organisations are formally involved in the SESAR work programme, contributing experts and taking part in
validation tests.
Airport operators
SESAR aims to triple the capacity of civilian airports in Europe. The ATM technology developed through the
R&D programme will contribute to more direct flight paths and smoother, more rapid descents, reducing noise
and other environmental impacts. Several large consortia of airport operators, such as SEAC (expected to
include six large European airports), AENA and NORACON, are already SESAR members.
Air navigation service providers (ANSP)
Europe will see a doubling in demand for air transport by 2020 according to projections. In order to manage this
increased capacity, air traffic control or air navigation service providers will need improved technology to help
communicate, coordinate and share information among themselves and with aircraft, as well as more accurate
information
on
the
position
and
trajectory
of
the
aircraft.
The DSNA (France), the DFS (Germany), ENAV (Italy), NORACON (covering northern Europe and Austria),
AENA (Spain), and NATS (En Route) Ltd (United Kingdom) are already SESAR members.
Suppliers
The competitiveness of European industry depends on innovation and technological advancement. The
European aerospace industry, whether manufacturing aircraft or equipment for the ground or the air, is
committed to pursuing this through R&D. The SESAR programme is the best way to provide this for air traffic
management.
Several major companies from the following aviation supply industry sectors are already SESAR members,
including: ground and aerospace manufacturing - Frequentis, Indra, Natmig and SELEX Sistemi Integrati;
aircraft manufacturers - Airbus and Alenia Aeronautica; airborne equipment manufacturers - Honeywell and
Thales.
Airline, airport and air traffic navigation staff
The human factor is at the heart of air navigation systems. Professionals from the air transport sector are
involved in the programme to ensure that future systems are built to their needs and specifications.
Regulators and administrations
Air travel is a highly regulated industry, whether its environmental, security, safety or competition aspects.
European governments also have an interest in ensuring that the European air industry, both users and suppliers,
remains competitive in future and continues to contribute to economic growth and jobs. The SESAR programme
will result in new patents and products, as well as contributing to and taking account of new regulations and
standards.
Individuals, as both passengers and citizens
Through improved air traffic navigation, information and positioning, passengers stand to benefit through
shorter and more reliable journeys, lower costs and improved safety. Society at large, whether or not they use air
transport, will also gain from a more competitive European air industry, less noise around airports, more
efficient and convenient travel and a contribution to cutting greenhouse gases and reducing climate change
impacts.
218

Copyright 2014 JSP-Teleconsultancy

SESAR WP 15.2.10 VoIP Validation work

SESAR members & WP 15


members
SESAR Members

SELEX (work package leader)


Thales (work package leader)
AENA, Airbus, ALENIA, DFS, DSNA, ENAV, Eurocontrol, FREQUENTIS,
Honeywell, INDRA, NATMIG, NATS, NORACON

WP 15.2.10
INDRA Leader
Aena, DFS, Frequentis, ENAV, Selex

Produced by JSP Teleconsultancy

219

WAN test bed network topology


The Validation of VoIP as part of WP15.2.10

The main goal of this project is to perform the appropriate R&D activities, technical assessments and
verifications necessary to implement a robust, safe and consistent ground-ground communication network
infrastructure adapted for the future ATM environment. The Validation phase is planned to be completed by the
end of 2012.
VoIP based upon standards developed by EUROCAE WG-67 (ED136, ED 137, ED 138 and ED 139) will be
also validated within the framework of this project in the PENS environment.
WA0. Project Management
L (INDRA)
WA1. Evaluation of end-to-end
performances in PENS
L (AENA)
WA2. Establishment of a Security Policy
L (EUROCONTROL)
WA3a. Verification of IP
multicast applications
L (FREQUENTIS)
WA3b. Verification of VoIP for ATM
L (FREQUENTIS)

The validation phase will help deliver the following solutions


Ref.

Description

Justification

15.2.10-D1

Assessment of the PENS performances and


potential gaps of end-to-end performances

J1

15.2.10-D2

Security policy and procedures for A/G-G/G


communications and applications

J2

15.2.10-D3

IP multicast data distribution applications on


PENS Guidelines

J1, J3

15.2.10-D4

VoIP for ATM Validation reports

J4

Approach to the work to be performed


In first place an assessment of the end-to-end performances of the PENS network will be carried out. So, a
complete evaluation of different type of applications and services in the ATM domain are to be connected to the
PENS architecture and evaluated. In order to achieve this objective, it will be necessary to use the ANSPs
connecting routers to the PENS infrastructure and other test network facilities from industry partners .
In second place, studies on security issues will be performed. Analysis on the main security issues regarding the
ground-ground network infrastructure will be done, including procedures to achieve the highest level on secured
best practises. In this particular task, an important input is expected from P14.2.2. SWIM Security Solutions
so as to create a security policy which is fully compatible and complementary with the security
recommendations released by WP14, which deals with the technical design of SWIM architecture. Inputs from
WP 16 on security requirements are also expected for this task.

220

Copyright 2014 JSP-Teleconsultancy

SESAR WP 15.2.10 VoIP Validation work

WAN test bed network topology


October 2011: SESAR
15.2.10 partners have
performed initial D11
VoIP validation, over
PENS Test bed VPN.
IPv4 network
infrastructure used
DSNA &
EUROCONTROL
observers to tests
PENS SESAR test VPN (SITA), REDAN network (AENA), RAPNET
network (DFS), and ENET network (ENAV) are connected to PENS
PoPs in Madrid, Langen (Frankfurt) and Rome, the networks of other
Industry Partners Frequentis (VCS) and Selex (Radios) are
connected to PENS PoPs in Vienna and Rome.
IP multicast and VoIP services will be tested in the last task proposed. EUROCAE WG-67 ATM VoIP
specifications will be used for these tests with the objective to formally validate them in a real
representative IP network environment including the PENS backbone. It includes interoperability aspects
and network infrastructure around the PENS backbone (i.e. IPv6 network). The outcomes of this task
could be recommendations to refine the EUROCAE specifications if required.
Project 15.2.10 deals with already mature technology aspects and focuses on verification of different types of
applications, such as VoIP (EUROCAE WG-67 deliverables) and IP multicast applications (EAD, CFMU,
AMHS, etc.) in a complex networking environment structured around the PENS backbone (i.e. IP V4 networks
interconnected with the dual stack (IPv4-IPv6) PENS backbone).
Test Environment:

PENS backbone (provided by SITA), REDAN network (AENA), RAPNET network (DFS), AENAs
test network, ATC/ATM data system simulator/ops in Madrid and Frankfurt.

REDAN and RAPNET will be connected to PENS PoPs in Madrid and Frankfurt respectively;
Expected that other nodes DSNA Toulouse, ENAV Rome and NATS Whitely will also be connected.

Produced by JSP Teleconsultancy

221

SESAR 15.2.10 VoIP related deliverables


Work
Activity

WA10

Deliverable Name

Scope

D10: Verification Analysis of


VoIP ground network within
PENS/ANSPs networks.
(This
Work
Activity
completed in 2010)

was

This document was divided into the following Parts:


PART 1: Identified all the pending issues required to be solved
prior to the standardization and integrated verification of the
VoIP ground network within the A/G and G/G voice
communications chain of the PENS network.
PART 2: Conducted a study that identified common new
service elements that may be required to support A/G voice
communications within the PENS/ANSPs ground network.
PART 3: Defines high level verification scenarios and test
specifications for both, laboratory tests and field trials. This
defines the following steps:

STEP 0: Local Laboratory test phase- Includes


conformance test phase and local lab interop test
scenarios.
STEP 1: Local/Remote Interoperability Test Phase
(Pre-PENS)- defining Telephone/ Radio Tests,
Telephone/Radio Gateway tests and Performance
Metrics
STEPS 2/3: Large Scale Field Trial over
PENS/ANSPs Networks (ON-PENS Tests)- Defines
test cases foreseen for Telephone/Radio interop tests
and Performance tests over PENS,
PART 4: Defines detailed verification test plan for laboratory
tests and field trials using the PENS/ANSPs infrastructure.

WA11

D11: Report on Verification of


VoIP Technology for G/G & A/G
Communications over the PENS
(This
Work
Activity
completed in 2011)

was

STEP 0: Local Laboratory test phase: Defines tests


for Telephone. Radio and Recorders
STEP 1: Local/Remote Interoperability Test Phase
(Pre-PENS)-defining Telephone/ Radio Tests,
Telephone/Radio Gateway tests and Performance
Metrics.
STEPS 2/3: Large Scale Field Trial over
PENS/ANSPs Networks (ON-PENS Tests) Defines
Telephone and Radio tests plus Network tests.

PART 1: Describes VoIP specific test cases that are performed


directly in the SESAR VPN (PENS). These tests are just
focusing on performance tests for VoIP (radio and telephone)
applications.
PART 2: Test Plan
PART 3: Result summary and provides an evaluation of the
results and draws some conclusions

WA12

D12: Final Verification of VoIP


Technology for G/G & A/G
Communications over the PENS

It is foreseen that besides repeating certain Performance tests


relating to Voice Quality, this Work Activity will now progress
to include more enhance test case scenarios.

(To be completed in 2012/2013)

These may include: Climax Multi-carrier offset tests using the


Dynamic Delay compensation mechanism algorithms defined
by VOTE SG2 and now integrated within the ED137B Volume
1 Radio document.
Further test case may include Best Signal Selection etc

222

Copyright 2014 JSP-Teleconsultancy

SESAR WP 15.2.10 VoIP Validation work

Produced by JSP Teleconsultancy

223

SESAR 15.2.10 D11 Tests


Telephone
Following tests categories are defined for telephone testing:

Radio

Interoperability: Direct Access (DA), Instantaneous Access (IA) call and Detection of Link connection loss tests
Call Performance: Direct Access (DA) call setup time, measured from call initiation to receiving and alerting
condition
Audio quality test case
Voice Delay test case
Thresholds: Tests for maximum throughput, increasing traffic with same and different Classes of Service (CoS),
Critical Jitter test
Call performance with network load

The EUROCONTROL document Radio Test case specification for VoIP in ATM Error! Reference source not found. is
the reference for most of the test cases.
For the test cases that haven't a reference in the EUROCONTROL documentation, the reference is then the official
documentation of "DFS/DSNA/FREQUENTIS FIELD TRIALS" Error! Reference source not found. Error! Reference
source not found..
The covered areas are:

Call setup performances;


Audio quality for G.711 Codec with A-law;
Signalling performance: PTT and SQL delay;
Network performance: Round-Trip delay, One-way delay through Receiver and
Transmitter.
System performance: Frequency Coupling Time, Cross-Coupled PTT Inhibition
Period, Best Signal Selection Differential Delay.

Langen

Vienna

(DFS)

(FREQUENTIS)

SESAR VPN
(PENS by SITA)

224

Madrid

Rome

(AENA + INDRA)

(ENAV)

Copyright 2014 JSP-Teleconsultancy

SESAR WP 15.2.10 VoIP Validation work

SESAR 15.2.10 D11 Tests


Telephone Test cases:
Interoperability: DA, IA call & Detection of Link connection loss tests
Call Performance: DA call setup time, Voice quality (G.711) & Delay
Thresholds: Tests for maximum throughput, increasing traffic with same
and different Classes of Service (CoS), Critical Jitter test
Call performance with network load
Radio Test Cases:
Radio Session performance;
Voice quality (G.711),
Signalling performance: PTT and SQL delay;
Network performance: Round-Trip delay, One-way delay through
Receiver and Transmitter.
System performance: Frequency Coupling Time, Cross-Coupled PTT
Inhibition Period, Best Signal Selection Differential Delay.

Produced by JSP Teleconsultancy

225

VoIP validation activities (SESAR 15.2.10)


The following defines the task 3 (VoIP activities) relating to VoIP ground network validation within the A/G
voice communications chain that were included in the SESAR JU WP.15.2.10 D12 test phase

Preliminary Network Performance Tests

Local interface configuration, IPv4 address reachability, IPv4 port connectivity test, NTP synchronization,
PENS CoS Tagging, PENS CoS performance, PENS CoS performance under load conditions,

Telephone Tests:

Detection Link Connection Loss recognition by interface of link loss when no response to OPTIONS ping.

SIP Call performance tests (i.e. Call setup times for DA under no traffic load conditions)

SIP Call performance tests (i.e. Call setup times for DA under low/medium/high traffic load conditions)

Codec Voice Quality Tests over WAN measured from End-to-End under pre-defined traffic load conditions

Codec Voice Quality Tests over WAN measured over Network only under pre-defined traffic load
conditions

Codec Voice Delay Tests over WAN measured from End-to-End under pre-defined traffic load conditions
etc.

Radio Tests

Radio Session Performance- measuring the time to establish a session to a radio.

Codec Voice Quality Tests over WAN measured from End-to-End under pre-defined traffic load
conditions.

Codec Voice Quality Tests over WAN measured over Network only under pre-defined traffic load
conditions.

PTT latency tests.

Squelch Delay tests.

Climax (Multicarrier off-set) delay tests over a WAN. Verification that during Voice transmission on
Multiple Carriers (with pre-defined off-sets), voice signals can be delayed with respect to the others in order
to prevent echo in cockpit.

Verification that each time a session is established to a radio, the VCS measures relative delay to GRS
transmitters in a multi-carrier offset climax group by performing a Ping-test and adjusts voice delay on each
path accordingly.

The SESAR 15.2.10 D12 report to be sent to SESAR JU in June 2013 will indicate whether the PENS network
can be used for operational voice traffic. (At network level, the results of ongoing safety case will also have to
demonstrate that the network can be employed for Voice traffic).

226

Copyright 2014 JSP-Teleconsultancy

SESAR WP 15.2.10 VoIP Validation work

Produced by JSP Teleconsultancy

227

Next Generation ICAO 9896 VoIP


interfaces for ATS Ground Voice Network
- Part 1

228

Copyright 2014 JSP-Teleconsultancy

SESAR WP 15.2.10 VoIP Validation work

Glossary
2W
4W
A-G
A-law
A/C
A/G
AAMS
ACC
ACL
ACP
ADPCM
AGC
AGVN
AIMS
AM
AMHS
ANSP
ATC
ATM

2wire
4wire
Air to Ground
PCM companding algorithm used in Europe
Aircraft Call
Air/Ground
Advanced Airspace Management System
Area Control Centre
Access Control Lists
Aeronautical Communications Panel
Adaptive Differential Pulse Code Modulation
Automatic Gain Control
ATS Ground Voice Network
Aeronatical Information Management System
Amplitude Modulation
Advanced Message Handling System
Air Navigation Service Provider
Air Traffic Control
Air Traffic Management-- or --Asynchronous Transfer Mode

ATN

Aeronautical Telecommunication Network-- or --Air Traffic Network

ATS
ATS-IP
ATS-No.5
ATS-QSIG
ATS-R2
ATSU
BCP
BSS
C/N
CAS
CB
CCS
CDM
CFMU
CLD
CLIMAX
CNS
CNS/ATM
COMT
CPU
CS-ACELP
CSMA/CA
CSRC
CWP
DA
DACS
DC
DCCP
DCCVC
DHCP
DS
DSCP
DSP
DTMF
E1
EC
ECAC
ECIP
ED
E-LAN
ENUM
EPL

Air Traffic Services


Air Traffic Services IP network
Air Traffic Services Number 5 signalling protocol
Air Traffic Services Signalling at the Q reference point
Air Traffic Services- R2 signalling protocol
Air Traffic Service Units
Best Current Practices
Best Signal Selection
Carrier to Noise Ratio
Channel Associated Signalling
Central Battery
Common Channel Signalling
Collaborative Decision Making
Central Flow Management Unit
Climax time Delay
Off-set carrier transmission
Communication, Navigation, Surveillance
Communication, Navigation, Surveillance / Air Traffic Management
Communication Team
Central Processing Unit
Conjugate Structure - Algebraic Code Excited Linear Prediction
Carrier Sense Multiple Access with Collision Avoidance
Contents Source Identifiers
Controller Working Position
Direct Access
Digital Access Cross-connect Switch
Direct Current
Datagram Congestion Control Protocol
Direct Controller to Controller Voice Communication
Dynamic Host Configuration Protocol
Differentiated Services
DiffServ CodePoint
Digital Signal Processor
Dual Tone Multi-Frequency
2048kbps interface
European Community
European Civil Aviation Conference
European Convergence and Implementation Plan
EUROCAE Document
Ethernet-Virtual Private LAN service
E.164 Numbering mapping to URI
Ethernet Private Line

Produced by JSP Teleconsultancy

229

ESSI
ESSIP
ETSI
EUROCAE
EVPL
FAB
FAB-EC
FTP
G-G
G.114
G.703
G.704
G.711
G.728
G.729
G/G
GRS
GW
H.323
HE
HMI
HQ
HTTP
I/F
IA
IAX
ICAO
ICCVC
ID
IDA
IETF
IF
IP
IP-PBX
IP-VCS
IPS
IPTV
IPsec
IPv4
IPv6
ISDN
ISP
ITU
ITU-T
JU
LAN
LD
LD-CELP
LED
LSP
MASPS
MFC-R2
MGCP
MIB
MMUSIC
MOPS
MPEG
MPLS
NAT
NIMS
NOP
NSP
NVS
OSI
OVR
PABX
PC

230

European Single Sky Implementation


European Single European Sky Implementation Programme
European Telecommunication Standard Institute
European Organisation for Civil Aviation Equipment
Ethernet Virtual Private Line
Functional Airspace Block
Functional Airspace Block - European Central
File Transfer Protocol
Ground-Ground
ITU-T recommendation: One-way Transmission Time
ITU-T recommendation for transmitting voice over digital carriers
ITU-T recommendation: framing specification for G.703.
ITU-T recommendation for PCM voice coding
ITU-T recommendation: LD-CELP voice coding
ITU-T recommendation: CS-ACELP speech coding
Ground to Ground
Ground based RAdio Station
Gateway
A "Voice Over Ip" Standard
Header Extension
Human Machine Interface
Headquarters
Hyper Text Transfer Protocol
Interface
Instantaneous Access
Internet Asterisk Exchange
International Civil Aviation Organisation
Instantaneous Controller to Controller Voice Communication
Identity
Indirect Access
Internet Engineering Task Force
Intermediate Frequency
Internet Protocol
IP based Private Branch Exchange
IP based Voice Communication System
Internet Protocol Suite
Internet Protocol Television
Internet Protocol Security
Internet Protocol version 4
IP Version 6
Integrated Services Digital Network
Internet Service Provider
International Telecommunication Union
International Telecommunications Union - Telecommunication
Joint Undertaking
Local Area Network
Loop Disconnect
Low Delay-Code Excited Linear Prediction
Light Emitting Diode
Label Switched Paths
Minimum Aviation System Performance Specifications
Multi-Frequency Compelled R2
Media Gateway Control Protocol
Management Information Base
Multipart MUltimedia Session Control
Minimum Operation Performance Specifications
Moving Picture Experts Group
Multi-Protocol Label Switching
Network Address Translation
Network Information Management System
Network Operations Plan
Network Service Provider
National Voice Switch
Open Systems Interconnection
Override
Private Automatic Branch Exchange
Personal Computer-- or --Protocol Control-- or --Provisional Council

Copyright 2014 JSP-Teleconsultancy

SESAR WP 15.2.10 VoIP Validation work

PCM
PCMA
PDA
PDH
PENS
PHB
PINT
PMU
PPP
PSD
PSSG
PSTN
PT
PTT
PTT-id
PUG
Q.921
QSIG
R2S
RCE
REC
RFC
RIP
RRCE
RSSI

Pulse Code Modulation


Post Code Modulation using A-law companding
Personal Digital Assistant
Plesiochronous Digital Hierarchy
Pan European Fixed Network Service
Per-Hop Behaviours
PSTN and Internet Interworking
PENS Management Unit
Point-to-Point Protocol
Power Spectral Density
PENS Service Steering Group
Public Switched Telephone Network
Payload Type
Push To Talk
Push-to-Talk Identity
PENS User Group
ITU-T recommendation: Digital Subscriber Signalling System No 1 (DSS1) - ISDN
user - network data link layer - specification
Signalling at the Q reference point
Real Time Session Supervision
Radio Control Equipment
RECORDERS
Request for Comments
Routing Information Protocol
Radio Remote Control Equipment
Received Signal Strength Indication

RTCP
RTP
RTPRx
RTPTx
RTSP
RTx
RX
S/N
SARP
SCT
SDH
SDP
SES
SESAR
SG1
SG2
SG4
SIMPLE
SINAD
SIP
SIP-CWP
SIPPING
SIPit
SJU
SLA
SMTP
SNMP
SNR
SOAP
SOW
SPIRITS
SSRCI
SWIM
TA
TCP
TCP/IP
TDM
TELCO

Real Time Control Protocol


Real Time Protocol
Real time Transport Protocol Receive path
Real-time Transport Protocol Transmit path
Real-time Transport Streaming Protocol
Radio Transceiver
Receive
Signal to Noise
Standards and Recommended Practices
Simultaneous Call Transmissions
Synchronous Digital Hierarchy
Session Description Protocol
Single European Sky
Single European Sky ATM Research
Sub-Group 1
Sub-group 2
Sub-Group 4
SIP for Instant Messaging and Presence Leveraging Extensions
SIgnal to Noise Ratio And Distortion
Session Initiation Protocol
Controller Working Position employing SIP
Session Initiation Protocol InvestIGation
SIP interoperability tests
SESAR JOINT UNDERTAKING
Service Level Agreement
Simple Mail Transfer Protocol
Simple Network Management Protocol
Signal to Noise Ratio
Simple Object Access Protocol
Statement Of Work
Service in the PSTN/IN requesting Internet Services
Synchronization Source Identifier
System Wide Information Management
Transversal Area
Transport Control Protocol
Transfer Communications Protocol /Internet Protocol
Time Division Multiplexing
Telecommunication Network Operators

TF
TLS

Task Force
Transport Layer Security

Produced by JSP Teleconsultancy

231

TMA
UA
UAC
UDP
UHF
UMTS
URL
US
UTC
VAD
VC
VCS
VCS-TF
VHF
VLL
VOTE
VPLS
VPN
VRRP
WAN
WG
WG-I
WG67
WP
WWW

232

Terminal Management Area


Unnumbered Acknowledgement
Upper Air Control
User Datagram Protocol
Ultra-High Frequency
Universal Mobile Telecommunications System
Uniform Resource Locator
United States
Universal Co-ordinated Time
Voice Activity Detection
Virtual Circuit
Voice Communication System
Voice Communication Systems Task Force
Very High Frequency
Virtual Leased Line
VoIP in ATM implementation & Transition Expert-group
Virtual Private LAN Service
Virtual Private Network
Virtual Router Redundancy Protocol
Wide Area Network
Working Group
ICAO WG-I
Working Group 67
Work Package
World Wide Web

Copyright 2014 JSP-Teleconsultancy

SESAR WP 15.2.10 VoIP Validation work

Produced by JSP Teleconsultancy

233