You are on page 1of 89

Next Generation ICAO 9896

VoIP interfaces for the


ATS Ground Voice Network
Presented by
JOHN PALMER

Course Objectives - PART 2


Part 2 of this course will introduce you to:
Added benefits VoIP brings to ATS Ground
Telephone network
Added benefits VoIP brings to ATS Ground
Radio network

Course Objectives - Part 3


Part 3 of this course will introduce you to:
Added benefits VoIP brings to Recording
equipment
Network performance aspects
VoIP in ATM network architecture
VoIP in ATM network security
EUROCONTROL Test Tool
Interoperability Events overview
Network emulator/Performance Measurements

Agenda
Introduction
Added benefits VoIP brings to ATS Ground
Telephone network
Added benefits VoIP brings to the ATS Ground
Radio network

SIP Request Messages (1)


SIP used for Peer-to-Peer Communication although it
uses a Client-Server model;
Requests are called methods
Six methods are defined in base RFC 3261:
INVITE

Sent by User Agent to request media session with


another User Agent

ACK

Sent by User Agent or Proxy Server to Acknowledge


final response to INVITE request.

BYE

Sent by User Agent to terminate a media session

CANCEL

Sent by User Agent or Proxy Server to terminate


pending searches or call attempts

REGISTER

Sent by User Agent to notify SIP network of its current


Contact URI (IP address)

OPTIONS

Sent by User Agent or Proxy Server to send and


receive capabilities without call(s) established.

SIP Request Messages (2)


Seven methods are defined in other RFCs
REFER

Sent by User Agent to request another User Agent to access


the URI supplied. (i.e. call transfer)

SUBSCRIBE/
NOTIFY

Sent by User Agent to establish a subscription for the purpose


of receiving notifications via NOTIFY method (e.g. Presence
and Message Waiting Indication)

MESSAGE

Transports instant messages between User Agents;

INFO

Sends call signalling info between User Agents during media


session;

PRACK

Open one-way media session before call establishment & QoS


negotiation before completing INVITE

UPDATE

Modifies session prior to establishment (e.g. placing call on


hold etc.) after session estblished re-INVITE is used.

SIP Response Messages (Classes)


Class

Description

Action

1xx

Informational

Indicates status of call prior to completion. If first


informational or provisional response

2xx

Success

Request has succeeded. For an INVITE, ACK


should be sent; otherwise stop retransmissions of
request.

3xx

Redirection

Server has returned possible locations. The client


should retry request at another server.

4xx

Client Error

Request has failed due to an error by client. The


client may retry request if reformulated according to
response.

5xx

Server failure

Request has failed due to an error by server.


Request may be retried at another server.

6xx

Global failure

Request has failed. Request should not be tried


again at this or other servers.

SIP User Agents


SIP User Agent

SIP User Agent

User Agent Client


(UAC)

User Agent Client


(UAC)

User Agent Server


(UAS)

User Agent Server


(UAS)

SIP User Agent is a SIP enabled end device containing:


User Agent Client application: Initiates SIP requests
User Agent Server application: Receives requests and returns Responses on
behalf of user;

SIP User Agent establishes a media session with


another SIP User Agent.
Maintains state of calls it initiates or participates in;
Supports Session Description Protocol (SDP) for
media description;

SIP Registration

A establishes its presence by sending REGISTER request to


Registrar Server;
REGISTER message contains normal URI address of A and a
Contact URI indicating current IP address of A;
Registrar Server updates Location database used by Proxy
Servers to route SIP Requests to A; This binds address to As
current location
Registrar Server sends a 200 OK response to A;
Any new INVITE requests to A received by Proxy Server will be
proxied to new contact address after Location Server query;
SIP CWP A

User Agent
Client/Server

REGISTER sip:aena.es SIP/2.0


From: sip:radar-south@en_route.lecm.aena.es
To: sip:radar-south@en_route.lecm.aena.es
Contact: <sip:195.37.83.161>
Expires: 3600

Location
Server

Registrar
Server

radar-south@195.37.83.161

200 OK

Domain: aena.es

SIP Network Servers


SIP Proxy Server: logical entity containing:
Proxy Server client application: Forwards SIP Requests received from

SIP User Agent or another SIP Proxy server.


Proxy Server application: Forwards SIP responses received from
another SIP User Agent or SIP Proxy server.

SIP Proxy Server can access DNS or Location servers


to aid Request processing
SIP Proxy Server does not issue Requests;
SIP Proxy Server has no Media capabilities;
SIP Proxy Server must support TCP, UDP, TLS.
Can be stateless (no call state stored) or stateful (call
state stored);
SIP Redirect Server: Responds to SIP Requests received from SIP
User Agent with a redirection class response (3xx) containing address
of next server (similar to Call Forwarding).

SIP session establishment


between VCS's
SIP sessions between VCSs established on-demand basis,
when a call is made;
Can be initiated and cleared from both VCS endpoints;
No limit on number of sessions, only related to number of
SIP user agents at VCS endpoints;
If Voice Activity Detection (VAD) disabled, audio + silence
periods transported continuously during a call;
If VAD is enabled, audio is only transported when speech is
present and silence period suppressed (saves on
bandwidth)
RTP audio packets every 20ms (default) transport voice
between endpoints;

Example of SIP Direct Access Call

A sends INVITE request;


B returns 180 Ringing & 200 OK final response;
A sends ACK to complete 3-way session setup handshake
(INVITE, final response, ACK).
Media session established;
B sends BYE request and A returns 200 OK response.
INVITE

User Agent A
VCS
endpoint

180 Ringing
200 OK
ACK

User Agent B
VCS
endpoint

Media session
BYE
200 OK

Call types
SIP signalling used by Direct Access (DA), Indirect Access (IDA)
and Instantaneous Access (IA) call types should be identical.
Call importance identified by SIP Priority Header field value
Call type identified by SIP subject Header field
First time a protocol for IA call implementation has been defined;
Type of call
Priority

Priority Direct /
Indirect Access call
Instantaneous Access call

Routine

Monitoring

SIP Priority header


field value
emergency
urgent

Tactical Direct /
Indirect Access call

urgent

Strategic Direct /
Indirect Access call

normal

General Purpose Direct /


Indirect Access call

non-urgent

Position monitoring

non-urgent

Type of call

Instantaneous Access call

SIP Subject
header field value
IA call

Priority Direct / Indirect Access


call

DA/IDA call

Routine Direct / Indirect Access


call

DA/IDA call

Position monitoring (combined)


Position monitoring (A/G)
Position monitoring (G/G)

monitoring
A/G monitoring
G/G monitoring

Proposed VCS Address scheme


and its operation
Proposed format of SIP URIs at VCS endpoint as specified by RFC
3261, the formal syntax for a SIP is:
SIP-URI=sip: [ userinfo ] host [ : port ] uri-parameters [ headers ]
userinfo=( ATS_telephone_no. / user_role) @

host= atsu . centre_id . local_domain

ATS_telephone_number=1*DIGIT
user_role=1* (unreserved)

