Rail Telecommunications (RT); Future Rail Mobile Communication System (FRMCS); Study on system architecture

DTR/RT-0011

General Information

Status
Published
Publication Date
02-Jan-2019
Current Stage
12 - Completion
Due Date
14-Jan-2019
Completion Date
03-Jan-2019
Ref Project
Standard
ETSI TR 103 459 V1.1.1 (2019-01) - Rail Telecommunications (RT); Future Rail Mobile Communication System (FRMCS); Study on system architecture
English language
37 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)


TECHNICAL REPORT
Rail Telecommunications (RT);
Future Rail Mobile Communication System (FRMCS);
Study on system architecture
2 ETSI TR 103 459 V1.1.1 (2019-01)

Reference
DTR/RT-0011
Keywords
architecture, 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 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

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 only prevailing document is the
print of the Portable Document Format (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
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
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 2019.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
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.
ETSI
3 ETSI TR 103 459 V1.1.1 (2019-01)
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 . 8
3.1 Terms . 8
3.2 Symbols . 9
3.3 Abbreviations . 9
4 High level approach description . 11
4.1 Introduction . 11
4.2 FRMCS functional architecture . 12
4.3 Functional Example . 15
4.4 On-board architecture . 16
5 Mapping of FRMCS System Functions . 17
6 Discussions . 17
6.1 FRMCS/MCX support for Railway Applications . 17
6.1.1 General considerations . 17
6.1.2 Arguments for loose coupling of data centric Railway Applications . 18
6.1.3 Arguments for integration of data centric Railway Applications. 18
6.1.4 Assessment . 18
6.2 FRMCS/4G support for Railway Applications. 20
6.2.1 Use cases . 20
6.2.2 QoS Management in LTE . 20
6.3 FRMCS/5G support for Railway Applications. 21
6.3.1 Use cases . 21
6.3.2 QoS Management in 5G/NR . 22
6.3.3 Comparison and Suitability of QoS Management Options for Rail Operations . 23
6.4 Communication system resource sharing . 24
6.4.1 Network Sharing . 24
6.4.2 Network Slicing . 24
6.4.3 Precursors of Network Sharing and Slicing in Release 13/14 . 25
6.4.4 E2E Network Slicing as enabled through NR Release 15 . 27
6.4.4.1 General considerations . 27
6.4.4.2 RAN slicing. 27
6.4.4.3 CN slicing . 28
6.4.5 Comparison and Suitability of Network Sharing and Slicing Options for Rail Operations . 29
6.5 SIP core vs. IMS functions . 30
6.6 Communication Recording . 32
6.6.1 Overview of recording options . 32
6.6.2 Description of recording options . 32
6.6.2.1 UE based recording . 32
6.6.2.2 Centralized recording . 33
6.6.3 Security considerations . 33
6.7 FRMCS Security . 33
6.7.1 General Considerations . 33
6.7.2 Security Structure Elements . 34
ETSI
4 ETSI TR 103 459 V1.1.1 (2019-01)
7 Conclusions and Next Steps . 35
Annex A: Change History . 36
History . 37

ETSI
5 ETSI TR 103 459 V1.1.1 (2019-01)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables 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 (https://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.
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.
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 railway community has been
considering how to meet railway requirements with a future proof and flexible radio communication system.
The rail needs are defined in the User Requirements Specification (URS) delivered by the UIC Project Future Rail
Mobile Communications System (FRMCS) [i.1]. Those requirements are the basis for the development of the GSM-R
successor, in the form of individual and technology independent applications.
The present document is a study on system architecture which describes a potential high-level functional architecture,
investigating how the rail requirements can be met. The need for interworking with the legacy GSM-R system during
the transition period to its successor is also considered. The document presents a high level grouping of FRMCS
features for each major system function. In addition, it investigates different technical options and solutions to address
those requirements.
A comparison of technical solutions (including 4G versus 5G) in the context of typical rail applications is presented.
While no conclusion can be drawn, it is understood that several building blocks defined in 3GPP can be used to address
most of the requirements. However, it is acknowledged that a gap analysis should be undertaken to identify which rail
features require a potential standardization effort in ETSI. In addition, a mapping of applications to system functions,
and a mapping of system functions to subsystems and network elements would be needed to refine the FRMCS
architecture.
ETSI
6 ETSI TR 103 459 V1.1.1 (2019-01)
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, and that the telecom standards evolution remains dependent of the
telecom industry evolution cycles, with an end of support for GSM-R planned by 2030 onwards, UIC launched in 2012
the first studies for a successor to GSM-R, pertinently named Future Rail Mobile Communications 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 system architecture, investigating how the requirements from the URS can be met;
keeping in mind that interworking with the legacy GSM-R system is necessary during the transition period from GSM-
R to its successor.
ETSI
7 ETSI TR 103 459 V1.1.1 (2019-01)
1 Scope
The present document:
1) Provides a reference model of FRMCS system architecture from a functional point of view.
2) Provides a high-level description of the functions that address FRMCS requirements (as specified by FRMCS
URS and Use Cases).
3) Defines internal and external boundaries of the FRMCS system (e.g. transport versus applications, external
systems, external networks, etc.).
4) Defines further potential steps.
The present document describes a potential high-level functional architecture, as well as a high level grouping of
FRMCS system functions and mapping towards requirements.
In addition, the present document investigates different technical possibilities, e.g. 3GPP building blocks, to address the
requirements of the FRMCS system. Some of the currently developed techniques, e.g. Service Based Architecture
(SBA) or Software Defined Networks (SDN), have not been considered in the present document and might be included
in a future release.
Finally, the present document identifies the next steps to ensure the complete definition of the FRMCS system.
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 v3.0: "User Requirements Specification".
[i.2] Recommendation ITU-T I.112: "Vocabulary of terms for ISDNs".
[i.3] ETSI TS 124 010: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; Mobile radio interface layer 3;
Supplementary services specification; General aspects (3GPP TS 24.010)".
[i.4] 3GPP TR 22.889: "Study on Future Railway Mobile Communication System".
[i.5] IEC 61375-1:2012: "Electronic railway equipment - Train communication network (TCN) -
Part 1: General architecture".
[i.6] ETSI TS 136 300: "LTE; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (3GPP
TS 36.300)".
[i.7] ETSI TS 123 501: "5G; System Architecture for the 5G System (3GPP TS 23.501)".
ETSI
8 ETSI TR 103 459 V1.1.1 (2019-01)
[i.8] NGMN Alliance 5G White Paper v1.0.
[i.9] ETSI TS 123 401: "LTE; General Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E-UTRAN) access (3GPP TS 23.401)".
[i.10] IETF RFC 7866: "Session Recording Protocol".
[i.11] ETSI TS 103 389: "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".
[i.12] ETSI TS 133 180: "LTE; Security of the mission critical service (3GPP TS 33.180)".
[i.13] ETSI TS 122 278: "LTE; Service requirements for the Evolved Packet System (EPS) (3GPP
TS 22.278)".
[i.14] 3GPP TR 28.801: "Telecommunication management; Study on management and orchestration of
network slicing for next generation network".
[i.15] ETSI TS 122 261: "5G; Service requirements for next generation new services and markets (3GPP
TS 22.261)".
[i.16] ETSI TS 138 211: "5G; NR; Physical channels and modulation (3GPP TS 38.211)".
[i.17] P. Marsch et. al (editors): "5G System Design - Architectural and Functional Considerations and
Long Term Research", Wiley, May 2018.
[i.18] IEEE 802.11™: "IEEE Standard for Information technology--Telecommunications and
information exchange between systems Local and metropolitan area networks--Specific
requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
FRMCS client: client enabling the use of the FRMCS communication services and railway services for the railway
applications including railway services
FRMCS communication services: services enabling the exchange of information (control plane) between FRMCS
Users and/or external systems to manage communication between two or multiple FRMCS Users by using the
capabilities of the FRMCS transport system
FRMCS gateway: gateway coordinating and managing FRMCS Users access to the FRMCS Transport Services
offered by the FRMCS System
NOTE: The FRMCS Gateway may support the FRMCS Proxy and the Legacy Conversion functions.
FRMCS proxy: function interacting with the FRMCS communication services and acting in the place of railway
applications for user plane purposes
FRMCS supporting and enabling services: services providing functions to enable communication services for
FRMCS users based on the 3GPP defined mission critical services and other enabling functions such as location and
recording
FRMCS system: telecommunication system conforming to FRMCS specifications, consisting of FRMCS transport
system and FRMCS communication services
FRMCS transport system: system encompassing the amount of terrestrial and/or non-terrestrial radio access
sub-systems consisting of 3GPP access and/or non-3GPP access, wireline access, the core sub-system having multi-
access capabilities and the User Equipment
ETSI
9 ETSI TR 103 459 V1.1.1 (2019-01)
FRMCS user: human or machine making use of FRMCS communication services
FRMCS user identity: unique identity associated with a single or multiple FRMCS user and can be complemented by
alternative addressing schemes
legacy conversion: function that provides conversion towards legacy interfaces (e.g. V.24 serial interface)
NOTE: The Legacy Conversion provides encapsulation/de-capsulation for control and user plane data as well as
the necessary conversion of the physical interfaces between legacy GSM-R UE and FRMCS. The Legacy
Conversion is based on FRMCS Proxy functions to use the FRMCS Communication Services.
non-MCX enabled: subset of the FRMCS System that provides simple connectivity by using the FRMCS Transport
System and does not interact with the FRMCS communication services and railway services
on-board transport system: system providing on-train only transport services and enables the interaction with the
FRMCS Gateway and the FRMCS communication services where applicable
proxy: person or entity acting or being used in the place of someone or something else
railway applications: applications that provides critical, performance and business related railway functionality using
communication services offered by the FRMCS System
railway services: railway specific services, using enabler services including 3GPP building blocks necessary for
railway applications
reference point: conceptual point at the conjunction of two non-overlapping functional groups
NOTE: See Recommendation ITU-T I.112 [i.2].
train communication network: sub-system of on-board transport system that aggregates various train backbones
user equipment: equipment that allows a user access to transport services via 3GPP and/or non-3GPP accesses
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
rd
3GPP 3 Generation Partnership Project
4G Fourth Generation Mobile Networks
5G Fifth Generation Mobile Networks
AKA Authentication and Key Agreement
AMF Access and Mobility Management Function
APN Access Point Name
ARP Allocation and Retention Priority
AS Access Stratum
ASCI Advanced Speech Call items
ATO Automatic Train Operation
AUSF Authentication Server Function
BGCF Breakout Gateway Control Function
BICN Bearer Independent Core Network
CN Core Network
COTS Commercial off-the-shelf
CUPS Control and User Plane Separation
DCN Dedicated Core Network
DCN-ID Dedicated Core Network Identity
DECOR Dedicated Core Networks
DN Data Network
DRB Data Radio Bearer
EAP Extensible Authentication Protocol
ETSI
10 ETSI TR 103 459 V1.1.1 (2019-01)
eDECOR enhancements of Dedicated Core Networks
EIRENE European Integrated Railway Radio Enhanced NEtwork
eNB evolved NodeB
EPS Enhanced Packet System
ETCS European Train Control System
E-UTRAN Enhanced UMTS Terrestrial Radio Access Network
EVC European Vital Computer
FA Functional Addressing
FEEI Fachverband der Elektro- und Elektronikindustrie Bereich Technik
FFS for further study
FQDN Fully Qualified Domain Name
FRMCS Future Rail Mobile Communications System
FRMCS Future Railway Mobiel Communication System
GPRS General Packet Radio Service
GSM Global System for Mobile communication
GSM-R Global System for Mobile communication for Railways applications
GUMMEI Globally Unique MME Identifier
HPLMN Home Public Land Mobile Network
HSS Home Subscriber server
IEEE Institute of Electrical and Electronics Engineers
IMS Internet Multimedia Subsystem
IN Intelligent Network
IoT Internet of Things
IP Internet Protocol
KASME Key transferred from the HSS to the Access Security Management Entity
KMS Key Management Server
LAA Licensed-Assisted Access
LDA Location Dependent Addressing
LTE Long Term Evolution
LTE-U Long Term Evolution-Unlicensed
LWA LTE-WLAN Aggregation
MAC Media Access Control
MC Mission Critical
MCData Mission Critical Data
MCPTT Mission Critical Push To Talk
MCVideo Mission Critical Video
MCX Mission Critical services
MGCF Media Gateway Control Function
MGW Media GateWay
MME Mobile Management Entity
MNO Mobile Network Operator
MOCN Multi Operator Core Network
MORANE MObile radio for RAilway Networks in Europe
NAS Non-Access Stratum
NEF Network Exposure Function
NGMN Next Generation Mobile Network
NR New Radio
NRF Network Repository Function
NSSAI Network Slice Selection Assistance Information
NSSF Network Slice Selection Function
OTT Over The Top
PCF Policy Control Function
PCRF Policy and Charging Rule Function
PDCP Packet Data Convergence Protocol
PDU Packet Data Unit
PLMN Public Land Mobile Network
PLMN-ID Public Land Mobile Network Identification
PSTN Public Switch Telephone Network
QCI QoS Class Identifier
QoS Quality of Service
RAN Radio Access Nework
RAT Radio Access Technology
ETSI
11 ETSI TR 103 459 V1.1.1 (2019-01)
RBC Radio Block Centre
REC Railway Emergency Call
RLC Radio Link Control
RRC Radio Resource Control
S/P-GW Serving Packet GateWay
SBA Service Based Architecture
SBC Session Border Controller
SDAP Service Data Adaptation Protocol
SDF Service Data Flow
SDN Software Defined Networks
SGSN Serving GPRS Support Node
SIEM Security Information and Event Management
SIL Safety Integrity Level
SIM Subscriber Identity Module
SIP Session Initiation Protocol
SMF Session Management Function
SS7 Signalling System No 7
SST Slice/Service Type
TAU Tracking Area Update
TC Technical Committe
TCN Train Communication Network
TCP Transmission Control Protocol
UDM Unified Data Management
UE User Equipment
UIC Union Internationale des Chemins de Fer
UPF User Plane Function
URS User Requirements Specification
USDM User & Service Data Management
UTRAN UMTS Terrestrial Radio Access Network
WiFi Wireless Fidelity
WLAN Wireless Local Area Network
4 High level approach description
4.1 Introduction
The FRMCS functional architecture objective is a clear separation between FRMCS Communication Services and
FRMCS Transport System to enable bearer flexibility/multi-access support. The FRMCS Transport System is
embedded within the FRMCS Communication Services, which provide a generic interface for Railway Applications to
support the communication between FRMCS Users. Railway Services address specific railway operational
requirements, which are not covered by FRMCS Communication Services.

