Railway Telecommunications (RT); Global System for Mobile communications (GSM); Usage of Session Initiation Protocol (SIP) on the Network Switching Subsystem (NSS) to Fixed Terminal Subsystem (FTS) interface for GSM Operation on Railways

DTS/RT-00009

General Information

Status
Published
Publication Date
25-Sep-2011
Current Stage
12 - Completion
Due Date
05-Oct-2011
Completion Date
26-Sep-2011
Ref Project
Standard
ts_103389v010101p - Railway Telecommunications (RT); Global System for Mobile communications (GSM); Usage of Session Initiation Protocol (SIP) on the Network Switching Subsystem (NSS) to Fixed Terminal Subsystem (FTS) interface for GSM Operation on Railways
English language
47 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)


Technical Specification
Railway Telecommunications (RT);
Global System for Mobile communications (GSM);
Usage of Session Initiation Protocol (SIP) on the
Network Switching Subsystem (NSS) to Fixed Terminal
Subsystem (FTS) interface for GSM Operation on Railways

2 ETSI TS 103 389 V1.1.1 (2011-09)

Reference
DTS/RT-00009
Keywords
FTS, GSM-R, NSS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2011.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 103 389 V1.1.1 (2011-09)
Contents
Intellectual Property Rights . 5
Foreword . 5
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 9
4 Reference System Architecture . 10
5 Interface Functionality . 11
5.1 Basic Call . 11
5.1.1 Progress Indication . 11
5.1.2 Early Media . 12
5.2 Connected Parties Identity Information . 12
5.3 Call Hold . 12
5.4 Multi Level Precedence and Pre-emption . 12
5.5 Voice Group Call and Broadcast Call Control . 12
5.6 User-User-Information-Element Transport . 12
5.7 Reason Transport . 13
6 Signalling Interface . 13
6.1 Network Layer Protocol . 13
6.2 Transport Layer Protocol . 13
6.3 Signalling Protocol . 13
6.3.1 SIP Entities . 13
6.3.1.1 SIP User Agent . 14
6.3.1.2 SIP Proxy . 14
6.3.2 SIP Request Methods . 14
6.3.3 SIP Responses . 15
6.3.4 SIP Header Fields . 15
6.3.5 SIP Bodies . 17
6.3.6 SIP URI Convention . 18
6.3.6.1 Display Name . 19
6.3.6.2 User Part . 19
6.3.6.3 Host Part . 19
6.3.6.4 URI Parameters . 19
6.3.6.5 Use . 19
6.3.6.6 Examples . 20
6.3.7 Option Tags . 21
6.4 Interface Functionality to Signalling Interface Mapping . 21
6.4.1 Basic Call . 21
6.4.2 Connected Parties Identity Information . 23
6.4.3 Media Session Renegotiation and Call Hold . 25
6.4.4 Early Media . 27
6.4.5 Multi Level Precedence and Pre-emption . 29
6.4.5.1 Resource Priority . 30
6.4.5.2 Reason Indication for Precedence and Pre-emption Events . 30
6.4.5.3 Signalling Procedure for Precedence Call Blocking . 30
6.4.5.4 Signalling Procedure for Pre-emption . 31
6.4.6 Group Call and Broadcast Call Control . 32
6.4.7 User-to-User-Information-Element Transport . 32
ETSI
4 ETSI TS 103 389 V1.1.1 (2011-09)
6.4.8 Release Cause Transport . 33
6.4.9 SIP Session Timer . 33
6.4.10 OPTIONS Processing . 35
6.4.10.1 OPTIONS Heartbeating . 36
7 Media Interface . 36
7.1 Network Layer Protocol . 36
7.2 Transport Layer Protocol . 36
7.3 Real-Time Transport Protocol . 37
7.4 Media Codecs . 37
7.4.1 DTMF . 37
7.4.1.1 Limitations to RFC 4733 . 38
Annex A (normative): Locating SIP Entities . 39
Annex B (informative): Quality of Service Framework . 42
Annex C (informative): Security Framework . 43
Annex D (informative): Mapping of EIRENE to Interface Features . 44
Annex E (informative): Bibliography . 46
History . 47

