ETSI TR 103 768 V1.1.1 (2022-09)

TECHNICAL REPORT
Rail Telecommunications (RT);
Future Rail Mobile Communication System (FRMCS);
Interworking study with legacy systems

2 ETSI TR 103 768 V1.1.1 (2022-09)

Reference
DTR/RT-0066
Keywords
FRMCS, GSM-R, interworking, radio, railways
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 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
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
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2022.
All rights reserved.
ETSI
3 ETSI TR 103 768 V1.1.1 (2022-09)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Executive summary . 5
Introduction . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 9
3.1 Terms . 9
3.2 Symbols . 9
3.3 Abbreviations . 9
4 FRMCS/GSM-R Interworking principle . 11
4.1 General concept . 11
4.2 FRMCS/GSM-R Interworking architectural principle s . 11
4.2.0 General Approach . 11
4.2.1 Reference points . 13
4.2.1.1 General . 13
4.2.1.2 Reference point IWF-1 (between the IWF and the MCPTT server) . 13
4.2.1.3 Reference point IWF-2 (between the IWF and the MCData server) . 13
4.2.1.4 Reference point IWF-3 (between the IWF and the group management server) . 13
4.2.1.5 Reference point IWF-g1 (between the IWF and the MSC server/MGCF) . 13
4.2.1.6 Reference point IWF-g2 (between the IWF and MGW) . 14
4.2.1.7 Reference point IWF-g5 (between the IWF and IP-SMS-GW) . 14
4.3 FRMCS/GSM-R Interworking addressing . 14
4.3.1 Addressing . 14
4.3.1.0 General . 14
4.3.1.1 SIP URIs and Generic MCX Interworking . 14
4.3.2 Key issues related to addressing . 15
4.3.3 Potential solutions . 15
5 The Mg/Mj/Mb Interface between IMS and CS Domain . 21
5.1 Introduction . 21
5.2 Viewpoint of the GSM-R Network . 21
5.3 Viewpoint of the MCX System . 22
5.4 End to End Use Cases of the Interworking Function FRMCS/GSM-R . 23
5.4.1 Interworking of point-to-point calls . 23
5.4.1.1 General . 23
5.4.1.2 Key issues . 24
5.4.1.3 Potential Solutions . 26
5.4.2 Interworking of group calls . 30
5.4.2.1 General . 30
5.4.2.2 Key Issues . 31
5.4.2.3 Potential solutions . 32
5.4.2.3.1 Interworking of the group call . 32
5.4.2.3.2 Interworking talker control in MCPTT and GSM-R . 34
5.4.3 Interworking of SMS, MCData message . 38
5.4.3.1 General . 38
5.4.3.2 IWF MCData SDS Information Flows . 38
5.4.3.3 Key issues . 39
5.4.3.4 Potential Solutions . 39
5.4.4 Interworking related to fixed line dispatcher . 40
ETSI
4 ETSI TR 103 768 V1.1.1 (2022-09)
5.4.4.1 Controller attached to GSM-R vs FRMCS . 40
5.4.4.1.1 Key issue . 40
5.4.4.1.2 Potential solutions . 40
Annex A: Proposal of Translation Rules for eMLPP Parameters . 42
History . 43