Figure 1: High Level functional layers
The FRMCS architecture can be vertically split into Railway Applications using FRMCS Communication Services and
other, which are Non-MCX enabled.
ETSI
12 ETSI TR 103 459 V1.1.1 (2019-01)
Railway Applications, which use functions from the FRMCS Communication Services (see Figure 1) start with
registration, authorization and request communication services from the FRMCS System. These Railway Applications
are supported by the FRMCS Communication Services and utilize related functionality, including addressing
(functional aliases), access and admission control, location, prioritization management and application interworking.

Figure 2: Reference model of the FRMCS System
The FRMCS Transport System consists of the core and the access services encompassing various access system which
provide connectivity to the User Equipment (UE). FRMCS Communication Services obtain from FRMCS Transport
System the required communication priority, latency and reliability. Non-MCX enabled applications rely on FRMCS
Transport services and have no interaction with FRMCS Communication Services.
NOTE 1: A commercial off-the-shelf camera, which requires only bearer connectivity, obtains FRMCS Transport
Services and communicate with its destination application or user.
NOTE 2: Train Control Applications can be MCX enabled or Non-MCX enabled (refer to clause 6.1).
4.2 FRMCS functional architecture
This clause focuses on the applications and functionality that only obtain FRMCS Communication Services. In other
words, the Railway Applications that use FRMCS Communication Services are associated with a FRMCS Users and
identities.
The FRMCS System consists of different functional layers to support Railway Applications as well as supporting the
interworking with external systems, including legacy systems or supporting sub-systems.