ETSI
5 ETSI TS 103 389 V1.1.1 (2011-09)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Railway
Telecommunications (RT).
Introduction
While a number of interoperability specifications for various interfaces at various layers of GSM-R systems exist, the
interface between the Network Switching Subsystem (NSS) and the Fixed Terminal Subsystem (FTS) has not yet been
addressed by any interoperability specification activity.
In most of the GSM-R system deployments available at the time of the creation of the present document, the Network
Switching Subsystem and the Fixed Terminal Subsystem are interconnected using TDM based interfaces such as
DSS1 [i.2].
TS 102 610 [9] specifies the usage and format of UUIE for call-related end-to-end functionality in GSM-R systems but
no other interworking topics.
The present document addresses the interoperability specification gap between the Network Switching Subsystem and
the Fixed Terminal Subsystem with an interface based on the Internet Protocol (IP) [2], the Session Initiation Protocol
(SIP) [3], the Session Description Protocol (SDP) [6] and the Real-Time Transport Protocol (RTP) [7].
In addition to the table of contents, the following explanation will help you navigate through and understand the
contents of the present document:
• Clauses 1 to 3 are predefined by ETSI.
• Clause 4 shows and explains the reference system architecture and identifies the interface(s) for the present
document.
• Clause 5 holds the functional requirements for the interface subject to the present document.
• Clause 6 specifies in detail the signalling interface for all supported functions and services.
• Clause 7 specifies in detail the media interface.
• Annex A explains the mechanism to locate SIP entities at the present interface.
• Annex B contains recommendations on the use and implementation of standardized Quality of Service
mechanisms at the present interface.
• Annex C contains recommendations about the security mechanisms.
• Annex D contains a mapping table of EIRENE [1] to interface features.
ETSI
6 ETSI TS 103 389 V1.1.1 (2011-09)
1 Scope
The present document defines the signalling and media interface between the Network Switching Subsystem and the
Fixed Terminal Subsystem in order to provide a clear set of services needed for GSM-R operations. This includes voice
call service and available call-related supplementary services. The present document addresses the Internet Layer and
upwards of the Internet Protocol Suite [i.18] on the signalling and media interface.
Any service other than voice call service and call-related supplementary services (such as data services, Short Message
Service, etc.) is out of scope of the present document; additional features may be addressed in future releases.
The present document does not specify any other interface between the Network Switching Subsystem and the Fixed
Terminal Subsystem nor does it cover any internal interfaces of either NSS or FTS. Voice recording and related
interfaces are out of scope of the present document. Such interfaces may be addressed in a future release of the present
document.
The present document does not address any specific 3GPP Release or Architecture.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
[1] UIC P001D010 (Version 15.1): "UIC Project EIRENE System Requirements Specification".
NOTE: Available at http://www.uic.org/IMG/pdf/p0011d010-15.1.pdf.
[2] IETF RFC 791 (1981): "Internet Protocol".
[3] IETF RFC 3261 (2002): "SIP: Session Initiation Protocol".
[4] IETF RFC 3264 (2002): "An Offer/Answer Model Session Description Protocol (SDP)".
[5] IETF RFC 4733 (2006): "RTP Payload for DTMF Digits, Telephony Tones, and Telephony
Signals".
[6] IETF RFC 4566 (2006): "SDP: Session Description Protocol".
[7] IETF RFC 3550 (2003): "RTP: A Transport Protocol for Real-Time Applications".
[8] IETF RFC 3326 (2002): "The Reason Header Field for the Session Initiation Protocol (SIP)".
[9] ETSI TS 102 610 (V1.1.0): "Railways Telecommunications (RT); Global System for Mobile
communications (GSM); Usage of the User to User Information Element for GSM Operation on
Railways".
[10] IETF RFC 5234 (2008): "Augmented BNF for Syntax Specifications: ABNF".
[11] IETF RFC 3262 (2002): "Reliability of Provisional Responses in the Session Initiation Protocol
(SIP)".
ETSI
7 ETSI TS 103 389 V1.1.1 (2011-09)
[12] IETF RFC 4412 (2006): "Communications Resource Priority for the Session Initiation Protocol
(SIP)".
[13] IETF RFC 3325 (2002): "Private Extensions to the Session Initiation Protocol (SIP) for Asserted
Identity within Trusted Networks".
[14] IETF RFC 5876 (2010): "Updates to Asserted Identity in the Session Initiation Protocol (SIP)".
[15] IETF RFC 3323 (2002): "A Privacy Mechanism for the Session Initiation Protocol (SIP)".
[16] IETF RFC 4028 (2005): "Session Timers in the Session Initiation Protocol (SIP)".
[17] IETF RFC 3311 (2002): "The Session Initiation Protocol (SIP) UPDATE Method".
[18] IETF RFC 2474 (1998): "Definitions of the Differentiated Services Field (DS Field) in the IPv4
and IPv6 Headers".
[19] IETF RFC 2475 (1998): "An Architecture for Differentiated Services".
[20] IETF RFC 4594 (2006): "Configuration Guidelines for DiffServ Service Classes".
[21] IETF RFC 5865 (2010): "A Differentiated Services Code Point (DSCP) for Capacity-Admitted
Traffic".
[22] ITU-T Recommendation Q.850 (1998): "Usage of cause and location in the Digital Subscriber
Signalling System No. 1 and the Signalling System No. 7 ISDN user part".
[23] ITU-T Recommendation E.164 (2010): "The international public telecommunication numbering
plan".
[24] ITU-T Recommendation Q.955.3 (1993): "Stage 3 description for community of interest
supplementary services using DSS 1 : Multi-level precedence and preemption (MLPP)".
[25] IETF RFC 3986 (2005): "Uniform Resource Identifier (URI): Generic Syntax".
[26] IETF RFC 768 (1980): "User Datagram Protocol".
[27] ITU-T Recommendation G.711 (1998): "Pulse code modulation (PCM) of voice frequencies".
[28] IETF RFC 2833 (2000): "RTP Payload for DTMF Digits, Telephony Tones and Telephony
Signals".
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] IETF draft RFC draft-johnston-cuss-sip-uui-01: "A Mechanism for Transporting User to User Call
Control Information in SIP".
[i.2] ETSI ETS 300 403-1 (V1.3.2): "Integrated Services Digital Network (ISDN); Digital Subscriber
Signalling System No. one (DSS1) protocol; Signalling network layer for circuit-mode basic call
control; Part 1: Protocol specification [ITU-T Recommendation Q.931 (1993), modified]".
[i.3] IETF RFC 6086 (2011): "Session Initiation Protocol (SIP) INFO Method and Package
Framework".
[i.4] IETF RFC 3428 (2002): "Session Initiation Protocol (SIP) Extension for Instant Messaging".
[i.5] IETF RFC 3515 (2001): "The Session Initiation Protocol (SIP) Refer Method".
[i.6] IETF RFC 3265 (2002): "Session Initiation Protocol (SIP)-Specific Event Notification".
[i.7] IETF RFC 3903 (2004): "Session Initiation Protocol (SIP) Extension for Event State Publication".
ETSI
8 ETSI TS 103 389 V1.1.1 (2011-09)
[i.8] IETF RFC 1594 (1994): "FYI on Questions and Answers to Commonly asked "New Internet User"
Questions".
[i.9] IETF RFC 3665 (2003): "Session Initiation Protocol (SIP) Basic Call Flow Examples".
[i.10] IETF RFC 3960 (2004): "Early Media and Ringing Tone Generation in the Session Initiation
Protocol (SIP)".
[i.11] ETSI EN 300 925 (V7.0.2): "Digital cellular telecommunications system (Phase 2+) (GSM);
Voice Group Call Service (VGCS) - Stage 1 (GSM 02.68 version 7.0.2 Release 1998)".
[i.12] ETSI EN 300 926 (V8.0.1): "Digital cellular telecommunications system (Phase 2+) (GSM);
Voice Broadcast Service (VBS) - Stage 1 (GSM 02.69 version 8.0.1 Release 1999)".
[i.13] IETF RFC 3263 (2002): "Session Initiation Protocol (SIP): Locating SIP Servers".
[i.14] IETF RFC 1035 (1987): "Domain names - implementation and specification".
[i.15] IETF RFC 2181 (1997): "Clarifications to the DNS Specification".
[i.16] IETF RFC 2663 (1999): "IP Network Address Translator (NAT) Terminology and
Considerations".
[i.17] ITU-T Recommendation I.255.3 (1990): "Multi-Level Precedence and Pre-emption service".
[i.18] IETF RFC 1122 (1989): "Requirements for Internet Hosts -- Communication Layers".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
Network Switching Subsystem (NSS): part of the PLMN infrastructure that performs all necessary functions in order
to handle the call services to and from the mobile stations as well as to and from fixed terminals
Fixed Terminal Subsystem (FTS): part of the EIRENE [1] system that provides access to this network (and services)
via controller equipment (in general referred to as Fixed Terminals)
Signalling Endpoint, SIP Endpoint: entity that acts as a SIP User Agent
NOTE: Within the scope of the present document this term refers to NSS and FTS.
Media Endpoint, RTP Endpoint: entity that terminates RTP stream(s) under the control of a single SIP Endpoint in
the same subsystem
NOTE: This entity may be physically separated from the SIP Endpoint.
Signalling Proxy, SIP Proxy: Proxy Server as defined by RFC 3261 [3]
call: refers to a SIP Dialog (RFC 3261 [3]) between two Signalling Endpoints, established for the purpose of a voice
communication and related data exchange
operational priority: as defined in EIRENE SRS [1] different call types have call priorities during railway
communications. This behaviour is mentioned as operational priority of a call
For the purposes of the present document, the following terms and definitions given in RFC 1594 [i.8] apply:
Fully-Qualified Domain Name
ETSI
9 ETSI TS 103 389 V1.1.1 (2011-09)
For the purposes of the present document, the following terms and definitions given in RFC 3261 [3] apply:
Client
Dialog
Final response
Header
Header field
Initiator, Calling Party, Caller
Invitee, Invited User, Called Party, Callee
Method
Option-tag
Provisional response
Proxy, proxy server
Request
Response
Server
Session
(SIP) transaction
Tag
User Agent Client
User Agent Server
User Agent
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AF Assured Forwarding
AoCC Advice of Charge (Charging)
AoCI Advice of Charge (Information)
B2BUA Back to Back User Agent
BAIC Barring of All Incoming Calls
BAOC Barring of All Outgoing Calls
BIC-Roam Barring of Incoming Calls when Roaming Outside the Home PLMN Country
BOIC Barring of Outgoing International Calls
BOIC-exHC BOIC except those to Home PLMN Country
CCBS Completion of Calls to Busy Subscribers
CFB Call Forwarding on Mobile Subscriber Busy
CFNRc Call forwarding on Mobile Subscriber Not Reachable
CFNRy Call Forwarding on No Reply
CFU Call Forwarding Unconditional
CLIP Calling Line Identification Presentation
CLIR Calling Line Identification Restriction
CoLP Connected Line Identification Presentation
CoLR Connected Line Identification Restriction
CUG Closed User Group
CW Call waiting
DNS Domain Name Service
DSCP Differentiated Service Code Point
DTMF Dual Tone Multi Frequency
ECT Explicit Call Transfer
EF Expedited Forwarding
EIRENE European Integrated Railway Radio Enhanced Network
eMLPP enhanced Multi-Level Precedence and Pre-emption
FQDN Fully Qualified Domain Name
FTS Fixed Terminal Subsystem
GSM-R Global System Mobile-Railways
HOLD Call hold
IP Internet Protocol
MLPP Multi-Level Precedence and Pre-emption
MO/PP Mobile Originated/Point-to-Point
ETSI
10 ETSI TS 103 389 V1.1.1 (2011-09)
MPTY Multi Party Service
MT/PP Mobile Terminated/Point-to-Point
NAPT Network Address Port Translation
NAT Network Address Translation
NSS Network Switching Subsystem
PABX Private Access Branch eXchange
PHB Per Hop Behaviour
PLMN Public Land Mobile Network
PRACK Provisional Response Acknowledgement
PSTN Public Switched Telephone Network
QoS Quality of Service
RFC Request For Comments
RTP Real-Time Transport Protocol
SDP Session Description Protocol
SIP Session Initiation Protocol
SRTP Secured Real-time Protocol
TDM Time Division Multiplexing
ToS Type of Service
UA User Agent
UAC User Agent Client
UAS User Agent Server
UDP User Datagram Protocol
UIC Union Internationale des Chemins de Fer, International Union of Railways
URI Uniform Resource Identifier
USSD Unstructured Supplementary Service Data
UUIE User to User Information Element
UUS1 User-to-User Signalling 1
VBS Voice Broadcast Service
VGCS Voice Group Call Service
4 Reference System Architecture
The system architecture used to identify the interface that is the subject of the present document is a simplification of a
GSM-R system down to a minimum of logical entities relevant to the present document.
Within the context of the present document a GSM-R system is logically divided into a GSM-R Network and a Fixed
Terminal Subsystem. The interface between the Mobile Terminals and the NSS as well as the interface between the
Fixed Terminals and the FTS are explicitly not addressed in the present document. The focus of the present document is
solely:
• the Signalling Interface; and
• the Media Interface;
between the logical subsystem NSS and the logical subsystem FTS.
It is important to note that this architecture does not necessarily reflect any physical entities in a GSM-R system.
Figure 4.1 illustrates the reference system architecture.
ETSI
11 ETSI TS 103 389 V1.1.1 (2011-09)