ETSI
5 ETSI TR 103 768 V1.1.1 (2022-09)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are 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 (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
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.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Railway Telecommunications (RT).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Executive summary
Since the first studies on the successor to GSM-R have been launched by UIC in 2012, the rail community has been
considering how to meet rail requirements with a future proof and flexible radio communication system.
The rail needs are defined in the User Requirements Specification (URS) [i.1] and the Telecom Onboard Architecture
(TOBA) Requirements [i.2] delivered by the UIC Project Future Rail Mobile Communications System (FRMCS). From
the UIC requirements, requirements relevant to 3GPP have been captured in 3GPP TS 22.889 [i.3]. Altogether, the
stated requirements are the basis for the development of the GSM-R successor.
The present document is a study on FRMCS interworking with GSM-R, which initially analyse potential interworking
scenarios and potential solutions applicable for GSM-R.

ETSI
6 ETSI TR 103 768 V1.1.1 (2022-09)
Introduction
GSM-R has been a great success not only in Europe, where more than 100 000 km of railway tracks are daily operated
through GSM-R, but also worldwide, and this number will double within the next years due to the on-going installations
of this technology all over the world.
As the needs of the railways are constantly evolving, in particular in the context of the digitalisation of rail operation
that is pursued in many countries and considering the upcoming obsolescence of GSM-R technology, UIC launched in
2012 the first studies for a successor to GSM-R, pertinently named Future Rail Mobile Communication System
(FRMCS). The UIC project then concretely delivered the new User Requirements Specifications (URS) [i.1] focusing
mainly on rail communication needs - as a basis for the development of the GSM-R successor.
The present document is a study on the FRMCS interworking with GSM-R, which defines potential solutions and likely
deployment scenarios, and which elaborates on possible technical realizations of the interworking.

ETSI
7 ETSI TR 103 768 V1.1.1 (2022-09)
1 Scope
The present document analyses the interworking scenario between FRMCS and GSM-R and the solution applicable to
GSM-R. The focus is on GSM-R services equivalency such as voice, SMS, data and other services.
The present document presumes the existence of an interworking function IWF between FRMCS and GSM-R, however
the IWF and the interface between IWF and GSM-R network are not specified.
ETSI TS 123 283 [i.13] specifies the stage 2 of interworking of MCX Systems with LMR Systems, where the
requirements of interworking between FRMCS and GSM-R have not been considered completely.
NOTE: It is assumed that FRMCS is based on MCX Systems and interworking with GSM-R is to be defined on
the same basis of the interworking with LMR systems.
The present document reviews this interworking from three viewpoints:
GSM-R EIRENE specification of services
MCX System ETSI TS 123 283 [i.13]
FRMCS 3GPP TS 22.889 [i.3]
This study focuses on the identification of key functions, key issues and solutions recommended for way forward
resulting in end to end use cases for the IWF.
Prerequisites & Assumptions:
1) The interworking and interconnect is based on SIP interface.
2) The interworking is based on SIP protocol for signalling and RTP protocol for bearer (G.711 codec and
AMR-WB as option).
3) The service continuity is not foreseen as per 3GPP TS 22.889 [i.3].
4) Cybersecurity is not part of this study.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative 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
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
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] UIC FRMCS URS v5.0: "User Requirements Specification".
[i.2] UIC FRMCS TOBA-7510 (V1.0.0) (April 2020): "FRMCS Telecom On-Board System -
Functional Requirements Specification".
[i.3] 3GPP TS 22.889 (V17.2.0) (January 2020): "Study on Future Railway Mobile Communication
System (FRMCS)".
ETSI
8 ETSI TR 103 768 V1.1.1 (2022-09)
[i.4] ETSI TS 123 040 (17.2.0): "Digital cellular telecommunications system (Phase 2+) (GSM);
Universal Mobile Telecommunications System (UMTS); LTE; 5G; Technical realization of the
Short Message Service (SMS) (3GPP TS 23.040 version 17.2.0 Release 17)".
[i.5] ETSI TS 129 163 (V17.3.0): "Digital cellular telecommunications system (Phase 2+) (GSM);
Universal Mobile Telecommunications System (UMTS); LTE; 5G; Interworking between the IP
Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks (3GPP
TS 29.163 version 17.3.0 Release 17)".
[i.6] ETSI TS 103 389: "Rail 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".
[i.7] ETSI TS 123 002 (V17.0.0): "Digital cellular telecommunications system (Phase 2+) (GSM);
Universal Mobile Telecommunications System (UMTS); LTE; Network architecture (3GPP
TS 23.002 version 17.0.0 Release 17)".
[i.8] 3GPP TS 23.280 (V17.2.0) (March 2020): "Common functional architecture to support mission
critical services; Stage 2".
[i.9] ETSI TS 123 228 (V16.4.0): "Digital cellular telecommunications system (Phase 2+) (GSM);
Universal Mobile Telecommunications System (UMTS); LTE; IP Multimedia Subsystem (IMS);
Stage 2 (3GPP TS 23.228 version 16.4.0 Release 16)".
[i.10] ETSI TS 123 379 (V17.9.0): "LTE; Functional architecture and information flows to support
Mission Critical Push To Talk (MCPTT); Stage 2 (3GPP TS 23.379 version 17.9.0 Release 17)".
[i.11] ETSI TS 123 282 (V17.9.0): "LTE; Functional architecture and information flows to support
Mission Critical Data (MCData); Stage 2 (3GPP TS 23.282 version 17.9.0 Release 17)".
[i.12] ETSI TS 143 068 (V17.0.0): "Digital cellular telecommunications system (Phase 2+) (GSM);
Voice Group Call Service (VGCS); Stage 2 (3GPP TS 43.068 version 17.0.0 Release 17)".
[i.13] ETSI TS 123 283 (V17.3.0): "LTE; Mission Critical Communication Interworking with Land
Mobile Radio Systems (3GPP TS 23.283 version 17.3.0 Release 17)".
[i.14] ETSI TS 102 610 (V17.3.0): "Railways Telecommunications (RT); Global System for Mobile
communications (GSM); Usage of the User-to-User Information Element for GSM Operation on
Railways".
[i.15] ETSI GTS GSM 09.02 (V7.15.0) (March 2004): "Digital cellular telecommunications system
(Phase 2+) (GSM); Mobile Application Part (MAP) specification (GSM 09.02)".
[i.16] ETSI TS 123 038 (V17.0.0): "Digital cellular telecommunications system (Phase 2+) (GSM);
Universal Mobile Telecommunications System (UMTS); LTE; Alphabets and language-specific
information (3GPP TS 23.038 version 17.0.0 Release 17)".
[i.17] IETF RFC 4412: "Communications Resource Priority for the session Initiation Protocol (SIP)".
[i.18] IETF RFC 8101: "IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority
Namespace for Mission Critical Push To Talk Service".
[i.19] EIRENE System Requirements Specification, Version 15.1 (2010).
ETSI
9 ETSI TR 103 768 V1.1.1 (2022-09)
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
IMPU: IMS Public User Identity in the form of a SIP URI
NOTE 1: The domain part of the IMPU is equal to the domain of the IMS.
NOTE 2: An IMS subscription support one or more IMPUs.
MCX: all MC services standardized by 3GPP that are foreseen for interworking with GSM-R in the FRMCS
NOTE: Only MCX services related to Voice and Data are considered.
MCX IDs: users and groups of all MC services standardized by 3GPP
NOTE 1: MCX IDs include MCPTT ID, MCPTT group ID, MCData ID and MCData group ID.
NOTE 2: MCX IDs are always defined in the form of SIP URIs.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AMR Adaptative Mobile Rate
AMR-WB Adaptative MultiRate-Wide Band
AoCC Advice of Charge Charging
AoCI Advice of Charge Information
AS Application Server
BAIC Barring All Incoming Calls
BAOC Barring All Outgoing Calls
BGCF Breakout Gateway Control Function
BIC Barring Incoming Call
BICC Bearer-Independent Call Control
BOIC Barring of Outgoing International Calls
CCBS Call Control for Busy Subscriber
CFB Call Forwarding Busy
CFNRc Call Forwarding Not Reacheable
CFNRy Call Forwarding No Reply
CFU Call Forwarding Unconditional
CLIP Calling Line Identity Presentation
CLIR Calling Line Identification Restriction
CoLP Connected Line Identification Presentation
CoRL Connected Line Identification Restriction
CS Circuit Switch
CSC Control Signalling Code
CSCF Circuit Switch Control Function
CT-7 Call Type 7
CUG Closed User Group
CW Call Waiting
DNS Domain Name Server
ECT Explicit Call Transfer
EiNUM tElephone IP NUMber mapping
EIRENE European Integrated Radio Enhanced NEtwork
ETSI
10 ETSI TR 103 768 V1.1.1 (2022-09)
eMLPP Enhanced Multi-Level Precedence and Pre-emption
ENUM tElephone NUMber mapping
eREC enhanced Railway Emergency Call
EVS Enhanced Voice Service
exHC except Home Country
FA Functional Address
FA/FN Functional Address/Functional Number
FN Functional Number
FRMCS Future Railway Mobile Communications System
GC Group Call
GCR GSM Call Register
GPS Global Positioning System
GSM Global System for Mobile communications
GSM-R Global System for Mobile communications - Railway
GW GateWay
HLR Home Location Register
I-CSCF Interrogating-Call Session Control Function
ID/MC Identifier/Mission Critical
IM-MGW IMS MediaGateWay
IMPU IMS Public User identity
IMS IP Multimedia Subsystem
IoT Internet of Things
IP Internet Protocol
IP-SMS Internet Protocol Short Message Service
ISC International Switching Center
IWF Interworking Function
LDA Location Dependant Addressing
LMR Land Mobile Radio
MAP Mobile Application Protocol
MC Mission Critical
MCDATA Mission Critical Data
MCPTT Mission Critical Push To Talk
MCX Mission Critical Services
MCX-ID Mission Critical Service Identifier
MGCF Mobile Gateway Communication Function
MGW Media GateWay
MLPP Multi-Level Precedence and Pre-emption
MOC Mobile Originated Call
MPTY Multi ParTY service
MRFP Media Resource Function Protocol
MS Mobile Station
MSC Mobile Switching Center
MSC-S Mobile Switching Center-Serving
MSISDN Mobile Station International ISDN Number
NG Next Generation
OTDI Originator to Dispatcher Information
P2P Point 2 Point
PABX Private Automatic Branch eXchange
PAI P-Asserted Identity
P-CSCF Proxy-Call Session Control Function
REC Railway Emergency Call
RPH Retention Priority Handling
RTP Real-time Transport Protocol
SA1 Service Aspect 1
SCP Service Control Point
S-CSCF Serving-Call Session Control Function
SDP Session Description Protocol
SDS Short Data Service
SIM Subscriber Identity Module
SIP Session Initiation Protocol
SM Short Message
SME Short Message Entity
ETSI
11 ETSI TR 103 768 V1.1.1 (2022-09)
SMPP Short Message Peer-to-Peer protocol
SMS Short Message Service
SMSC Short Message Service Center
TCP/IP Transmission Control Protocol/Internet Protocol
TE Terminat Equipment
TOBA Telecom On-Board Architecture
UIC Union Internationale des Chemins de fer
URI Uniform Resource Identifier
URS User Requirements Specification
USSD Unstructured Supplementary Service Data
UUI User to User Information
UUIE User to User Information Element
UUS Unstructured Supplementary Service
UUS1 User-to-User Signalling type 1
VBS Voice Broadcast Service
VGCS Voice Group Call Service
XML eXtensible Markup Language
4 FRMCS/GSM-R Interworking principle
4.1 General concept
The IWF is distributed over the SIP/IMS Core and the MCX AS.
An FRMCS/GSM-R specific SIP Profile (also known as SIPCORE) is to be defined for the Mg/Mj/Mb interface
between IMS Domain and CS Domain to allow interworking of railway specific services between FRMCS and GSM-R:
• Based on ETSI TS 129 163 [i.5] (MGCF), enhanced by parts of ETSI TS 103 389 [i.6] (SIP-R), and
potentially other enhancements.
The FRMCS UE is to be built on top of MCX UE.
The FRMCS AS is to be built on top of MCX AS.
4.2 FRMCS/GSM-R Interworking architectural principles
4.2.0 General Approach
The main objective of the present document is to identify the use cases to be considered for interworking. Then, for all
the identified use cases, solutions suitable for interworking between mission critical systems and GSM-R systems are
proposed.
The goal of the present document is to define the reference points that are between the IWF and the MC service servers
and the reference points that are between the IWF and the GSM-R nodes. Additionally it defines the functionality of the
IWF, which acts as an MC service server connecting with the MC service server utilizing the IWF-1 or IWF-2 reference
points, including protocol translation, identity mapping, transcoding, routing and so on to be performed by the IWF
between the reference points on the MC service side to the GSM-R side and vice versa.
The IWF provides centralised support for interworking between an MCPTT or MCData system and a GSM-R system.
In MCPTT or MCData systems, the identity of a GSM-R user is provided as an MCPTT or MCData ID, and the identity
of a GSM-R group is provided as a MCPTT or MCData group ID, which is to be used by the IWF to derive the
corresponding identities used in the GSM-R system and vice versa.
The IWF performs the identity mapping between an MCPTT system or MCData system and a GSM-R system during
exchange of signalling and media messages.
ETSI
12 ETSI TR 103 768 V1.1.1 (2022-09)
MCx
GSM-R
IWF-1
MCPTT server
MSC server
IWF-g1
MGCF
GCR
Group
IWF-3
management
IWF-g2
MGW
server
Configuration
management
server
Identity
IWF
management
server
Key
management
server
Location
management
server
Common
services core
IWF-g5
IP-SMS-GW
IWF-2
MCData server
Figure 1: Functional model for application plane for interworking
Figure 1 illustrates the functional model for application plane for interworking between GSM-R and MCPTT and
MCData. It is based on ETSI TS 123 283 [i.13]. The protocols on any reference point that is exposed for MCPTT
service interoperability with other SIP core or other IMS entities in other systems is to be compatible with the protocols
defined for the corresponding reference point defined in ETSI TS 123 002 [i.7].
From 3GPP TS 23.280 [i.8]:
"The SIP core shall be either:
1. compliant with ETSI TS 123 228 [i.9], i.e. the SIP core is a 3GPP IP multimedia core network subsystem; or
2. a SIP core, which internally need not comply with the architecture of ETSI TS 123 228 [i.9], but with the
reference points that are defined in subclause 7.5.3 (if exposed), compliant to the reference points defined in
ETSI TS 123 002 [i.7]."
ETSI
13 ETSI TR 103 768 V1.1.1 (2022-09)
4.2.1 Reference points
4.2.1.1 General
The SIP core as mentioned above does not need to be compliant to the IMS architecture, but the reference points is to be
derived from IMS specific reference points as shown in Table 1.
Table 1: Proposed mapping of refence points on GSM-R side according to ETSI TS 129 163 [i.5]
Original IMS reference point Derived IWF-gx reference point
Mg/Mj IWF-g1
Mb IWF-g2
ISC IWF-g5
4.2.1.2 Reference point IWF-1 (between the IWF and the MCPTT server)
The IWF-1 reference point, which exists between the IWF and the MCPTT server, provides peer to peer interconnection
between a GSM-R system and the MCPTT system. IWF-1 supports a subset of MCPTT-3 as defined in ETSI
TS 123 379 [i.10], with some differences. The IWF-1 interface is supported by the same signalling plane protocol(s) as
defined for MCPTT-3. Floor control signalling and media are also transferred using the IWF-1 reference point.
4.2.1.3 Reference point IWF-2 (between the IWF and the MCData server)
The IWF-2 reference point, which exists between the IWF and the MCData server, provides SDS interconnection
between a GSM-R system and the MCData system. IWF-2 supports a subset of the functionality of MCData-SDS-1 and
MCData-SDS-2, as defined in ETSI TS 123 282 [i.11] with some differences. The IWF-2 interface is supported by the
same signalling plane protocol(s) as defined for MCData-3 except.
4.2.1.4 Reference point IWF-3 (between the IWF and the group management server)
The IWF-3 reference point, which exists between the IWF and the group management server, provides group
management interconnection between an GSM-R system and the MC service system. IWF-3 is based upon CSC-16, as
defined in 3GPP TS 23.280 [i.8] with some differences.
4.2.1.5 Reference point IWF-g1 (between the IWF and the MSC server/MGCF)
The IWF-g1 reference point, which exists between the IWF and the MSC server via MGCF, provides signalling plane
for voice communication based on implementation of the reference point Mg/Mj as defined by ETSI TS 129 163 [i.5].
Additional information on GCR from ETSI TS 143 068 [i.12]:
"The general architecture of GSM is maintained. In addition, a network function is required which is used for
registration of the group call attributes, the Group Call Register (GCR)".
The protocol for GCR is not specified, but the interface is standardized.
NOTE: The GCR implementation is not specified. It is to be realized e.g. as a new network node, in a PABX
directly attached to an MSC, inside an MSC or as an HLR. The interface between the GCR function and
other functions is not specified in the GSM technical specifications. As a consequence, the functional split
between MSC and GCR as developed in the present document is only indicative.
The GCR data for a specific voice group call is set at the creation of the group call attributes, and is to be subsequently
modified. No support for these functions is specified in the GSM technical specifications.
In a RANflex configuration with group call redundancy GCRs associated to MSCs belonging to the same redundancy
pool need to communicate with each other by means of SYNC_GCR messages.
ETSI
14 ETSI TR 103 768 V1.1.1 (2022-09)
4.2.1.6 Reference point IWF-g2 (between the IWF and MGW)
The IWF-g2 reference point, which exists between the IWF and the MGW, provides media plane protocol for voice
communication.
4.2.1.7 Reference point IWF-g5 (between the IWF and IP-SMS-GW)
The IWF g5 reference point exist between the IP-SMS-gateway on the GSM-R side and the IWF.
Since the assumption is that SIP interfaces are used the IP-SMS-GW is introduced on the GSM-R side to convert the
SMPP MAP protocol to SIP (ISC).
4.3 FRMCS/GSM-R Interworking addressing
4.3.1 Addressing
4.3.1.0 General
The addressing relies on ETSI TS 123 283 [i.13] LMR specification to minimize potential impact on GSM-R side.
The IWF is to be the placeholder for adaptation to keep GSM-R untouched and most of the work is to be done on the
IMS side.
4.3.1.1 SIP URIs and Generic MCX Interworking
One main aspect of the interworking is the fact that different types of identities are used in FRMCS and in GSM-R. The
IWF plays a main role here as it performs the conversion of the IDs used in FRMCS and those used in GSM-R. The
IWF is capable to convert both physical and functional IDs in both systems.
IWF
GSM-R
MCX AS
MCX-ID "MCX-ID"
SIP-R URI
Figure 2: Functional model for interworking functional alias/addressing
Example, from MCX system to GSM-R:
1) Incoming "MCX ID":
a) Identify entities (users, groups) on the MCX System.
2) Outgoing ID:
a) Identify entities (users, services) on the GSM-R System.
3) Incoming and outgoing IDs are either a physical ID (holding a physical address according to E.164 or a MCX
ID) or a functional ID (holding a functional number according EIRENE or a holding an MCX Functional
Alias).
For GSM-R the MSISDN (mobile/fixed) could be registered for functional numbers using the SCP of the GSM-R into
IN database. In FRMCS the MC Service User ID/MC Service ID could be activate for several functional alias into
configuration management Server including functional alias management server database.
ETSI
15 ETSI TR 103 768 V1.1.1 (2022-09)
Both, functional numbers and functional alias are reflecting railway specific roles (e.g. dispatcher, Train xy coach z) for
telecommunication services and needs to be mapped to the technic corresponding public user identity (MSISDN /MCX
User ID).
There are three possible scenarios for translating interwork functional alias which could be applied, further details in
clause 4.3.3
Group mgmt server
Configuration mgmt server
(functional alias management
Server)
IWFg-5 IWF-3
Identity mgmt server
Key mgmt server
Location mgmt server
Common service core
MC Data Server
IWFg-2 IWF-2
GSMR IWF FRMCS / MCX
IWFg-1 IWF-1
MC PTT Server
Figure 3: Functional model for interworking functional alias/addressing
Figure 3 illustrates the functional model for signalling (IWFg-1) and media plane (IWFg-2) for interworking between
GSM-R and MCPTT and MCData.
4.3.2 Key issues related to addressing
• Identify and define criteria to route id towards IWF or not.
• Routing decision.
4.3.3 Potential solutions
Rule based mapping
Addressing Principles:
• Clear Mapping Rules to be standardized between FNs (EIRENE numbers) and FA (FRMCS Functional
Aliases), so that a transformation of addresses is to be done without inquiry at the Configuration Management
Server.
ETSI
16 ETSI TR 103 768 V1.1.1 (2022-09)
• FA(164): FRMCS FAs to be introduced that describe international E.164 numbers.
FA(EIRENE): suggestion is FRMCS FAs are to be introduced that describe international EIRENE numbers (to enable
calls from FRMCS user to GSM-R FNs that do not have an "equivalent" FRMCS FA).
This could be useful e.g. for the breakout into the public network via GSM-R R4.
FRMCS SIP URI Convention
When interpreting SIP URIs as FRMCS/GSM-R addresses, the IWF detect in all cases from the context, if a SIP URI is
to be inter-pre-ted as FRMCS MCX ID or as FRMCS FA or as something else. This knowledge is to be seized by the
IWF always, if available.
Examples for the Suggested FRMCS URI Scheme:
Functional Aliases (at ISC interface and Gm):
FA(164): sip:+435025587100234@oebb.at;user=phone
FA(EIRENE): sip:0435020199299@oebb.at;user=gsmr
FA: sip:MainController.67890@oebb.at
NOTE 1: This approach implies that "function" and "type" of the FRMCS FAs start with an alpha character and are
distinct and unique.
NOTE 2: The types of FAs is to be recognized by one of two mechanisms:
First letter of user part ('+', [0-9] or alpha character);
User parameter "user=gsmr|phone|dialstring|ip" (preferred solution).
MCPTT ID (at ISC interface and Gm)
sip: walter@oebb.at
SIP URI Convention (at Mg/Mj) - ETSI TS 103 389 [i.6]
E.164 sip:+435025587100234@oebb.at;user=phone
EIRENE sip:0435020199299@oebb.at;user=gsmr
Table 2: Example for the Mapping between GSM-R FN and FRMCS FA
Use Case FN (GSM-R) Calls FA (FRMCS) via IWF Example
LDA CT1 to CT7 Controller Identity PrimaryController.12345@oebb.at
(first-to-answer)
Function.Location@CC
Train Number CT2 Train Identity LeadingDriver.54321@oebb.at
(first-to-answer)
Function.TrainNumber@CC
Engine Number CT3 Vehicle Identity Details Tbd.:
(first-to-answer) .equipment.EVN@oebb.at
Coach Number CT4 Vehicle Identity Details Tbd.
(first-to-answer) .equipment.EVN@oebb.at
VGCS/VBS CT5 Profile Addressing traindrivers.12345@oebb.at
(prearranged)
Profile.Location@CC
Shunting Team CT6 Team Identity TeamMember2.Shunting1.12345@oebb.at
(first-to-answer)
Function.Type.Location@CC
Calling the CT7 Controller Identity MainController.12345@oebb.at
Controller (first-to-answer)
Function.Location@CC
Calling a MSISDN E.164 to CT8 FA (164) +43502550001@oebb.at
(private)
ETSI
17 ETSI TR 103 768 V1.1.1 (2022-09)
The following FRMCS FAs are not reachable by GSM-R FNs as without equivalent in GSM-R:
• Equipment Identity (IoT is new).
• Some Functions of:
- Train Identity
- Controller Identity
- Team Identity
• Some Profiles of Profile Addressing (those without equivalent GSM-R FN).
NOTE 3: It may not be needed to normalize the above as no IWF is foreseen on unknown element to GSM-R.
Table 3: Example of mapping FRMCS Service with GSM-R Service
Use Case FA (FRMCS) Calls FN (GSM-R)
Vehicle Identity Function.Equipment.EVN@CC CT3/CT4
LDA -> Controller Function.Location@CC CT7 (user=gsmr)
Identity
Controller Identity Function.Location@CC CT7 (user=gsmr)
Train Identity Function.TrainNumber@CC CT2 (user=gsmr)
Team Identity Function.Type.Location@CC CT6 (user=gsmr)
Profile Profile.Location@CC CT5 (user=gsmr)
Addressing
Call FA/FN Equivalent FA Equivalent FN
(user=gsmr)
Direct Call FN FA(EIRENE) FN (user=gsmr)
Direct Call E.164 FA(164) E.164 (CT8/CT9)
(user=phone)
Mapping Rules for Called Address and Calling Address for FRMCS Terminating Calls
The following two scenarios ( I and II) for Translation from GSM-R to FRMCS are considered:
I.) Called Number is E.164:
I.a) Calling Number (From) is E.164/UUIE holds Calling FN.
I.b) Calling Number (From) is CT5/UUIE holds OTDI.
II.) Called Number is FN (CT2/3/4/5/6/7):
II.a) Calling Number (From) is E.164/UUIE holds Calling FN.
II.b) Calling Number (From) is CT5/UUIE holds OTDI.
Handling of Called Address is depicted in Figure 4. The red and green text below is related to the green and red lines in
Figure 4 and corresponds to the 2 scenarios above identified.
Called Address is mapped by MGCF as follows:
• an E.164 ===> MGCF sends to IWF in Request-URI and To-Header
a SIP URI according to ETSI TS 103 389 [i.6]: CT8 address, optionally CT9 or E.164
• an FN ===> MGCF sends to IWF in Request-URI and To-Header
a SIP URI according to ETSI TS 103 389 [i.6]: FN (CT2/3/4/5/6/7) address
IWF translates Request URI and ignores To Header:
• Req-URI = CT8/CT9/E.164 ===> destination FA(164) in XML Body
• Req-URI = FN ===> destination FA (straight forward mapping algorithm into XML Body)
ETSI
18 ETSI TR 103 768 V1.1.1 (2022-09)
MCX AS delivers MCX ID/resolves FA (dependent on scenario):
• Resolves FA (164) and delivers MCX ID to registered IMPU
• Resolves FA and delivers to resulting MCX ID