Figure 3: FRMCS functional architecture
ETSI
13 ETSI TR 103 459 V1.1.1 (2019-01)
The core and the access services including the relevant UEs form the FRMCS Transport Service. The core is based on
3GPP functions and provides the ability to integrate the access service consisting of various access system (3GPP or
non-3GPP) as well as fixed broadband access systems.
FRMCS Communication Services obtain FRMCS Transport Services, which provide transport adaptation. In addition,
the transport adaptation functionality may provide transparent and flexible communication services with different
transport bearers provided by one or more access networks (alternative, redundant or aggregated bearer usage). The
main purpose of the FRMCS transport adaptation functionality is to manage and combine one or more transport bearer
services for an application communication session and make the underlying transport layer details, network changes or
handovers completely transparent to the Railway Applications layer.
NOTE 1: The transport adaption functionality is FFS.
Session control & management layer is part of the FRMCS Communication Services layer and is aligned with 3GPP,
e.g. IMS. It manages the application session control, orchestrate communication requests and invoke services necessary
for user and service data management functions as well as e.g. policy management and control.

Figure 4: Service control & management, core and transport (access network) layers
The FRMCS Communication Services also support services that are based on the 3GPP Mission Critical Services and
other supportive functionality as such as location management, recording or interworking with other external systems.
The 3GPP MCX framework provides point-to-point and group communication for voice, data and video. In
consequence, the MCX framework is the heart of the FRMCS Communication Services to manage Railway
Applications. The 3GPP MCX framework functions support FRMCS User registration and flexible addressing
including i.e. functional aliases, location management and communication logging.
In addition, the 3GPP MCX framework requires extension for supplementary services (ETSI TS 124 010 [i.3]) and the
capability for recording voice and data sessions, which might be defined by upcoming 3GPP releases or need to be
captured in ETSI TC RT specifications. FRMCS recording functionality requires further analysis to assess the
implications of end-to-end encryption requirements as outlined in the discussion clause 6.6.
NOTE 2: Further requirements to the 3GPP MCX framework to support Railway Applications and Use Cases in
3GPP TR 22.889 [i.4] are FFS.
ETSI
14 ETSI TR 103 459 V1.1.1 (2019-01)