Figure 4.1: Reference System Architecture
Depending on the deployment scenario and the NSS/FTS design there may be one or more Signalling Endpoints, one or
more Media Endpoints and zero or more Signalling Proxies on either side of the interface.
The Media Endpoint(s) are controlled by (a) Signalling Endpoint(s) in the same subsystem. This control mechanism is
out of scope of the present document.
One Signalling Endpoint may establish more than one call. Also one Signalling Proxy and one Media Endpoint may be
involved in one or more calls.
The maximum number of Signalling Endpoints allowed to be involved in a single call on the present interface is
two-one on each side.
Optionally deployed Signalling Proxies may be involved in the signalling flow for either incoming traffic or outgoing
traffic or both incoming and outgoing traffic at either side of the interface. This depends on the FTS/NSS design and the
deployment scenario. The entities involved might differ depending on the call direction, but have to be the same for all
calls in the same direction in a single deployment scenario.
Annex A includes several deployment scenario examples that illustrate some of the Signalling Proxy deployment
options.
5 Interface Functionality
This clause specifies functional requirements of the interface. The technical details are specified in clauses 6 and 7 of
the present document.
5.1 Basic Call
The primary function to be delivered by the present interface is the means to initiate and tear down full duplex audio
(voice) connections between the NSS and FTS with a single, logical, SIP Endpoint involved per connection on each
side of the present interface that controls the connection as well as its respective Media Endpoint (compare clause 4).
Such a connection can be initialized by either NSS or FTS. The initiation phase shall specifically provide means and
mechanisms for per call/connection capability exchange, media negotiation, progress indication as well as error
indication and handling.
5.1.1 Progress Indication
Progress indication shall be provided via explicit signalling. In addition a progress tone generation policy, clearly
stating which party shall generate which progress tones and when, is defined.
ETSI
12 ETSI TS 103 389 V1.1.1 (2011-09)
5.1.2 Early Media
Furthermore, the basic call procedure shall provide a means for media (i.e. audio) exchange prior to call setup
completion. This shall be possible in the direction callee to caller only. This functionality is needed in order to provide
pre-call announcements to the user before the dialog is established.
5.2 Connected Parties Identity Information
The calling party shall provide its identity information with the connection request.
The calling party shall be informed about the identity of the remote party.
The identity information shall contain a routable number in the underlying network's address space and in addition - if
available - an EIRENE functional number.
Upon change of identity of either connected party an immediate identity update shall be transmitted to the other side.
5.3 Call Hold
Both endpoints of an established call shall be able to suspend an associated media stream and resume it at a later time.
The endpoint holding the call shall inform the other party that the call is suspended and shall further inform the other
party when the call is reconnected. The media stream is not just interrupted, but possibly redirected to some other
source which generates, for example, an announcement or "music on hold".
5.4 Multi Level Precedence and Pre-emption
In order to allow differentiated/preferred treatment of calls of different/higher operational priority (e.g. emergency calls)
when facing resource limits, the interface shall support signalling mechanisms and procedures to provide multi level
precedence signalling and as well as call pre-emption functionality. Additionally, MLPP is used by the Signalling
Endpoints to handle different priorities at the operational level. In particular this includes flagging of session priority
and signalling flows for precedence blocking as well as pre-emption of calls, but not for reservation of resources.
The present document defines how call precedence and pre-emption is performed, but it does not define the algorithm
that causes precedence blocking or call pre-emption to be performed.
5.5 Voice Group Call and Broadcast Call Control
Voice Group Calls [i.11] and Voice Broadcast Calls [i.12] are service implementations in the NSS.
The interface subject to the present document shall provide mechanisms for the FTS to control voice group calls and
voice broadcast calls from the perspective of Fixed Terminal users as defined by EIRENE [1]. Control of voice group
calls and voice broadcast calls from the perspective of other users is out-of-scope of the present document.
The following control mechanisms shall be supported on the present interface:
• Termination ("kill") of VGCS/VBS calls.
• Requests for muting and unmuting of the mobile terminal downlink of VGCS calls.
When an FTS subscriber is involved in such a call then it is connected by means of a point to point call on the present
interface. The VGCS/VBS call is identified at the application level purely on the basis of the NSS subscriber number
contained in the call signalling.
5.6 User-User-Information-Element Transport
User-to-User-Information-Elements (UUIE) [i.2] are used in GSM-R systems to carry EIRENE specific information
and are exchanged within basic call control messages. TS 102 610 [9] specifies in detail the use and content of UUIEs
in GSM-R and also distinguishes between international and national EIRENE UUIE tags.
ETSI
13 ETSI TS 103 389 V1.1.1 (2011-09)
The interface subject to the present document shall support a mechanism to transparently transport the content of the
UUIE specified by TS 102 610 [9]. The transport of international and national tags and their values shall be supported.
5.7 Reason Transport
In most currently deployed GSM-R systems fixed and mobile terminals make use of end-to-end release cause
signalling.
The present interface shall therefore support the transparent, end-to-end transport of release and disconnect reasons
between the fixed terminals and GSM-R mobile terminals and vice versa.
6 Signalling Interface
6.1 Network Layer Protocol
NSS and FTS shall use IPv4 [2] as the network layer protocol.
Network Address Translation (NAT) is a method used for IP address translation between address realms. NAT adds
complexity to higher layer protocols that is not dealt with in the present document. Therefore no form of NAT shall be
implemented in the network infrastructure at the signalling interface. See [i.16] for more information on NAT.
6.2 Transport Layer Protocol
NSS and FTS shall use UDP [26] as the transport layer protocol.
Network Address and Port Translation (NAPT) is a form of NAT that extends to the transport layer. For the same
reason as for pure network layer NAT, NAPT shall not be implemented in the network infrastructure at the signalling
interface. See [i.16] for more information on NAPT.
6.3 Signalling Protocol
NSS and FTS shall support SIP in accordance with:
• RFC 3261 [3];
and SDP in accordance with:
• RFC 4566 [6]; and
• RFC 3264 [4];
as signalling protocols further qualified by statements in later clauses of the present document.
Requirements for support of other IETF RFCs and other standards are as stated in later clauses of the present document.
Deviations from and/or limited applicability of those RFCs are explicitly pointed out where appropriate.
6.3.1 SIP Entities
A SIP network can be composed of many logical SIP entities. Each entity provides specific functions and participates in
SIP communication as a client (initiates requests), as a server (responds to requests), or as both. One physical entity can
implement the functionality of more than one logical SIP entity.
On the interface subject to the present document the allowed, and therefore relevant, SIP entities are SIP User Agents
(UAs) and SIP Proxy Servers, both defined in RFC 3261 [3].
ETSI
14 ETSI TS 103 389 V1.1.1 (2011-09)
Depending on the FTS and NSS implementation the interaction at the interface may be performed:
• directly between a SIP User Agent and a SIP User Agent; or
• between a SIP User Agent, one or more SIP Proxy Servers and a SIP User Agent.
6.3.1.1 SIP User Agent
UAs initiate and terminate sessions by exchanging requests and responses. RFC 3261 [3] defines a User Agent as a
logical entity that can act both as User Agent Client and as User Agent Server. User Agent Client and User Agent
Server are defined in RFC 3261 [3].
In a SIP environment a SIP User Agent (UA) is a Signalling Endpoint. Therefore on the present interface every
connection is terminated by one SIP UA on either side of the interface.
Which physical entities represent the SIP UAs are subject to the subsystem design of the NSS and FTS.
6.3.1.2 SIP Proxy
A Proxy Server is defined in RFC 3261 [3].
The deployment of SIP Proxy Servers on either side of the present interface is optional and subject to the FTS/NSS
design.
A typical application probably requiring the use of a SIP Proxy at the present interface may be a load balancing service
in front of a number of Signalling Endpoints.
As implicitly required by the reference system architecture in clause 4 of the present document, a SIP Proxy at the
present interface shall not perform parallel forking as defined in RFC 3261 [3] as this would increase the number of
Signalling Endpoints involved in a single dialog. If such functionality is required at a system level it shall be
implemented and hidden within the FTS and/or NSS.
6.3.2 SIP Request Methods
Table 6.1 specifies the requests that shall be, may be, or shall not be, supported by the SIP entities on the present
interface in order to provide the required interface functionality. The terms and abbreviations used in table 6.1 have the
following meaning:
"Sending" means "initiating the method"
"Replying" means "answering the method with an appropriate response"
"Proxying" means "Forwarding the method to another SIP entity"
"m" means "Mandatory"
"o" means "Optional"
"x" means "Not allowed"
"n/a" means "Not applicable"
ETSI
15 ETSI TS 103 389 V1.1.1 (2011-09)
Table 6.1: Supported SIP Methods
SIP Entity
Method Reference User Agent Proxy Server
Sending Replying Sending Replying Proxying
INVITE RFC 3261 [3] m m c (see note 1) o (see note 2) m
ACK RFC 3261 [3] m n/a n/a n/a m
CANCEL RFC 3261 [3] m m n/a n/a m
BYE RFC 3261 [3] m m o (see note 3) n/a m
OPTIONS RFC 3261 [3] o m o m m
PRACK RFC 3262 [11] m m n/a n/a m
UPDATE RFC 3311 [17] o m n/a n/a m
REGISTER RFC 3261 [3] x x x x x
INFO RFC 6086 [i.3] x x x x x
MESSAGE RFC 3428 [i.4] x x x x x
REFER RFC 3515 [i.5] x x x x x
NOTIFY RFC 3265 [i.6] x x x x x
SUBSCRIBE RFC 3265 [i.6] x x x x x
PUBLISH RFC 3903 [i.7] x x x x x
NOTE 1: Conditional, a proxy server is allowed to send an INVITE method in some circumstances (e.g. serial
forking) but only if no new dialog is established.
NOTE 2: The only response a proxy server may generate and send is 100 Trying.
NOTE 3: Is only allowed in case of session timeout.