Figure 4: Called Addresses (functional and physical) in an FRMCS Terminating Call
Handling of Calling Address is depicted in Figure 5. The red and green text below is related to the green and red lines in
Figure 5.
Depending on the scenario, the MGCF sends the following values to describe calling address and additional calling
address:
- GSM-R point-to-point call to FRMCS user
E.164 calling party in PAI and From Header (ETSI TS 129 163 [i.5])
calling FN in User-To-User Header (ETSI TS 103 389 [i.6])
- GSM-R VGCS/VBS includes FRMCS User as terminating dispatcher
E.164 calling party in PAI (ETSI TS 129 163 [i.5]),
CT5 FN in From Header (ETSI TS 103 389 [i.6]),
calling OTDI in User-To-User Header (ETSI TS 103 389 [i.6] & ETSI TS 102 610 [i.14]).
IWF translates as follows:
• User-To-User Header is forwarded transparently to FRMCS User
• E.164 from the From Header ===> calling MCX ID in XML Body
• FN from the From Header ===> calling FA in XML Body (straight forward mapping algorithm)
• If no FN in From Header ===> try to map FN/OTDI from User-To-User header ===> calling FA
ETSI
19 ETSI TR 103 768 V1.1.1 (2022-09)

Figure 5: Calling Addresses (functional and physical) in an IMS Terminating Call
NOTE 4: It will not be possible to map EVERY UUI to an FA as UUI is transparent per definition.
Mapping Rules for Called Address and Calling Address for FRMCS Originating Calls
The translation rules for Called Addresses are depicted in Figure 6.
The FRMCS User calls either:
• An MCX ID (without knowing, whether the MCX ID is external or internal).
• An FA(164) - an equivalent of a global E.164 address.
• An FA(EIRENE) - an equivalent of a global EIRENE FN.
• A FA - to be resolved to an MCX ID by AS or to be translated to an FN by IWF.
For each called FA, the MCX AS decides:
• Whether the FA is to be resolved, or is to be forwarded to the IWF.
For each called MCX ID, the MCX AS decides:
• Whether the MCX ID is to be delivered within MCX or is to be forwarded to the IWF.
ETSI
20 ETSI TR 103 768 V1.1.1 (2022-09)

Figure 6: Called Addresses (functional and physical) in an MOC
The translation rules for Calling Addresses are depicted in Figure 7. In any case, the calling MCX ID is translated by
the IWF into
...