Figure 5: FRMCS Service layer covering the MCX framework
The Railway Services in Figure 6 describes specific service logic and control functions beyond the functionality offered
by the 3GPP MCX framework. For example, the railway emergency call interacts with various 3GPP MCX functions,
including group communication, functional alias, user positioning to affiliate to a group communication.
The Railway Applications can reside within the train (on-board) or along the tracks (trackside) or deployed centrally as
network Railway Applications. Railway Applications (MCX enabled) are associated with FRMCS Users and identities
and use services offered by the FRMCS Communication Services. A Railway Application can request a communication
session or become part of a point-to-point or group communication session with other Railway Applications.
NOTE 3: The communication requirements between the ETCS application on-board (EVC) and the associated
trackside application (RBC) can be based on an on-board Railway Application exchanging information
with the relevant Railway Application trackside. The on-board Railway Application would obtain
FRMCS Communication Services.
NOTE 4: The interworking between Railway Applications and non-MCX enabled Railway Applications is FFS.

Figure 6: Railway Services and Railway Applications
NOTE 5: Railway Addressing can also cover Location Dependent Addressing or Follow Me functionalities.
Finally, the FRMCS System foresees also functionality to support the interworking with GSM-R systems. In detail, the
interworking supports the bearer connectivity including transcoding or media mixing for voice and
encryption/decryption as well as call control interactions and services interworking for supplementary services,
EIRENE services (e.g. functional addressing alignment with FRMCS functional alias).
ETSI
15 ETSI TR 103 459 V1.1.1 (2019-01)
In addition, the FRMCS System enables the interconnection and usage of communication services between FRMCS
based networks for roaming users. In addition, it also supports communication services with other external systems,
including public mobile and fixed line operators networks, as well as using railway supporting functions including
railway specific location information providers (e.g. train describer databases).