6.3.3 SIP Responses
Upon receiving a SIP request SIP entities reply to it with an appropriate SIP response, which depends on the type of
request, the type of the receiving SIP entity and the request computing logic.
All SIP entities implementing the present interface shall support sending, receiving and processing of all applicable
response codes defined in RFC 3261 [3], RFC 4412 [12] and RFC 4028 [16] and use them in accordance with the
respective description in RFC 3261 [3], RFC 4412 [12] and RFC 4028 [16].
6.3.4 SIP Header Fields
RFC 3261 [3], RFC 3262 [11], RFC 3326 [8], RFC 4412 [12], RFC 3325 [13], RFC 5876 [14], RFC 3323 [15],
RFC 4028 [16] and RFC 3311 [17] - all of them are applicable to the present interface - specify in detail the SIP header
fields used at the present interface and explain their respective usage.
General rules for processing SIP header fields are defined in RFC 3261 [3] and fully apply to the present interface.
Table 6.2 summarizes the usage of SIP header fields at the present interface. The table legend can be found in
RFC 3261, section 20 [3].
ETSI
16 ETSI TS 103 389 V1.1.1 (2011-09)
Additional information is encoded in the cell background colour:
• "Grey" cells indicate that the usage pattern on the present interface is the same as that of the original RFC
definition.
• "White" cells indicate that the usage pattern at the present interface is different from the original RFC
definition.
Table 6.2: Summary of SIP Header Fields
Header field Reference Where Proxy ACK BYE CAN INV OPT PRA UPD
Accept RFC 3261 [3] R  - o - o m* o o
Accept RFC 3261 [3] 2xx  - - - o m* - o
Accept RFC 3261 [3] 415  - c - c c c c
Accept-
RFC 3261 [3] R  - o - o o o o
Encoding
Accept-
RFC 3261 [3] 2xx  - - - o m* - o
Encoding
Accept-
RFC 3261 [3] 415  - c - c c c c
Encoding
Accept-
RFC 3261 [3]   - - - - - - -
Language
Accept-
Resource- RFC 4412 [12]   - - - - - - -
Priority
Alert-Info RFC 3261 [3]   - - - - - - -
Allow RFC 3261 [3] R  - o - o o o o
Allow RFC 3261 [3] 2xx  - o - m* m* o o
Allow RFC 3261 [3] r  - o - o o o o
Allow RFC 3261 [3] 405  - m - m m m m
Authentication-
RFC 3261 [3]  - - - - - - -
Info
Authorization RFC 3261 [3]  - - - - - - -
Call-ID RFC 3261 [3] c r m m m m m m m
Call-Info RFC 3261 [3]  ar - - - o o - o
Contact RFC 3261 [3] R  o - - m o - m
Contact RFC 3261 [3] 1xx  - - - o - - o
Contact RFC 3261 [3] 2xx  - - - m o - m
Contact RFC 3261 [3] 3xx d - o - o o o o
Contact RFC 3261 [3] 485  - o - o o o o
Content-
RFC 3261 [3]   o o - o o o o
Disposition
Content-
RFC 3261 [3]   o o - o o o o
Encoding
Content-
RFC 3261 [3]   - - - - - - -
Language
Content-Length RFC 3261 [3]  ar t t t t t t t
Content-Type RFC 3261 [3]   * * - * * * *
CSeq RFC 3261 [3] c r m m m m m m m
Date RFC 3261 [3]  a o o o o o o o
Error-Info RFC 3261 [3] 300-699  - - - - - - -
Expires RFC 3261 [3]   - - - - - - -
From RFC 3261 [3] c r m m m m m m m
In-Reply-To RFC 3261 [3] R  - - - o - - -
Max-Forwards RFC 3261 [3] R amr m m m m m m m
MIME-Version RFC 3261 [3]   o o - o o o o
Min-Expires RFC 3261 [3] 423  - - - - - - -
Min-SE RFC 4028 [16] R amr - - - o - - o
Min-SE RFC 4028 [16] 422  - - - m - - m
Organization RFC 3261 [3]   - - - - - - -
P-Asserted- RFC 3325 [13]
r - o - o o o o
Identity RFC 5876 [14]
P-Preferred- RFC 3325 [13]
- - - - - - -
Identity RFC 5876 [14]
Priority RFC 3261 [3]  - - - - - - -
Privacy RFC 3323 [15]  r o o o o o o o
ETSI
17 ETSI TS 103 389 V1.1.1 (2011-09)
Header field Reference Where Proxy ACK BYE CAN INV OPT PRA UPD
Proxy-
RFC 3261 [3]   - - - - - - -
Authenticate
Proxy-
RFC 3261 [3]   - - - - - - -
Authorization
Proxy-Require RFC 3261 [3] R ar - o - o o o o
The present
User-to-User R r - o - o - - -
document
The present
User-to-User r r - o - o - - -
document
RAck RFC 3262 [11] R  - - - - m -
Reason RFC 3326 [8] R r - o o - - - -
Reason RFC 3326 [8] r r - - - o - - -
Record-Route RFC 3261 [3] R ar o o o o o o o
Record-Route RFC 3261 [3] 2xx,18x mr - o o o o o o
Reply-To RFC 3261 [3]   - - - - - - -
Require RFC 3261 [3]  r - - - m m - m
Resource-
RFC 4412 [12] R r
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...