atsu=1* (unreserved)
centre_id
= 4*ALPHA; /*ICAO identifier for a specific ATS centre
local_domain = 1* (unreserved); /*ANSP domain

Example:
sip:user_info@atsu.icao_centre_id.local_domain
Planner sector zmu at en-route centre (ICAO code LECM) within the
AENA domain has SIP URI:
sip:planner.zmu@en_route.lecm.aena.es
sip:314002@en-route.lecm.aena.es

Media session attribute negotiation


During SIP session establishment, Codecs and send/receive mode
attributes are negotiated between endpoints;
INVITE (PCM u-law, PCM A-law, LD-CELP, Sendrecv session)

200OK (PCM A-law, Sendrecv session)


<send-receive mode>

recvonly
sendrecv
sendonly
inactive

rtpmap:<payload type>

rtpmap:0 (for PCM-)


rtpmap:8 (for PCM-A)
rtpmap:15 (for G.728)
rtpmap:18 (for G.729)

<encoding name>/<clock rate>

PCMU/8000 (for PCM-)


PCMA/8000 (for PCM-A)
G728/8000 (for G.728)
G729/8000 (for G.729)

Attributes (a=)

SIP call detail (INVITE)


10.100.1.101

SIP INVITE

Proxy Server in NATS UK

planner.zmu@en_route.lecm.aena.es

radar.sec1@en_route.egpn.nats.uk

INVITE sip:planner.zmu@en_route.lecm.aena.es SIP/2.0


Via: SIP/2.0/UDP 10.100.1.101:5060; rport; branch=z8hH4aFnp18a
From: radar.sec1<sip:radar.sec1@en-route.egpn.nats.uk>;tag=123
To: <sip:planner.zmu@en_route.lecm.aena.es>
Call-ID: 122276776@10.100.1.101
CSeq: 20 INVITE
Contact: <sip:radar.sec1@10.100.1.101:5060>
Max-Forwards: 20
User_Agent: NATS_UA1
Subject: DA/ IDA call/ IA call/ monitoring /A/G or G/G monitoring
Priority: emergency/urgent/normal/non-urgent
WG67-Version: phone.01
Expires: 120
Allow: INVITE, ACK, BYE, CANCEL, INFO, REFER, NOTIFY, SUBSCRIBE
Content-Type: application/sdp
Content-Length: 205
v:0
o:NATS_UA1 0 1 IN IP4 10.100.1.101
c:IN IP4 10.100.1.101
t:0 0
m:audio 5004 RTP/AVP 8 0 15
a:rtpmap:8 pcma/8000
a:rtpmap:0 pcmu/8000
a:rtpmap:15 g728/8000
a:sendrec

20.200.2.202

SIP INVITE

INVITE sip:planner.zmu@en_route.lecm.aena.es SIP/2.0


Via: SIP/2.0/UDP proxy.nats.uk 5060;branch=z8hH4aF838421
Via: SIP/2.0/UDP 10.100.1.101:5060;rport; branch=z8hH4aFnp18a
From: <sip:radar.sec1@en-route.egpn.nats.uk>;tag=123
To: <sip:planner.zmu@en_route.lecm.aena.es>
Call-ID: 122276776@10.100.1.101
CSeq: 20 INVITE
Contact: <sip:radar.sec1@10.100.1.101:5060>
Max-Forwards: 19
User_Agent: NATS_UA1
Subject: DA/ IDA call/ IA call/ monitoring /A/G or G/G monitoring
Priority: emergency/urgent/normal/non-urgent
WG67-Version: phone.01
Expires: 120
Allow: INVITE, ACK, BYE, CANCEL, INFO, REFER, NOTIFY, SUBSCRIBE

Content-Type: application/sdp
Content-Length: 205
v:0
o:NATS_UA1 0 1 IN IP4 10.100.1.101
c:IN IP4 10.100.1.101
t:0 0
m:audio 5004 RTP/AVP 8 0 15
a:rtpmap:8 pcma/8000
a:rtpmap:0 pcmu/8000
a:rtpmap:15 g728/8000
a:sendrec

SIP Call detail (180 Ringing)


10.100.1.101

20.200.2.202

Proxy Server in NATS UK


180 Ringing

180 Ringing
planner.zmu@en_route.lecm.aena.es

radar.sec1@en_route.egpn.nats.uk

SIP/2.0 180 Ringing


Via: SIP/2.0/UDP proxy.nats.uk 5060;branch=z8hH4aF838421;
received=10.100.1.101
Via: SIP/2.0/UDP 10.100.1.101:5060;branch=z8hH4aFnp18a
From: radar.sec1<sip:radar.sec1@en_route.egpn.nata.uk>;tag=123
To: planner.zmu<sip:planner.zmu@en_route.lecm.aena.es>;tag=321
Call-ID: 122276776@10.100.1.101
CSeq: 20 INVITE
Contact: sip:planner.zmu@20.200.2.202:5060
WG67-Version: phone.01
Content-Length:0
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.100.1.101:5060;branch=z8hH4aFnp18a
From: radar.sec1<sip:radar.sec1@en-route.egpn.nats.uk>;tag=123
To: planner.zmu<sip:planner.zmu@en_route.lecm.aena.es>;tag=321
Call-ID: 122276776@10.100.1.101
CSeq: 20 INVITE
Contact: <sip:planner.zmu@20.200.2.202:5060>
WG67-Version: phone.01
Content-Length:0

SIP Call detail (200 OK)


10.100.1.101

20.200.2.202

200 OK

Proxy Server in NATS UK

200 OK

planner.zmu@en_route.lecm.aena.es

radar.sec1@en_route.egpn.nats.uk

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.100.1.101:5060;branch=z8hH4aFnp18a
From: radar.sec1<sip:radar.sec1@en_route.egpn.nats.uk>;tag=123
To: planner.zmu<sip:planner.zmu@en_route.lecm.aena.es>;tag=321
Call-ID: 122276776@10.100.1.101
CSeq: 20 INVITE
Contact: <sip:planner.zmu@20.200.2.202:5060>
User_Agent: AENA_UA1
Allow: INVITE, ACK, BYE, CANCEL, INFO, REFER, NOTIFY, SUBSCRIBE
Subject: DA/ IDA call/ IA call/ monitoring /A/G or G/G monitoring
Priority: emergency/urgent/normal/non-urgent
WG67-Version: phone.01

Content-Type:application/sdp
Content-Length:159
v:0
o:AENA_UA1 0 1 IN IP4 20.200.2.102
c:IN IP4 20.200.2.102
t:0 0
m:audio 5004 RTP/AVP 8
a:rtpmap:8 pcma/8000
a:sendrec

SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.nats.uk 5060;branch=z8hH4aF838421;
received=10.100.1.101
Via: SIP/2.0/UDP 10.100.1.101:5060;branch=z8hH4aFnp18a
From:radar.sec1<sip:radar.sec1@en_route.egpn.nats.uk>;tag=123
To:planner,zmu<sip:planner.zmu@en_route.lecm.aena.es>;tag=321
Call-ID: 122276776@10.100.1.101
CSeq: 20 INVITE
Contact: <sip:planner.zmu@20.200.2.202:5060>
User_Agent: AENA_UA1
Allow: INVITE, ACK, BYE, CANCEL, INFO, REFER, NOTIFY, SUBSCRIBE
Subject: DA/ IDA call/ IA call/ monitoring /A/G or G/G monitoring
Priority: emergency/urgent/normal/non-urgent
WG67-Version: phone.01

Content-Type:application/sdp
Content-Length:159

v:0
o:AENA_UA1 0 1 IN IP4 20.200.2.102
c:IN IP4 20.200.2.102
t:0 0
m:audio 5004 RTP/AVP 8
a:rtpmap:8 pcma/8000
a:sendrec

SIP Call detail (ACK)


20.200.2.202

Proxy Server in NATS UK

10.100.1.101

ACK
radar.sec1@en_route.egpn.nats.uk

planner.zmu@en_route.lecm.aena.es

ACK sip:planner.zmu@20.200.2.202 SIP/2.0


Via: SIP/2.0/UDP 10.100.1.101:5060; branch=z9hG4bKka42
Max-Forwards:20
From: radar.sec1<sip:radar.sec1@en_route.egpn.nats.uk>;tag=123
To: planner.zmu<sip:planner.zmu@en_route.lecm.aena.es>;tag=321
Call-ID: 122276776@10.100.1.101
CSeq: 20 INVITE
Contact: sip:planner.zmu@20.200.2.202
WG67-Version: phone.01
Content-Length:0

SIP Call detail (BYE & 200 OK)


Proxy Server in NATS UK
10.100.1.101

radar.sec1@en_route.egpn.nats.uk

20.200.2.202

BYE
planner.zmu@en_route.lecm.aena.es

200 OK

BYE sip:planner.zmu@en_route.lecm.aena.es SIP/2.0


Via: SIP/2.0/UDP 20.200.2.202:5060; branch=z9hG4bk4332
Max-Forwards:20
From: planner.zmu<sip:planner.zmu@en_route.lecm.aena.es>;tag=321
To: radar.sec1<sip:radar.sec1@en_route.egpn.nats.uk>;tag=123
Call-ID: 122276776@20.200.2.202
CSeq: 56 BYE
WG67-Version: phone.01
Content-Length:0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 20.200.2.202:5060; branch=z9hG4bk4332
From: planner.zmu<sip:planner.zmu@en_route.lecm.aena.es>;tag=321
To: radar.sec1<sip:radar.sec1@en_route.egpn.nats.uk>;tag=123
Call-ID: 122276776@20.200.2.202
CSeq: 56 BYE
WG67-Version: phone.01
Content-Length:0

WG67-Version header field

Mandatory in all requests and responses from Feb 2012


onwards;
Header syntax:
WG67-Version = WG67-Version HCOLON version-value *(COMMA version-value)
version-value = field-value *(SEMI version-params)
field-value = type . number
type = radio / phone / legacy-eu / recorder / supervision
number = 2*DIGIT

field-value uses following latest document versions


ED-137 Volume 1 = radio.01
ED-137 Volume 2 = phone.01
ED-137 Volume 3 = legacy-eu.01
ED-137 Volume 4 = recorder.01
Examples are:
WG67-Version: radio.01
WG67-Version: radio.01; gateway=RRC
WG67-Version: phone.01
WG67-Version: phone.03,legacy-eu.01
WG67-Version: legacy-eu.01; gateway=ATS-R2

Instantaneous Access Call


functionality
IA call handled as 2
A-party UA
Proxy 1
Proxy 2
B-party UA
independent sessions
A activates IA key INVITE (urgent, IA call, ses1) INVITE (urgent, IA call, ses1)
(AB & BA).
INVITE (urgent, IA call, ses1)
100 Trying
100 Trying
The initial session AB is
200 OK
controlled (released) by A
200 OK
200 OK
& its possible response
ACK
ACK
ACK
from BA is controlled
Both-way RTP media for the 1st session
One-way voice path A-B
connected to Bs ground
(released) by B.
A B: monitoring
telephne earpiece or
A B: talking
loudspeaker. Voice path
The only dependency
B-A used for monitoring
Ground & Radio calls in
between 2 sessions is
progress at B-partyss
terminal.
within application or
INVITE (urgent, IA call, ses2)
B activates IA key
INVITE (urgent, IA call, ses2)
Graphical User Interface.
100 Trying
Auto answer

INVITE (urgent, IA call, ses2)

Auto answer

With Both-way talking,


VCS must remove calling
& called party voice from
One-way voice path B-A
its respective
connected to As ground
earpiece or
monitoring channels telephne
loudspeaker. Voice path
A-B used for monitoring
to avoid acoustic
Ground & Radio calls in
progress at A-partys
feedback problems.
terminal.

100 Trying
200 OK
200 OK

ACK

ACK

200 OK
ACK

Both-way RTP media for the 2nd session


A B: talking
A B: monitoring

Instantaneous Access Calls with


monitoring disabled
If VCS has monitoring
disabled, it sends an
200OK final response
containing an
a=recvonly SDP
answer attribute. Only
one-way RTP media is
established for the
session.

A-party UA

Proxy 1

Proxy 2

B-party UA

Both-way RTP media for the 1st session


A B: monitoring
A B: talking
INVITE (urgent, IA call, ses2)
INVITE (urgent, IA call, ses2)
INVITE (urgent, IA call, ses2)

100 Trying
100 Trying

Auto answer

In this example,
monitoring is not
configured on VCS A

B activates IA key

200 OK
a=recvonly

ACK

200 OK
a=recvonly
ACK

200 OK
a=recvonly
ACK

One-way RTP media for the 2nd session


A B: talking

Indication given to
calling party that
monitoring is not
possible;
BYE (ses2)

BYE (ses2)

BYE (ses2)
200 OK
200 OK
200 OK

B de-activates IA key

OVR call example (sid SDP attribute)


INVITE and INFO in forward direction send sid (source identity) attribute defining Tail
200OK and INFO in backwards direction send sid (source identity) attribute defining Chain
INFOs defining chain identifiers sent in backwards direction as OVR calls added to chain.
INFOs defining tail identifiers sent in forwards direction as OVR calls added to tail.
1. B makes OVR call to C
2. C makes OVR call to D

Chain: C (2)
Chain: C,D (5)

3. D makes OVR call to A


Tail: D,C,B (6)

Chain: C,D,A (9)

200OK sid:C (2)


INFO sid:C D (5)

INVITE sid:B (1)

200OK sid:A (7)

INFO sid:C D A (9)


Chain: D (4)
Chain: D,A (8)
Tail: B (1)

INVITE sid:D C B (6)

INVITE sid:C B (3)


D

C
200OK sid:D (4)
INFO sid:D A (8)

Chain: A (7)
Tail: C,B (3)

OVR call audio loop detection


Following on from previous scenario:
10. A makes OVR call to B

B enters OVR-loop state as Tail list from A-party matches at least 1 element in its current
Chain list. B creates Local intersection list: Tail (A,D,C.B) Chain list (C,D,A) = C,D,A
11. B sends empty sid attribute to A & blocks audio received on forward & receive paths from being summed.

B does not send INFO to C with updated tail


On receiving sid empty, A-party does not update its local Chain list or send INFO with
updated chain.
Chain: C,D,A (9)
Tail: A,D,C,B (10)

OVR-loop
state

Chain:
Tail: D,C,B (6)

200OK sid:empty (11)

INVITE sid:A,D,C,B (10)

200OK sid:C (2)


INFO sid:C D A (9)

INVITE sid:B (1)

INVITE sid:D C B (6)

200OK sid:A (7)


INVITE sid C B:(3)
D

C
Chain: D,A (8)
Tail: B (1)

200OK sid:D (4)


INFO sid:D A (8)

Chain: A (7)
Tail: C,B (3)

OVR call- Audio block on Loop


detection
1. B makes OVR call to C
2. C makes OVR call to D
3. D makes OVR call to A
4. A makes OVR call to B

Block

B
Block

CG/G+A/G+C Mic
DG/G+A/G+D Mic
AG/G+A/G+A Mic
BA/G (included only
after loop detection)

Forward path
Return path
B G/G+B Mic
C G/G+C Mic
D G/G+D Mic
A G/G+A Mic

BA/G

B G/G+B Mic

B G/G+B Mic
C G/G+C Mic
D G/G+D Mic
AG/G+A/G+A Mic
BA/G (included only

B G/G+A Mic
C G/G+C Mic

after loop detection)

C
D G/G+A/G+D Mic
A G/G+A/G+A Mic
BA/G (included only
after loop detection)

OVR call example (rid SDP attribute)


Local rid list at A:
f5

Local rid list at C:


(2) f1,f2

Local rid list at B:


(4) f1, f2,f4

C adds new freq f3


(5) f1,f2,f3
INVITE (1)

INVITE (3)

200OK rid f1,f2,f4 (4)


INFO rid: f1,f2,f3,f4 (6)

200OK rid: f1,f2 (2)


INFO rid: f1,f2,f3 (5)

C sends its Radio IDs: f1 & f2 to B.


As B already has local frequencies f1+f2, it will sum in only f4
before sending summed audio stream to A.
If new frequency f3 added at C, it triggers C to send an INFO
message with updated rid list and B in turn will send INFO
updated rid list to A.

New network wide supplementary


services
Whenever possible WG67 cited existing IETF RFCs defining
required feature (Dont re-invent the wheel)
Call hold: (RFC 5359)
Call Transfer: (Attended & Unattended within existing dialog)- (RFC
5359)
Conference: (3-party conference and Conference of N) with conference
focus either User Agent or External conference focus entity (RFC 4579
ad hoc SIP method)
Call intrusion: (as a Conference with focus (RFC 3840) with intrusion
on timer expiry, immediate or forbidden as ED137)
Positioning Monitoring: (Monitoring audio at other CWPs as ED137)
Presence Event package: (RFC 3856) (i.e. CWP on/off line status)
Dialog package: (RFC 4235) (i.e. Dialog states-Busy, Free)
Link connection loss detection: (RFC 3261) (OPTIONS Ping To
check if call setups possible to SIP-CWPs, Servers and gateways)

Broadcast Conference

Any User Agent or a separate internal VCS Conference Focus Entity


can be conference focus;
Conference creation is based on SIP ad-hoc methods according to RFC
4579.
Also uses RFC 3891 (Replaces Header), RFC 3515 (Refer Method),
RFC 4575 (Event Package for Conference State) and RFC 4579 (Call
Control - Conferencing for User Agents);
Migration of 2 party call between A & B to a 3 party conference with C:

If using CFE. A makes session with CFE and also transfers its call with B to
the CFE. The CFE invites B and B clears its original call with A. CFE then
invites C to conf call.
If using A in focus role. A reINVITES B to Conf session and then
A invites C to Conf Session

If A as focus leaves conference, the conference isnt terminated because


A still performs audio mixing, but it is now mute;
Audible conference entry tone to all participants is possible, as each new
participant joins conference.

Call intrusion (1)

Every SIP end SHOULD


act as focus for a
conference and its URI
SHOULD be a conference
URI (RFC 3840);
On timer T1 expiry intrusion
occurs. T1 (set by ANSP)
allows user to clear existing
call prior to an intrusion
occurring on T1 expiry;
To implement an Intrusion
the Focus has to re-INVITE
unwanted party(s) into a
conference, then connect
intruding user;
INFO method (RFC 2976)
informs users and
gateways of intrusion status
(i.e. Intrusion in progress,
Intrusion completed)

Successful Priority Call Intrusion (single session)


SIP UA A
(Served User)

SIP UA B (focus)
(Wanted User)

SIP UA C
(Unwanted User)

Media Session
INVITE(emergency)
Visual and/or audible
intrusion notification
to Wanted User

182 Queued
Visual and/or
audible notification
to Served User

T1

reINVITE Contact B; isfocus (intrusion)


183 Intrusion in progress
Visual and/or audible intrusion
notification to Served User
200 OK Contact B; isfocus
ACK

200 OK
ACK
INFO Intrusion in progress
200 OK
Visual and/or audible
intrusion notification
to Unwanted User

Media Session

Media Session

Call intrusion (1)


Priority call answered before a predefined time interval
SIP UA A
(Served User)

SIP UA B
(Wanted User)

Media Session

INVITE(emergency)

Visual and/or audible


intrusion notification
to Wanted User

182 Queued
Visual and/or
audible notification
to Served User

SIP UA C
(Unwanted User)

T < T1
BYE
200 OK

200 OK
ACK
Media Session

Automatically or
manually answered

Call Intrusion (2)

Protection from intrusion


possible;
Not possible to intrude
into a priority call
Unwanted user cant
prevent call intrusion;
Users can optionally
SUBSCRIBE (RFC 3265)
to focus requesting
notification about users in
conference session;
Dialog Package (RFC
4235) optional- allows
User Agent to notify
subscribers when their
call state changes (i.e.
Confirmed=Busy,
Terminated= No calls in
progress;

Priority Call Intrusion Forbidden by Wanted User


Priority call is displayed at SIP_End2 and manually answered
SIP_End1
(Served User)

SIP_End2
(Wanted User)

Proxy

SIP_End3
(Unwanted User)

Conference Media Session: 2 parties


Priority Header =normal

INVITE (emergency)
100 Trying

INVITE (emergency)
180 Ringing

180 Ringing

200 OK
200 OK
ACK

ACK
Media Session: 2 parties

SIP_End2 Call intrusion


Protection-ON
SIp End1 does not act as
focus for conference
Call displayed as
Priority call at
SIP_End2

Call manually answered


by SIP_End2 user

Position Monitoring
Enables a user to hear any active voice call at other user
positions; (Note: nothing to do with IA monitoring);
Configured according to ANSP specific needs;
A CWP can be enabled/disabled to send INVITE requesting
monitoring;
Target CWP can refuse request (488 Not acceptable) or
accept request;
INVITE subject header can define:
Monitoring (combined A/G + G/G)
G/G monitoring (i.e. DA/IDA/IA Telephone voice calls)
A/G monitoring (Outgoing & Incoming Radio Calls) in progress at
CWP;

Position Monitoring indication given at CWP being monitored


(ANSP specific);

Network Management Sector Delegation


Protocol Required
WAN

ACC1
NM

NM Command OFFER SECTOR X

ACC2
NM

NM Response ACCEPT SECTOR X


NM Response Confirm control of SECTOR X
NM ACK Confirm control of SECTOR X

UPDATE pre-defined
Network Proxies
with New Sector X address
Loc.
Database
A

Out-In call
Routing tables
updated

UPDATE New
OK
Sector X address
REGISTER
Old VCS A Sector X addr.
REG. New VCS B Sector X addr.
A
Legacy Command
for Sector X
Pull from NM

Proxy
A

Out-In call
Routing Tables
updated

Proxy
B

Outgoing calls Outgoing calls


to Sector X
to Sector X
now routed to B
remain at B

VCS
UA_A

VCS
UA_B

Response
for process
completed

Response
for process
completed

OK

Loc.
Database
B

UPDATE New
Sector X address

REGISTER
Old VCS A Sector X addr/ REG.
New VCS B Sector X addr.
B
Legacy Command
for Sector X
Push from NM

Legacy v SIP interworking specifications

ED 137B Volume 3A- Legacy interworking defines SIP v MFC-R2,


ED-137B Volume 3B-Legacy interworking defines SIP v ATS No.5
ED-137B Volume 3B-Legacy Interworking defines SIP v ATS-QSIG
VCS vendors are developing standalone gateways to aid migration
towards IP networks;
Beware that call performance with gateway at one side only
remains the same as that of legacy protocol, while gateways at
both sides doubles call performance;
VCS

MFC-R2
ATS-No.5
ATS-QSIG

SIP Gateway
with SIP
User Agent

SIP Proxy
Server
SIP

SIP

WAN
ATS-R2
ATS-QSIG
PSTN
RADIO

VCS with SIP


User Agents

SIP Proxy
Server
SIP

SIP

WAN

Foreseen stepped migration


towards SIP from MFC-R2
MFC-R2 circuits should be migrated link-by-link to SIP;
The VCS then becomes the interworking gateway;
Migration at one end only using Gateway has same call setup
time as legacy signalling
VCS C

Legacy system

ATS-R2 IF

ATS-R2 IF

(4W analogue line)

Direct route

In example VCS B has role of


Outgoing Gateway VCS
(i.e. converts SIP signalling from
IP network to MFC-R2 signalling
on Outgoing link towards VCS C.

ATS-R2 IF
(4W analogue line)

VCS B
SIP UA

ATS-R2 IF

VCS A

Gateway
VCS
VoIP system

SIP UA

Indirect route
VoIP system

Foreseen stepped migration


towards SIP from ATS-QSIG
ATS-QSIG lines can be migrated to SIP using gateways on one or
both ends, eventually removing gateways to achieve end-to-end
SIP;
SIP v ATS-QSIG interworking is faster- leading to reduced Call
establishment times,
VCS C
ATS-QSIG IF

ATS-QSIG IF

EN 300 289 line

Direct route
EN 300 289 line

Gateway

Gateway
ATS-QSIG IF

VCS A
SIP UA
ATS-QSIG IF

ATSQSIG IF

SIP UA

In example VCS B has role of


Outgoing Gateway VCS
(i.e. converts SIP signalling from
IP network to ATS-QSIG signalling
on Outgoing link towards VCS C.
ATS-QSIG IF
SIP UA

SIP UA

VCS B

ATS-QSIG IF
ATSQSIG IF

Indirect route

Outgoing gateway SIP v ATS-R2


interworking example 1
SIP_End
(A-side)

Strategic routine
call establishment
from SIP end to
ATS-R2 emulator
and ATS-emulator
clears call

ATS-R2 Emulator
(B-Side)

Gateway

INVITE (normal)
100 Trying

SEIZING line signal


MF Digit
MF Digit Ack
Priority Digit (3)
Priority Digit Ack
MF Digit
MF Digit Ack

P22
STATUS Terminal Free (6)

200 OK
ACK

Status ACK
Ringing Tone

Both-way RTP media

BYE
200OK

Both Way Voice

RELEASE line signal

Call manually
Answered-Ringing
Tone stopped
Call manually
cleared

Incoming gateway ATS-R2 v SIP


interworking example 1
ATS-R2 Emulator
(A-side)

Priority call
establishment of
ATS-R2 call with
Priority digit 1
from ATS-R2
emulator to SIP end
and ATS-R2 emulator
clears call

Gateway
(B-side)

SIP_End

SEIZING line signal


MF Digit
MF Digit Ack
Priority Digit (1)
Priority Digit Ack
MF Digit
MF Digit Ack

INVITE (emergency)

P22
STATUS Terminal Free (6)

180 Ringing

Status ACK
Ringing tone
Ringing tone
stopped

Both Way Voice

200 OK
ACK
Both-way RTP media

BYE
RELEASE line signal

Call manually
answered

200 OK

Call manually
cleared

Added benefits - Telephone


1. Multi-supplier VCS-VCS Interoperability using Common
Telephone interfaces (ED-137B Volume 2).
2. Test Tools available to validate interfaces now VOTER
2.0.0
3. COTS Test Equipment (i.e. Wireshark, WAN emulators,
ITG etc. )
4. 1st time IA call specification
5. Codec negotiation allows bandwidth reduction maybe
new IP codecs in future.
6. Range of telephone features available from IETF
7. GWs tests with SIP v legacy interworking

Agenda
Introduction
Added benefits VoIP brings to ATS Ground
Telephone network
Added benefits VoIP brings to the ATS Ground
Radio network

Call establishment controller -pilot


(Ground - Air)

Call establishment pilot -controller


(Air - Ground)

Call establishment Pilot - Controller


(Air-Ground with Best Signal Selection)

Step 1: SIP session establishment


(VCS & GRS Transceiver endpoints)

WAN
VCS endpoint

VCS endpoint initiates SIP protocol to establish SIP Session


with GRS Transceiver endpoint and define/negotiate SDP
parameters

GRS Transceiver
endpoint

Step 1: SIP session establishment


(VCS & separated GRS Tx and Rx
endpoints)
VCS endpoint initiates SIP protocol to establish separate
SIP Session with GRS Receiver endpoint(s) and
define/negotiate SDP Parameters

GRS Receiver
endpoint

VCS endpoint

WAN

VCS endpoint initiates SIP protocol to establish separate


SIP Session with GRS Transmitter endpoint(s) and
define/negotiate SDP Parameters

GRS Transmitter
endpoint

SIP session establishment


procedure
UA_A1 at
VCS Endpoint

UA_B1 at
GRS Endpoint

INVITE (F1)

100 Trying (F2)

200OK (F3)

Connected

Call is
automarically
answered
ACK (F4)

Tx path
Two way RTP Session

Rx path

Radio SDP attribute negotiation


INVITE (F1)
INVITE sip:txrx.126.125.en_route@10594.dsna.fr:5060 SIP/2.0
Via: SIP/2.0/UDP 10.100.2.101:5060;rport;branch=z9hG4bK1105483690
From: <sip:planner_north@en_route.lecm.anea.es>;tag=790976275
To: <sip:txrx.126.125.en_route@10594.dsna.fr:5060>
Call-ID: 1819029731@10.100.2.101
CSeq: 20 INVITE
Contact: <sip:planner_north@en_route.lecm.anea.es:5060>
Max-Forwards: 20
Subject: radio
Priority: normal or emergency
WG67-Version: radio.01
Expires: 120
Allow: INVITE, ACK, BYE, CANCEL, INFO, REFER, NOTIFY, SUBSCRIBE
Content-Type: application/sdp
Content-Length: 216
v=0
o=vcs-endpoint 2 0 1 IN IP4 10.100.2.101
s=subject
c=IN IP4 10.100.2.101
t=0 0
m=audio 5004 RTP/AVP 8
a=rtpmap:8 PCMA/8000
a=sendrecv
a=type:Radio-Tx/Rx or Radio-Rxonly or Coupling
a=txrxmode: TxRx or Tx or Rx
a=bss:RSSI
a=sigtime:1
a=ptt_rep:3 (implies 3 voice packets sent with PTT-OFF on PTT deactivation)
a=R2S-KeepAlivePeriod:200
a=R2S-KeepAliveMultiplier:10
a=fid:126.125
a=rtphe:1

200OK (F3)
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.100.2.101:5060;rport=5060;branch=z9hG4bK1105483690
From: <sip:planner_north@en_route.lecm.anea.es>;tag=790976275
To: <sip: txrx.126.125.en_route@10594.dsna.fr:5060>;tag=2589
Call-ID: 1819029731@10.100.2.101
CSeq: 20 INVITE
Contact: <sip:txrx.126.175.en_route@10594.dsna.fr:5060>
Max-Forwards: 20
Subject: radio
Priority: normal or emergency
WG67-Version: radio.01
Content-Type: application/sdp
Content-Length: 285
v=0
o=txrx 123456 654321 IN IP4 10.100.6.101
s= subject
c=IN IP4 10.100.6.101
t=0 0
m=audio 5004 RTP/AVP 8
a=rtpmap:8 PCMA/8000
a=sendrecv
a=type:Radio-Tx/Rx or Radio-Rxonly or Coupling
a=txrxmode: TxRx or Tx or Rx
a=bss:RSSI
a=sigtime:1
a=ptt_rep:3 (implies 3 voice packets sent with PTT-OFF on PTT deactivation)
a=R2S-KeepAlivePeriod:200
a=R2S-KeepAliveMultiplier:10
a=fid:126.125
a=PTT-id:000001 to Max value (i.e. 000111)
a=rtphe:1

Media Session attribute negotiation


<send-receive mode>

rtpmap:<payload
type><encoding
name> /<clock rate>

123 R2S/8000 (for R2S)-mandatory

0 PCMU/8000 (G711 PCM mu-law)

8 PCMA/8000 (G711 PCM A-law )

15 G728/8000 (G728 LD-CELP )

18 G729/8000 (G729-CS-ACELP)
(Default=08 Europe, 00 North America)
(Value 123 present in addition to codec)

Sendrecv (default)

Radio-Idle
Radio-Rxonly
Radio-TxRx or Radio (default)
Coupling

txrxmode:
<connection-type>
(optional)

Tx
Rx
TxRx

bss: <BSS quality


index method>
(optional)

No BSS- (Default)
RSSI
AGC
C/N
PSD

type: <call type>

sigtime: <Signalling
Info Time Period>
(optional)

PTT ON/PTT OFF time period in


multiples of RTP packet interval.
Default value is 1 -> implies Radio
signalling info sent in RTP header
extension of every RTP Voice packet
(20ms default) and every R2S-Keepalive
packet (200ms default)

fid: <Frequency ID>


(optional)

Frequency ID (7 character ICAO standard


presentation e.g. 124.175 for 25kHz channel
spacing or 118.005 for 8.33kHz channel
spacing)

ptt_rep: <PTT OFF


Repetition>
(optional)

Number of voice packets sent indicating PTT-OFF


following transition from PTT-ON to PTT OFF: (0-3)
Number of voice packets sent indicating SQU-OFF
following transition from SQU-ON to SQU OFF:(0-3)
Default value 0 -> Implies 1 RTP Voice packet sent
with PTT-OFF/SQU-OFF, prior to R2S-Keepalive
packets being sent with PTT-OFF/SQU-OFF.

R2SKeepAlivePeriod:

Maximum time between R2S-Keepalive packets (201000ms)


Default Value = 200ms

R2SKeepAliveMultiplier
:

No. of R2S-Keepalive packets in error or not received


by endpoint before R2S-LocalHoldTime counter
expires
and
SIP
session
times
out:
(2-50) Default Value = 10

ptt-id: <PTT
identity>

PTT identity (value from 000001 to max no. of


possible RTP streams, e.g. 111111=63) assigned by
GRS endpoint in 200OK response. For Radio-TxRx
or Coupling call types only.

rtphe: <RTPHE
Version>
(optional)

0-1
RTP Header Extension Version used.
At Jan 2012 latest version is 1.

ls-pl: <linked session


protection value
(optional)

LSDeletionDisabled (default) session in linked


session set cant be cleared (Protected)
LSDeletionEnabled: Session in linked session set
can be cleared by another session request defining
DeleteLS (Unprotected)

ls-execute: <linked
session execute
value>
(optional)

KeepLS (default)- will add extra session to Linkedsession set, not effecting those present
DeleteLS will clear all other unprotected sessions
in Linked-session set

SIP session establishment to GRS


SIP sessions to a GRS can be established on a permanent or ondemand basis;
Always initiated from VCS endpoint, but can be cleared from VCS
or GRS endpoints;
SIP session can be established to GRS Receiver only and to a
GRS Transmitter only (i.e. ATIS). Normally a Tx session implies a
Rx session (on same frequency) also established;
5 Transceivers implies 5 sessions established, while 5
Transmitters and Receivers implies 10 sessions established.
VCS with single SIP URI can establish 1 session with GRS,
implies VCS performs switching role connecting session to Users
that have Rx-only or Tx/Rx frequency key selected;
Single GRS can accept 7 SIP session establishments from 7 User
Agents (each with different SIP URIs);

Max no. of SIP Sessions- PTT


lockout/summation
ANSP defines maximum no. of Normal SIP sessions
That can be established using SIP Priority header
Normal,
An extra Normal session request is then rejected.
Slides shows an example of 7 sessions max

PTT-Lockout : Only audio from single VCS


transmitted
PTT-Summation: Audio from multiple VCSs
summed for transmission
GRS Transceiver/Transmitter
(configured for max of 7
SIP sessions)

Normal
PTT-ON

WAN
Normal
Session
PTT-id
=0001

VCS 1

PTT-id
=0002

VCS 2

Normal Session
request rejected
Normal
Session

Normal
Session

PTT-id
=0003

VCS 3

Normal
Session

PTT-id
=0004

VCS 4

Normal
Session

PTT-id
=0005

VCS 5

Normal
Session

Normal
Session

PTT-id
=0006

PTT-id
=0007

VCS 6

VCS 7

VCS 8

SIP Session pre-emption


A maximum of N SIP sessions can be established using
a mix of SIP Priority header Normal and SIP Priority
header Emergency.
The (N+1)th session request using SIP Priority Header
Normal is rejected.
An (N+1)th session request using SIP Priority Header
Emergency will pre-empt previous established
Normal session without PTT activated.
Algorithm for PTT pre-emption undefined
by ED-137B.
Possible for Radio to identify session
with least number of PTT activations
over pre-defined interval.

Normal
Session

VCS 1

GRS Transceiver/Transmitter
(configured for max of N
SIP sessions)

Normal
PTT-ON

WAN

PTT-id
=0001

Audio from VCS1

PTT-id
=0002

VCS 2

Normal
Session
Normal
Pre-empted Session

PTT-id
=0003

VCS 3

Normal
Session

PTT-id
=0004

VCS 4

Normal
Session

PTT-id
=0005

VCS 5

Normal
Session

Normal
Session

PTT-id
=0006

Emergency
Session causes
Pre-emption of
PTT-id=2

PTT-id
=0007

VCS 6

VCS 7

VCS 8

SIP session pre-emption (GRS Receiver)


A maximum of N SIP sessions can be established using
a mix of SIP Priority header Normal and SIP Priority
header Emergency.
An (N+1)th session request using SIP Priority Header Normal
is rejected.
An (N+1)th session request using SIP Priority Header
Emergency will pre-empt previous established
Normal session.
Algorithm for PTT Pre-emption
undefined by ED137B.
Radio Rx could also select session
with least number of PTT activations.

GRS Receiver
(configured for max of N
SIP sessions)

SQUON

WAN
Normal
Session

VCS 1

Incoming A/C call

VCS 2

SQU
ON
Normal
Session

Normal
Session

VCS 3

SQU
ON

SQU
ON
Normal
Session

VCS 4

SQU
ON

SQU
ON
Normal
Session

VCS 5

Example of
Emergency
Session request
causing 6th normal
Session to be
pre-empted

Normal
Session
Pre-empted

Normal
Session

VCS 6

VCS 7

VCS 8

Proposed GRS Address scheme

Proposed format of SIP URI for GRS TxRx, Tx and Rx:

sip:txrx.m/s.frequency.atsu@radio_site_id.local_domain
sip:tx.m/s.frequency.atsu@radio_site_id.local_domain
sip:rx.m/s.frequency.atsu@radio_site_id.local_domain
GRS Transceiver configured for En-route frequency of 125.075MHz at
Radio Site 10594 within DSNA domain has SIP URI:
sip:txrx.m.125.075.en_route@10594.dsna.fr
Separate GRS Rx & Tx configured for Tower frequency 133.050 MHz
at Radio Site 7345 within DFS domain have SIP URIs:
sip:rx.m.133.050.twr@7345.dfs.de
sip:tx.m.133.050.twr@7345.dfs.de
Main & Standby Radios on same frequency have different SIP
addresses defined by m/s bits.
Proposed format of SIP users at VCS endpoint:
sip:user_role@atsu.icao_centre_id.local_domain
Planner at en-route centre (ICAO code LECM) within the AENA
domain has SIP URI: sip:planner@en_route.lecm.aena.es

Real Time Session Supervision (R2S)


SIP cant monitor network link between endpoints;
After SIP session establishment its mandatory to establish
2-way R2S connection between endpoints; this provides endpoint
awareness about reachability of its peer endpoint;
2-way R2S connection between VCS and each TxRx/Tx/Rx
Exchange of R2S-Keepalive packets between endpoints every
200ms (default) when no audio;
R2S-Keepalive & RTP audio packets have same RTP header &
RTP HE and sent as one stream;
R2S-Keepalive packets distinguished by special Payload Type
(PT=123)
R2S-Keepalive packet sent immediately if RTP HE info changes;
RTP audio packets sent immediately if PTT or Squelch activated.

Step 2: Real Time Session Supervision


(R2S) establishment (VCS to GRS Tx/Rx)

VCS
endpoint

RTP Tx path

GRS
Transceiver
endpoint

WAN

RTP used to establish a Real Time Session Supervision.


No audio: RTP Keep-Alive packets with Header extension exchanged
Audio: RTP packets with Header extension to GRS when PTT ON
RTP packets with Header extension to VCS when Squelch ON
RTP Rx path
PTT-ON

RTP-Keepalive packets
(RTP Header+RTP HE but without
Audio)

R2S-KeepalivePeriod
(i.e. 200ms)

PTT-OFF
Audio packet
with PTT-OFF

RTP-Audio Packets
(RTP Header +HE +RTP payload
(i.e. 20ms voice sample)

RTP-Keepalive Packets
(RTP Header+ RTP HE but without
Audio)

R2S-KeepalivePeriod
(i.e. 200ms)

Step 2: Real Time Session Supervision


(R2S) - VCS to Tx & Rx endpoints
RTP used to establish a Real Time Session Supervision.
No audio: RTP Keep-Alive packets with Header extension exchanged
Audio: RTP packets with Header extension sent to VCS when Squelch ON

GRS Receiver
endpoint

RTP Tx path

VCS endpoint

RTP Rx path
RTP Tx path

WAN

RTP Rx path
RTP used to establish a Real Time Session Supervision.
No audio: RTP Keep-Alive packets with Header extension exchanged
Audio: RTP packets with Header extension sent to GRS when PTT ON

GRS Transmitter
endpoint

Real Time Session Supervision Operation


LOCAL HOLD
TIME =2S

RADIO
TRANSCEIVER

VCS
INVITE (F1)

LOCAL HOLD TIME =0.0s


=0.2s
LOCAL HOLD TIME =0.4s
=0.8s
=0.6s
=1.0s
=1.4s
LOCAL HOLD TIME =1.2s
LOCAL HOLD TIME =1.8s
=1.6s
=2s

100 Trying (F2)


200OK (F3)

SIP Session
Connected

Call is
automarically
answered

ACK (F4)

RTP KEEP-ALIVE-PACKETS exchanged every 200ms


Activate PTT Voice packets sent every 20ms
Activate Aircraft call Voice packets sent every 20ms

Voice

RTPTx
RTPTxHE
HE
PTT=Type ON

WAN
RTPRx
HE
RTPRx
RTPRxHE
HE
PTT
type=ON
SQU=ON

Voice
BYE (F5)
200 OK (F4)

LocalHoldTime
Expires Radio
closes session

LOCAL HOLD TIME (2s) =R2S KEEP-ALIVE PERIOD (200ms) x R2S-KEEP-ALIVE-MULTIPLIER (10)

RTP Header and RTP Header


extension structure
0

V=2 P

3
x
=
1

CC=0

31

16

PT=123 (keepalive)
PT=0,8,15 or 18 (audio)

Sequence Number

Timestamp=0000

Synchronization Source Identifier (SSRC)

RTP Header Extension

Contributing Source Identifier (CSRC) list


0

16

31

Type= 1 x 67h
0

PTT type

3
S
Q
U

PTT-id

Length
10 11 12 13
15 16
P P
S
T
T
C Reserved X
T
T
T
M S

20

TYPE

31

24

LENGTH

VALUE

RTP Header Extension principle


Ethernet/IP/UDP/RTP Packets

Ethernet/IP/UDP/RTP Packets

Ethernet/IP

Audio
31

LENGTH

VALUE

TYPE

Reserved

P
T
T
S

P
T
T
M

PTT-id

S
Q
U

PTT type

- PTT type (5 possible values) + PTT-id


- PTT Mute and PTT Summation
- Type, Length, Value- Additional features (i.e. Climax Time Delay -CTD)
- New types can be added in the future

Ethernet/IP/UDP/RTP Packets

Ethernet/IP/UDP/RTP Packets

Ethernet/IP

Audio
0
PTT type

31
S
Q
U

PTT-id

P
T
T
M

P
T
T
S

S
C
T

Res

TYPE

LENGTH

VALUE

- Squelch (Aircraft Call)


- PTT type (ACK) and PTT-id Ack
- Simultaneous Call Transmission detection
- PTT Mute and PTT summation
- Type, Length, Values Additional features (i.e. BSS type, Reception quality index)
- New types can be added in the future

PTT-type & PTT-id echo back


GRS Transceiver/
Transmitter/Receiver

For single SIP session with GRS transceiver/transmitter/receiver


endpoint, the same PTT-type value and PTT-id sent in
RTPTx HE SHALL be echoed back towards VCS endpoint
in RTPRx HE.
RTP packets with
RTPTx HE sends
PTT-type +PTT-id

PTT value

Description

0x00

PTT OFF

0x01

Normal PTT ON

0x02

Coupling PTT ON

0x03

Priority PTT ON

0x04

Emergency PTT ON

0x05

Reserved

0x06

Reserved

0x07

Reserved

VCS endpoint

WAN

RTP packets with


RTPRx HE echoes
back PTT-type +PTT-id
PT No.

PTT-id

SIP session

000000

Not Used

000001

1st

000010

2nd

000011

3rd

000100

4th

000101

5th

000110

6th

000111

7th

PTT-id assigned by Tx, Rx or TxRx only for


Radio-TxRx or Coupling sessions

PTT ON/OFF transmission timing


diagram

Two sessions- Normal/Normal PTTtypes with GRS Lockout


Only the first Audio stream
SHALL be transmitted

Audio from
VCS endpoint 1
transmitted
GRS Transceiver/
Transmitter configured for
PTT-lockout

Tx path sends
Normal PTT-ON
PTT-id=0002

Tx path sends
Normal PTT-ON
PTT-id=0001

WAN
Rx path
echoes back
Normal PTT-ON
PTT-id=0001
VCS endpoint 1
assigned
PTT-id=0001

Rx path
echoes back
Normal PTT-ON
PTT-id=0001
VCS endpoint 2
assigned
PTT-id=0002

Two sessions - Normal/Normal PTTtypes with GRS summation


The sum of both RTP audio streams
SHALL be transmitted.
Each user has its PTT-id echoed back,
Implying they are transmitting
PTT-sum=1 from GRS implies audio
being summed with other users

Sum of Audio from


VCS endpoint 1 &
VCS endpoint 2 transmitted
GRS Transceiver/
Transmitter configured for
PTT-Summation

Tx path sends
Normal PTT-ON
PTT-id=0002

Tx path sends
Normal PTT-ON
PTT-id=0001

WAN
VCS endpoint 1
assigned
PTT-id=0001

Rx path
echoes back
Normal PTT-ON
PTT-id=0001
PTT-Sum=1

Rx path
echoes back
Normal PTT-ON
PTT-id=0002
PTT-Sum=1

VCS endpoint 2
assigned
PTT-id=0002

Two sessions Normal/Priority PTT-types


Audio from VCS1 using Normal PTT-ON blocked
by GRS if Audio from VCS2 using Priority PTT-ON
arrives

Audio from
VCS endpoint 2
transmitted
GRS Transceiver/
Transmitter

Tx path sends
Priority PTT-ON
PTT-id=0002

Tx path sends
Normal PTT-ON
PTT-id=0001

WAN

Rx path
echoes back
Priority PTT-ON
PTT-id=0002
VCS endpoint 1
assigned
PTT-id=0001

Rx path
echoes back
Priority PTT-ON
PTT-id=0002
VCS endpoint 2
assigned
PTT-id=0002

3 sessions-Priority/Normal/Priority PTT
types with GRS summation
The sum of both RTP audio
streams with Priority-PTT SHALL
be transmitted.
If echoed back PTT-id=Sent PTT-id ,
this implies VCS transmitting.
PTT-sum=1 from GRS implies audio
Summing of multiple users.

Sum of Audio from


VCS endpoint 1 &
VCS endpoint 3 transmitted
GRS Transceiver/
Transmitter configured for
PTT-Summation

VCS2 has PTT locked-out

Tx path sends
Priority PTT-ON
PTT-id=0001

Tx path sends
Normal PTT-ON
PTT-id=0002
Rx path
echoes back
Priority PTT-ON
PTT-id=0001
PTT-Sum=1

VCS endpoint 1
assigned
PTT-id=0001

Rx path
Tx path sends
echoes back
Priority PTT-ON
Priority PTT-ON
PTT-id=0003
PTT-id=0001
PTT-Sum=1
Rx path
echoes back
WAN Priority PTT-ON
PTT-id=0003
PTT-Sum=1

VCS endpoint 2
assigned
PTT-id=0002

VCS endpoint 3
assigned
PTT-id=0003

Summation of multiple RTP audio


streams in the VCS,
Sum of Audio from
VCS endpoint 1 &
VCS endpoint 2 transmitted

If VCS1 sums audio from 2 PTT-ON events


send PTT-sum=1, Normal PTT-ON sent to GRS.
If VCS2 then sends Normal PTT-ON to
GRS (configured for PTT-lockout), it is
blocked. VCS1 & VCS2 have PTT-Sum=1
echoed back, Implying audio being summed
with other users
Tx path sends
Normal PTT-ON
PTT-id=0001
PTT-Sum=1

VCS
VCS endpoint 1
configured for
assigned
PTT-Summation
PTT-id=0001
PTT-ON

GRS Transceiver/
Transmitter configured for
PTT-Lockout

WAN
Rx path
echoes back
Normal PTT-ON
PTT-id=0001
PTT-Sum=1

PTT-ON

Tx path sends
Normal PTT-ON
PTT-id=0002
Rx path
echoes back
Normal PTT-ON
PTT-id=0001
PTT-Sum=1
VCS endpoint 2
assigned
PTT-id=0002

Aircraft Call ON/OFF reception


timing diagram

Incoming A/C call to GRS receiver


Incoming
Aircraft
Call
GRS Receiver
endpoint

No PTT-ON
signal

Rx path sends
SQUELCH-ON
PTT-OFF
PTT-id=0000

WAN

VCS endpoint 1

PTT-id

SIP session

000000

Not Assigned

000001

1st

000010

2nd

000011

3rd

000100

4th

SQU

Description

000101

5th

0x00

SQ OFF

000110

6th

0x01

SQ ON

000111

7th

PTT-id not assigned by GRS Receiver for


for Radio-Rxonly or Idle sessions

PTT-ON for Radio-TxRx session to


GRS receiver
Off-air transmission
from Transmitter

GRS Receiver
endpoint

Tx path sends
Normal PTT-ON
PTT-id=0001

VCS endpoint 1

Rx path sends
SQUELCH-ON
Normal PTT-ON
PTT-id=0001

WAN

PTT-id

SIP session

000000

Not Assigned

000001

1st

000010

2nd

000011

3rd

000100

4th

SQU

Description

000101

5th

0x00

SQ OFF

000110

6th

0x01

SQ ON

000111

7th

PTT-id assigned by GRS Receiver only


for Radio-TxRx or Coupling sessions

Incoming Cross-coupled frequency


re-transmission distinguished from A/C call
Incoming
Aircraft
Call on f1

Audio cross-coupled
at VCS endpoint 1
Is transmitted on f2

GRS Receiver
Frequency f1

Cross-coupled
Re-transmission
on f2

GRS Transmitter
Frequency f2

Rx path sends
Squelch-ON
PTT-id=0000
Rx path
echoes back
Coupling PTT-ON
PTT-id=000X

2 frequency
Cross-coupled
Group f1+f2
configured

WAN

GRS Receiver
Frequency f2

Rx path sends
Squelch-ON
Coupling PTT-ON
PTT-id=000Y,,,,,

Tx path sends
Coupling PTT-ON
PTT-id=000X

VCS endpoint 1

Tx path sends
Coupling PTT-ON
PTT-id=000Y

GRS Receiver detecting an A/C call


(squelch) & simultaneously receiving
ptt-type=Coupling PTT-ON and PTT-id
value in RTPTx HE from VCS endpoint,
will recognise that A/C call is a
result of a cross-coupled frequency
transmission.

A/C call detection by multiple GRS


Transceivers & Best Signal Selection

Aircraft Call with


Weak signal
strength detected

f1

f1

Aircraft Call with


Strong signal
strength detected
GRS Receiver/
Transceiver
2

GRS Receiver/
Transceiver
1

Tx path

Rx path sends
Squelch-ON
PTT-id=0000
Bss-qidx-ml
BSS-qidx

Rx path sends
Squelch-ON
PTT-id=0000
Bss-qidx-ml
BSS-qidx

Tx path

WAN
VCS endpoint 1

VCS reads BSS method + BSS quality


index in RTPRx HE on all Rx paths.
Selects Best signal in real time to be
forwarded to end-user
(i.e. GRS Transceiver 2)

Simultaneous Aircraft Call Transmission


detection by GRS Receiver
f1

f1
Simultaneous
Transmissions
from aircraft
detected
GRS Receiver

Tx path

WAN

VCS endpoint 1

Rx path sends
SQUELCH ON
PTT-id=0000
SCT=1

RTPRx HE SCT bit remains set while simultaneous


Transmissions on same frequency detected.
SCT Event Warning provided to controller

Stepped on transmissions- A/C


call + Normal PTT activation
f1
Audio from
VCS endpoint 1
Transmitted on f1

Incoming Aircraft
Call on f1

GRS Receiver
Frequency f1

Tx path sends
Normal PTT-ON
PTT-id=000Y

GRS Transmitter
Frequency f1

Rx path sends
Squelch-ON
Rx path echoes back
SCT=1
Normal PTT-ON
Echoes back
PTT-id=000X
Normal PTT-ON
PTT-id=000Y

When GRS Receiver receives Normal


PTT-ON +PTT-id of Tx session
while detecting A/C call and sending
SQUELCH ON indication, implies that
a Stepped-on transmission has occurred.
It shall set SCT bit to 1.

WAN
VCS endpoint 1

Tx path sends
Normal PTT-ON
PTT-id=000X

When VCS receives SQUELCH ON and


SCT=1 from GRS Receiver, while
sending Normal PTT-ON indication to
GRS Receiver, due to Transmission
at GRS Transmitter implies that a
Stepped-on transmission has occurred

Off-air Squelch detection with separated


GRS Transmitter and Receiver
Transmission detected
by GRS Receiver (appears as
Incoming Aircraft call)

Off-air Squelch
detected
GRS Receiver

Tx path sends
Normal PTT-ON
PTT-id=000Y

GRS Transmitter

Rx path sends
Squelch-ON
SCT=0
+ echoed back
Normal PTT-ON
& PTT-id=000Y

GRS Receiver detecting an aircraft call


(squelch) and simultaneously receiving
ptt-type and PTT-id values in RTPTx HE
from VCS endpoint, will recognise that
squelch signal is a result of off-air squelch
and set SCT bit to 0.

Audio from
VCS endpoint 1
transmitted

Rx path echoes back


Normal PTT-ON
PTT-id=000X

WAN
VCS endpoint 1

Tx path sends
Normal PTT-ON
PTT-id=000X

One Way Audio Delay Estimation


TdTx=Tv1+Tp1+Tn1+Tj1+Td1+Ts1

VCS System Delay Tv1

Audio Delay Mic to Antenna TdTx

VCS
CWP

VoIP Network
Interface(s)

System Delay Ts1

T1

T2

GRS
Tn1

Tp1
Packing

Mic

Tj1

Td1

Jitter
Buffer

Delay
Line
Digital
System

Response
Jitter
Buffer

Packing
Tn2

Tj2
T4

TdTx:Audio delay Mic to Antenna


Tv1:VCS System Delay (constant)
Tp1:Packetizing Delay (constant)
Tn1:Network delay for Transmission (unknown)
Tj1:Jitter Buffer Delay at GRS1 (Variable)
Td1:Time to compensate delay
differences between different GRSs
Ts1:System Delay within GRS (constant)
Tid=Td1+Ts1
Tsd=Time difference between receiving RMM
and transmitting MAM (T2-T3)

Analog
System

Tp2
T3

If VCS and GRS have NTP Absolute Time


available then Tn1: T2-T1
TdTx=Tv1+Tp1+T2-T1+Tj1+Td1+Ts1
Otherwise Round Trip Time calculated:
Tsd=T3-T2
Assume that Tn1=Tn2 then
Tn1=(T4-T1-Tsd)/2
TdTx=Tv1+Tp1+Tn1+Tj1+Tid

Request for Measurement and


Measurement Answer Messages
GRS TxRx 2
Freq: f1

GRS TxRx 1
Freq: f1

T2

T3

GRS TxRx3
Freq: f1

MAM Message:
TQG: Time Quality GRS
T1: Pkt sent time
T2: Pkt Rec time
Tsd: T3-T2
Tj1, Tid

T2

RMM Message:
TQV: Time Quality
VCS+ Packet sent
time T1 in
125us ticks

T3

MAM Message:
TQG: Time Quality GRS
T1: Pkt sent time
T2: Pkt Rec time
Tsd: T3-T2
Tj1, Tid
RMM Message:
TQV: Time Quality
VCS+ Packet sent
time T1 in
125us ticks

T2

T3

MAM Message:
TQG: Time Quality GRS
T1: Pkt sent time
T2: Pkt Rec time
Tsd: T3-T2
Tj1, Tid

WAN
RMM Message:
TQV: Time Quality VCS
+ Packet sent time T1
in 125us ticks

T4 T1

T4

T1

T1
T4

VCS endpoint 1

VCS sends RMM message to each


Transmitter. On receiving all MAM
Messages VCS can calculates CLD
value to be applied towards each
transmitter (or additional relative
delay to be added at VCS endpoint)
in order to avoid ground
segment delay differences

VOTE SG2 solution for Dynamic Delay


Compensation for Climax

Ground segment delay for VoIP network is variable and cant be


compensated for by a fixed delay (as with analogue lines or TDM network);
VCS periodically sends Audio or Keep-alive packets with new RTPTx HE
Type 4-Request for Measurement Message (RMM) to all GRS Tx in
Climax group defining Packet Transmit Time T1 at VCS endpoint;
Each GRS Transmitter replies with Audio or Keep-alive packets with RTPRx
HE Type 4- Measurement Answer Message (MAM) containing Packet
Transmit Time T1, Packet Receive Time T2, Packet Processing time Tsd
(T3-T2), Jitter Buffer Delay Tj1, Sum of Delay line+System Delay Tid etc;
For Absolute Delay: VCS calculates 1-way network delay Tn1: difference
in NTP timestamps expressed as 125us ticks between GRS endpoint
receiving RMM (T2) and VCS endpoint sending RMM (T1) (i.e. Tn1=T2-T1);
VCS calculates Absolute Mic to Antenna delay: TdTx=Tv1+Tp1+T2T1+Tj1+Tid & compensates audio delay within CLIMAX group.
For Round Trip Time (RTT) Tn1: difference in 125us ticks between VCS
endpoint sending RMM and receiving MAM) (Tn1=T4-T1-(T3-T2))/2;
VCS estimates Mic to Antenna delay: TdTx=Tv1+Tp1+Tn1+Tj1+Tid &
compensates audio delay within CLIMAX group.

Climax Time DelayCompensation mechanism


Audio from
VCS endpoint 1
Transmitted on f1
GRS TxRx 1
Freq: f1

Tx path sends
Normal PTT-ON
PTT-id=000X
CLD value 0 (ms)

Audio from
VCS endpoint 1
Transmitted on f1

Audio from
VCS endpoint 1
Transmitted on f1

GRS TxRx 2
Freq: f1

GRS TxRx3
Freq: f1

Tx path sends
Normal PTT-ON
PTT-id=000Y
CLD value 10 (ms)
Rx path sends
Timestamp info
Echoes Normal
PTT-ON
PTT-id=000X

VCS uses measured Absolute time


(1-way) or estimate Round-Trip Time/2)
methods to calculate Mic to Antenna
Delay. VCS sends appropriate CLD values
to each transmitter to compensate for
propagation delay.

Tx path sends
Normal PTT-ON
PTT-id=000Z
CLD value 15 (ms)

WAN
Rx path sends
Timestamp info
Echoes Normal
PTT-ON,
PTT-id=000Y

VCS endpoint 1

Rx path sends
Timestamp info
Echoes Normal
PTT-ON
PTT-id=000Z

WG67 KEY-IN EVENT PACKAGE


WG67-KEY-IN Event package: informs subscribed User agents
about bindings existing between User agents at VCS endpoints
that have SIP sessions established with a GRS.
SUBSCRIBE (RFC3265): sent by User containing event header
WG67 KEY-IN;
NOTIFY (RFC3265): sent by GRS containing event header
WG67 KEY-IN plus PTT-id (assigned for Radio-TxRx or coupling
sessions only), SIP URI, Call-type (optional) for every URI with
session established.
<ptt-id-1, decimal value>, <sip-from-uri-1, sipuri format>, <call type>crlf

Example:
1,sip:user_a@domain,coupling
2,sip:user_b@domain,Radio-TxRx
sip.user_c@domain,Radio-Rxonly
sip.user_c@domain,Radio-Idle

PTT Mute- Signalling PTT-ON at


inactive transmitters
GRS Transmitter1
Frequency f1

Normal PTT-ON
PTT-id=0001
PTT Mute=0
Priority PTT-ON
PTT-id=0002
PTT Mute=1

1st: Normal PTT Transmission by VCS1


at Transmitter1 blocks Transmitter2
2nd: Priority PTT Transmission by VCS2
on Transmitter2 will interrupt transmission
at Transmitter1 .

Normal PTT-ON
PTT-id=0001
PTT Mute=0
Priority PTT-ON
PTT-id=0002
PTT Mute=1

GRS Transmitter2
Frequency f1

Normal PTT-ON
PTT-id=0001
PTT Mute=1

Normal PTT-ON
PTT-id=0001
PTT Mute=1
Priority PTT-ON
Normal PTT-ON
PTT-id=0002
Normal PTT-ON
No Audio
PTT Mute=0
WAN
Priority PTT-ON
+ Audio
PTT-id=0001
+ Audio
PTT-id=0001
PTT Mute=1
Priority PTT-ON
PTT-id=0002
PTT Mute=0
+ Audio
PTT Mute=0
Priority PTT-ON
PTT-id=0002
PTT-id=0002
PTT Mute=1
VCS endpoint 1
PTT Mute=0
VCS endpoint 2

Uses
Normal
PTT level

can transmit
at GRS Tx1 only

can transmit
at GRS Tx2 only

Uses
Priority
PTT level

What is Linked Session Management?

GRS links sessions with same USERNAME part of SIP FROM address &
containing Linked Session Protection SDP attribute (ls-pl) into a set.
Provides solution for switchover of sessions between GRS to Main/Standby VCSs
(M/S VCSs having same SIP FROM address Usernames, but different domain
names).
GRS has capability to manage from 4 to max sessions in Linked Session up to
GRS. Session requests exceeding limit are rejected.
Only 1 RTP stream from Linked-Session forwarded by GRS to Antenna.
Also allows redundant sessions between VCS & GRS to improve link reliability.
Unprotected session- ls-pl:LSDeletionEnabled Session can be removed from
Linked session set in case of pre-emption.
Protected Session- ls-pl:LSDeletionDisabled- Session cant be removed from
Link session set in case of pre-emption.
Linked session execution- ls-execute:KeepLS-all other sessions in linkedsession set are kept (Sent by VCS on session establishment).
Linked session execution- ls-execute:DeleteLS-all other sessions in linkedsession set are deleted (Sent by VCS in Re-INVITE when RTP stream corrupt).

Linked-Session ManagementMain/Standby Switchover


VCS1-Main
Linked Session

INVITE
VCS1
Main

From UserA@VCS1-main
Type: Radio-TxRx
ls-pl: LSDeletionEnabled
ls-execute: KeepLS

GRS
TxRx1
Main

VCS1-Standby
Radio-Idle session from VCS1 Standby
established with protection (i.e. ls-pl:
LSDeletionDisabled) and any other sessions
in Linked-Session remain (i.e. ls-execute:
KeepLS).

INVITE
VCS1
Standby

Radio-TxRx session from VCS1 Main


established without protection (i.e. ls-pl:
LSDeletionEnabled) and any other sessions
in Linked-Session remain (i.e. ls-execute:
KeepLS).

From UserA@VCS1-standby)
Type: Radio-Idle
ls-pl: LSDeletionDisabled
ls-execute: KeepLS
Linked Session

VCS1
Main

INVITE
From UserA@VCS1-main
Type: Radio-TxRx
ls-pl: LSDeletionEnabled
ls-execute: KeepLS
Re-INVITE

VCS1
Standby

SIP: From UserA@VCS1-standby)


Type: Radio-TxRx
ls-pl: LSDeletionEnabled
ls-execute: DeleteLS

GRS
TxRx1
Main

Switchover

On VCS1 Main failure, switchover to


Standby VCS occurs by VCS1 Standby
sending Re-INVITE with Radio-TxRx,
ls-pl:
LSDeletionEnabled
(Session
becomes unprotected)
and ls-execute:
DeletedLS), causing all other unprotected
sessions in Linked-Session to be
disconnected.

Linked and Non-linked sessions


All sessions in Link session have
same Username in SIP FROM URI
and send SDP ls-pl attribute,

VCS1

Main
GRS1

Non-linked sessions dont include SDP


ls-pl attribute.

VCS2

Standby
GRS1

VCS can establish redundant protected session (Radio-Idle, RadioRxonly or Radio-TxRx access mode) with
Radios as reserve.
Redundant RTP audio is then ready for use should main session have
corrupt RTP audio stream.
PTT hierarchy applies within Linked sessions and between Linked and
Non-linked sessions.
Linked sessions can contain any combination of sessions with any Radio
Access mode (I,e, Radio-Idle, Radio-Rxonly, Radio-TxRx, Coupling);

Backup Cross Coupling Solution


Linked Session
Coupling session

VCS1
Main

GRS
F1

Standby VCS often has to have same


cross coupling group as in the main
VCS, such that changeover is faster.
Coupling session from Main VCS and
Idle session from Standby VCS are
placed in Linked Session at each GRS.

VCS1
Standby
or
VCS2

GRS
F2
Idle Session

Coupling session

VCS1
Main

VCS1
Standby
or
VCS2

A idle session with protection reserves


resources at the GRS, protecting it
from pre-emption and uses minimal
bandwidth.

Linked Session
Linked Session

GRS
F1

GRS
F2
Coupling session

Linked Session

In case of Main VCS failure, the


Standby VCS performs Re-invite to
establish a Coupling Session with
GRS(s) and could delete Main coupling
session. Main sessions could then be
re-established as idle sessions
Multiple coupling sessions to single
GRS are allowed within a linked
session. One Linked session with call
type coupling can exist at GRS.

Prevention of Cross-coupling chains between


VCSs

GRS-A

FAB-1
Sector 1

GRS-B

GRS1

VCS1

GRS-C

Coupling

Re-INVITE Radio

VCS2

FAB-1
Sector 2

GRS-E
GRS-F

GRS-D

Radio Remote Control (RRC)


GRS-VHF

RRC

VCS

MTxF1

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

Added benefits Radio (1)


1. Multi-supplier VCS-GRS Interoperability using Common
Radio interfaces (ED-137B Volume 1).
2. Test Tools available to validate interfaces (VOTER 2.0.0)
3. COTS Test Equip (i.e.Wireshark, WAN emulators, ITG etc)
4. VoIP radios now addressable,- can accept sessions from
any authenticated VCS in network.
5. Through keep-alive signals, connection between VCS and
radio is monitored constantly.
6. Allows multiple sessions to be handled which will be
beneficial in Dynamic Resectorization situation if a sector
passes from one VCS to another.
7. Provides PTT and control signal acknowledgement from
TxRx, Tx and Rx.
8. Allows both Off-Air side tone or Local-side tone to be used
back to controller earpiece.

Added benefits Radio (2)


9. Signal strength measured at Radio directly, while Rx voting
implemented at VCS side.
10. Climax time delay compensation calculated at VCS but
delayed either at VCS or GRS side.
11. Can inform subscribed users about who has sessions
established to it.
12. Can be enabled to send audio streams + Call Record Data
to a Voice Recorder.
13. Can be used to detect Stepped-on transmissions and
indicate this to the VCS.
14. Offers Linked-session management solutions for
Main/Standby Radio switchover and idle redundant
sessions taking over from main session
15. Prevent Cross-coupling chains from occurring.