Figure 7: External systems
4.3 Functional Example
The following example should help to clarify the functional scope and purpose of the different layers in the FRMCS
reference architecture. The Railway Emergency Calls (REC) represents a complex service that leverages a number of
support functions as well as involving different Railway Applications and the associated FRMCS Users into a
communication session.
The REC call is in the example below initiated by the train driver registered as FRMCS User with the train driver
FRMCS User Identity. The service invocation is validated by the MCX framework and passed on to the Railway
Service for REC. The REC service is invoking different functions from the FRMCS Service layer to create a group
communication session with other FRMCS Users in the area.

Figure 8: Railway Emergency Call Functional Example
ETSI
16 ETSI TR 103 459 V1.1.1 (2019-01)
4.4 On-board architecture
The on-board reference architecture represents the on-train FRMCS subsystem and covers the following functional
components:
• On-train Railway Applications supporting voice, data and video services and requiring FRMCS Transport
Services, and possibly natively including an FRMCS Client or utilizing a separate FRMCS Client to also use
FRMCS Communication Services beyond the FRMCS Transport Services.
• On-train FRMCS Gateway (or multiple gateways, see below) to coordinate the FRMCS Transport and
Communication Services between Railway Applications on-board, and between Railway Applications on-
board and trackside.
• On-train User Equipment (UE) (or multiple UEs, see below) which supports the FRMCS Transport services
for one or more radio access networks.
It is expected that multiple FRMCS Users and/or Railway Applications share the same on-board to trackside transport
capabilities. The FRMCS Gateway provides the physical adaptation and encompasses the means to manage the on-
board and train to ground communication and transport service needs.
For improving availability, the on-board network could support more than one FRMCS Gateway. The number of
FRMCS gateways depends on the integration requirements on the train.
The FRMCS Gateway handles the FRMCS Transport Services and provides access to the one or more on-train Railway
Applications through the IP-based on-board communication network. The on-board communication network should be
compatible to the train communication network (TCN) as defined in IEC 61375-1 [i.5] and is not in the scope of the
FRMCS functional architecture.
The on-board reference architecture is depicted in Figure 9.

Figure 9: On-board reference architecture
The Railway Applications are here categorized into the following groups (shown from left to right in Figure 9):
1) Legacy Railway Applications, which rely on non-IP interfaces and protocols, for example a V.24 serial
interface. These require a Legacy Conversion to IP and Proxy functionality to use FRMCS Transport Services.
As shown in Figure 9, Legacy Railway Applications may or may not involve an FRMCS Client, if these
should explicitly use, e.g. Functional Aliasing or other FRMCS Communication Services beyond FRMCS
Transport Services.
ETSI
17 ETSI TR 103 459 V1.1.1 (2019-01)
2) Generic Railway Applications supporting IP transport services and connectivity (e.g. IP based IoT sensors or
COTS IP cameras). Similar to the Legacy Railway Applications, these may or may not make use of an
FRMCS Client if FRMCS Communication Services beyond FRMCS Transport Services are to be used.
3) Railway Applications which are natively MCX-enabled and which already inherently include an FRMCS
Client.
5 Mapping of FRMCS System Functions
Table 1 provides an example of high level mapping and grouping of the features (authentication, addressing, access
control, etc.) required by FRMCS applications onto System Functions (Radio, Core, Session control, MCX, Railway
Applications, UE, etc.).
Table 1: Example of high level mapping and grouping of features
System Function related features
MC Client MCX functions, authentication/authorization, Application interface
UE (terminal) Arbitration, authentication, location, Pro-Se, inter RAT service continuity
Radio Priority handling, arbitration, location, resource management, ciphering
Core Authentication, authorization, data transport, bearer handling, QoS, encryption
Session Control Session control, addressing, routing, QoS, security
MC Common Addressing, functional alias, presence, config, priority, arbitration
MC Voice (MCPTT) P2P voice, voice group communication, assured voice communication
MC Data P2P data, data broadcast
MC Video P2P video, group video
User & Service Data Management Access to the data, authentication, authorization, service profile, configuration
(USDM) storage
Recording Session recording, (voice, data, etc.)
Location Location information interface, location collection/query
Interworking Bearer interworking, service interworking
Multi-Bearer control & Selection, aggregation and management of different bearers and radio networks
management
Network Management Manage user & service data, billing request, network configuration, network
management, recording control & management

6 Discussions
6.1 FRMCS/MCX support for Railway Applications
6.1.1 General considerations
The FRMCS System is relying on the MCX functionality to provide voice services including point-to-point and group
communication to railway users. For data centric Railway Applications the question can be raised, if applications
should utilize the MCData functions and features or if such applications simply require a plain data pipe, which is
provided by the core and transport layers of the FRMCS architecture.
It seems undisputable, that data centric applications, which require group communication would benefit significantly
from the MCX framework functions to exchange data between all members of a group based on centralized
configuration and dynamic group associations. Examples range from railway emergency alert and shunting data
communication to trackside warning system, etc. Furthermore, the discussion around using the MCX framework for
data communication seems comparable to the discussion how voice point-to-point calls are managed. TC RT agreed
that point-to-point voice calls should be handled by the MCPTT framework and handled as private calls. For coherency
reasons the same might apply for data communication service handling.
The discussion could even be extended, which would lead to the question where the boundaries of the FRMCS System
are and what attributes are required to make a Railway Application an FRMCS application.
ETSI
18 ETSI TR 103 459 V1.1.1 (2019-01)
6.1.2 Arguments for loose coupling of data centric Railway Applications
Railway Applications like ETCS or ATO do not necessarily rely on a FRMCS User (and FRMCS equipment e.g. EVC)
on-board as well as the associated FRMCS User trackside, because these applications can use a plain point-to-point data
connection without the MCX framework leveraging only the FRMCS core and transport functions. Especially already
deployed on-board applications which will likely not be changed cannot be adapted to use the FRMCS service layer
functions. ETCS or ATO can rely on a FRMCS User, if there are requirements for Functional Addressing (FA) or
location based addressing (LDA), but operators should be able to use them without the MCX framework. In FRMCS
Functional Aliasing will only be available within the MCX framework.
The whole FRMCS has two parts that are MCX enabled and non-MCX enabled. There are use cases which do not
require the MCX framework e.g. ETCS/ATO, critical video (without role management). The whole FRMCS System
will be still aware of all the data and voice communications (independently in which sub-network it is) and can ensure
the prioritization via QoS classes within the core and radio subsystems.
6.1.3 Arguments for integration of data centric Railway Applications
From a single data application perspective (e.g. ETCS) the benefits and additional value to integrate MCX functionality
might look limited and cause a more complex solution, because each application could rely on a data pipe with a
defined QoS profiled provided by the system, in more detail by the core and transport subsystems.
From a system perspective, the FRMCS system should be aware of all applications using the system to allow control
and management of functions and enable the admission and prioritization not only on the bearer level but also at the
application level. As example, the QoS use cases in 3GPP TR 22.889 [i.4] include a requirement for arbitration of
application and the feedback capability to inform applications, which are pre-empted by the system. In conclusion, a
pure QoS based approach on the transport layer does not support the admission and pre-emption requirements for
FRMCS.
Furthermore with the support of MCX capabilities the applications receive an identity in the system, which is used to
give the applications access to the system, make the application entities addressable by other a
...

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...