d4.2 – report on technical and quality of service viability

Document version: 1.2 Submission date: 2019-03-12

(H2020 730840)

D4.2 – Report on Technical and Quality of Service

Viability

Version 1.2

Final Version

Published by the MISTRAL Consortium

Dissemination Level: Public

This project has received funding from the European Union’s Horizon 2020 research and

innovation

programme under grant agreement No 730840

H2020-S2RJU-2015-01/H2020-S2RJU-OC-2015-01-2

Topic S2R-OC-IP2-03-2015: Technical specifications for a new Adaptable Communication

system for all Railways

Ref. Ares(2019)1779406 - 18/03/2019

MISTRAL D4.2 – Report on Technical and Quality of Service Viability

Document version : 1.2 of 88 Submission date: 2019-03-12

Document control page

Document file: D4.2 Report on Technical and Quality of Service Viability

Document version: 1.2

Document owner: Alexander Wolf (TUD)

Work package: WP4 – Technical Viability Analysis

Task: T4.3, T4.4

Deliverable type: R

Document status: approved by the document owner for internal review

approved for submission to the EC

Document history:

Version Author(s) Date Summary of changes made

0.1 Alexander Wolf (TUD) 2017-12-27 TOCs and content description

0.4 Alexander Wolf (TUD) 2018-01-31 First draft version

0.5 Carles Artigas (ARD) 2018-02-02 Contribution on LTE Security, Chapter 5

0.8 Alexander Wolf (TUD) 2018-03-31 Second draft version

0.9 Alexander Wolf (TUD) 2018-04-27 Release candidate

1.0 Alexander Wolf (TUD) 2018-04-30 Final version

1.0.1 Alexander Wolf (TUD) 2018-05-02 Formatting corrections

1.0.2 Alexander Wolf (TUD) 2018-05-08 Minor additions on chapter 6

1.1 Alexander Wolf (TUD) 2018-10-29 Minor additions after 3GPP comments

1.2 Alexander Wolf (TUD) 2019-03-12 Revision after Shift2Rail JU comments

Internal review history:

Reviewed by Date Summary of comments

Edoardo Bonetto (ISMB) 2018-04-19 Review, comments and remarks

Laura Masullo (SIRTI) 2018-04-19 Review, comments and remarks

Laura Masullo (SIRTI) 2018-04-29 Review



Legal Notice

The information in this document is subject to change without notice.

The Members of the MISTRAL Consortium make no warranty of any kind with regard to this document,

including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The Members of the MISTRAL Consortium shall not be held liable for errors contained herein

or direct, indirect, special, incidental or consequential damages in connection with the furnishing,

performance, or use of this material.

The JU cannot be held liable for any damage caused by the Members of the MISTRAL Consortium or to

third parties as a consequence of implementing this Grant Agreement No 730840, including for gross

negligence.

The JU cannot be held liable for any damage caused by any of the beneficiaries or third parties

involved in this action, as a consequence of implementing this Grant Agreement No 730840.

The information included in this report reflects only the author’s view and that the JU is not responsible

for any use that may be made of such information.



Index:

1 Executive summary ................................................................................. 9

2 Introduction .......................................................................................... 10 2.1 Purpose ............................................................................................... 10 2.2 Scope ................................................................................................. 10 2.3 Methodology ........................................................................................ 11 2.4 Outline ................................................................................................ 11

3 Requirements within Railway Communication Systems ......................... 12 3.1 Overview General Aspects ..................................................................... 12 3.2 Existing Definitions and Standardisations ................................................. 13

3.2.1 CENELEC definitions ...................................................................... 14 3.2.2 Safety requirements ...................................................................... 15

3.3 Retrospective: GSM-R ........................................................................... 16 3.3.1 Functional Requirements – Mandatory Applications features ............... 18 3.3.2 Functional Requirements – Optional Applications features .................. 22 3.3.3 Network Performance Requirements ................................................ 23

3.4 Voice Connectivity ................................................................................ 23 3.4.1 Call related services ...................................................................... 24 3.4.2 Railway specific services ................................................................ 24

3.5 Data Transmission (ERTMS/ETCS, EDOR) ................................................ 24 3.6 Cryptography ....................................................................................... 25

3.6.1 Encryption and authentication algorithms within GSM-R ..................... 25 3.6.2 EuroRadio .................................................................................... 25 3.6.3 Encryption of GSM-R traffic ............................................................ 26 3.6.4 Encryption weaknesses .................................................................. 26 3.6.5 Summary of railway specific services ............................................... 28

3.7 Overview of existing railway QoS definitions ............................................ 32 3.7.1 Specific railway Quality of Service requirements ............................... 32 3.7.2 Packet Core IP network QoS Management ........................................ 34 3.7.3 ETCS QoS Profile for GPRS ............................................................. 37

3.8 Conclusion on Requirements .................................................................. 38

4 QoS in IP-based Systems....................................................................... 41 4.1 Typical QoS implementation methods ...................................................... 42

4.1.1 Oversizing of network and bandwidth .............................................. 42 4.1.2 Reservation of bandwidth ............................................................... 42 4.1.3 Prioritisation of data packets .......................................................... 42 4.1.4 DiffServ - Differentiated Services .................................................... 43 4.1.5 Jitter buffer .................................................................................. 43 4.1.6 CoS - Classes of Service Class Application ........................................ 43 4.1.7 Prioritisation and queuing .............................................................. 43

4.2 Summary ............................................................................................ 44

5 QoS within public mobile radio networks .............................................. 45 5.1 QoS implementation in mobile technology sector ...................................... 45

5.1.1 Requirements on high service availability ......................................... 45 5.2 QoS mechanisms offered by 4G .............................................................. 46

5.2.1 Access Class Barring (ACB) ............................................................ 46 5.2.2 Allocation and Retention Priority (ARP) ............................................ 46 5.2.3 QoS Class Identifier (QCI) .............................................................. 47 5.2.4 4G QoS implementation ................................................................. 47 5.2.5 Requirements and Features of EPS security: ..................................... 50 5.2.6 LTE Security architecture ............................................................... 51

5.3 QoS mechanisms offered by 5G .............................................................. 54 5.3.1 QoS Model – general overview ........................................................ 54



5.3.2 Quality Requirements in 5G Networks .............................................. 54 5.4 Architectural and procedural basics ......................................................... 54

5.4.1 Voice Services within 4G IP networks .............................................. 55 5.4.2 IP Multimedia Subsystem ............................................................... 55

5.5 3GPP Mission Critical Communication Enhancements ................................. 58 5.5.1 Quality of Service requirements for mission critical applications .......... 60 5.5.2 Derived QoS from Future Railway Mobile Communication System ....... 62

5.6 Summary ............................................................................................ 64

6 Railways QoS Implementation Requirements for future scenarios ........ 65 6.1 System architectural requirements ......................................................... 65 6.2 QoS for MISTRAL innovative services ...................................................... 66 6.3 Conditions for railway functionalities ....................................................... 68

6.3.1 Data Transmission ........................................................................ 68 6.3.2 Voice Transmission........................................................................ 69 6.3.3 Security requirements ................................................................... 73 6.3.4 Authentication concepts ................................................................. 74

6.4 Mapping of functional requirements ........................................................ 75 6.5 Conclusion on Technical viability ............................................................. 76

6.5.1 Connection to economic analyses within MISTRAL ............................. 76 6.5.2 Connection with other projects ....................................................... 77

7 Conclusion ............................................................................................. 79

8 List of tables, figures, and references.................................................... 80 8.1 Tables ................................................................................................. 80 8.2 Figures ................................................................................................ 80 8.3 References........................................................................................... 81

9 ANNEX ................................................................................................... 82



Terms and definitions

Term Definition

3GPP 3rd Generation Partnership Project – the organisation responsible for the LTE

standard

4G 4th Generation cellular radio technology covers 3GPP standards from Release

8 to Release 14

5G 5th Generation cellular radio technology, including the evolution of LTE along

with new Radio Access technologies in ultra-high Frequency bands

Application Method that provides a solution for a communication need that is considered

necessary for current and future railway operations

Data

communication

Exchange of information in the form of data via a network, including video

transmission (excluding voice communication)

EIRENE

network

An EIRENE network is a railway telecommunications network, based on the

ETSI GSM standard, which complies with all related mandatory requirements

specified in the EIRENE FRS and SRS.

European

Railway Agency

The agency for railway safety and interoperability established by Regulation

(EC) No 881/2004 of the European Parliament and the Council of 29th April

2004 establishing a European Railway Agency.

GSM-R GSM-Railway is an international wireless communications standard for

railway communication and applications.

Network

registration

delay

Value of elapsed time from the request for registration to indication of

successful registration by CREG response (GSM-R)

Packet

Switched Data

(PSD)

All transmitted data is grouped into packets, which are transmitted via a

medium that may be shared by multiple simultaneous communication

sessions.

Quality of

Service (QoS)

QoS describes the quality of a communication service from the user's point

of view. The necessary QoS mechanisms must be implemented along the

entire transmission path between the network elements.

Transmission

interference

A transmission interference period is the period during the data transmission

phase of an existing connection in which, caused by the bearer service, no

error-free transmission of user data units is possible.

Voice

communication

Exchange of information in the form of voice communication, regardless of

the transmission method



Abbreviations Specific Abbreviations of this document are listed below.

3GPP Third Generation Partnership Project

ASCI Advanced Speech Call Items

ATC Automated Train Control

ATO Automated Train Operation

BTM Balise Transceiver Module

CBTC Communication based train control

CCTV Closed Circuit Television

CS Circuit Switched

DoS Denial of Service

DSCP Differentiated Services Code Point

EAP Extensible Authentication Protocol

EDOR European Data Only Radio

EPC Evolved Packet Core

eLDA enhanced Location Dependent Addressing

eMLPP Multi-Level Precedence and Pre-emption

eREC enhanced Railway Emergency Calls

ERTMS European Railway Traffic Management System

ETCS European Train Control System

ETSI European Telecommunications Standards Institute

FRMCS Future Railway Mobile Communication System

FRS Functional Requirements Specifications

GBR Guaranteed Bit Rate

GGSN Gateway GPRS Support Node

GPRS General Packet Radio Service

GSM-R Global System for Mobile Communication – Railway

HSS Home Subscriber Server

IETF Internet Engineering Task Force

IM Infrastructure Manager

IMS IP Multimedia Subsystem

IP v4/v6 Internet Protocol (Version 4 / Version 6)

IPSec IP Security

IoT Internet of Things

ITU International Telecommunication Union

LTE Long Term Evolution (4G cellular system)

MAC Message Authentication Code

MME Mobile Management Entity

MORANE MObile radio for RAilway Networks in Europe

MS Mobile Station

MSISDN Mobile Station International ISDN Number

NGBR Non-Guaranteed Bit Rate

NSS Network Sub-System

OSI Open System Interconnection reference model

PCRF Policy and Charging Rules Function

PDN Packet Data Network

PER Packet Error Rate

PS Packet switched

PTT Push-To-Talk

QoS Quality of Service

RAN Radio Access Network

RSVP Resource Reservation Protocol

SDF Service Data Flow



SIL Safety Integrity Level

SRS System Requirement Specification

TOS Type of Service

TSI Technical Specification for Interoperability

UE User Equipment

UIC Union Internationale des Chemins de Fer

URS User Requirements Specification

VBS Voice Broadcast Service

VGCS Voice Group Call Services

VoLTE Voice over LTE

VoIP Voice over IP

VRS Voice Recording System

WAN Wide Area Network



1 Executive summary

A future migration of recent railway communication services to more modern, non-

exclusive Wireless Voice and Data Communication is currently being studied in

numerous working groups in the Telecom Industry, Railway Supply Industry and

normative Organisations mainly in terms of basic (technical) feasibility. However, a

coherent business scenario model has not been presented yet. This is mainly due to

several missing complex technical and economic issues that must be analysed. The

MISTRAL project will process these issues by aiming at these objectives. In addition to

economic considerations, MISTRAL also addresses the technical prerequisites, which are

necessary for the implementation of the new paradigms.

Today, the European Train Control System (ETCS) is the leading signalling system for

train control functionality. In the future, ETCS will be provided over new generation

(4G/5G) mobile networks.

It is necessary to analyse whether the specific railway safety requirements can be met

by the performance of the new networks. Special emphasis must be placed on the

integrity of ETCS data, i.e. ETCS data transmission must be protected against loss,

damage and manipulation. This deliverable considers various approaches to quality of

service analysis. These analyses are intended to clarify whether ETCS data integrity and

the functionality of other railway-specific services can be achieved even under difficult

conditions using the appropriate 4G/5G network QoS mechanisms.

The Global System for Mobile Communications-Railways (GSM-R) currently provides

communication between the ETCS elements. ETCS and GSM-R form the European Rail

Traffic Management System (ERTMS). GSM-R was developed specifically for railway

communication, but is now an out-dated technology with known limitations, especially

in the performance of data transmission mechanisms.

Inefficient use of network resources, insufficient capacity and limited support for

broadband data communication are the main problems of GSM-R. Alternative packet-

oriented technologies would bring higher capacity and efficiency. 4G and 5G network

technologies are under consideration to replace GSM-R in the future.

The convergence to an all IP based network will provide a more efficient use of the

network capabilities. Main drawbacks and challenges of this paradigm change are the

QoS assurance methods, guaranteed call setup times, proper service prioritisation and

IP security issues. The 4G and 5G QoS mechanisms have to be identified, discussed and

analysed if they fulfil existing and future railway requirements.

In order to define a comprehensive QoS definition for the future communication

technology, it is first necessary to analyse and define both functional and system-

specific technical requirements to the communication network. The definition of a QoS

vector for railway communication applications will be examined in the following

document and its applicability to new architectural network paradigms will be verified.



2 Introduction

2.1 Purpose

The evolution of mobile telecommunication network standards is constantly being

driven forward. Increasing the data rates and improving the data transmission will

stimulate ideas to use the latest standards also for railway communication purposes as

well.

In the process of finding a replacement for GSM-R different mobile communication

standards were discussed within the MISTRAL project (D4.1). For the application of

future mobile radio systems within the railway sector and especially with the utilisation

of new paradigms (like Network-as-a-Service) certain individual service features and

their high technical requirements must be taken into account. The deliverable D4.2

focuses on the implementation of railway-specific requirements of the train radio

system on the technical characteristics of a modern mobile radio generation. The focus

is on quality of service and a possible feasibility study is performed.

2.2 Scope

The innovation cycles of technical railway systems are considerably longer than in other

industrial sectors. The reasons for this are, among other things, the longevity of

individual components, the complexity of the overall system, the compulsion for

compatibility (especially downward compatibility) of different technologies and the high

investment sums.

However, this makes it necessary to define the Quality of Service (QoS) requirements

to the communication layer as independent of the actual mobile radio standard as

possible. Although the change from circuit-switched transmission to packet-switched-

transmission necessitates a new conception of the QoS, it does not seem sensible to

determine a new QoS vector for each new telecommunications standard.

The idea of QoS for networks is to calculate, improve and guarantee in advance the

transfer rates, error rates and other transmission channel characteristics. QoS within

railway radio systems is particularly important for the continuous transmission of critical

low-latency data and also of high-bandwidth data in future, as this content is difficult to

transmit especially in public networks using common best-effort protocols. Quality of

service can be improved with various techniques such as packet prioritisation,

application classification and queue management.

The definition of a generic QoS vector for railway communication applications will be

examined in the following document and its applicability to new architectural network

paradigms will be addressed. This vector describes qualitatively and quantitatively the

characteristics and performance indicators of the transmission channel that meets the

specific requirements of future railway communication.

A capture of requirements is done, that leads to a clear definition of user requirements,

both functional and non-functional. This is a basis for a feasibility study to carry out an

initial assessment of the next generation system. The aim is to determine whether the

system meets its requirements and whether it is viable to implement as a railway

communication system. The study consists of defining the requirements for the new

system, identifying implementation options and assessing their impact.



2.3 Methodology

The approach used for the analyses carried out to recommend a future QoS and

performance vector are the following. First, the functional and technical requirements of

the existing GSM-R train radio system are analysed. The system specifications of

ERTMS and existing standardisations in the railway domain are used as a foundation.

The existing requirements and principles of operation must also be implemented in a

corresponding way in future communication systems in order to guarantee efficient

railway operation. Furthermore, the network transmission functionalities provided by

future systems are evaluated. Modern mobile radio networks offer comprehensive QoS

functionalities that can be used in the future railway radio system. The results of both

analyses are compared and a new QoS vector is derived and specified, which can be

used for future railway communication.

2.4 Outline

Chapter 3 analyses the existing normative specifications, requirements and

implementations of functions and their quality of service demands of today’s railway

communication networks. An outline is given which specifications and standards are

relevant in the existing GSM-R train radio system. Derived from this, the functional

requirements for the train radio system are described and analysed.

The chapter 4 explains how Quality of service paradigms are fundamentally

implemented in modern IP-based network systems and which methods and algorithms

nowadays exist. Parameters that are particularly relevant for assessing the functionality

are explained in more detail. This chapter also forms the basis for the analyses in

Chapter 5.

Within the 5th chapter the QoS implementations of current public mobile phone

standards will be examined. Modern 4G and 5G mobile radio standards offer powerful

QoS frameworks on the network side, which contain flexibly adjustable prioritisation

functionalities for specific service demands. These capabilities and principles are

examined and the performance characteristics are identified.

The following chapter 6 combines the results of the previous chapters. An analysis

whether the existing stringent requirements can also be fulfilled in the future is

executed. Defining a concrete QoS vector for a future IP based railway communication

network is the aim of this section. The deliverable concludes with a summary and

overview of the results.



3 Requirements within Railway Communication

Systems

3.1 Overview General Aspects

Basic principles and requirements on the development of railway voice and data

applications must first be specified, before specific technical details of the application

demands to the transmission technology can be addressed. Within the chapter 3

existing definitions and standardisations of functional and technical requirements for

railway communication are being discussed. The current ERTMS definitions are analysed

and requirements for the corresponding applications and communication methods are

evaluated.

First, this document analyses and highlights the end-to-end performance and

functionalities of the legacy GSM-R radio railway systems. This analysis serves as a

basic requirement to recognize necessary services, which a future railway

communication system has to provide. These functionalities are compared with the

technical performance features of new IP-based technology candidates (such as 4G/5G

networks) and conclusions with regard to the required feature implementation are

made. This document also contains novel introduced functionalities provided by the

MISTRAL project as innovative solutions for the development of railway services for

operational purposes as well as for railway passengers.

In order to define QoS within the railway communication system, an assessment must

first be made of which functions and subareas are of interest for the characteristics of

the data and voice transmission. This concerns the following questions:

• Which railway specific applications and services must be implemented within the

future railway communication network to meet todays and future demands?

• What are the requirements on QoS of these services that can be deduced from

this?

• Which QoS parameters are suitable for description?

• How can concrete values be defined quantitatively?

From a general point of view, the term QoS is derived from a series of measurable

values that indicates the total performance of a particular service. Basic criteria for

assessing the service performance of network applications are reliability (occurrence

and amount of transmission errors), throughput and delay requirements. Powerful QoS

management in mobile networks is particularly important to ensure that the

performance expectations of different users, which differ depending on the type of

application, must be met for critical applications on the network side. Varying levels of

performance will be required from users of different services.



3.2 Existing Definitions and Standardisations

First, within this section an outline is given of which standardisations apply to the

railway communication system and which definitions exist.

Fundamentally GSM-R represents a special extension of the GSM standard for the

railway sector and includes additional railway-specific functions. The TSIs for Control

and Command ([19]) contain a complex structure of generic requirements on GSM-R

and ETCS. The references to underlying detailed technical specifications referring to

GSM-R are:

• EIRENE (UIC) Functional Requirements Specification FRS

• EIRENE (UIC) System Requirements Specification SRS

• MORANE (UIC) FFFIS for Euroradio

• Test Specifications for Mobile Equipment GSM-R

• GSM-R Version Management

The UIC project EIRENE developed a set of specifications for the European railways that

form part of the specification for technical interoperability as required by the EC

Directive for interoperability of the Trans-European high speed rail system.

The EIRENE specifications ([9]) were written down in the Functional Requirements

Specification (FRS) and the System Requirements Specification (SRS). These

standardisations include the comprehensive requirements for the system.

The FRS distinguishes between four basic service types, derived from requirements

defined by UIC. These elementary service categories are in particular:

• Voice services,

• Data services,

• Call related services,

• Railway operation specific services.

These basic functional groups are examined in more detail in the following sub-chapters

3.3 – 3.6 and the associated requirements for the communication network are derived

and explained in more detail.

The EIRENE Specifications define a radio system satisfying the mobile communications

requirements of the European railways. They encompass ground-to-train voice and data

communications, together with the ground-based mobile communications needs of

track-side workers, station and depot staff and railway administrative and managerial

personnel. The application of the specifications will ensure interoperability for trains and

staff crossing national and other borders between systems. It also intends to provide

manufacturing economies of scale wherever practical.

Together with the MORANE specifications the EIRENE are designed to provide the

minimum set of requirements necessary to ensure international interoperability

between GSM-R networks. The E-SRS covers summarized the following sections:

• Network services (GSM Phase 2 services, railway-specific services)

• Network planning

• Mobile Equipment specification (Core specification, cab radio specification,

general purpose radio, operational radio)



• Numbering plan and call routing (Numbering plan requirements, constraints,

structure of functional Numbers, numbering plan)

• Subscriber management

• Modes of operation (standard mode, railway emergency calls, shunting mode,

direct mode)

With ERTMS/GSM-R the UIC started a project to complement the work specified in

EIRENE and MORANE. ERTMS is a system, formed by three elements:

• GSM-R, the telecommunication system and bearer for ETCS,

• ETCS as the European train control system

• The Traffic Management Layer.

The requirements defined in the above specifications for the existing railway

communication network form the basis for the analyses of this document. Future

technologies will have to measure up to both functional requirements and technical

requirements. Fulfilling existing quality of service values is essential.

However, it should be noted that existing quantitative specifications cannot be adopted

directly and that new requirements must be specified, which also flow into

standardisation. Due to the paradigm shift in future transmission technologies

(connection-oriented to packet-based transmission), new methods and evaluation

standards are taking effect.

3.2.1 CENELEC definitions

Furthermore, fundamental requirements of data transmission via open networks are

also being considered within these studies. At the European level, there exist a number

of standards which may be relevant to the safety of railway communications:

• IEC 61508, Functional Safety: Safety Related Systems;

• EN 50126, Railway Applications: Dependability for Guided Transport Systems;

• EN 50128, Railway Applications: Software for railway control and protection

systems;

• EN 50129, Railway Applications: Safety-related Electronic Railway Control and

Protection Systems;

• EN 50159-1, Railway Applications Part 1: Communication in Closed Transmission

Systems; Requirements for Safety-Related data communication,

• EN 50159-2, Railway Applications Part 2: Communication in Open Transmission

Systems. Requirements for Safety-Related data communication.

The standards are aimed at the development, maintenance and operation of systems.

They embody the concept of the safety lifecycle, in which the most important levels of

the safety guarantee are defined. Furthermore, the processes and procedures to be

applied in each phase according to the required safety integrity are specified.

The two EN50159 standards apply to communication systems for the transmission of

safety-relevant data. Since GSM-R is one implementation for data transmission, these

standards are not being directly applicable to GSM-R. However, they would apply to any

application that uses a data bearer (e.g. via GSM-R or successor technology) to

transmit safety-relevant data. Especially for IP-based transmission, the structural notes



of CENELEC EN50159 “Safety-related communication in transmission systems” are also

retained.

An overview of safety-critical communication in public and private networks as well as

reference architectures is given.

The recent applicable standard for railway in the domain of communication, which

covers aspects of safety and also security, is the EN 50159 "Railway Applications -

Communication, Signalling and Processing Systems – Safety Related Communication".

Standard EN50159 is defining clearly what aspects of communication are covered:

Requirements needed to achieve a safety-related communication between safety

related equipment using a transmission system which was not necessarily designed for

that. The analyses take into account intended attacks by means of messages to safety-

related applications, but do not concern general communication security issues.

3.2.2 Safety requirements

Safety approvals for train communications systems are carried out on a national level.

However, several Member States, as well as the UIC Safety Committee have stated that

the GSM-R system itself does not possess any safety requirements.

There are no specific safety requirements on GSM-R and therefore do not need to be

linked to a specific safety integrity level (SIL), but certification for certain GSM-R

system elements is required.

Telecommunications services within railway sector are used to support safety-relevant

railway applications. However, safety is ensured by applications outside the

telecommunication systems or by operating procedures. Communication systems are

only used as a non-safety relevant carrier service. In order to ensure adequate safety

for specific railway applications using telecommunications services, the transmission

systems themselves have certain reliability requirements, but no special safety

requirements.



3.3 Retrospective: GSM-R

According to the European Council Directive 91/449/EEG of 29 July 1991 concerning the

development of Railways in the European Community a telecommunications network

has to fulfil the following requirements:

1. be open and based on non-proprietary and standardized technology,

2. be nationally interoperable,

3. allow for international train traffic,

4. allow for open competition between train operators,

5. support new, standardized train control systems (ETCS),

6. be future-proof,

7. be able to support safety voice communication and other railway functionalities,

8. be able to support the different business needs of track owners and train

operators,

9. allow for competition between telecom suppliers.

These basic defined requirements are still valid and serve as a normative basis for the

assessment of the qualification of new communication technologies within the railway

sector.

In 1995 the International Railway Union (UIC) chose GSM as the most appropriate

platform for railways. Today, GSM-R, the Global System for Mobile Communication for

Railways, is a worldwide mobile communication system in the railway domain.

GSM-R is based on the most advanced and widely used 2nd generation GSM network

and is standardised by ETSI, the European Telecom Standards Institute and is

supported by the GSM Association (GSMA). However, the standard GSM specification

could not meet all the requirements for efficient railway communication in operation. It

was therefore necessary to identify and specify extra functionalities.

The GSM-R radio standard uses a specific frequency band around 800/900MHz. In

addition, the frequency bands 873-876 MHz (uplink) and 918-921 MHz (downlink) are

used as extenders for GSM-R at national level under the name Extended GSM-R (E-

GSM-R). Typically, GSM-R is implemented via dedicated base stations (BSs) near the

track, with distances between two adjacent BS of maximum 7-15 km to ensure higher

availability and reliability. GSM-R must meet stringent requirements for the availability

and performance of radio services.

The diagram Figure 1 shows an overview of the architectural framework of the services

that can be offered by the GSM-R network.

Several additional, railway specific features had to be described, standardized and

developed, in order to integrate the specific requirements of railways into existing

mobile communication. These functions are called ASCI features. ASCI stand for

Advanced Speech Call Items.

Specific ASCI features for implementation within the railway communication system

are:

• priority and pre-emption,

• voice group-calls,

• voice broadcast calls,

• railway emergency calls,

• fast call set-up for railway emergency calls,



• functional numbering,

• location dependent addressing.

Figure 1: GSM-R service architecture {Ref [16]}

These features are described in more detail below. In principle, these functions are

regarded as the basic functional requirements for voice communication in railway

operations. Future technologies must also be able to reflect these specific

functionalities.

Nowadays, radio networks and railway-specific communication services for railways are

usually provided by the infrastructure manager. In a future scenario, it is probably

mandatory for private telecom providers to implement similar functionalities in order to

be able to map all previous GSM-R functions to a next-generation system. MISTRAL

developed different approaches on how an implementation strategy for train radio could

be implemented in the future. The main focus was on Network as a Service (NaaS)

approaches.

The above-mentioned features were developed together with ETSI and have meanwhile

been incorporated into the GSM standards. They are also partly developed by GSM

providers and made partially available to public operators in selected public networks.

Firstly, we will not go into the technical specification of the equipment technology and

the performance of the network level here. This description of the GSM-R system is

referenced in MISTRAL D4.1. Document D4.2 focuses on the functional requirements

and the QoS definitions, which are important as input variables for future analyses of

requirements to the next generation communication system.

In the following, all functional requirements for the railway-specific communication

network (voice and data) are discussed and summarized. This creates a basis for

identifying the suitability of new technologies and revealing possible shortcomings and

challenges in implementation.



3.3.1 Functional Requirements – Mandatory Applications features

The applications described in this chapter form special functional requirements for the

future communication system. The network implementation might be done in a different

way, but the basic principles and paradigms have to be taken into account. These

requirements are derived from the legacy GSM-R technology.

Future enhancements of these basic mandatory functions are described in the MISTRAL

project and discussed in more detail in a further chapter.

3.3.1.1 Multi-Level Precedence and Pre-emption (eMLPP)

The functionality for Precedence and Pre-emption is implemented with eMLPP. It is a

mandatory functionality within the GSM-R system. The service consists of two parts:

Priority and Pre-emption.

The Precedence feature is responsible for assigning a priority level to a call, in

combination with a fast connection setup. Pre-emption is the seizure of resources used

by a call with lower priority, by a call with higher priority if no unused resources are

available. With Pre-emption it is also possible to involve a disconnection of a running

lower priority call in order to accept an incoming call with higher priority.

The standard system currently distinguishes between 5 different priority levels. The

Table 1 shows the differences between the functions and the individual priority levels.

Table 1: Priority regimes within GSM-R voice connections {Ref UNISIG}

eMLPP

priority

UIC description Pre-emption

0 Railway emergency calls 1 and below

1 Control-commands (safety) 2 and below

2 Public emergency and group calls

between drivers in the same area

3 and below

3 Railway operation

(calls between train drivers and

controllers) and Control-

command information

4

4 Railway information and all other

calls

-

3.3.1.2 Railway Emergency Calls

The Railway Emergency Call (REC) is required to alert railway personnel in a predefined

area in the event of an emergency. The railway emergency call is set up as a high-

priority connection. Railway emergency calls are divided into different groups for train

radio, shunting radio and general voice services.

Two types of railway emergency calls are defined:

• Train emergency calls (for railway emergencies without shunting operation),

• Emergency shunting calls (for railway emergency in shunting operation).

Railway emergency calls are not covering public emergency calls (e.g. 112) handled by

GSM-R with a lower eMLPP priority (2 vs. 0; see the previous section on eMLPP for

details).



Within the EIRENE FRS also an optional enhancement of RECs (eRec, see 3.3.2.3) is

described. Extended localisation and referencing on specific tracks and train-run paths

should help to restrict the selection of railway emergency call recipients:

To minimise the impact on trains not affected by the incident it should be possible to

use an additional set of functionalities to enhance the operation of railway emergency

calls so as to define these areas to include or exclude joining, crossing and parallel

tracks and shunting areas.

3.3.1.3 Functional Addressing

Functional addressing allows a user or application to be reached under a number that

identifies its relevant function (e.g. driver of a specific train) and not the terminal. The

functional HLR (HLRf) controls the assignment of functional numbers to MSISDN. The

participant must register with his MSISDN and the functional number at the beginning

of the mission. Afterwards, it can be reached under this special function number.

There are different possible options for the implementation of a functional addressing

service:

• using Intelligent Network (IN) facilities,

• within the HLR of the GSM network using additional services,

• implementation of a dedicated switch with associated databases.

The IN-based solutions call routing is implemented separately from the communication

service provider. So called Service Switching Points (SSP) are used to detect whether a

calling party wishes to use IN functionality. If this is detected, then the information

provided by the calling party is transferred to the Service Control Point (SCP) which will

act upon the information provided.

If the IN solution is used within the GSM-R network, the caller can dial a Functional

Number (e.g. specific Number of Train plus additional service numbers to reach the

train driver directly), which is "trapped" by the SSP and forwarded to the SCP. The SCP

translates the functional number into the corresponding MSISDN. The SSP will then

make the call as desired.

Once the connection is established, the Functional Number is passed via the fixed

network and the MSC/SSP to the Service Control Point, where it will be translated into

the MSISDN number of the appropriate mobile equipment. Using this number, the call

will then be set up via the GSM network to the correct mobile extension.

3.3.1.4 Group & Broadcast Calls

Group calls in GSM-R are based on the GSM ASCI Voice Group Call Service (VGCS)

whereas broadcast calls are based on the GSM ASCI Voice Broadcast Service (VBS).

The Voice Group Call Service (VGCS) enables a group of subscribers to communicate

with each other in a predefined service area. The VGCS reaches all authorized users in

the defined area. The triggering mobile subscriber can leave the voice channel to

another subscriber the uplink can be changed several times. Operational use is the train

radio emergency call.

Voice Broadcast Service (VBS) group call is a call that reaches all authorized subscribers

in the predefined group call area. The calling party can speak, all other parties can hear

only. The group call is made within a defined group in a defined range. These

parameters are recorded in the Group Call Register (GCR).



3.3.1.5 Location Dependent Addressing

Location-dependent addressing enables calls from the train to be forwarded directly to

the responsible dispatcher. This depends on the current position of the train. The driver

dials the dispatcher via a speed dial number. The call is forwarded to the responsible

dispatcher based on the cell identification. To be able to forward the call correctly, GSM-

R requires information about the train location.

The train passes various control areas within its journey. An automatic update process

is implemented within GSM-R to forward the driver's call to the right dispatcher at any

time. It’s not feasible for the driver to manually determine where the train is and then

enter this information into the handset before making the call, especially for emergency

calls.

3.3.1.6 Fast Call Setup

As defined in EIRENE FRS as a requirement, railway emergency calls must be set-up in

less than 2 seconds in 95% of cases. This feature is required to support this definition.

Important is the end-to-end delay of the radio call setup. The fixed network layer also

has an important role within the transmission chain for the connection setup. It could

delay the connection setup by 250ms. In the future, particular focus must also be

placed on these values, as new mechanisms are used in the paradigm shift from circuit-

switched to IP-based voice transmission, which also have a significant influence on call

set-up times and connection initiation procedures.

3.3.1.7 European Train Control System

One of the most important current GSM-R main application is the European Train

Control System (ETCS). Today GSM-R is the only available carrier for vital data

transmission in ETCS. In order to meet the ETCS requirements, the stricter

requirements for the GSM-R network described in the EIRENE specification must be

met. The quality of service (QoS) requirements are described in Subset 093.

The test conditions for the measurement of subset 093 compliance are described in the

UIC document (Subset 093 - GSM-R for ETCS QoS requirements).

The EuroRadio protocol (see 3.6.2) uses the carrier services of a GSM-R network to

transmit information between OBU and RBC. The service provider supplies these data

carrier services at defined interfaces. The cryptographic techniques of the EuroRadio

layer are described in section 3.6.2 and conclusions are drawn for future

implementation strategies.

The ERTMS/ETCS reference architecture is shown in Figure 2. The main functionality of

the logic for train control is in the Radio Block Centre (RBC). The RBC decides how the

trains run in their specific controlling area. The RBC receives necessary real-time

information about the monitored area from the train. Each ETCS train is equipped with

an ETCS On-board Unit (OBU). The OBU is responsible for the transmission and

processing of the information of the RBC. Important data such as train position, speed

and direction are transmitted. The RBC must also be informed about the condition of

the track elements on the track. Based on all this information, the RBC can decide

which trains are allowed to run on a particular train route and transmit these decisions

to the OBU via messages (specifically the ETCS movement authority (MA)). Different

message types can be exchanged within the ETCS (e.g. configuration messages,

location information). However, the most important message types, that provide the

core functionality of the system, are the location update and the MA.



Figure 2: Reference architecture of train-side/track-side components of ERTMS/ETCS {Ref [6]}

ETCS ensures safe and efficient train operation. To achieve this aim, reliable and low-

latency communication between the ETCS elements is required. However, if ETCS data

transmission between the entities is disrupted or malfunctioning, trains have to be

stopped preventively until communication is restored. This situation is undesirable as it

leads to operational interference. In addition, any uncontrolled state always represents

a safety risk.

Due to the strict security and efficiency concerns, the underlying network must meet

high requirements for the performance of ETCS message transmission. Currently the

transmission is carried out via circuit-switched data calls in the GSM-R network.

Therefore, ETCS requirements have so far only been defined for circuit-switched

transmission. New generation mobile networks are packet-switched networks.

Therefore, the performance conditions of 4G networks data transmission capabilities will

not be directly comparable with current requirements.



3.3.2 Functional Requirements – Optional Applications features

In addition to the mandatory functions to be implemented, the GSM-R specification also

contains functions that can be implemented optionally. The implementation of this

functionality is the responsibility of the respective infrastructure manager. In order to

consider the requirements of future transmission technology, the analysis of these

functionalities is carried out at this point.

3.3.2.1 Direct Mode

Within the EIRENE specifications an option for direct point-to-point communications

between personnel is defined. If the mobile network services provided by the GSM-R

core network become unavailable, this system can still be used for communication. This

method is known as Direct Mode.

The direct mode functionalities are:

• short range fall-back communications between train-side and track-side

personnel in the event of failure of all railway and/or public GSM services,

• short range communications for railway personnel in areas where no GSM

facilities are available at all. (Ref EIRENE FRS and SRS sections 15).

3.3.2.2 eLDA

Enhanced Location Dependent Addressing (eLDA) is an optional feature that improves

the accuracy of GSM-R Location Dependent Addressing and is specifically intended for

use in situations where the accuracy of cell dependent addressing is not sufficient. eLDA

functionality uses data from external systems (for example GPS, balises and trackside

train detection systems).

eLDA call setup times shall meet the call setup timing requirements for point to point

calls as specified in the EIRENE FRS specification. The eLDA system shall be possible to

transmit train location data over the air interface with a granularity equivalent to a

maximum distance of 1 meter.

3.3.2.3 eREC

With emergency calls in GSM-R (RECs), there is no distinction between specific track

lines possible. Therefore, when a REC is initiated in a particular area, the trains on the

other lines can also receive the REC. The consequence is that trains unnecessarily on

other tracks are affected by the emergency. This can be a big drawback in concerning

delays, particularly when a high-speed train is stopped to due to a conventional train.

eREC stands for enhanced Railway Emergency Calls and its purpose is to provide a

solution to this problem by enabling Railway Emergency calls to be set up only to the

subscribers/lines that are directly affected.

3.3.2.4 Shunting communication

Within the EIRENE FRS and SRS the requirements for shunting are defined. Shunting as

a GSM-R application is an optional service, but some shunting features are mandatory

in all cab radios. The shunting requirements have been written to integrate common

features to make shunting safer and more viable. These features include the link

assurance signal, protected group calls and shunting emergency calls.



3.3.3 Network Performance Requirements

The infrastructure manager and GSM-R operator needs to check frequently the fault-

free operation of the network. It must be ensured that the requirements for the quality

of the radio network are fulfilled and QoS values are met. For network planning, the

coverage level is defined in terms of time and area where the minimum signal criteria

are achieved.

Selected relevant radio coverage criteria:

• The level of coverage should be at least 95% of the time over 95% of the

designated coverage area for a radio installed in a railway vehicle with an

external antenna.

• The land-based part of the system shall provide communications for mobiles

when stationary and when travelling at speeds up to the maximum allowable line

speed or 500 km/h.

• Received Signal Quality “rxQual UL & DL”: 95% of the results must be level ≤4

• Received Signal Level “rxLev UL & DL”: 95% of the results must be level ≥15

3.4 Voice Connectivity

Railway voice communication is quite similar to commercial mobile communication.

However, due to several railway specifics, there are some important differences in

terms of features and performance requirements.

The description of existing functional requirements regarding voice applications are

defined in EIRENE FRS chapter 2.2 and is limited to the different types of calls. The

following implementations are mentioned in detail:

• point-to-point voice calls

(voice calls between any two call parties, which shall allow both parties to talk

simultaneously)

• public emergency voice calls

(allow a user to make public emergency point-to-point voice calls. Such

emergency calls include ‘112’ calls and may not be used for railway

emergencies)

• broadcast voice calls

(these voice calls provide one-way voice communications from a single user to

multiple users in a pre-defined local area)

• group voice calls

(provide voice communications between a number of users in a predefined

local area, all of whom are members of the same call group. The composition of

call groups shall be able to be modified within the network)

• multiparty voice calls

(multi-party voice communications between up to six different parties. Any of

the parties involved in a multi-party voice call shall be able to talk

simultaneously).

Besides the additional features, railways defined requirements on call setup times.

These requirements ensure a sufficient level of service. Fast call setup times directly

contributes to railway safety: in the case of a railway emergency call a short setup time

ensures that all railway staff are quickly informed about a potentially dangerous

situation.



Table 2: Requirements on voice call setup times {Ref [9]}

Type of call Call setup time

Railway emergency call <4s

High priority group calls <5s

All operational and high priority

mobile-to-fixed calls not covered by

the above

<5s

Other operational mobile-to-fixed

calls

<7s

Other operational mobile-to-mobile

calls

<10s

Low-priority calls <10s

3.4.1 Call related services

As mandatory implemented call related communication services, the following

applications are identified, following FRS (Ref FRS, Sec 2.4):

• Display of identity,

• Priority and pre-emption,

• Closed user groups,

• Call forwarding,

• Call hold,

• Call waiting,

• Charging information,

• Call barring.

These call related services are features that provide basic functionality related to user

interaction and operation for call devices.

3.4.2 Railway specific services

As mandatory implemented railway specific services, the following applications are

identified, following FRS (Ref FRS, Sec 2.5). The EIRENE network shall provide support

for the following railway specific services:

• Functional addressing including registration/deregistration,

• Location dependent addressing,

• Railway emergency calls.

3.5 Data Transmission (ERTMS/ETCS, EDOR)

As use cases of implemented data-only communication services, the following

applications are identified, following FRS (Ref FRS, Sec 2.3):

• text messages (optional)

(point-to-point and point-to-multipoint text messages from the ground to mobile

users)



• general data applications

(range of data communications between the ground and mobile users, i.e.

timetable information; maintenance and diagnostic applications; mail and

messaging; remote database access)

• train control applications

(Where ERTMS/ETCS level 2 or 3 is implemented, the network shall be capable

of supporting data communications for that train control system with the

required quality of service. Communications for train control may be

characterised as low data rate per train; however, in some areas there will be a

high density of trains requiring simultaneous communications).

These functions are explained in more detail within this section and the requirements

for the communication network are specified.

3.6 Cryptography

3.6.1 Encryption and authentication algorithms within GSM-R

The legacy GSM-R-System is based on the GSM standard. Standardized cryptographic

methods are used for the application of network internal procedures for encryption of

the connection.

Securing the use of voice privacy (encryption) algorithms and authentication algorithms

for SIM cards is of interest to railways. Examples of standardized GSM cryptographic

algorithms are:

• A3 and A8 authentication algorithms,

• A5/3 encryption algorithm.

The A3 and A8 algorithms are open documented and freely available (see 3GPP TS

55.205 "Specification of the GSM-MILENAGE Algorithms”). A5 is closed source.

The ETSI GSM specifications only refer to the algorithms in general terms and do not

specify them in detail. The use of standardized voice privacy algorithms is mandatory

for a GSM-R network. Each railway is free to implement its own authentication

algorithms providing that there is no resulting loss in cross-border interoperability.

GSM-R uses the A5 suite of cryptographic ciphers, more specifically A5/1, a stream

cipher based on Linear Feedback Shift Registers (LFSRs). Optionally, the block cipher,

A5/3, may be supported. These ciphers are used for encryption of the communication

between mobile stations and the network plane (e.g. trains and handheld devices).

Mobile handsets and devices (e.g. cellular staff phone, cab radios) are authenticated

onto the network. However, due to the limited authentication functionality of GSM, the

base station is never authenticated to the handset.

3.6.2 EuroRadio

The EuroRadio protocol is a specific protocol layer between the GSM-R and Application

Layer protocol (see Figure 3). EuroRadio provides the authentication functionality and

integrity verification for ETCS messages sent and received via GSM-R. Thus, by adding

cryptographic MACs EuroRadio guarantees that messages received are authentic. GSM-

R provides the encryption methods between the train and network plane (mobile base

stations).



Figure 3: Communication protocol stack architecture (TUD)

The MAC used in EuroRadio is derived from the ISO 9797-1 MAC Algorithm 3. This

cryptographic algorithm computes a MAC using DES and 3DES ciphers. The MAC is

computed on the length of the entire message, the ETCS ID of the recipient, the

message being sent and optional padding to ensure appropriate length for the MAC

computation. However, the specific EuroRadio MAC algorithm uses three distinct keys in

the final 3DES computation. The cryptographic keys used by EuroRadio to generate the

MACs are session keys. These keys are derived from a pre-shared 3DES key. They are

exchanged during the protocol handshake phase.

To ensure validity and integrity of ETCS messages, the EuroRadio layer is capable to set

different priorities of messages. Messages which have a “normal” priority, must have a

MAC computed and added to the payload. Messages with “high” priority do not contain

a MAC and bypass verification by the EuroRadio layer. They can include a very

restricted set of commands only (e.g. emergency stop).

3.6.3 Encryption of GSM-R traffic

GSM-R utilise the cryptographic mechanisms of GSM to protect messages. Security

vulnerabilities that exist against the GSM standard may be exploitable within GSM-R as

well. For example, channel jamming attacks could affect all operations within range of

the equipment for ERTMS. Also the interception of communications or an insertion of

messages into the communications channel might be possible. Unauthorized, inserted

messages could cause a train to stop and thus to influence the traffic operation within a

railway network completely.

The weaknesses of GSM encryption have been already evaluated. It was shown that the

A5/1 cipher used in both GSM and GSM-R could be broken with different attack

approaches. An export variant of A5/1, A5/2, was also shown to be weak and is

vulnerable to real-time attacks. Once the A5 key has been established, it is then

possible to recover traffic sent over the GSM-R link, including train control messages.

Another security risk is posed by so-called “IMSI Catchers”, which can get the TSMI and

some undisclosed ERTMS values (e.g. train ID) of an operational train.

3.6.4 Encryption weaknesses

EuroRadio MAC algorithm is the algorithm used to secure communication between trains

and track radio network equipment. On the ERTMS stack EuroRadio provides the safety-

critical function of message authentication.



There are potential security vulnerabilities that could be exploited ([17][18]). This made

it possible to develop a key recovery attack by exploiting collisions in the MAC for

various messages. Cryptographic weaknesses of EuroRadio can be exploited if one of

the keys used to generate the MACs is successfully recovered. This vulnerability can be

combined in the Application Layer protocol to create a fake Movement Authority with a

valid MAC. These fake messages can be accepted by a train and possibly leading it in a

potential unsafe situation!

Although EuroRadio currently is safe for use in current ERTMS command and control

applications the recommendation is that EuroRadio should not be considered for use in

future high-bandwidth applications (e.g. video streaming, monitoring). High-bandwidth

applications reduce the time required to get collisions and thus session key recovery

becomes more likely. As a result, the MAC algorithm in EuroRadio should not be

considered for such applications.

Among other activities, the following measures are proposed ([18]) to achieve the

objectives of secure network for railway in the future:

• A restriction of utilisation of EuroRadio in high-bandwidth applications,

• Implementation of an alternative, more secure MAC Algorithm,

• Combining EuroRadio and Application Layer to achieve a secure message

sending/receiving service.

The limitations of the current GSM-R encryption strategies have already been confirmed

by railway infrastructure managers and public authorities. UK’s Rail Safety and

Standards Board (RSSB) and Network Rail concluded that EuroRadio is not safe to be

used with a transport protocol faster than GSM-R. For the future use of a next

generation mobile radio standard in the railway sector, it is essential to implement the

authorisation of subscribers with new, safe methodologies.

Approaches to more secure authentication are already included in the 4G/5G standards.

It is necessary to discuss how these more modern cryptographic methods can also be

used in the future railway communication networks. In chapter 5.2.6 we address

authentication concepts and analyse the possibility of an extended implementation for

railway applications.



3.6.5 Summary of railway specific services

The following

Table 3 summarises in detail all functional requirements that currently exist for railway

specific communication via the GSM-R systems with regard to voice and data

connections. These requirements are based on the EIRENE FRS and are referenced to

the specification.

Future mobile radio standards will necessarily have to support these functional

requirements. The challenge is the implementation of specific voice services for railway

operations, especially the strict requirements for RECs. Individual requirements

regarding the mandatory quality of service will be further investigated in chapter 3.7.

Functions ERTMS Spec.Ref

ERTMS Functional Description

Data/Voice

Voice services EIRENE-FRSv7 2.2.1

This section describes the generic voice telephony services which are to be supported by the railway communication system: − point-to-point voice calls; − public emergency voice calls; − broadcast voice calls; − group voice calls; − multi-party voice calls.

V

Voice services EIRENE-FRSv7 2.2.2

All voice call services shall be able to operate between any combination of fixed and mobile equipment users.

V

Voice services - Point-to-point voice calls

EIRENE-FRSv7 2.2.3

The system shall support point-to-point voice calls between any two call parties.

V

Voice services - Point-to-point voice calls

EIRENE-FRSv7 2.2.4

The IP Communication System should support full duplex communications.

V

Voice services - Public emergency voice calls

EIRENE-FRSv7 2.2.5

The system shall allow a user to make public emergency point-to-point voice calls.

V

Voice services - Broadcast voice calls

EIRENE-FRSv7 2.2.7

The system shall support broadcast voice calls. V


EIRENE-FRSv7 2.2.9

The composition of call groups shall be able to be modified within the network. A single user shall be able to be a member of one or more call groups.

V


EIRENE-FRSv7 2.2.10

The local area over which broadcast calls shall be implemented shall be able to be modified within the network.

V


EIRENE-FRSv7 2.2.11

It shall only be possible for the user who initiated the call to talk, other users can only listen.

V



Voice services - Group voice calls

EIRENE-FRSv7 2.2.12

The system shall support group voice calls. V


EIRENE-FRSv7 2.2.14

The composition of call groups shall be able to be modified within the network. A single user shall be able to be a member of one or more call groups.

V


EIRENE-FRSv7 2.2.15

The local area over which group calls are implemented shall be able to be modified within the network.

V


EIRENE-FRSv7 2.2.16

It is acceptable that only one mobile user involved in the group call may talk at any time. In this case: − It shall be possible for controllers to speak at any time during the call. − A mechanism shall be provided by the system to arbitrate between those users wishing to speak within the group call.

V

Voice services - Multi-party voice calls

EIRENE-FRSv7 2.2.17

Any radio can transmit and receive data to and from several different IP sources and destinations addresses.

V

Voice services - Multi-party voice calls

EIRENE-FRSv7 2.2.18

Any of the parties involved in a multi-party voice call shall be able to talk simultaneously.

V

Data services EIRENE-FRSv7 2.3.1

The Communication System network will provide data services to support the following data applications: − text messages; (O) − general data applications; (M) − automatic fax; (O) − train control applications. (O)

D

Data services - Text messages

EIRENE-FRSv7 2.3.2

The network should support the transmission of point-to-point and point-to-multipoint text messages from the ground to mobile users. (O)

D


EIRENE-FRSv7 2.3.3

The network should support the receipt of mobile-originated text messages by the ground. (O)

D


EIRENE-FRSv7 2.3.4

If the text message facility is implemented, it shall not interfere with the ability of users to make or receive high priority voice or data calls. (M)

D

Data services - General data applications

EIRENE-FRSv7 2.3.6

The network shall support point-to-point data communications. D

Data services -

General data applications

EIRENE-

FRSv7 2.3.8

The network shall support data rates of at least 2.4 Kbit/s. D

Data services - Automatic fax

EIRENE-FRSv7 2.3.11

The network should support fax transmissions between the ground and mobile users. (O)

D

Data services - Automatic fax

EIRENE-FRSv7 2.3.12

Where fax functionality is provided, it shall be possible to interrupt the fax to make or receive a high priority voice or data call. (M)

D

Data services - Train control applications

EIRENE-FRSv7 2.3.13

Where ERTMS/ETCS level 2 or 3 is implemented, the network shall be capable of supporting data communications for that train control system. (M)

D



Call related services

EIRENE-FRSv7 2.4.1

The Communication System will support the following call related services: − display of identity of called/calling user; (M) − restriction of display of called/calling user; (O) − priority and pre-emption; (M) − closed user group; (M) − call forwarding; (M) − call hold; (M) − call waiting; (M) − charging information; (O) − call barring. (M)

V

Call related services - Display of identity

EIRENE-FRSv7 2.4.2

It shall be possible for the equipment to display the identity of the called or calling party in the form of a standard telephone number.

V

Call related services - Display of identity

EIRENE-FRSv7 2.4.3

It shall be possible to display the identity of the called or calling party as a textual description of their function.

V

Call related services - Restriction of display of identity

EIRENE-FRSv7 2.4.4

It should be possible for the network to prevent the identity of certain users from being displayed on the mobile, either when being called, calling or both. (O)

V

Call related services - Priority and pre-emption

EIRENE-FRSv7 2.4.5

The network shall provide a mechanism whereby calls may be assigned one of a number of different priority levels.

V


EIRENE-FRSv7 2.4.6

This mechanism shall allow calls with a higher assigned priority to override (pre-empt) existing calls of a lower priority.

V


EIRENE-FRSv7 2.4.7

Pre-empted calls will be discontinued and the new call of a higher priority shall be connected instead.

V

Call related services - Closed user group

EIRENE-FRSv7 2.4.8

The group of users who may access the facilities of the Communication System shall be limited.

V

Call related services - Closed user group

EIRENE-FRSv7 2.4.9

Any user who is not within the list of allowed Communication System users shall not be able to gain access to any of the functions and services provided by the network. (M)

V

Call related services - Call forwarding

EIRENE-FRSv7 2.4.10

It shall be possible for an incoming call or data message for one user to be forwarded to another user using functionality provided by the network. (M)

V


EIRENE-FRSv7 2.4.11

In the case of voice calls, it shall be possible for the user who is attempting to forward a call to converse with the intended recipient prior to forwarding. (M)

V


EIRENE-FRSv7 2.4.12

There are a number of sub-classes of call forwarding to be supported by the network: − automatically forward the incoming call without any user interaction (unconditional); (M) − automatically forward the incoming call without user interaction if the user is busy in an existing call (busy); (M) − automatically forward the incoming call if there is no reply from the intended recipient (no reply); (O) − automatically forward the incoming call if the intended recipient cannot be contacted via the network (not reachable). (O)

V

Call related services - Call hold

EIRENE-FRSv7 2.4.13

The network shall allow the user to temporarily exit from an existing call by putting the call on hold. (M)

V

Call related services - Call hold

EIRENE-FRSv7 2.4.14

It shall be possible for the user to re-join the call which is on hold at any time. (M)

V



Table 3: Functional requirements of railway communication system (Extracted from EIRENE FRS)

Call related services - Call waiting

EIRENE-FRSv7 2.4.15

The network shall provide the ability to inform a user, who is involved in an existing call, of attempts by other users to contact them. (M)

V

Call related services - Charging information

EIRENE-FRSv7 2.4.16

Where network services are chargeable, it should be possible for the network to provide information about call rates and on-going call charges. (O)

V

Call related services - Call barring

EIRENE-FRSv7 2.4.17

It shall be possible, using network management or maintenance facilities, to prevent individual users from: (M) − making calls to: − another network (fixed or mobile) (e.g. can only call on home network); − certain types of numbers within or external to the network (e.g. cannot call teleshopping numbers); − certain pre-defined telephone numbers (e.g. cannot call drivers and on-train users); − receiving calls from: − all other networks (fixed or mobile); − certain other networks (fixed or mobile); − certain types of numbers within or external to the network; − certain pre-defined telephone numbers.

V

Railway specific services

EIRENE-FRSv7 2.5.1

The System shall also provide support for the following railway specific services: − functional addressing including registration/deregistration (see section 11); (M) − location dependent addressing (see section 11); (M) − shunting mode (see section 14); (M) − Railway emergency calls (see section 13). (M)

V



3.7 Overview of existing railway QoS definitions

This section is concerned with the specific definition of QoS implementation within the

GSM-R system and ERTMS/ETCS services. The individual parameters are described and

evaluated in detail.

In general, the quality of a voice or data transmission can be evaluated and controlled

in various ways. However, availability of transmission with a given coverage is a first

indicator for its quality. The end-to-end quality of transmission can be managed by

different IP QoS paradigms.

The QoS itself can be defined a series of parameters of network and service

performance indicators which determines the degree of service fulfilment. QoS

management in communication networks is based on the fact that different application

types and different performance levels are required by the users of different services.

Fundamental parameters are reliability (transmission link erroneousness) and

throughput/delay requirements. Services which having strict delay and reliability

requirements are regarded to real time classes, while services characterised by high

reliability and relaxed delay requirements are categorised as non-real time services.

Real time traffic classes can ask for guaranteed bitrate to ensure required service

performance while non-real time traffic classes cannot.

The ETCS application has pre-defined delay and reliability requirements, which are

specified in QoS specification in appropriate UNISIG subsets.

3.7.1 Specific railway Quality of Service requirements

This sub-section evaluates Quality of Service requirements based on UNISIG SUBSET-

093 and proposes a standardized QoS vector of existing GSM-R communication

networks.

It contains:

• Detailed definitions of the QoS parameters for the GSM-R bearer service,

• The interfaces on which the bearer service and the QoS parameters are

applicable.

The operation of the ETCS application has strict delay and high reliability requirements.

Since ETCS GSM-R circuit switched bearer is an end-to-end bearer service, it is not

enough to limit the quality of service requirements to the air interface. End-to-end

quality of service must be taken into account also for service access points.

In the context of end-to-end QoS the network may be regarded as the sub-system that

provides data connectivity between the mobile terminal and the external IP-based

network. The end-to-end transmission path between mobile terminal and RBC consists

of three segments:

• Radio Access Network

• Packet Core Network

• External IP based Packet Data Network

The communication network shall be able to support transparent train-to-trackside and

trackside-to- train data communications at train speeds up to 500 km/h e.g. in tunnels,

cuttings, on elevated structures, at gradients, on bridges and stations. Furthermore, the

required QoS parameters shall not depend on network load.



Given the performance constraints of GSM-R, pre-conditions may be necessary to meet

the railway operational targets. The values shown in the following Table 4 characterise

the specified quality of service of the ETCS data connection according to UNISIG

SUBSET 093.

QoS Parameter Specified Value

Connection establishment delay of

mobile originated calls

< 8.5s (95%), ≤10s (100%)

Connection establishment error

ratio

<10-2

Maximum end-to-end transfer

delay

(30 byte data block)

≤ 0.5s (99%)

Connection loss rate ≤ 10-2 /h

Transmission interference period < 0.8s (95%), <1s (99%)

Error-free period >20s (95%), >7s (99%)

Network registration delay ≤30s (95%), ≤35s (99%), ≤40s (100%)

Table 4: Summary of QoS requirements {Ref [2]}

It is obvious that within the QoS parameters listed and specified in Table 4 a further

distinction is made between two subcategories. The registration of the network

connectivity itself and the characteristics of the specific connection.

First, relevant parameters for network registration are analysed. This is the first

essential step before applications are able to use the network. The registration process

to the network within GSM-R is independent of the type of applications to be used later,

i.e. data or voice transmission.

• Connection establishment delay is the value of elapsed time between the

connection establishment request and the indication of a successful connection

establishment. The value shall not depend on user data rate of the bearer

service.

• The connection establishment error ratio rates the number of unsuccessful

connection establishment attempts to the total number of connection

establishment attempts. With regard to the operational QoS targets, the ETCS

infrastructure should be designed in such a way that at least two consecutive

connection setup attempts are possible (recommended prerequisite for the ETCS

infrastructure).

The following parameters are related to data transmission over the established

connection.

• The Transfer delay is defined as a value of elapsed time between the request for

transfer of a user data block and the indication of successfully transferred end-

to-end user data block.

• The connection loss rate is specified as the number of unintentionally released

connections per cumulative connection time.



• A transmission interference period TTI is the period during the data transmission

phase of an existing connection in which, caused by the bearer service, no error-

free transmission of user data units of 30 bytes is possible. An error-free period

shall follow every transmission interference period to re-transmit user data units

in error (e.g. wrong or lost) and user data units waiting to be served.

• The GSM-R network registration delay is a defined value of elapsed time from

the request for registration to successful registration. GSM-R network

registration delays >40s are evaluated as registration errors.

All these specified connection parameters form the QoS vector for circuit-switched data

connections in ETCS via GSM-R.

In the future, however, there will be a paradigm shift in data transmission. These

parameters will then no longer be applicable for next generation railway communication

networks (e.g. 4G/5G) and it is necessary to define other measurable characteristics.

QoS values for packet-based transmission technologies are already specified and in use.

These parameters concern the GPRS extension of the GSM-R. The following section

explains this extension and the quality of service expectations and definitions.

3.7.2 Packet Core IP network QoS Management

This sub-section introduces existing Quality of Service definition and requirements of

the Packet Core IP network (GPRS). The purpose is to provide principles for QoS

measures in PS-Mode. The basic need is to agree on a QoS profile that enables railway

communication via a IP-based communication network. The values proposed focus on

the 3GPP specified network elements (e.g. SGSN, GGSN, RNC and BSC) and not the

backbone network.

Today, railways and infrastructure managers are already enabled to use IP based GSM-

R enhancement GPRS/EGPRS to realise different operational services. Also ETCS over

GPRS/EGPRS is introduced.

QoS management includes methods to negotiate the quality to be provided, to prioritize

particular connections and to guarantee certain performance classes of higher priority

data flows at the expense of lower priority data flows.

However, QoS mechanisms allow infrastructure operators to realise the operation of

ETCS in PS-mode and other application at the same time.

Various QoS mechanisms are used along the end-to-end connection and it is necessary

to coordinate QoS management between all network segments. For example, in an

external IP network, differentiated services etc. can be implemented, which can also be

used in the Packet Core Network. In the GPRS/EGPRS network, the Gateway GPRS

Support Node (GGSN) can use QoS attributes to configure the differentiated edge

functionality to enable cooperation between the GPRS/EGPRS and the external IP-based

data network.

The concept of GPRS/EGPRS-QoS architecture was already standardized in 3GPP release

97/98. A QoS profile for a data transfer session between mobile phone and network can

be negotiated. The QoS concept in 3GPP Release 99 introduced a new set of QoS

parameters. Four new traffic classes have been introduced to differentiate between the

various service characteristics:

• Conversational traffic class is meant for services sensitive to delay and delay

variations.



• Streaming class can compensate delay variations with the use of buffering

mechanisms.

• Interactive class is meant for applications that are sensitive to delay but less

sensitive to delay variations.

• Background class, low priority data transmission.

The requirements on reliability in interactive and background class are higher than in

conversational and streaming. The ranking between the four traffic classes is obvious,

background data flows have the lowest priority and will have less resources assigned

than conversational or streaming or interactive.

3GPP has specified a QoS concept and a QoS architecture for IP based networks. The

choice of QoS parameters is an important part of the QoS concept. The traffic class is

probably the most important QoS parameter. This parameter type divides the traffic

into distinct traffic classes, according to how delay sensitive typical services are.

All QoS parameters together form the so-called QoS profile. QoS profiles are associated

with each PDP context and define the characteristics of the connection through the

mobile network. The QoS characteristics affect the parameters in the radio network and

policing/shaping functions in the core network.

The QoS profile resides in the home PLMN HLR. QoS parameter values also work in a

multi-operator environment, which could also become relevant for the railway sector in

the future, if NaaS paradigm also applies to it. The QoS profile is defined per end-user

and per APN, that means a single end-user may have a separate QoS profile.

3GPP has only specified a model for the traffic classes and the other QoS parameters.

However, the detailed implementation is not described in the specifications and actually

vary from network vendor to vendor. The QoS parameters also have to work in a multi-

vendor environment.

3.7.2.1 QoS PARAMETER in Packet Core IP network

In this section an overview and description for QoS parameters in PS-Mode will be

given. The description includes the definition and the resulting effect of the parameter.

• Traffic class

The traffic class is an important QoS parameter. The traffic class parameter

maps different services onto different bearers so that the service requirements

can be met. The distinguish into specific traffic classes are made according to

how delay sensitive typical services are. The conversational class is the most

delay sensitive traffic class and the background class the least sensitive.

o Interactive traffic class

The idea behind the interactive class is to enable prioritisation between end-

users or services. Prioritisation does not offer any guarantees in form of bit

rate or delay. Instead a higher priority offers a higher portion of the available

resources in congestion situations.

o The background traffic

The background traffic class is the least delay sensitive traffic class and has

the lowest priority of all traffic.



• Delivery order

The delivery order parameter indicates whether the bearer should provide in-

sequence delivery of Service Data Units (SDU) or not. The specifications indicate

a coupling to the reliability of the bearer. Using the delivery order is comparable

to guaranteeing the packet order in IP networks. In contrast to circuit-switched

connections, IP networks, in general, do not reorder packets or guarantee in-

sequence delivery of packets.

• Maximum bit rate (DL/UL)

Specifies the maximum allowed bit rate. In practice, the maximum bit rate

parameter defines the maximum bit rate for the mobile core network (CN). The

maximum value that can be used is of course limited by the bit rate the network

supports.

• Residual BER

Indicates the undetected bit error ratio in the delivered SDUs. If no error

detection is requested, residual bit error ratio indicates the bit error ratio in the

delivered SDUs. Generally speaking, the Residual BER parameter is used to

configure radio interface protocols, algorithms and error detection coding.

The reliability class maps to residual BER, delivery of erroneous SDUs and SDU

error ratio in QoS parameters. The recommended value for residual BER is

therefore 10-5 for background and interactive classes.

• SDU error ratio

Indicates the fraction of SDUs lost or detected as erroneous. SDU error ratio is

defined only for conforming traffic. For example, traffic that exceeds the

maximum bit rate and is hence dropped is not included in the SDU error ratio.

By reserving resources, SDU error ratio performance is independent of the

loading conditions, whereas without reserved resources, SDU error ratio is used

as target value.

General, the SDU error ratio is used to configure the radio interface protocols,

algorithms and error detection schemes.

• Traffic handling priority (THP)

The THP parameter is only specified for the interactive class and enables

prioritisation between bearers, which in turn enables service prioritisation

capabilities. THP specifies the relative importance for handling of traffic

belonging to a RAB compared to traffic belonging to other RABs. THP affects the

relative priority, which means that it affects the allocation of the bearers and the

retention of the bearer. In other words, it affects the operation of the packet

scheduler located in the RNC.

There are two different parameters that do the same prioritisation over the air

interface, precedence class (i.e. ARP) and THP (requires interactive traffic class)

in 3GPP Release 99 networks. The recommendation for priorities should be made

in a consistent way in network and it is recommended to use the same value for

the THP and ARP parameters for the interactive class.

• Allocation/Retention priority

The ARP parameter is a subscription parameter, which is not negotiated from the

mobile terminal. The priority is used for differentiating between bearers when

performing allocation and retention of a bearer. In situations where resources



are scarce, the relevant network elements can use the ARP to prioritise bearers

with a high ARP over bearers with a low ARP when performing admission control.

These key parameters describe the QoS characteristics for certain services within

transmission in an IP-based (E)GPRS network. The following section shows how these

values are defined quantitatively for railway communication.

3.7.3 ETCS QoS Profile for GPRS

ETCS operation shall make use of streaming traffic class according to ETSI TS 123 107.

The data transport within the ETCS application is delay sensitive. Simultaneous

operation of ETCS and non-ETCS applications may cause unexpected transfer delay to

ETCS if the QoS profile parameters are treated always as best effort. Therefor a higher

priority and stringent QoS requirements in ETCS data transmission is demanded. It is

strongly recommended to provide an enhanced HLR QoS profile to be used for ETCS, to

meet the most demanding requirements that the ETCS application could impose and to

meet the performance requirements of the ETCS application. Other applications should

be provided with lower priority QoS profiles.

Table 5: Selected parameter of ETCS QoS Profile (PS-Mode) {Ref UNISIG}

3GPP ETCS QoS profile

parameters

QoS

parameter

settings

SDU error ratio 10-4

Traffic handling priority (THP) 1

Allocation/Retention priority (ARP) 1

Maximum bitrate [kbps] 64

Guaranteed bit rate [kbps]

( Up- and Downlink)

4

The values in this table are sufficient to meet the most demanding requirements that

the ETCS application could impose and to meet the performance requirements of the

ETCS application. It is strongly recommended to provide the HLR QoS profile to be used

for ETCS. Other non-ETCS applications should be provided with lower priority QoS

profiles.

3.7.3.1 Packet Core QoS Management

To ensure that resources required for a specific service are available within IP Networks,

it is also necessary to perform resource management. Where the resources for the IP

bearer service to be managed are not owned by the GPRS/EGPRS network, the resource

management of those resources need to be performed through an interaction with the

external network.

Interworking can be realised by packet marking or labelling along the flow path using

implemented standard QoS methods of IP networks e.g. DiffServ or MPLS (see section

4.1). DiffServ functionality classify packets of aggregated flows or "classes", based on

the DiffServ code point (DSCP) in the packet's IP header. DSCP (IETF RFC 2474) shall

be used to guarantee the interoperability between the different network types. The



DiffServ function shall be aligned on the basis of PDP Context QoS parameters that a

user data packet between OBU and RBC contains QoS performance marking.

3.8 Conclusion on Requirements

Existing definitions and requirements for QoS measurements of the communication

connections within railway domain are clearly specified. However, the standardised QoS

connection values of the UNISIG subsets for the ETCS data connections are linked to

the existing GSM-R system definitions. The defined parameters refer to circuit-switched

connections or packet-based transmission with the GPRS/EDGE extension of the 2G

generation system. These definitions are valid and determine the quality of service and

network requirements to provide the required operational performance.

With the knowledge of which railway specific functions are using communication

services in the railway system and which requirements are set for characteristics of the

services and the transmission channel itself, further analyses on future technologies can

be carried out.

The Table 6 shows in detail all requirements on Quality of Service parameters regarding

the mobile network from the EIRENE and references the corresponding values.

For future communication systems, however, it will be necessary to define other QoS

characteristics. The parameters defined so far are no longer applicable in the new

networks or can be renewed by a much more stringent design. 4G and 5G have

powerful implementations to enable different QoS approaches for various applications.

In the future, these methods will monitor and influence the transmission quality of data

and voice connections to a much greater extent.

Especially with the focus on the main parameters of different key services within the

railway communication (Singalling, Critical data, Critical voice, Critical Video and

Passenger connectivity services) a QoS evaluation is mandatory.

In the following chapters we will discuss the basic principles of QoS in IP-based

networks and their derived implementations in current mobile networks. Novel

approaches are explained in detail and conclusions are drawn as to how the use of

these methods can influence the railway communications system of the future.

Functions ERTMS

Specification Ref

ERTMS Functional Description

Network configuration - Coverage and performance

EIRENE-FRSv7 3.2.2

The level of coverage should be at least 95% of the time over 95% of the designated coverage area for a radio installed in a vehicle with an external antenna. (O)

Network configuration - Coverage and performance

EIRENE-FRSv7 3.2.4

The communication system shall provide communications for mobiles when stationary and when travelling at speeds up to the maximum allowable line speed or 500 km/h, whichever is the lower. (M)

Network configuration - Call set-up time requirement

EIRENE-FRSv7 3.4.2

The required call set-up times shall be achieved in 95% of cases. (M)


EIRENE-FRSv7 3.4.3

Call set-up times for 99% of cases shall not be more than 1.5 times the required call set-up time. (M)


EIRENE-FRSv7 3.4.4

Set-up times shall include the time required for any translation of functional numbers internal to the IP communication system. (M)

Quality of Service requirements

SS-093 v230 6.3.1.5

The network shall provide a Quality of Service for ETCS data transfer that is at least as good as listed below. The parameters are valid for one end-to-end connection for one train running under all operational conditions.




SS-093 v230 6.3.1.6

The required QoS parameters shall not depend on network load.


SS-093 v230 6.3.1.7

These performance figures reflect railway operational targets [EEIG 04E117].


SS-093 v230 6.3.1.8

QoS requirements are specified independently of the method of measurement (refer to [O-2475] for specification of testing).


SS-093 v230 6.3.1.11

Given the performance constraints of GSM-R, pre-conditions may be necessary to meet the railway operational targets of [EEIG 04E117]. If different operational QoS targets are required, then other pre-conditions on ETCS application may be necessary. Such a case is not covered by this specification and this aspect of ETCS System Performance becomes the responsibility of whoever specifies different operational targets.


SS-093 v230 6.3.2.1

Connection establishment delay is defined as: Value of elapsed time between the connection establishment request and the indication of successful connection establishment.


SS-093 v230 6.3.2.2

In case of mobile originated calls, the delay is defined between the request by command ATD and indication by the later of the two events response CONNECT or transition of DCD to ON.

Quality of Service

requirements

SS-093 v230

6.3.2.3

The connection establishment delay of mobile originated calls

shall be <8.5s (95%), ≤ 10s (100%).


SS-093 v230 6.3.2.4

Delays >10s shall be evaluated as connection establishment errors.


SS-093 v230 6.3.2.5

The required connection establishment delay shall not depend on user data rate of the asynchronous bearer service.


SS-093 v230 6.3.2.6

The required connection establishment delay is not valid for location dependent addressing.


SS-093 v230 6.3.3.1

The Connection establishment error ratio is defined as: Ratio of the number of unsuccessful connection establishment attempts to the total number of connection establishment attempts.


SS-093 v230 6.3.3.2

“Unsuccessful connection establishment attempt” covers all possible types of connection establishment errors caused by end-to-end bearer service.


SS-093 v230 6.3.3.3

Connection establishment delays >10s shall be evaluated as connection establishment errors.


SS-093 v230 6.3.3.4

The GSM-R networks should be designed in such a way, that at least two consecutive connection establishment attempts will be possible (pre-condition on GSM-R networks), e.g. regarding GSM-R radio coverage related to maximal possible train speed.


SS-093 v230 6.3.3.5

If the operational QoS targets of [EEIG 04E117] are wanted, then the ETCS infrastructure should be designed in such a way, that at least two consecutive connection establishment attempts will be possible (Recommended pre-condition for ETCS infrastructure).


SS-093 v230 6.3.3.6

The connection establishment error ratio of mobile originated calls shall be <10-2 for each attempt.


SS-093 v230 6.3.4.1

The end-to-end transfer delay of a user data block is defined as: Value of elapsed time between the request for transfer of a user data block and the indication of successfully transferred end-to-end user data block


SS-093 v230 6.3.4.2

The delay is defined between the delivery of the first bit of the user data block at the service access point of transmitting side and the receiving of the last bit of the same user data block at the service access point of the receiving side.


SS-093 v230 6.3.4.3

The end-to-end transfer delay of a user data block of 30 bytes shall be ≤ 0.5s (99%).




SS-093 v230 6.3.5.1

The Connection loss rate is defined as: Number of connections released unintentionally per accumulated connection time.


SS-093 v230 6.3.5.2

The requirements for connection loss rate varies depending on ETCS system variables such as T_NVCONTACT and the possible train reactions after connection loss (see section 10.5).


SS-093 v230 6.3.5.3

If the operational QoS-targets of [EEIG 04E117] are wanted, then the ETCS infrastructure should be designed in such a way, that at least the following conditions are fulfilled (Recommended pre-condition for ETCS infrastructure): • T_NVCONTACT ≥ 41s and • M_NVCONTACT different to train trip and • a new MA reach the OBU before standstill.


SS-093 v230 6.3.5.4

If the connection establishment error ratio is <10-2, then the connection loss rate shall be <10-2/h.


SS-093 v230 6.3.6.1

A transmission interference period TTI is the period during the data transmission phase of an existing connection in which, caused by the bearer service, no error-free transmission of user data units of 30 bytes is possible.


SS-093 v230 6.3.6.2

A transmission interference happens, if the received data units of 30 bytes deviate partially or completely from the associated transmitted data units.


SS-093 v230 6.3.6.3

The transmission interference period shall be < 0.8s (95%), <1s (99%).


SS-093 v230 6.3.6.4

An error-free period shall follow every transmission interference period to re- transmit user data units in error (e.g. wrong or

lost) and user data units waiting to be served.


SS-093 v230 6.3.6.5

The error-free period shall be >20s (95%), >7s(99%).


SS-093 v230 6.3.7.1

The GSM-R network registration delay is defined as: Value of elapsed time from the request for registration to indication of successful registration by +CREG response.


SS-093 v230 6.3.7.2

The GSM-R network registration delay shall be ≤ 30s (95%), ≤ 35s (99%).


SS-093 v230 6.3.7.3

GSM-R network registration delays > 40 s are evaluated as registration errors.

Table 6: QoS requirements on railway communication systems (Extracted from EIRENE FRS)



4 QoS in IP-based Systems

In future different approaches to defining QoS requirements in railway specific

communication networks will certainly be necessary. The completely (end-to-end)

packet-based data transmission via modern IP networks makes this development

necessary. Within this chapter we will first analyse how QoS is implemented as standard

in IP networks, which paradigms and methods exist and which basic principles are also

used within the transmission networks. The applicability of these principles must be

examined in more detail.

Normally, all data packets in a network are treated equally according to the best-effort

principle. In a packet-oriented network, the individual data packets can travel at

different speeds and on different paths. As long as low-priority messages and data files

are mainly transferred, transmission problems rarely occur. However, when real-time

applications such as Voice over IP, video streaming or particularly critical services are

used, delays or packet losses have a negative effect on transmission characteristics

between subscribers. For example, by partially interrupted language or missing image

sequences in a video stream. In comparison, it is barely noticeable when a text

message arrives at the recipient a few seconds later.

A low bandwidth, poor transmission characteristics and different utilisation lead to the

discarding or delayed delivery of data packets. As a consequence, data transmission is

disrupted.

Because TCP/IP separates the application layer from the transmission layer and makes

it independent, no communication takes place between these layers. The transmission

systems are not able to distinguish between a voice packet and a normal data packet.

The OSI layer model ensures that the protocols work independently of each other on

the different layers. However, this approach causes problems in audio and video

transmission.

So-called QoS methods try to eliminate this deficiency and to mark data packets with

service classes that are assigned to certain applications. In this way, an attempt is

made to define service characteristics at application level and to pass them down

through the protocols. In the TCP/IP world, QoS describes the quality of a

communication service from the user's point of view. The network service quality is

often defined by the parameters bandwidth, delay, packet loss and jitter.

The network load influences the quality of the transmission. For example, how long it

takes for a data packet to reach the recipient. Therefore one tries to mark data

packages with appropriate service classes. Prioritized data packets are preferably

forwarded in routers or switches. However, this only makes sense if all network

components and subnetworks support the same traffic classes and priority rules. For

QoS to function, the necessary QoS mechanisms must be implemented along the entire

transmission path between the participants. Of course, this is only possible if the

network belongs to a single organisational unit, which is not the case on the Internet.

It is not enough to implement QoS features within the network architecture. Whoever

introduces QoS methods should take their measurability into account. Quality

improvements in the network should always be measured before and after. If

something is to be improved, it must be determined before doing so what and how it

can be improved. For this purpose, quality must be checked with suitable measuring

and monitoring tools. For example, the available bandwidth for certain applications

must be continuously monitored.

Criteria for the quality of the transmission are for example packet delays, packet loss

rate and jitter. Depending on the application, further quality characteristics must be

examined and measured.



4.1 Typical QoS implementation methods

Quality of Service implementation can be achieved through a variety of coordinated

methods. Some of them are:

• Prioritized transmission of certain data packets

• Connection-oriented protocol below the IP layer

• More bandwidth than required (oversizing the network)

• Reservation of bandwidth for specific applications

These basic methods and their technical backgrounds are examined and explained in

the following sub-chapters in more detail.

4.1.1 Oversizing of network and bandwidth

Formerly it was the practice not to implement dedicated QoS algorithms, but to provide

much more bandwidth than was practically necessary for the services within the

network. This approach only works if there is a too low bandwidth demand. However,

the bottlenecks along the entire transmission path must be taken into account. If the

bandwidth requirement increases over time, even more bandwidth must be made

available. An approach that means very high technical effort, especially with increasing

user counts. A priority differentiation between different services is not performed here.

If critical applications are used, this implementation approach is not suitable.

4.1.2 Reservation of bandwidth

In order to achieve a high QoS, it is common practice to reserve and guarantee the

available bandwidth for certain applications. Other applications are given lower priority

and then receive less bandwidth. One implementation approach of this method is the

Resource Reservation Protocol (RSVP). This makes it possible to reserve bandwidth for

specific applications. RSVP is a typical QoS measure.

When designing a data network that is also to be used for time-critical applications such

as Voice over IP or video transmission, the runtime of data packets must be kept as

short as possible. To achieve this, data packets containing language are preferably

processed during forwarding in network nodes (e.g. routers, switches). Mechanisms for

compliance with runtime variations are provided by the network. In the IP network, this

is done via the Resource Reservation Protocol (RSVP).

4.1.3 Prioritisation of data packets

The definition of specific traffic classes is necessary in order to prioritise certain data

packets. The traffic class is defined according to a fixed quality of service. Data packets

of a higher traffic class are then also transmitted with higher priority.

However, prioritisation only works where the traffic classes apply. If prioritized data

packets leave a special network type and enter other network architectures, other

traffic classes may apply here.



4.1.4 DiffServ - Differentiated Services

DiffServ is a standardised QoS method for prioritizing traffic for real-time applications

over IP. Each data packet is assigned to a specific traffic class. Data packets of a higher

traffic class are given preference over a lower traffic class. DiffServ is an IETF standard.

It is one of the class-based QoS mechanisms and is used on layer 3 of the OSI model as

a supplement to IP. It is a method for prioritizing data traffic for real-time applications

over IP. Each data packet is assigned to a traffic class. Transmitting data packets of a

higher traffic class are given higher priority over a lower traffic class. With DiffServ, the

sender classifies and marks the data packages. The routers on the way to the receiver

evaluate this mark.

The possibilities to define QoS in the IP header are very limited. DiffServ is a model to

give independent systems priorities for traffic control. The advantage: DiffServ does not

change the IP packet. Only the ToS field in the IP header is interpreted differently. The

ToS field in the IP header is therefore also called Differentiated Services Code Point

(DSCP).

As DSCP provides information about the QoS request for a packet, this functionality is a

basic principle in IP QoS management.

4.1.5 Jitter buffer

Jitter is the term used to describe the difference in packet runtimes between sender and

receiver. Runtime differences in the data packets are particularly negative for time-

critical data transmission in real-time applications (voice and video transmissions).

Jitter buffers are used to avoid differences in runtime. A jitter buffer can compensate for

these irregularities to a certain extent. It records all real-time data packets and returns

them in a smooth flow.

4.1.6 CoS - Classes of Service Class Application

Classes of Service defines different classes of specific data transfers to which

application-oriented data packets are assigned. Each class corresponds to a priority,

which is used to decide which data packets are to be transmitted preferentially. It

should be noted that the amount of data in the high traffic classes must be limited,

otherwise no transmission is possible on overloaded connections for low-priority data

packets. The implementation of CoS is usually made more difficult because different

CoS rules exist in the different networks of the network operators. Each network

operator sets its own definitions here.

4.1.7 Prioritisation and queuing

When designing a data network that can also be used for time-critical data

transmission, the runtime of the data packages must be kept as short as possible. To

achieve this, specific data packets with different priorities are processed. So-called

prioritisation and queuing mechanisms ensure this.

Weighted Fair Queuing (WFQ) is such a queuing method where small packet streams

are preferred. In this functional procedure, each priority has a guaranteed minimum

bandwidth. WFQ distributes the available bandwidth dynamically among the various

data streams. This prioritisation mechanism is used directly in network core elements,

routers or Layer 3 switches. This gives voice or video data priority when it is

transmitted through the IP network.



4.2 Summary

Quality of Service is a method of controlling the data traffic of networks with the aim of

ensuring that data from certain services are delivered to the receiver according to

specified quality parameters. QoS procedures ensure a higher level of network

reliability.

The introduced basic implementation strategies within IP networks will also be applied

to QoS approaches within next generation mobile networks. They serve as a basis for

implementing powerful QoS frameworks in 4G/5G networks. This enables network

providers to implement and offer differentiated QoS strategies.

In the next chapter, the QoS implementations of the mobile radio standards will be

examined in more detail. The basic paradigms and performance expectations for the

control of the connection quality are shown, as well as the suitability for future railway

communication are indicated.



5 QoS within public mobile radio networks

5.1 QoS implementation in mobile technology sector

Quality of Service has become an important part of network planning and design when

deploying public wireless networks for data and voice services. There are public

subscribers which are using mobile radio services for critical operations and furthermore

there are subscribers who just want to use broadband internet with low latencies.

One of the future trends in next-generation solutions for communication in the railway

sector is the use of commercial 4G (and later 5G) networks. The MISTRAL project deals

with different scenarios and approaches to implement a NaaS paradigm for railway

communication networks. But will these 4G/5G networks are able to offer the high

service availability and high quality of service offered by existing standardized

technologies such as GSM-R?

This chapter focuses on the functions for prioritizing data connection, one of the key

criteria for high service quality. Within this chapter the QoS frameworks of 4G and 5G

networks are introduced. Current narrowband systems already offer versatile

prioritisation mechanisms.

5.1.1 Requirements on high service availability

In general there are several core features that make a mobile network compatible with

critical communications requirements. These include the following:

• High availability and reliability

The network must be designed, implemented and maintained with the aim of

high availability and reliability. Typical methods are additional, redundant base

stations to cover public safety and improve resistance through rigid single-point

of failure analysis, including power supply to radio sites (cover radio access,

transmission, core elements, terminals and applications)

• Prioritising public safety users

The priorities of the network must be designed to provide critical users with

radio and other network resources in all situations. In practice, this means giving

them higher priorities than consumers or business users.

• Prioritisation of traffic classes

Mission Critical users have different demands on the handling of means of

transport, so that users can have different priority levels for different

applications: different applications, such as Push-To-Talk (PTT) voice services,

time-critical data queries or video transmission demands higher different

prioritisation levels

• Management in special conditions

Under extreme conditions, extremely high traffic volumes can occur in networks

that go far beyond the normal level. These situations may be caused by

accidents or disasters. Exceptional circumstances are naturally unpredictable and

difficult to plan. Therefore, the networks must be able to adapt very quickly to

the extraordinarily high mission-critical load.



5.2 QoS mechanisms offered by 4G

Mobile broadband IP communication for mission-critical users can be provided with 4G

(LTE) technology, standardized by 3GPP and implemented by telecom providers.

The time lines of development and standardization of different recent and future

telecommunication standards are considered in MISTRAL D4.1. Furthermore, the

document provides a comprehensive review of current requirements and performance

aspects of railway communication systems for main-line railway domain. Possible future

railway communication technology candidates and recent trends have been analysed

there.

The technology provides QoS functions that are able to set priorities and traffic

management to certain users. Today, 3GPP begins work on the 5G standard.

Development is expected to take several years, but the first high-level architectural

concepts are already taking shape.

The 4G high-level architecture includes user equipment (UE), wireless access, E-UTRAN

and core network elements. It also supports collaboration with 2G (GERAN) and 3G

(UTRAN) network access.

The approach of QoS definitions in 4G is based on so called bearers. A 4G bearer is a

specific transmission mode via the infrastructure and radio interface with a pre-defined

capacity, latency time and packet loss. Depending on the transmission requirements, a

specific bearer can be assigned either dynamically or statically. When a terminal

connects to the network, it always receives a static default owner. Additional dedicated

carriers may also be set up on the basis of the subscription or added later.

Especially for mission-critical communications, it is mandatory that the communication

service itself remains available even if the network or parts of it are congested. Within

the 4G standard a set of tools for managing QoS and prioritisation for specific

subscribers and users is specified.

Three main functionalities regarding QoS are realized within this toolkit: Access Class

Barring, Allocation and Retention Priority and QoS Class Identifier. These functions are

first introduced and described in more detail below and then the implementation of the

methods in the 4G network is examined in more depth.

5.2.1 Access Class Barring (ACB)

The Access class barring function is used to prioritise different terminal classes in the

radio interface when connecting to the network. If the wireless interface is massively

overloaded, a terminal may not even be able to give the network its identity or the

status of its request caused by channel interference of other devices.

If such a state is detected, a base station can block certain classes of terminals.

Different Access Classes (AC) are defined with values from 0 to 15. All consumer

terminals have an access class from AC0 to AC9, and the terminals for public safety can

also be equipped with AC14 (emergency) or AC12 (security). Consumer terminals that

make an emergency call can also have AC10.

Only terminals with AC12/AC14 and terminals that attempt a public emergency call can

access the network. The other terminals are blocked either for a certain period of time.

5.2.2 Allocation and Retention Priority (ARP)

The Prioritisation of data transfer is an important function block for QoS control.

Prioritisation in bearer admission control for attached terminals using ARP has three

components:

1. Priority (1-15) where 1 is the highest value. (public safety may use values 1-8)

2. Pre-emption capability indicator (PCI)



3. Pre-emption vulnerability indicator (PVI)

Allocation and Retention Priority is part of QoS profile definition within the Home

Subscriber Server (HSS) for the default bearer. ARP values are used for deciding

whether a bearer can be admitted or pre-empted if there is insufficient transmission

capacity available. ARP is not used by schedulers or packet queue management.

5.2.3 QoS Class Identifier (QCI)

These methods allow prioritisation in scheduling and queuing of data flows, with

specified values of 1-254. Each value is associated with three attributes: Priority,

Packet delay budget, Packet error loss. Possible QCI values between 1-127 are reserved

for standardisation. 3GPP has already standardised some of these for different

application categories and requirements (see Table 27). QCI 9 is used for the best

effort traffic and most of the current commercial user data flows are classified for QCI

9.

More detailed considerations are given in section 5.2.4.

For public safety services QCI values have been standardised starting within 3GPP

rel.12 (compare chapter 5.5):

• QCI 65 for Guaranteed Bit Rate (GBR) bearers used for the mission critical user

plane (e.g. MCPTT voice),

• QCI 69 for Non-guaranteed Bit Rate bearers (NGBR) used for mission critical

signalling,

• QCI 70 for Non-guaranteed Bit Rate bearers used for mission critical data.

The 4G QoS toolbox implemented on the network side can be utilised to prioritise

specific user classes (e.g. mission-critical services) and data transmission streams in

LTE networks. It makes it possible to flexibly and extensively control QoS functionalities

in the 4G network.

5.2.4 4G QoS implementation

Service provider should be able to differentiate between subscribers and provide QoS

requirements depending on the subscriber level. That implies that the service provider

should have knowledge about which type of subscriber is a certain user and which

services requirements are demanded, that, will allow to assign properly the radio

resources.

The LTE network classifies user traffic in different service data flow (SDF) each of them

having different QoS classes based on the type of service that is being provided. SDFs

are delivered through EPS bearers to their destination, EPS bearers can be seen as

virtual connections with a specific QoS service characteristic.



Figure 4: SDF and EPS Bearers {Ref [22]}

An SDF refers to a group of IP flows associated with a service that a user is using, and

a EPS bearer refers to IP flows of aggregated SDFs that have the same QoS class.

There are specific packets filters that are preconfigured by network operators in

accordance with the policy and classified in 5 values: source IP, destination IP, source

port, destination port and protocol ID. All SDF with the same QoS requirement are

aggregated in a EPS bearer with the same QoS class and mapped by the P-GW, and

then delivered to the UE or vice versa.

Different services have different QoS classes. Appropriate QoS policies (e.g. priority,

bandwidth control, etc.) are applied to these SDFs before they are delivered to the UE.

There are two types of EPS bearer (see Figure 5): default bearer and dedicated bearer.

When a UE attaches to the LTE network a default EPS bearer is assigned with a

standard QoS requirements, for example internet. If the UE starts a service that the

bearer cannot identify, a new EPS bearer is created on demand, the maximum number

of EPS that a UE can have is 11. The default bearer lasts until the UE is detached from

the network and there is one per each PDN that the UE is connected. When the UE

attach to the network the HSS provide the subscribe information to the MME related to

the UE and selects a P-GW for data flow and activates the EPS bearer depending on the

subscribed QoS.

Figure 4 shows EPS bearers and SDFs when downlink IP flows are delivered to a UE

through EPS. The IP flows arriving at a P-GW through a PDN are filtered to SDFs

templates (kind of packet filters). In the figure, IP flows 1, 2 and 3 are filtered to SDFs

1, 2 and 3, respectively while IP flows 4 and 5 are filtered to SDF 4. Different QoS

policies are applied to each SDF and then the SDFs are mapped to EPS bearers as

classified by using Traffic Flow Template (TFT). SDFs 1 and 2 are mapped to the default

bearer and SDFs 3 and 4 are mapped to the dedicated bearer, all destined to the UE.

Upon arrival at the UE, the IP flows are all sent to their destination applications.

In the LTE network QoS parameters are defined both in service level and bearer level.

SDF aggregate refers to a group of SDFs which have the same QCI (QoS class

identifier) and ARP (Allocation and Retention Priority) and belongs to the same EPS

session. QCI and ARP are the basic QoS parameters applied to SDF and EPS.



Figure 5: 4G/5G Bearer QoS concept (TUD)

QCI serves as a reference that indicates the performance characteristics of EPS and

SDF. There are as well GBR, MBR and AMBR parameters that specify the bandwidth

utilisation. The QCI values 1 to 9, indicates nine different QoS performance

characteristics of each IP packet, i.e. packet delay, packet error rate. Maximum Bit Rate

(MBR) and Guaranteed Bit Rate (GBR) indicates Bandwidth. AMBR (Aggregated

Maximum Bit Rate) indicates the maximum total bandwidth for multiple EPS bandwidth

allocation. There are two types of AMBR: APN-AMBR, the maximum bandwidth that can

be shared by all non-GBR bearers in a PDN, and UE-AMBR, the maximum bandwidth

that can be shared in a UE. A UE can be connected to more than one PDN, in which

case the total APN-AMBR of all PDNs cannot exceed the UE-AMBR.

LTE has a big granularity and is able to recognize and differentiate specific types of

traffics. The entity which provides this characteristic is the Policy and Charging Rules

Function (PCRF) and enables the network core to shape bandwidth and implement QoS

manage resource allocation.

The 3GPP has defined a series of standardized QCI types, which are summarized in

Table 7.

QCI Resource

Type

Priority Packet

Delay

Budget

Packet

Error

Loss

Rate

Services

1 GBR 2 100 ms 10-2 Conversational voice

2 4 150 ms 10-3 Conversational Video

3 3 50 ms 10-3 Real time Gaming

4 5 300 ms 10-5 Non-conversational video

(Buffered Streaming)

5 Non-GBR 1 100 ms 10-5 IMS Signalling

6 6 300 ms 10-5 Video (Buffered streaming) TCP

based services (www, E-mail)

7 7 100 ms 10-3 Voice, Video (live streaming)

8 8 300 ms 10-6 Video, TCP based services

(iwww, E-Mail, ftp) 9 9 300 ms

Table 7: Pre-defined Quality class indicators in LTE (3GPP) {REF [11]}



This list of QCI values contains standardized values for a typical implementation in LTE.

Additional QoS parameter vectors can be defined and implemented for special

applications. 3GPP has already issued a recommendation for QCI definitions especially

for Mission Critical Services. Table 8 extends the above table with introduced Mission

Critical specific values. An overview of all pre-defined QCI values and characteristics can

be found in Table 27.

QCI Resource

Type

Priority Packet

Delay

Budget

Packet

Error

Loss

Rate

Services

65 GBR 0.7 75ms 10-2 Mission Critical user plane Push

To Talk voice (e.g., MCPTT)

66 2 100ms 10-2 Non-Mission-Critical user plane

Push To Talk voice

67 1.5 100ms 10-3 Mission Critical Video user plane

69 Non-GBR 0.5 60ms 10-6 Mission Critical delay sensitive

signalling (e.g., MC-PTT

signalling, MC Video signalling)

70 5.5 200ms 10-6 Mission Critical Data (e.g.

example services are the same

as QCI 6/8/9)

79 6.5 50ms 10-2 V2X messages

Table 8: Quality class indicators for Mission Critical service (3GPP) {REF [11]}

The exemplary expansion of the QCIs for Mission Critical Services is a decisive

advantage for the later implementability of the functions in the 5G network

infrastructure. The more stringent QoS requirements of railway-specific applications can

only be met with this. Simultaneously, the table shows exemplarily how adaptable the

QoS management is within the 3GPP specifications.

QCIs 65 and 69 are particularly interesting for use in the railway domain. For the

transmission of ETCS telegrams (railway signalling) a short latency and extremely low

packet error rates are expected. The data rate, on the other hand, is not primarily

relevant due to small transmission capacities. This is achieved by class 69.

Voice communication also requires low latencies, as defined in QCI 65. On the other

hand, the error rate of the package does not necessarily have to be low, as error-

tolerant methods are used by the speech codec. In this context, the bandwidth is of

greater importance. The higher the available bandwidth, the more powerful and better

quality codecs can be used. For uninterrupted voice communication, it is also necessary

to guarantee this bandwidth.

5.2.5 Requirements and Features of EPS security:

The following list provides an overview of implemented features in the 4G/LTE that refer

to the security aspects of the connection and the connection setup:

• EPS provided a high level of security.

• EPS should provide protection against threats and attacks.



• EPS shall support authenticity of information between the terminal and the

network.

• Appropriate traffic protection measures should be provided.

• EPS shall ensure that unauthorized users cannot establish communications

through the system.

• EPS shall allow a network to hide its internal structure from the terminal.

• Security policies shall be under home operator control.

• Security solutions should not interfere with service delivery or handovers in a

way noticeable by end users.

• EPS shall provide support for lawful interception.

• 3GPP Rel-99 (or newer) USIM is required for authentication of the user towards

EPS.

• USIM shall not be required for re-authentication in handovers (or other changes)

between EPS and other 3GPP systems, unless requested by the operator.

• EPS shall support IP Multimedia Subsystem (IMS) emergency calls (ECs).

• EPS shall provide several appropriate levels of user privacy for communication,

location and identity.

• Communication contents, origin and destination shall be protected against

disclosure to unauthorized parties.

• EPS shall be able to hide user identities from unauthorized parties.

• EPS shall be able to hide user location from unauthorized parties, including

another party with which the user is communicating.

5.2.6 LTE Security architecture

The EPS must be able to interwork with legacy systems, so these adaptations have to

be done in a backward-compatible way. In addition to the adaptation of legacy systems,

new extensions and enhancements have been introduced in the EPS security

architecture.

ASME (Access Security Management Entity) is an entity that receives top-level key(s),

from an HSS, to be used in an access network. In EPS an MME takes the role of ASME

and generates a KASME that is used as the top-level key to be used in the access

network. The MME, on behalf of an HSS, conducts mutual authentication with a UE

using KASME.

After the identification of the UE, the Mobility Management Entity in the serving network

fetches authentication data from the home network. Next the MME triggers the

Authentication and key agreement (AKA) protocol with the UE. The result is that MME

and the UE share a secret key, KASME.



Figure 6: EPS security Architecture {Ref [21]}

Now the MME and the UE are able to derive further keys from the KASME. Two derived

keys are used for confidentiality and integrity protection of the signalling data between

the MME and the UE. This is represented in the figure by the arrow with ‘Non-Access

Stratum (NAS) protection’.

Another derived key is transported to the base station (evolved NodeB, eNB). From this

key three more keys in the base station and in the UE are derived. Two of these keys

are used for confidentiality and integrity protection of the signalling data between the

eNB and the UE – see the arrow with ‘AS protection’ (Access Stratum). AS security is

purposed to ensure secure delivery of data between an UE and an eNB over radio links.

The third key is used for confidentiality protection of the user plane (UP) data between

the eNB and the UE – see the arrow with ‘UP encryption’.

There is also confidentiality and integrity protection for the signalling and user data

carried over the interface between the base station and the core network (EPC). The

signalling data is transferred between the UE and the MME over the S1-MME interface

while the user data is transferred between the UE and the Serving Gateway (S-GW)

over the S1-U interface. If cryptographic protection is applied to the S1-interfaces, the

protection mechanism used is IPsec.

The X2-interface between two base stations is similarly protected by IPsec with keys

that are not specific to the UE in case cryptographic protection is applied.

Confidentiality and integrity protection mechanisms are embedded in the protocol stack

of EPS. Figure 7 shows the relevant signalling plane protocols.



Figure 7: EPS signalling plane protection {Ref [21]}

Figure 8: EPS user plane protection {Ref [21]}

For signalling and user data, the confidentiality protection between the UE and the base

station is in charge of Packet Data Convergence Protocol (PDCP). As seen in the Figure

8 there is no integrity protection for user data between eNB and UE. IPsec is used on

both signalling and user data on X2 and S1 interfaces.

The main challenges regarding security of the transmission are in the coding and

integrity protection of vital railway application messages (e.g. ETCS) and user data.

Due to the IP basis of the LTE network, the security risks are directly associated with

the implementation of powerful security protocols for secure IP transport. Mechanisms

for mutual authentication of the devices and the network, and for encryption and

verification of message integrity in data communication between Terminal and e-

NodeB. The IMS architecture provides mechanisms for secure IP Data transport and SIP

signalling are also encrypted.



5.3 QoS mechanisms offered by 5G

3GPP is constantly working on the standardisation of 5G. The high-level system

architecture is already formulated in the normative standard draft and includes the QoS

concept. The 5G QoS concept will be flow-based. Packets are classified and marked with

QoS Flow Identifier (QFI). There will be two types of flows: one with standardized QoS

profiles and the other with operator-specific QoS profiles. For the first one, only the QFI

value is used in the network. For the latter one, QoS attributes are also signalled

between the network elements. The 5G QoS flows are mapped in the Access Network to

Data Radio Bearers (DRBs), unlike 4G where the mapping is 1:1 between EPC and radio

bearers. Anyway, the 3GPP work on the 5G standard is expected to refine the QoS

concept over the next few years.

5.3.1 QoS Model – general overview

The 5G QoS model supports a QoS flow based framework. This approach provides both

QoS flows that require guaranteed flow bit rate and QoS flows that do not require

guaranteed flow bit rate. The 5G QoS model also features reflective QoS, where no

explicit signaling is needed for the configuring of QoS rules – the network decides which

QoS characteristics are applied.

Basically, the QoS flow is the finest granularity of QoS differentiation in the PDU

session. A QoS Flow ID (QFI) is used to identify a QoS flow in the 5G system. User

Plane traffic with the same QFI within a PDU session receives the same traffic

forwarding treatment (e.g. scheduling, admission threshold). It can be applied to PDUs

with different types of payload, i.e. IP packets, unstructured PDUs and Ethernet frames.

The QFI shall be unique within a PDU session.

5.3.2 Quality Requirements in 5G Networks

During the evolution of QoS management mechanism in 3GPP (GSM/UMTS/LTE)

networks there was a migration from QoS management at the user equipment level to

the QoS management at the network level. This approach to QoS management will be

maintained in 5G networks as well.

QoS management mechanisms in 5G networks should provide video and VoIP traffic

prioritisation towards Web-search traffic and other applications tolerant to quality. The

service of streaming video transfer without buffering is very sensitive to network delay,

so one of the most important parameters that determine QoS requirements is the total

packet delay budget (PDB), which is formed on the RAN air interface, and is treated as

the maximum packet delay with a confidence level of 98%.

5.4 Architectural and procedural basics

At this sub-section the architecture of 4G, especially the implemented services for voice

transmission and data prioritisation will be examined. The aim of these studies is to

proof whether existing railway applications (voice functions, with focus on critical

services, e.g. railway emergency calls) can be implemented within the next standards.

Railway applications demand specific functionalities as introduced in section 3.3. The

ASCI enhancements are one example for this. 4G/5G network features and mechanisms

to implement the railway functionalities are introduced and summarized within this sub-

chapter.



5.4.1 Voice Services within 4G IP networks

The ASCI enhancements within GSM-R networks for specific railway voice services are

core functionalities for railway operation. The voice service capabilities within the 4G

3GPP standards are major challenges that must be analysed.

The technological solutions for delivering voice over LTE are based on the IP Multimedia

Subsystem (IMS), with the implementation known as Voice Profile for Voice over LTE

(VoLTE). The main characteristics of this solution and the advantages and

disadvantages from the railway point of view are discussed. Table 9 gives an overview

of the main expected advantages of the VoLTE for railway applications.

Table 9: VoLTE capabilities overview

VoLTE capability

Seamless Continuity of Voice Services Single Radio-Voice Call Continuity

Mechanisms

Support of IMS Based Service Priority and QoS handling of different Voice

types (i.e. staff communication, RECs)

Support of 4G/5G QoS mechanisms

Specific qualification for railway

applications

Supports transparent handover between LTE

and GSM/UMTS for migration phase

Provides end-to-end IP services

Supports simultaneous voice / data

transmission

Low latency

Short Call Setup Times

Compared to the 2G or 3G network capabilities used up to now for voice telephony,

VoLTE offers significant improvements such as reduced power consumption, improved

voice quality and faster connection setup. In contrast to GSM, voice communication via

VoLTE is packet-based. VoLTE is distinguished above all by its better voice quality and

faster call set-up. Usually the AMR-WB codec commonly is used, depending on the

network operator. The narrowband AMR-NB codec is also supported for compatibility

purposes.

Before the introduction of VoLTE, it was not possible to establish a standard voice

connection via the LTE network. The circuit-switched fall-back (CSFB) was introduced. If

the mobile network signals a call to the mobile phone, the modem of the device

switches from LTE to GSM in order to establish the circuit-switched call. This procedure

can be important in the future migration scenario between GSM-R and a successor

technology.

5.4.2 IP Multimedia Subsystem

The IP Multimedia System within 4G networks (IMS) is an IP-based architecture for

delivering multimedia services independently of the underlying access network. IMS

offers several functionalities, such as interworking with circuit-switched networks, user

roaming, and negotiation of QoS requirements.



The IMS functionalities are necessary for providing voice communication via 4G

networks. VoLTE defines a specific subset of the IMS functionalities required to provide

a standardized voice communication service over the LTE network.

The basics of the IMS are described in the "Technical Specifications" of the 3GPP

standardisation committees. The specifications of IMS can be found in 3GPP TS 23.228

and 3GPP TS 23.002 (overall architecture). IMS also forms the basis for the Next

Generation Network Release 1 described by ETSI.

IMS supports the following services:

• packet-switched connections between two or more subscribers,

• collaboration between the circuit-switching and packet-oriented domains,

• end-to-end point negotiation of service quality (QoS),

• service-based cost accounting,

• provision of the home network environment in foreign networks,

• support of different media types,

• fast and flexible creation of services through predefined service components

("service enabler"),

• services should be independent of the access network.

Figure 9: IMS architecture within LTE Evolved Packet Core (Spirent)

The standard describes how multimedia connections and services are controlled by an

IMS core network. Application servers provide the services via open interfaces to the

core network. Signalling, transport and security mechanisms were defined for this, but

not the services themselves. Today, IMS is a step towards the Next Generation Network

(NGN). IMS brings all communication services together on one technical platform to

enable versatile IP-based communication services.

IMS is based on SIP, the signalling protocol. The connection between the different

network types is created by so-called media gateways. The user can access services

and applications from any network. The difference between wired and wireless networks

disappears. This is known as "Seamless Mobility". In such a network, it no longer

matters which terminal device, which content is accessed or which services are used.



There will still be different networks, but they will only be based on the Internet

Protocol (IP).

The main challenge in the implementation are the unstructured services and systems.

On the one hand, there is the transmission of voice and SMS. On the other hand, data

services and combined voice and data services.

IMS actually consists of four layers:

• Application Layer (Service/Application Layer)

• Session Layer (IMS Layer)

• Transport Layer

• Access layer (terminals)

The aim of IMS is that the applications in the core network no longer communicate with

every end device, but only with the session layer, which acts as middleware. Another

advantage is that the user is no longer tied to a specific terminal device.

The core architecture of 3GPP IMS (see Figure 10) is described in the specification 3GPP

TS23.228. It describes various elements of the architecture.

• User Agent (UA)

• Call Session Control Function (CSCF)

• Home Subscriber Server (HSS)

• Application Server (AS)

• Media Gateway (MGW)

• Media Gateway Controller (MGC)

• Signalling Gateway (SGW)

Figure 10: IMS core elements (Spirent)

The IMS architecture simplifies infrastructure management. Network operators can

expand their range of services at any time without interfering with the network. The

basic functions are set up on a central server. These functions are required for a large



number of applications. This includes authentication, billing, QoS and registration.

Flexible access to various functions enables new services to be provided much faster.

5.4.2.1 IMS Signalling

The central element for the connection establishment of multimedia sessions is the

Session Initiation Protocol (SIP). It is a protocol for IP-based communication services

such as voice and video telephony or group calls. It does not matter whether it is a

voice or data connection.

SIP is a text-based protocol used by clients and servers to control their connections.

With SDP, media description, codec, ports and transmission direction are exchanged.

With RTP, the media streams are transmitted in real time. In parallel to RTP, RTCP is

used to exchange important control information about the RTP media stream between

client and server.

But before signalling starts, the User Agent must first establish a connection to a proxy

(P-CSCF). After that the User Agent has to register. The aim is to establish a unique

assignment between the unique public ID of the user and the user agent. The user is

always addressed using the public ID. While this is unique, the user's IP address can

always be different, or the user is registered in several places on the network at the

same time.

5.5 3GPP Mission Critical Communication Enhancements

The standardisation of current wireless technologies is an ongoing process that is

constantly being driven forward by the 3GPP standardisation initiative. In the recent

years, progress has been made in the definition of mission critical communication1,

which is particularly important in the railway sector.

Mission Critical Push To Talk (MCPTT) was the first development step of 3GPP Mission

Critical (MC) Services and functionalities. In Release 14 (2017), 3GPP added

supplementary MC Services and enhancements to its repertoire of standardized

applications, specifically:

• Enhancements to MCPTT,

• MCData,

• MCVideo,

• General framework which facilitates standardizing additional MC Services.

The Release 14 specification on MC Services required a large set of new protocol

additions and new security functionality. The introduced MC Services were split into

smaller, self-contained features. These MC Services introduced in Rel-14 offer stand-

alone functionality that enriches the existing base of services, so the providers don’t

have to wait for the completion of additional standardized functionality in Rel-15.

With the extension of the functionalities in MCCore and additional features introduced in

Release 16 (e.g. MCData and MCVideo enhancements), all necessary functional

requirements of railway communication are to be addressed for the first time.

A detailed list of selected Mission critical functionalities, that may be of special interest

for use in the railway communication, completed in Rel-13, Rel-14, Rel-15 and Rel-16 is

shown in Table 10:

1 http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1875-MC_SERVICES



Rel-13 MCPTT

(completed 2016)

Rel-14 MC Services

(completed 2017)

Rel-15 MC Services

(completed 2018)

Rel-16 MC

Services

(in progress)

User authentication and

service authorisation

User authentication

and service

authorisation

Enhanced MCPTT

group call setup

procedure with

MBMS bearer

MCCore Services

Common

Functionalities

Enhancements

Affiliation and de-

affiliation

Extended Location

Features

Enhanced Location

management,

information and

triggers

Enhancement of

MCPTT

(e.g. Enhanced

Broadcast group

call, Multiple

simultaneous

users)

Group calls on-network

and off-network (within

one system or multiple

systems, pre-arranged

or chat model, late

entry, broadcast group

calls, emergency group

calls)

(Dynamic) Group

Management

Interconnection

between 3GPP

defined MC systems

MCData additions

(e.g. Emergency

Alert, Enhanced

Status,

Accessing list of

deferred

communications)

MCPTT security

Group Call (including

emergency group

calls, imminent peril

group calls,

emergency alerts)

Interworking with

legacy systems

MCVideo additions

(e.g. Emergency

and imminent peril

private

communications,

Broadcast Group

Call)

Simultaneous sessions

for call

Transmission and

Reception Control

Enhanced handling of

MCPTT Emergency

Alerts

Pre-established sessions

Short Data Service

(SDS)

Enhanced Broadcast

group call

Location configuration,

reporting and triggering

MC Security

framework

Broadcast Group Call

Table 10: 3GPP Mission Critical services and enhancements in Release 13 to 16 (3GPP, TUD)

These extensions for mission critical communication introduced by 3GPP offer the

possibility to implement the stringent requirements of railway-specific data transmission

into the 4G/5G network. Only with the help of these additional functionalities it is

possible to handle the railway QoS requirements and also to perform the data

transmission over public commercial networks in a future NaaS scenario for railway

communication.



5.5.1 Quality of Service requirements for mission critical applications

As introduced within the functional requirements, in railways a number of commonly

used applications exchange information via the railway communication mobile network.

These applications comprises data- (e.g. Train Protection and Automation), voice- (e.g.

staff calls, calls between drivers and controllers) and video-applications (e.g. driver

CCTV). Each application type has a different quality of service requirement. A general

approach of QoS requirements for common types of applications (not railway specific)

can be found in [15]. This study covers, QoS definitions, Classification of applications

(real-time, non-real-time) and QoS metrics for different classes of applications.

3GPP is following a progressive definition of future network technologies that can

transmit mission critical data with the QoS definition ([10],[11]). The application that

transfers data within the networks is assigned to certain categories according their

demands on network resources.

A qualitative classification of the QoS characteristics for different applications is defined

in the following table.

Application

Category

Service Attribute Session

establishment

Session Loss

Rate Latency

peer to peer

Packet

Loss Rate

Voice Low

Normal

Normal

-

Critical Voice Low

Low

Immediate

-

Video Normal Low Normal -

Critical Video Low Low Immediate -

Very Critical

Data

Ultra-Low Ultra- Low Immediate -

Critical Data

(future

applications)

Low Ultra- Low Immediate -

Critical Data

(legacy

applications)

Normal Low Normal <10-2/h

Non-Critical

data

Normal Low Normal -

Messaging Best Effort Low Normal - Table 11: QoS categorisation for different application types (3GPP) {Ref [10]}

To ensure the required communication quality for a specific application demand, the

network requests the resources required for the communication service from the

underlying 3GPP transport.

The transport resources are characterized by latency, reliability, guaranteed bit

rate/unguaranteed bit rate and priority of the communication service. If no specific

resource characteristics are required for a particular communications service, the

mobile network can use a predefined standard. Each feature of the communication

service resource can be requested independently by the application.

As a result of the request the mobile network system can offer different values than

those requested, but which match the required QoS application categories (Table 11).

According to the 3GPP specification ([11]), a differentiation of the following application

categories for transmission services will be considered in the future:



• Voice

user to user or multiuser communication;

• Critical Voice

follows the voice conversational pattern but requires immediate session setup;

• Video

visual train remote control or observations purposes; Video requires low jitter;

• Critical Video

door monitoring by the Driver, passenger surveillance, driverless mode in urban

rail;

• Very critical data

for future rail applications;

• Critical data

follows the response pattern and requires high reliable transport. This category

comprises future and legacy applications e.g. ETCS;

• Non-Critical data

used for the exchange of railway system or communication relevant information;

requires high reliable transmission and preservation of the response pattern;

• Messaging

for the exchange of non-critical short information messages, recorded voice (for

example voicemail), data, pictures, video; requires reliable transmission.

To achieve the QoS applicable to each application category, specific priority levels are

required to differentiate communication priority. The priority handling of a

communication service includes the assignment of a priority to a communication and

the handling also includes the interruption of a running communication with lower

priority in order to enable an incoming communication with higher priority. The

appropriate used priority level depends on the user initiating the communication. The

communication can have the priority level selected by the user at setup or the priority

level is predefined at network registration.

In order to meet the different application characteristics such as real-time or critical

data, further quantitative specification is necessary. 3GPP recommends the following

values for the mapping of service quality for the specific categories (see Table 12).

Mapping the service attributes latency and reliability between the functional

requirements and the communication network system and their target values are

prerequisites for the implementation of QoS.

Service Attribute System

Requirement

(according 3GPP)

Service

Attribute value

Latency Ultra-Low ≤10ms

Low ≤100ms

Normal ≤500ms

Best Effort >500ms

Transport reliability - Packet Loss (%)

Ultra-Low 99.9999%

Low 99.9%

Normal 99%

Session

Establishment

Immediate <1s

Normal <3s (typical) Table 12: Quantitative Mapping of service and QoS attributes (3GPP) {Ref [10]}

The attributes are defined on the following basic aspects. Latency quantifies the end-to-

end user data transport delay between the involved communication entities and are

classified:

• Low: Delays harm the functioning of the application.



• Normal : Delays do not harm the sequence and progress of the application.

Reliability defines the amount of sent network layer packets, which are successfully

delivered to a given node within a specified time constraint, divided by the total number

of sent network layer packets. Two levels are to be taken into account:

• High: The packet loss at transport level is exceptional rare.

• Normal : The packet loss at transport level is seldom.

The Session Establishment time defines the time to initiate a voice or data

communication session with the application that is sufficient to perform the specific

railway operation.

• Immediate: A session is set up time critically <1s

• Normal : A typical session setup time does not harm the specific railway

application (typically <3s).

In order to meet the different application characteristics also for real-time applications

and critical data, further detailing is necessary. The requirements for ultra-low latency

and particularly ultra-high reliability are expected especially for mission-critical

applications.

5.5.2 Derived QoS from Future Railway Mobile Communication System

In 2012 the UIC set up the Future Rail Mobile Communications System (FRMCS)

project. The aim was to prepare the introduction of a successor of GSM-R. These first

steps started with an evaluation of the actual situation, included several studies on

railways’ needs and ended with the delivery of a first set of “User Requirements

Specification”.

The UIC driven FRMCS project and the 3GPP standardisation body work closely

together. The UIC is an international association of railway companies. Besides, the

3GPP works as a standardization body for communication technologies. The UNIFE

Unitel committee, which gathers the main suppliers of railway telecommunication

systems, is also involved within the activities about FRMCS specifications. Mobile

network operators are not participating in the UIC working groups.

The results of the FRMCS study are incorporated in the following standards and

recommendations. Within the FRS a set of technology independent user requirements

for the FRMCS are defined. The various inputs were received from globally railway

communities.

The technology independent user requirements for the future radio mobile

communications are defined in the form of individual application use cases. Each of

these applications has been defined to provide or support an identified communications

demand that is considered necessary for current and future railway operations.

These use cases are differentiated of the following railway application types:

• Critical Communication Applications,

• Performance Communication Applications,

• Business Communication Applications,

• Critical Support Applications.

Of particular interest are the generic approaches for QoS and critical support functions,

which are the prerequisites for the actual critical railway applications. In Table 13 the

main groups are named and briefly described.



Critical Support

Applications

Description

Assured Voice

Communication

Indication as soon as an end-to-end voice communication link is

broken or as long as the end-to-end communication link is active. Multi user talker

control

Limits the number of simultaneous talkers in a multi-user voice

communication and mitigates the risk of miscommunication. Role management

and presence

A user shall be able to register and deregister to one or more

functional identity/ies. Location services The system shall be able to store and provide the location of the

user(s) or devices. Authorisation of

communication

The system shall be configurable, so that access to voice and

data communications can be controlled QoS Class

Negotiation

The system shall be able to assign different QoS classes in order

to fulfil the level of communication quality required by the

applications. Safety application

key management

communication

Authentication of the source of the messages received as a

trusted source, and shall be able to detect corruption of the

messages received.

Assured data

communication

Indication to the users as soon as an end-to-end data

communication link is broken or as long as the end-to-end

communication link is active. Table 13: Overview of Critical Support Applications (FRMCS) {Ref [10]}

With the help of these predefined methods it is possible to introduce critical railway

applications also within 4G networks. These supporting methods can be implemented

after they have been incorporated into the 3GPP standard. The committees work closely

together.

Furthermore, FRMCS also provides a qualitative approach for the definition of a QoS

recommendation for the respective use cases. Table 14 shows a selected set of use

cases with different characteristics and compares the recommended QoS

characteristics.

Application Type Symmetry Up/Down

Latency Bandwidth Reliability Setup Train Speed

Voice

Communica

tion

Voice 50/50 Low Low High Normal High

Public

Emergency

Call

Voice 50/50 Low Low High Normal High

Railway

Emergency

Communica

tion

Voice 50/50 Low Low High Immediate High

ATO Data 50/50 Normal Low High Immediate High

Critical

Realt-time

Video

Data 95/5 Low High High Normal High

Wireless

internet for

passengers

Data 20/80 Normal High Normal Normal High

Table 14: QoS of different selected FRMCS application types (FRMCS) {Ref [10]}



In comparison with the findings of 3GPP-QoS analyses from Table 11 a qualitative

statement about the required bandwidth of the application, the maximum train speed

and the expected symmetry for the upload and download is also evaluated here. The

following values from Table 15 can be assigned to these qualitative aspects, which

generate a plausible service characteristic.

Table 15: Quantitative Mapping of additional service attributes {Ref [10]}

Service Attribute System

Requirement

Service

Attribute value

Bandwidth High 5000 kbit/s

Medium 500 kbit/s

Low 50 kbit/s

Very-Low 5 kbit/s

Train speed High >250 km/h (up to 500 km/h)

Normal >40 km/h

<250 km/h

Low <40 km/h

5.6 Summary

Quality of Service (QoS) has become an important part of network planning and design

when deploying 4G/5G networks for specific data and voice services.

Especially for network users who demand LTE services for critical operations, 4G was

designed to meet these increased data and application demands with reliable

connections parameters. A highly-flexible QoS framework was introduced to allow

assignment of different priorities for certain applications or services.

QoS is implemented and applied to a set of specific bearers with defined priority

regimes, specified with certain QCI parameters. This framework provides the platform

for implementing special functions that were previously only available via a dedicated

network, as we have learned from the example of GSM-R.

Newer approaches such as Network Function Virtualisation (NFV) follow the aim to

virtualise parts of mobile networks and have obviously some overlap with the

functionality of 5G Network Slicing. The main advantage of the Network Slicing

approach is that it provides a logical virtual end-to-end network for a specific user

segment. No existing QoS-based solution can offer this. With the introduction of

Network slicing concept in 3GPP TS22.889 standardized extensive possibilities are made

available, which will facilitate the QoS definition and alignment for railway

communication networks.



6 Railways QoS Implementation Requirements for

future scenarios

This chapter serves as a derivation of the preceding main chapters. With the knowledge

of which requirements exist for different specific voice and data railway services and

which methods are available in future IP based standards, an attempt is now being

made to combine the results. The focus is also on whether the necessary technical

prerequisites can be provided in a future scenario. The conclusion whether the

requirements that currently exist for railway-specific services can also be applied in

NaaS scenarios and if so, which preconditions exist are examined.

6.1 System architectural requirements

Future railway communication technologies will most likely be based on 5G network

technology. Already in MISTRAL D4.1 the new technical approaches of this new

generation were mentioned and the differences in design to 4G networks were

highlighted.

Current standardisations of 3GPP (starting with Release 13) are already starting to

incorporate special functionalities and requirements for the domain of mission critical

applications into the specification. Especially the use cases of the railway domain are

considered relevant for our analysis in MISTRAL project.

This section is dedicated to current developments and highlights the basic approaches

for implementing the railway QoS principles (and other possible mission critical

application domains) in the 5G specification.

The future 5G network will support many commercial applications with specific priority

demands. These special services share strict common QoS characteristics such as

latency and packet loss rate, but do not necessarily require the same priority regime.

On the other hand, voice-based services (e.g. operational railway calls, railway

emergency call) may have common QoS features as they apply to normal public voice

communication, but with different priority requirements. These mechanisms, which

enable the decoupling of the priority of a particular communication from the associated

QoS characteristics such as latency and reliability, will be implemented by the 5G

network. The priority of each service can be different for a user of that service,

depending on operational requirements and regional or national regulations.

Therefore, the 5G system should provide a flexible framework for prioritising and

implementing priorities in services (e.g. Emergency, Public Safety, Railway domain).

The future network shall deliver the ability to provide the required QoS (e.g. in terms of

defined values for reliability, latency and bandwidth) for specific services and prioritize

resources when required to meet service requirements. Existing QoS and policy

frameworks handle latency times and improve reliability through traffic engineering.

The 5G network will operate in a heterogeneous environment with several access

technologies, different types of UE, etc. It is necessary to implement a harmonised QoS

and guideline system applicable to several types of access.

For QoS control in future railway communication networks, End-to-End QoS (e.g. RAN,

Backhaul, core network, Network to Network Interconnect) is required to achieve the

user demands (e.g. ultra-low latency, ultra-high bandwidth).



6.2 QoS for MISTRAL innovative services

The MISTRAL project defined different application scenarios and innovative functions for

the railway sector that will transmit data via future communication networks. The

analyses focused on different fields of application and user groups. A detailed

description of the innovative services is provided in MISTRAL deliverable D2.1.

At this point the presented application areas are linked with the previously introduced

application categories for specific communication parameters and QoS requirements.

The Table 16 shows the results of the analyses.

It is obvious that the generic approaches of QoS classification are also applicable to the

identified innovative services. The general distinction between voice and data

transmissions with different priority and requirement levels enables a logical integration

of services into specific QoS classes.

In order to analytical break down the identified service categorisation, a clear distinction

can be made between railway-related services (mission critical communication),

business-related analysis services (IoT and maintenance data, with low bandwidth and

latency demands) and services for passengers (bandwidth related demands).

While QoS for mission critical applications must be defined much stringent in terms of

latencies and reliability parameters, on the other hand, the quality of service with

regard to high bandwidth plays the major role in services for passengers, such as the

provision of on-board entertainment services. Especially if a larger number of

passengers use the services simultaneously on trains, a high bandwidth can be

expected here.

MISTRAL Innovative Service/Application

Comm. vector

Type of Trans-

mission

QoS require-ments

Service Attributes

List of innovative services described in deliverable D2.1

Application Category (linked to 3GPP TR22.889)

Latency

Pac-ket Loss

Session establish-ment

Band-width

Moving Block (signalling)

Train-To-Infrastruc

ture

Data communica

tion

Critical Data

(future application)

Low Ultra-Low

Immediate

Low

Data

communication

Very

Critical Data (future application)

Ultra

-Low

Ultra-

Low

Immedi

ate

Low

GOAx (signalling) - ATO - ATP

Train-To-Infrastruc

ture

Data communica

tion

Critical Data

(legacy application)

Normal

Low Immediate

Low

Data communica

tion

Critical Data

(future application)

Low Ultra-Low

Immediate

Low

Improved railway emergency calls

Train-To-Infrastruc

Voice call Critical Voice

Low Low Immediate

Medium



ture Video call Critical Video

Low Low Immediate

High

Precise and certified timing and train position (signalling)

Train-To-Infrastruc

ture

Data communication

Non-critical data

Normal

Low Normal Low

Voice, Data communication,

Messaging

Voice, Non-critical data,

Messaging

Low-Normal

Low-Normal

Normal Medium

IoT-enabled maintenance in railways (real time and smart

monitoring TCMS)

Train-To-Infrastructure

Data communication

Non-critical data

Normal

Low-Normal

Normal Low

Bidirectional real- time monitoring and recovery of trains information and voice

communication

Data communication

Non-critical data

Normal

Low-Normal

Normal Low

Monitoring infrastructure


Data communication

Critical data

Normal

Low Normal Medium

Real-time video

surveillance (on-board)

Train-To-

Infrastructure

Video Video Nor

mal

Low Normal High

Cost analysis of

operational and maintenance (Big-Data)

Train-To-

Infrastructure

Data

communication

Non-critical

data

Nor

mal

Low Normal Low

Statistical analysis of safety-related failures of systems and devices


Data communication

Non-critical data

Normal

Low Normal Low

Ad-hoc

operational data dispatching

Train-To-

Infrastructure

Data

communication

Non-critical

data

Nor

mal

Low Normal Low

Automated Train-to-Train

communication (information about track

conditions, obstacles, weather, etc.)

Train-To-Infrastruc

ture

Data communica

tion

Non-critical data

Normal

Low Normal Low

Additional information (multi-modal

seamless experience)


Data communication,

Messaging

Non-critical data,

Normal

Low Normal Medium

Messaging Messaging Best Effort

Low Normal

Electronic ticketing

Train-To-Infrastruc

ture

Data communica

tion

Non-critical data

Normal

Low Normal Low

On board entertainment

Train-to-mobile

Data communication

Non-critical data

Normal

Low Normal High

One-stop Train-to- Data Non-critical Nor Low Normal Medium



shopping gateway application

mobile communication

data mal

Context aware marketing and

services

Train-to-mobile

Data communica

tion

Non-critical data

Normal

Low Normal Medium

Context aware shopping

Train-to-mobile

Data communication

Non-critical data

Normal

Low Normal Medium

Railway services elicited from the

metro context

Data communica

tion

Non-critical data

Normal

Low Normal Low

Assisted decision-making: Optimal choice for the

transport and route (criteria:

more comfortable, faster, cheaper, better connections, etc.)

Data communication

Non-critical data

Normal

Low Normal Low

Real-time timetable

information (enhanced connection and routing information)

Data communica

tion

Non-critical data

Normal

Low Normal Medium

Provide precise

positioning data of trains(e.g. for maps/guides in emergency cases)

Train-to-

mobile

Data

communication

Non-critical

data

Nor

mal

Low Normal Low

Seamless services available on board

and at the station (business)

Train-to-mobile

Data communica

tion

Non-critical data

Normal

Low Normal Medium

Table 16: MISTRAL innovative services and QoS attributes mappings (TUD)

6.3 Conditions for railway functionalities

This section is intended to provide an overview of the basic conditions and requirements

for the transfer functions of the network when railway-specific functions and

applications are used. Prerequisites are defined for data and voice connections, as well

as overlapping features, such as cryptographic requirements for transmission or

authentication features.

6.3.1 Data Transmission

The minimum functional and performance requirements for a 4G-based data

communication network for railway domain can be derived from [13]. Table 16 shows a

summary of the most important parameters regarding network deployment.

Items Description

Coverage

and performance

Network coverage: 98%

Communication up to a train speed of 500 km/h



Handover

success

seamless data transmission,

handover success rate shall be 99%

Connection drop

rate

a call disconnection rate less than 0.01 times per

hour

Train control data

transmission

>99% data reliability to transmit data for train control

Train control data shall have highest priority.

Network

redundancy

network equipment, core equipment and server shall

be designed to be redundant for stability and

availability.

Table 17: Minimum requirements on railway network performance

In particular, all functionalities and performance requirements with the exception of the

high speed (500 km/h) mentioned above were fully supported by LTE.

Promising Mission Critical Services functionality (see Chapter 5.5) that extends 3GPP

Rel. 16 to meet more demanding requirements have to be taken into account for future

networks. In this context, these requirements to future railway network technology can

be regarded as basic functional and performance requirements.

Application

Category

Service Attributes Session

establishment

QCI

Latency

peer to

peer

Reliability Priority

Critical Data

(future

applications)

≤100ms 99.9999% 0.5 <1s 69

Critical Data

(legacy

applications)

≤500ms 99.9% 5.5 <3s 70

Non-Critical data ≤500ms 99.9% 9 <3s 9 Table 18: Derived QoS vector for Data transmission

The values shown in Table 18 can be derived from the qualitative QoS requirements

recommended by 3GPP. These values for data communication are considered a

prerequisite for the minimum quality of service of the respective application class.

Particularly with regard to critical data transmission (e.g. railway signalling application),

the high level of reliability required for transmission must be taken into account.

6.3.2 Voice Transmission

The future transmission technology in the railway sector will be completely IP-based.

Especially in the transmission of voice, this will result in a complete paradigm shift

compared to GSM-R. Voice transmission will be carried out using Voice over Internet

Protocol (VoIP) technology, which enables voice calls over an IP communication

network instead of a standard dedicated (circuit-switched) channel. VoIP has high

demands on transmission quality.

For the IP transmission procedure this means that there are high requirements on

latency, jitter and packet loss rate (as low as possible). There are also data throughput

requirements (as high as necessary) that relate to the desired audio quality and depend



on the speech codec used. Particularly for voice transmission, the influences of packet

loss, distortion, echoes and degraded voice quality due to packet delay is particularly

significant.

6.3.2.1 Service quality requirements

The ITU has specified a reference model, in order to determine the expected quality of a

voice transmission, which defines a classification that can be correlated to the

demanded voice quality. The ITU specification defines different QoS classes and

guidelines for assessing service quality in IP terms, which class a particular type of

application should use. This assessment of quality can be derived from certain

transmission parameters.

Regarding voice services, the total end-to-end latency is the sum of delays in the

specific network areas from the speaker's terminal to the listener's terminal: within the

devices and network connections over which the voice traffic routes. Many factors

contribute to the end-to-end latency, which are discussed below:

• Network latency

Generically, a circuit-switched Public Switched Telephone Network (PSTN)

typically has a relatively low delay, which is primarily dependent on the

transmission distance. Typically, this latency is <100ms.

Latencies and delays within IP networks are primarily determined by the

performance of network elements (e.g. routers): Buffering, the queue and the

switching or routing delay are important factors. Specifically, the IP network

delay consists of packet recording delay, switching/routing and delay and waiting

time.

• VoIP device delay

Due to the signal processing on both the sending and receiving side of a

connection, VoIP gateways and VoIP terminals contribute significantly to the

end-to-end delay caused by the signal. This processing is necessary to enable

the coding and compression of the analogue speech signal into a digital signal.

The choice of voice codec implementation is important. The more effectively the

device is adapted to the speech codec used, the shorter the processing times

within the devices. On the other hand, powerful codecs can also achieve a lower

network load if smaller data packets can be generated by higher compression.

Various optimized speech codecs are available for transmission. Specific codecs

are optimized for the respective transmission medium and the requirements for

the QoS characteristics of the transmission. On the receiver side, voice packets

are intentionally delayed to compensate for variations in packet transmission

times (variation of packet run times is called "jitter"). Also packets that are

created with constant time intervals usually also come to the recipients with a

randomly allocated distribution due to the different buffering and queue times

within the network, because different transmission paths are normal within IP

networks.

Voice codecs (see 6.3.2.2) require a constant and seamless data flow. It is

recommended to perform voice transmissions with a guaranteed bit rate. The

use of jitter buffers is also required for jitter smoothing.

Above all, the use of mechanisms that prioritize voice traffic over other traffic on

the network can significantly reduce jitter and increase voice quality.

• Packet loss rate

If the network or a network segment is overloaded, packets may get lost and the

speech signal cannot be decoded. With real-time voice information, the packets

must arrive in a relatively short time to reconstruct the voice signal, otherwise it



would lead to incomprehensible voice transmission. In general, packet loss must

be less than 1% if audio quality is not to be affected. Greater than 3% is clearly

noticeable as a reduction in the quality of the language.

• Echo and Distortion

Echo and distortion problems are usually the result of insufficient service quality

of the transmission path. The errors are mainly handled in the VoIP gateways

and terminals. In the network, small delays, low jitter and low packet loss help

to counteract these problems.

These characteristics must be considered and evaluated in order to define requirements

for voice transmission.

6.3.2.2 Qualified voice codecs

A voice codec converts analogue speech into digital bit streams and back. In addition,

voice codecs usually use compression methods that filter redundant or less important

information to reduce the required transmission bandwidth.

Various voice codec algorithms were specified and defined e.g. within ITU-T. The

compression performance of a voice codec is a compromise between voice quality,

processing power of the equipment, the acceptable delay and required network

bandwidth. In general, the greater the bandwidth reduction, the higher the

computation costs of the codec for a certain level of quality.

In addition, a greater saving in bandwidth usually leads to a higher computing delay

and thus to a significant increase in end-to-end delay. The influence of a codec on the

voice quality is also influenced by the packet size, packet loss and possible errors

caused by the correction mechanisms used by the codec itself.

The standard codec for GSM-R is currently the Enhanced Full Rate Codec (GSM-EFR),

with a bandwidth requirement of 12.2 kbps. However, this codec will no longer be used

in future VoIP networks. New codecs with better performance and adaptability to

different bandwidths are in demand.

The AMR Wideband (AMR-WB) codec specifications is applicable for voice applications in

converging wired and wireless networks and standardised by ITU. Within the AMR-WB

speech codec nine different rates are defined of 23.85, down to lowest bitrate of 6.6

kbps. The standard supports dynamic adaptation to network conditions through lower

bit rates in the event of network overload or deterioration while maintaining audio

quality. AMR-WB also works together with VMR-WB, a 3GPP2 broadband voice standard

that is mandatory for broadband telephony and multimedia messaging services.

As a codec for voice transmission that offers quality requirements suitable for future

networks such as 5G and variable performance options, the AMR-AWB codec is the

recommended implementation.

6.3.2.3 Voice Group calls

The group call functionality is part of the EIRENE/ERTMS standard and is used, for

example, for shunting work, for commercial operation and for emergency railway calls.

With GSM-R, group calls currently use the Voice Group Call Service (VGCS). VGCS uses

a single voice channel to all receivers (downlink) in a cell and activates the uplink only

for the speaking person, initiated by a switch.

However, in a packet-switched network, group calls can be realized with individual

bidirectional calls to each receiver. Alternatively, multicast functionality can be used to

send efficiently to the group in a single transmission. The benefit of using a multicast

solution depends on the technology and implementation. In the most effective case, the



bitrate request for the group call can be reduced to the same requirement as a single

VoIP call.

6.3.2.4 Summary for Voice transmission

The following Table 19 shows the combined requirements which can be defined for a

standard voice connection for operational railway utilisation:

QoS channel indicator Quality characterisation

Bandwidth/Throughput

Depends on the used speech

codec and protocols.

AMR-WB codec is about 60

kbps

Guaranteed bitrate is

recommended

Latency

<150ms,

ideally <40ms

High priority regime class

Jitter

<25ms

Packet Loss rate

<0.5%,

ideally <0.1%

Table 19: Existing QoS recommendation for voice transmissions

A more generalized approach to integrate VoIP with different codec types into a

quantitative QoS assessment is described in the Table 28. However, these requirements

are less restrictive and not completely applicable to the railway communication.

Application

Category

Service Attribute Session

establishment

QCI class

Latency

peer to peer

Reliability Priority

Voice ≤100ms 99% 2 <3s

1

Critical

Voice

≤100ms 99.9% 0.7 <1s

65

Video ≤150ms 99.9% 4 <3s 2

Critical

Video

≤100ms 99.9% 1.5 <1s 67

Table 20: Derived QoS vector for Audio and Video transmission

The values shown in Table 20 can be derived from the qualitative QoS requirements

recommended by 3GPP. These values for voice communication are considered as a

prerequisite for the minimum quality of service of the respective application class.



6.3.3 Security requirements

In addition to the requirements for QoS features, security against cyber-attacks on the

network infrastructure will also be an important issue in the future, especially with focus

to the NaaS transition. It is necessary to investigate which security functions and

cryptographic approaches can be used in the future railway communication network.

The security framework of the communication network shall protect against attacks and

threats, like misuse, Denial of Service (DoS), unauthorized access to services,

interception, man-in-the-middle attacks, replay attacks and intended data modification.

General risks that may occur during the transmission of safety-relevant are analysed in

EN50159.

The followings risks could be caused by intentional influence on the communication

channel. A classification of these attacks can be made as follows:

• Jamming

A blocking or interference method, which can be used in wireless data

networks to partially or completely disrupt information flows.

• Denial-of-service attack (DOS)

Intentional overload of the system, by flooding the targeted network

resource with massive requests

• Spoofing and redirection of messages to other destination

This attack misleads the transmitted information to the receiver. This is

done by broadcasting not counterfeit data signals or genuine “corrupted”

signals captured and modified in a different source of information.

• Penetration into the communication system by an attacker stopping the

transmission system.

The availability of the communication system of signalling applications are indispensable

for safe railway operation. Railway signalling applications are designed in such a way

that, in the event of a communication failure (e.g. due to message cancellation,

intentionally denial of service), they react safe-side (stopping railway train operation).

Requirements regarding the transmission of safety-related messages are defined within

EN50159 as efficient measure against repetition, insertion, re-sequencing and delay,

based on sequence number, timestamps and safety code.

These methods are of course implemented at the application or transport level, but are

not significant for the IP-based communication system itself. These procedures do not

prevent the attack itself, but ensure that the application reacts fail-safe by reacting to

the attack.

Furthermore, it is not possible to prevent an attacker from creating safety-related

messages with a correct timestamp, sequence number and safety code (requires access

to the specification of the signalling application). For this reason, EN 50159 also

requires the avoidance of masquerade through the use of cryptographic techniques to

ensure the senders authentication.

Although not directly part of the EN 50159 standard, confidentiality is known to be

important to reduce the knowledge of any attacker and thus avoid knowing how to

efficiently control his attack.

The communication system itself is not a safe system. As a result, the railway signalling

application (and other services with vital and mission critical data transmission) itself

must implement countermeasures for transmission failures. The requirements to be met

by IP-based communication systems in terms of security and safety can be summarised

as follows:

• Availability of the communication (e.g. redundancy, diversity),

• Stringent authentication of the communication modules,



• Integrity of the transmitted messages,

• Confidentiality of the exchanged messages,

• Limited latency and jitter,

• Securing of the control plane.

However, the security of the transmitted information itself is handled at a higher

(application) level and does not fall within the IP-based communication system. The

security of the railway application that uses the communication network must be

guaranteed at higher levels.

6.3.4 Authentication concepts

To ensure that the right application is using the right priority and QoS profile, every

application must support an authentication procedure prior to the session

establishment.

The 3GPP 4G/5G network security features are implemented at the following

subsystems:

• SIM cards (UICC)

ICC performs the cryptographic operations for authentication

• Air Interface Protection (performing user-to-network security)

• IP Backhaul Protection

The 4G network entity authentication is as defined by TS 33.102. User data and

signalling data confidentiality is done according to the standard 3GPP TS 33.401. The

following security features related to entity authentication are provided within 4G:

• user authentication:

the property that the serving network corroborates the user identity of the user

• network authentication:

the property that the user corroborates that he is connected to a serving

network that is authorised by the user's HE to provide him services; this includes

the guarantee that this authorisation is recent.

To achieve these objectives, entity authentication occurs at each connection set-up

between the user and the network. Two mechanisms have been included: an

authentication mechanism using an authentication vector delivered by the user's HE to

the serving network, and a local authentication mechanism using the integrity key

established between the user and serving network during the previous execution of the

authentication and key establishment procedure.

According 3GPP TS 33.401 LTE authentication is mutual authentication performed by

and between a user and a network based on EPS Authentication and Key Agreement

(AKA) procedure. The mutual authentication is a major advantage compared to one-

sided (user-plane) authentication in the GSM network and the only solution to eliminate

existing vulnerabilities and threat vectors (see 3.6.4).



6.4 Mapping of functional requirements

A summary and mapping of requirements from existing requirements specifications and

functionalities of new communication technologies takes place within this chapter.

Table 21 shows the mapping of the functional requirements created from the supported

GSM-R functionalities analysed at the beginning. For this purpose, the functionalities

offered by an LTE network equipped starting with Rel. 13 standard according to 3GPP

(see 5.5) were compared. With the introduction of mission-critical services, special

functions were introduced that will primarily cover the railway specific functionalities in

the network. The mapping of these special capabilities is finally applied. The table

provides a comparison of the differentiated functional implementations of different

recent 3GPP releases.

Table 21: Mapping of functional railway requirements between GSM-R and 4G/5G networks (TUD)

Function implementation

GSM-R 4G (Rel. 12) 5G (Rel. 15,16)

incl. MC capabilities

Mandatory Priority and Pre-

emption

(eMLPP)

Access Class Barring

mechanisms (ACB),

QoS mechanisms

(ARP).

Enhanced QoS

mechanisms (ARP)

Mandatory Fast Calls Set-up IMS based VoLTE +

Access Class Barring

MC Voice functionality

(MCPTT)

Mandatory Railway

Emergency Calls

(REC, e-REC)

Emergency and

critical safety voice

services (IMS)

MC Emergency

priority call,

MC Localisation

Services

Mandatory Voice Group Call

Service (VGCS)

IMS based VoLTE +

IMS based Push to

talk Over Cellular

(PoC) +

Enhanced Multimedia

Broadcast Multicast

Service (eMBMS)

MC Group call

functionality,

MC Broadcast calls

Mandatory Voice Broadcast

Calls (VBS)

VoLTE + eMBMS: IP

multicast of voice

services

MC Broadcast calls

Mandatory Functional

Addressing (FN)

Session Initiation

Protocol (SIP)

Addressing

Session Initiation

Protocol (SIP)

Addressing

Mandatory Location

Depending

Addressing

(LDA, eLDA)

Localisation Services

(3GPP Rel. 10)

MC Localisation

Services

(3GPP Rel. 15)

Optional Data Exchange

(SMS)

IMS based SMS

Service

IMS based SMS

Service

Optional Direct Mode N/A On-/Off-network

communication

functionality



6.5 Conclusion on Technical viability

The analyses confirm that future transmission standards according to current 3GPP

definitions are capable meeting the high QoS requirements of railway applications.

4G LTE networks, as well as future 5G networks, offer different approaches and several

types of parameter classes which are used to implement traffic prioritisation and QoS

management. These methods need to be implemented according to 3GPP specifications.

Traffic prioritisation for mission critical users is a new domain for public communication

providers, which so far providing mostly non-prioritised services.

High QoS requirements for mission critical services cannot be met with the QoS

features offered by existing public 2G/3G networks. This highlights the need for

enhanced 4G or 5G network availability and coverage.

The aim of the study was to establish a specific QoS vector for railway applications. In

the first part of the document, all functional and technical requirements for railway

communication that are currently specified were analysed. These requirements were

compared and mapped with the functions provided by existing 4G and future 5G

networks.

Together with future innovative applications identified in MISTRAL, a requirement vector

has been specified for the communication technology to which a QoS vector can be

derived. In its analyses, MISTRAL introduces different implementation scenarios

regarding the design of future railway-specific communication networks. The NaaS

scenario seems to offer very promising technical and economically interesting solutions

for railways and mobile network provider.

Railway infrastructure managers may in future share the same communication system

infrastructure (i.e. with public commercial service operators or other mission-critical

users). In addition, different categories of applications of a railway company must share

the network infrastructure. The separation and prioritisation of the different

communication types is an essential prerequisite. The ability to provide diverse

applications with very differentiated authorisation regimes and performance values

within a network is an enormous advantage of 4G networks. However, only with the

implementation of Mission Critical service capabilities can a quality of service vector be

achieved that enables the complete replacement of the existing GSM-R network.

Railway applications that exchange critical information for railway operations require

secure radio access and transport resources. The 5G's end-to-end network capability for

network slices allows a design to achieve these stringent requirements. End-to-end

transport resources can be allocated and ensure the separation of communication

between railway infrastructure manager and railway undertakings.

For this reason, end-to-end network slicing, which includes 3GPP radio access (4G and

beyond) and core functions such as session, mobility and transport management

functions, must be supported by the future communications system. Moreover, end-to-

end network slicing offers scalability and flexibility to introduce new innovative

applications in the railway domain. It is necessary that the specific railway network slice

can be handled independently in terms of system functionality, priority, data rate

(guaranteed and maximum bit rate), latency and communication security.

6.5.1 Connection to economic analyses within MISTRAL

The project MISTRAL falls within the Shift2Rail Joint Undertaking Multi-Annual Action

Plan (MAAP) and has the goal to analyse a feasible and viable migration towards a new

management model for the railway communication system. To achieve this goal, all the

technical and economic issues have been analysed with the aim to create an adaptable



train-to-wayside IP communication technology. MISTRAL focuses its analyses on the

possibility, to shift from the network as an asset (NaaA) scenario to a network as a

service (NaaS) paradigm. This approach can affect not only the costs, (e.g., reduce

CapEx and increase OpEx) but also the creation of new services and new markets that

can attract both new and old operators.

A quantitative analysis has been leveraged in MISTRAL D3.2 to generate the main

results of the deliverable. The aim was to identify a set of plausible and real values for

the data and to define a total cost of ownership function linked to all the technical and

economic consideration. The results of the D3.2 confirmed the considerations about

NaaA and NaaS with 4G*-MC deployment. In particular a promising solution would be in

deploying a new infrastructure that can use both 4G*-MC and 4G for the railway

communication network.

This conclusion also forms the specific link to deliverable D4.2. It was shown that only

with the introduced extensions of the 3GPP MC services an implementability of the

existing and future requirements for IP based railway communication networks becomes

possible. However, the implementation of comprehensive NaaS approaches becomes

particularly interesting for MNOs with the introduction of standardised network

virtualisation functions of the upcoming 5G networks. Here a technical separation of the

network functionalities and thus also of the transmission characteristics of different

applications and services can be realised more comprehensive way.

6.5.2 Connection with other projects

The Roll2Rail project [20] aims to develop key technologies for innovations in the field

of future rail vehicle technology. The results should serve to increase operational safety

and reduce life cycle costs.

Within this project, the selection and validation of a radio transmission technology, in

particular LTE technology for wireless train backbone network, was analysed. The

Roll2Rail project identified various requirements for the transmission system in order to

accomplish this task. The areas Train Control and Monitoring System (TCMS) and On-

board Multimedia and Telematics Subsystem/Services (OMTS) are covered. For these

both domains a set of requirements to be fulfilled by applications working in each

domain was specified. From the TCMS standard point of view, there exist five different

Data Class which are: Process, Message, Supervision, Best Effort and Streaming with

different demands on the transmission. These requirements applicable for the

communication technology are introduced in Table 22.

Domain Data

Class

Data size Data rate

need

Cycle

time

Latency

max max min max

TCMS Process 1432 Bit 10 Mbit/s 16ms 80ms

Message 65388 Bit 10 Mbit/s Not

relevant

250ms

Supervision Not

relevant

10 Mbit/s 50ms 250ms

Best Effort Not

relevant

10 Mbit/s N/A N/A

Streaming N/A N/A N/A N/A

OMTS Process 1432 Bit 10 Mbit/s 16ms 80ms

Message 65388 Bit 10 Mbit/s Not

relevant

250ms



Supervision Not

relevant

10 Mbit/s 50ms 250ms

Best Effort 4 GByte 10 Mbit/s N/A N/A

Streaming Not

relevant

100 Kbit/s

(Audio),

8 Mbit/s

(Video)

– 0.1s

(Audio),

0.5s

(Video) Table 22: Identified requirements for communication technology from roll2rail {Ref [20]}

The identified parameters, especially regarding the latencies, are comparable to those

described and specified in the section 6.3. It can be recognized that with the utilisation

of modern 4G networks and the implemented powerful QoS mechanisms these

characteristic values can be also achieved and monitored. However, differences can be

seen in the expected data rate. While the FRMCS assumes the highest expected data

rate for railway applications with 5 Mbit/s (see Table 15), the values identified within the

Roll2Rail project are twice as high. At this point a suitability of 3GPP networks can also

be recommended for the Roll2Rail project with regard to the required QoS

characteristics.



7 Conclusion

The project MISTRAL has the goal to analyse a feasible and viable migration towards a

new management model for the railway communication system. To achieve this goal, all

the technical and economic issues have been analysed with the aim to create an

adaptable train-to-wayside IP communication technology. This deliverable D4.2 focuses

on technical viability and aims to establish a specific QoS vector for IP-based

communication in railway transmission systems.

The convergence to an all IP based network will provide an efficient use of the network

capabilities. The QoS methods, guaranteed call setup times, proper service prioritisation

and IP security capabilities, offer advantages over the previous GSM-R system. The 4G

and 5G QoS mechanisms were identified. With the introduction of mission critical

communications services, the standardization bodies open the door for the railways to

make a transition to the new network generation.

Both functional aspects of railway communication and their technical requirements can

be offered and handled in modern 3GPP mobile radio networks.

Comprehensive QoS methods for the future communication networks meet the

requirements of stringent QoS parameters of railway functions. The definition of a QoS

vector for railway communication applications for voice and data applications according

to the recent 3GPP standardisations have been examined. In comparison, 4G MC-

enabled networks not only offer the possibility of a very differentiated prioritization of

service features, they also use improved cryptographic methods and authentication

mechanisms. This will in addition enable higher safety standards to be met in the

future.

With network slicing mechanisms within 5G networks an implementation of

virtualisation is introduced that allows multiple virtual networks to operate on a

common physical network infrastructure. The aim is to enable a physical mobile

operator to partition its resources so that very different users with specific applications

and requirements for the transmission network can use a single physical infrastructure.

With focus on the railway sector, the sharing of a certain physical network, in order to

simultaneously allow application of Internet of Things (IoT) for maintenance purposes,

mobile broadband applications for passengers (MBB) and critical applications with high

QoS requirements (e.g. automatic train protection), is interesting. These applications

obviously have very different transmission characteristics.

The implementation of mission critical features, the flexible adaptation of QoS features

within the future network generation and the introduction of network slicing will change

communication in the railway sector. Most of all, these prerequisites will enable NaaS

application scenarios that have been presented in MISTRAL.



8 List of tables, figures, and references

8.1 Tables

Table 1: Priority regimes within GSM-R voice connections {Ref UNISIG} ...................................................... 18 Table 2: Requirements on voice call setup times {Ref [9]} .............................................................................. 24 Table 3: Functional requirements of railway communication system (Extracted from EIRENE FRS) ............ 31 Table 4: Summary of QoS requirements {Ref [2]} ........................................................................................... 33 Table 5: Selected parameter of ETCS QoS Profile (PS-Mode) {Ref UNISIG} ................................................ 37 Table 6: QoS requirements on railway communication systems (Extracted from EIRENE FRS) ................... 40 Table 7: Pre-defined Quality class indicators in LTE ....................................................................................... 49 Table 8: Quality class indicators for Mission Critical service (3GPP) {REF [11]} ............................................ 50 Table 9: VoLTE capabilities overview .............................................................................................................. 55 Table 10: 3GPP Mission Critical services and Enhancements in Release 13 to 15 (3GPP) .......................... 59 Table 11: QoS categorisation for different application types (3GPP) {Ref [10]}.............................................. 60 Table 12: Quantitative Mapping of service and QoS attributes (3GPP) {Ref [10]} .......................................... 61 Table 13: Overview of Critical Support Applications (FRMCS) {Ref [10]} ....................................................... 63 Table 14: QoS of different selected FRMCS application types (FRMCS) {Ref [10]} ....................................... 63 Table 15: Quantitative Mapping of additional service attributes {Ref [10]} ..................................................... 64 Table 16: MISTRAL innovative services and QoS attributes mappings .......................................................... 68 Table 17: Minimum requirements on railway network performance ................................................................ 69 Table 18: Derived QoS vector for Data transmission ...................................................................................... 69 Table 19: Existing QoS recommendation for voice transmissions .................................................................. 72 Table 20: Derived QoS vector for Audio and Video transmission ................................................................... 72 Table 21: Mapping of functional railway requirements between GSM-R and 4G/5G networks (TUD) ........... 75 Table 22: Identified requirements for communication technology from roll2rail {Ref [20]} .............................. 78 Table 23: Minimum performance requirements of railway communication systems {Ref [13]} ....................... 82 Table 24: Minimum functional requirements for LTE based railway communication system {Ref [14]}.......... 84 Table 25: FRMCS – Service and Service Attributes requirements (qualitative) {Ref [10]} ............................. 85 Table 26: FRMCS – Service attribute mapping (quantitative) {Ref [10]} ......................................................... 85 Table 27: Standardised QCI characteristics (including MC services) {Ref [11]} ............................................. 87 Table 28: QoS Metrics for Voice over IP (quantitative) {Ref: [15]} .................................................................. 88

8.2 Figures

Figure 1: GSM-R service architecture {Ref [16]} ............................................................................................. 17 Figure 2: Reference architecture of train-side/track-side components of ERTMS/ETCS {Ref [6]} ................. 21 Figure 3: Communication protocol stack architecture (TUD) .......................................................................... 26 Figure 4: SDF and EPS Bearers {Ref [22]} ..................................................................................................... 48 Figure 5: 4G/5G Bearer QoS concept (TUD) .................................................................................................. 49 Figure 6: EPS security Architecture {Ref [21]}................................................................................................. 52 Figure 7: EPS signalling plane protection {Ref [21]} ....................................................................................... 53 Figure 8: EPS user plane protection {Ref [21]} ............................................................................................... 53 Figure 9: IMS architecture within LTE Evolved Packet Core (Spirent) ........................................................... 56 Figure 10: IMS core elements (Spirent) ........................................................................................................... 57



8.3 References

[1] UNISIG SUBSET 88: “ETCS Application Levels 1 & 2 - Safety Analysis”, Parts 0-3

[2] UNISIG SUBSET 93: “GSM-R Interfaces Class 1 Requirements”, V2.3.0, 2005-10

[3] CENELEC - EN 50129: “Railway application – communication, signalling and

processing systems – safety related electronic systems for signalling”, CENELEC

2002

[4] ERTMS User Group: “ETCS/GSM-R quality of service – Operational analysis”,

2005

[5] ETSI TS 103 328: “Railway Telecommunications (RT); GPRS/EGPRS

requirements for ETCS”, V1.1.1, 2015-12

[6] P.Stanley: “ETCS for Engineers”, 1st Edition, Eurail Press 2011

[7] Aleksander Sniady, José Soler, Mohamed Kassab, Marion Berbineau: “Ensuring

Long-Term Data Integrity”, IEEE Vehicular Technology, pp. 60-70; 2016

[8] Shift2Rail: “MISTRAL: Communication System for Next-generation Railways”,

Project reference 730840,

[9] “System requirement specification” UIC Project EIRENE, UIC CODE 951, Ver.

15.4; 2014

[10] 3GPP TR 22.889: “Study on Future Railway Mobile Communication System”;

V16.2.0, 2018-03

[11] 3GPP TS 22.203: “Technical Specification Group Services and System Aspects;

Policy and charging control architecture (Release 15)”; V15.2.0, 2018-03

[12] 3GPP TS 33.102: “Technical Specification Group (TSG) SA; 3G Security, Security

Architecture, 1999-04

[13] TTA TTAK.KO-06.0370, “User Requirements for LTE-Based Railway

Communication System”, 2014-10

[14] TTA TTAK KO-06.0-369, “Functional Requirements for LTE-Based Communication

System”, 2014-10

[15] IOS Press, “QoS Requirements of Network Applications on the Internet”, 2004

[16] Kapsch, “White Paper: European Railway Traffic Management System – ERTMS”,

2012

[17] FRANEKOVÁ, et.al.: “Safety analysis of cryptography mechanisms used in GSM

for railway”, 2011

[18] Chotia, Ordean, Thomas, Ruiter: “An Attack Against Message Authentication in

the ERTMS Train to Trackside Communication Protocols”, 2017-02

[19] EC, “Commission Decision on the technical specification for interoperability

relating to the control-command and signalling subsystems”, 2012-01

[20] Roll2Rail Project, Internet URL: http://www.roll2rail.eu, 2017-10

[21] Forsberg, Horn, Meller, Niemi: “LTE Security”, WILEY, 2012

[22] Netmanias: “LTE Technical Documents”, Internet URL:

http://www.netmanias.com, 2018-03

http://www.roll2rail.eu/

http://www.netmanias.com/



9 ANNEX

Items Description Remarks

Coverage

and performance

Coverage shall be continuous from a time and space

perspective, and the temporal and spatial range to

guarantee stability shall be more than 98% based on

the vehicle being equipped with an external antenna.

The network shall be able to accommodate the mobile

terminal for railway communication.

The system shall be able to provide communication

when moving at track speed limit or 500 km/h,

whichever is lower.

Call setting time Railway emergency call <1s (90%), <2s(99% or

more)

Broadcasting or group call <1s (90%), <2.5s(99% or

more)

All voice/video calls that do not correspond to the

above

< 3.5s(90%), < 5s(99% or more)

*

External PSTN

connection not

considered

Handover

success

The network shall be able to have seamless data

transmission, and the handover success rate shall

be 99% or more.

Call access success The call access success rate shall be 99% or more.

Connection drop rate The system shall be able to guarantee a call

disconnection rate less than 0.01 times per hour

during a lengthy call

Train control data

transmission

The network shall guarantee more than 99% data

reliability to transmit data for train control.

Train control data shall have top priority.

Network redundancy The network including eNB equipment, core equipment

and server shall be designed to be redundant for

stability and availability.

However, the

application scope

of redundancy is

determined by

the operator.

Broadcasting and group

call area

Radio equipment in a restricted area can participate in

broadcasting and group call, and the radio equipment

out of broadcasting and group call area during call

shall be excluded from call.

Table 23: Minimum performance requirements of railway communication systems {Ref [13]}



Service Detailed

service Description

Mandatory/Op

tional

(M/O) Voice

service

Individual

voice call

The system shall support voice calling between

two callers.

M

Public

emergency

call

The system shall allow the user to make a

public emergency call.

M

Broadcasting

voice call

The system shall support a broadcasting call. M

Group voice

call

The system shall support a group call. M

Multi-party

voice call

The system shall support a multi-party call

between at least 3 different parties.

M

Data

service

Multimedia

message

service

The network shall support point-to-point and

point-to-multi-point message transmission from

the ground to mobile radio equipment users.

M

General data

service

The system shall support broadband data

communication between ground and mobile

radio equipment users.

M

Train control

service

The system shall support seamless data

communication for stable train control.

M

Video

service

Individual

video call

The system shall support video calling between

two callers.

M

Group video

call

The system shall support group video calling. M

Video

information

transmission

The system shall support the video information

transmission function related to safe train

operation.

M

Call

related

service

Receiver

/Caller

ID display

The equipment shall display the receiver or

caller ID in the form of a standard telephone

number.

M

Receiver

/caller ID

display

restriction

The system shall allow the ID of a specific user

to be prevented from being displayed on the

mobile radio equipment.

O

Priority and

pre-emptive

right

A function in which a call is allocated to the

member who has top priority among the

members who have different priority levels

shall be provided.

M

Closed user

group

The user group who can access the Korean

railway integrated radio network from outside

shall be restricted.

M



Service Detailed

service Description

Mandatory/Op

tional

(M/O) Call transfer The incoming call or data message for one user

shall be transferred to other devices in the

network.

M

Call holding The network shall allow the user to hold a call

temporarily from an existing call.

M

Call waiting The network shall be able to notify the user of

the existing call that another user is attempting

to access.

M

Charging

information

When there is a network service charge, the

network shall be able to provide the information

on call charge and ongoing call charges.

O

Call

restriction

The system shall be able to restrict a call using

the network management or maintenance

facility.

M

Automatic

answering

service

A call shall be answered automatically

according to the priority of an incoming call.

M

All voice/

Video call

recording

A call shall be answered automatically

according to the priority of an incoming call.

M

Railway

specializ

ed

service

Functional

addressing

The system shall provide the addressing system

in which the Controller can set communication

with the train driver using train number

M

Location-

dependent

addressing

The system shall provide the location-

dependent addressing system in order to

identify the destination number, which varies

depending on the location of users

M

Railway

emergency

call

The network shall provide the system to handle

a voice call with high priority for a railway

emergency call

M

Shunting

mode

The network shall provide the system to

regulate and control the user’s access to the

function and features of mobile radio

equipment being used for shunting mode

communication

M

Direct

communicati

on

The system shall support direct communication

between terminals in the event that an LTE-

based railway communication service is not

normally available due to a failure in eNB.

O

Table 24: Minimum functional requirements for LTE based railway communication system {Ref [14]}



Application

Category

Service Attribute

(according to Table

12.10-1)

Session

establishment

Session Loss

Rate

Latency

peer to

peer

Packet

Loss Rate

Voice Low

Normal

Normal

NA

Critical Voice Low

Low

Immediate

NA

Video Normal Low Normal NA

Critical Video Low Low Immediate NA

Very Critical

Data

(Note 1)

Ultra-Low Ultra- Low Immediate NA

Critical Data

(future

applications)

Low Ultra- Low Immediate NA

Critical Data

(legacy

applications)

Normal Low Normal <10-2/h

Non-Critical

data

Normal Low Normal NA

Messaging Best Effort Low Normal NA

Note 1: The applicable vehicle speed to be considered is in the range of 0-10

kmh-1.

Table 25: FRMCS – Service and Service Attributes requirements (qualitative) {Ref [10]}

Service Attribute FRMCS - Functional

Requirement

FRMCS – System

Requirement

Service

Attribute value

Latency Low Ultra-Low ≤10ms

Low ≤100ms

Normal Normal ≤500ms

Best Effort >500ms

Transport reliability -

Packet Loss (%)

High Ultra-Low 99.9999%

Low 99.9%

Normal Normal 99% Table 26: FRMCS – Service attribute mapping (quantitative) {Ref [10]}



QCI Resource Type

Priority Level

Packet Delay

Budget

Packet Error Loss

Rate

Example Services

1 (NOTE 3)

2 100 ms (NOTE 1, NOTE 11)

10-2 Conversational Voice

2 (NOTE 3)

GBR

4 150 ms (NOTE 1, NOTE 11)

10-3 Conversational Video (Live Streaming)

3 (NOTE 3, NOTE 14)

3 50 ms (NOTE 1, NOTE 11)

10-3 Real Time Gaming, V2X messages Electricity distribution - medium voltage (e.g. TS 22.261 [51] clause 7.2.2) Process automation - monitoring (e.g. TS 22.261 [51] clause 7.2.2)

4 (NOTE 3)

5 300 ms (NOTE 1, NOTE 11)

10-6 Non-Conversational Video (Buffered Streaming)

65 (NOTE 3, NOTE 9,

NOTE 12)

0.7 75 ms (NOTE 7, NOTE 8)

10-2

Mission Critical user plane Push To Talk voice (e.g., MCPTT)

66 (NOTE 3, NOTE 12)

2

100 ms (NOTE 1, NOTE 10)

10-2

Non-Mission-Critical user plane Push To Talk voice


1.5

100 ms (NOTE 1, NOTE 10)

10-3

Mission Critical Video user plane

75 (NOTE 14)

2.5 50 ms (NOTE 1)

10-2 V2X messages

5 (NOTE 3)

1 100 ms (NOTE 1, NOTE 10)

10-6 IMS Signalling

6 (NOTE 4)

6

300 ms

(NOTE 1, NOTE 10)

10-6

Video (Buffered Streaming) TCP-based (e.g., www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.)

7 (NOTE 3)

Non-GBR 7

100 ms

(NOTE 1, NOTE 10)

10-3

Voice, Video (Live Streaming) Interactive Gaming

8 (NOTE 5)

8

300 ms

(NOTE 1)

10-6

Video (Buffered Streaming) TCP-based (e.g., www, e-mail, chat, ftp, p2p file

9 (NOTE 6)

9 sharing, progressive video, etc.)

69 (NOTE 3, NOTE 9,

NOTE 12)

0.5 60 ms (NOTE 7, NOTE 8)

10-6 Mission Critical delay sensitive signalling (e.g., MC-PTT signalling, MC Video signalling)


5.5 200 ms (NOTE 7, NOTE 10)

10-6 Mission Critical Data (e.g. example services are the same as QCI 6/8/9)

79 (NOTE 14)

6.5 50 ms (NOTE 1, NOTE 10)

10-2 V2X messages

80 (NOTE 3)

6.8 10 ms (NOTE 10, NOTE 15)

10-6 Low latency eMBB applications (TCP/UDP-based); Augmented Reality



NOTE 1: A delay of 20 ms for the delay between a PCEF and a radio base station should be subtracted from a given PDB to derive the packet delay budget that applies to the radio interface. This delay is the average between the case where the PCEF is located "close" to the radio base station (roughly 10 ms) and the case where the PCEF is located "far" from the radio base station, e.g. in case of roaming with home routed traffic (the one-way packet delay between Europe and the US west coast is roughly 50 ms). The average takes into account that roaming is a less typical scenario. It is expected that subtracting this average delay of 20 ms from a given PDB will lead to desired end-to-end performance in most typical cases. Also, note that the PDB defines an upper bound. Actual packet delays - in particular for GBR traffic - should typically be lower than the PDB specified for a QCI as long as the UE has sufficient radio channel quality.

NOTE 2: The rate of non-congestion related packet losses that may occur between a radio base station and a PCEF should be regarded to be negligible. A PELR value specified for a standardized QCI therefore applies completely to the radio interface between a UE and radio base station.

NOTE 3: This QCI is typically associated with an operator controlled service, i.e., a service where the SDF aggregate's uplink / downlink packet filters are known at the point in time when the SDF aggregate is authorized. In case of E-UTRAN this is the point in time when a corresponding dedicated EPS bearer is established / modified.

NOTE 4: If the network supports Multimedia Priority Services (MPS) then this QCI could be used for the prioritisation of non-real-time data (i.e. most typically TCP-based services/applications) of MPS subscribers.

NOTE 5: This QCI could be used for a dedicated "premium bearer" (e.g. associated with premium content) for any subscriber / subscriber group. Also in this case, the SDF aggregate's uplink / downlink packet filters are known at the point in time when the SDF aggregate is authorized. Alternatively, this QCI could be used for the default bearer of a UE/PDN for "premium subscribers".

NOTE 6: This QCI is typically used for the default bearer of a UE/PDN for non-privileged subscribers. Note that AMBR can be used as a "tool" to provide subscriber differentiation between subscriber groups connected to the same PDN with the same QCI on the default bearer.

NOTE 7: For Mission Critical services, it may be assumed that the PCEF is located "close" to the radio base station (roughly 10 ms) and is not normally used in a long distance, home routed roaming situation. Hence delay of 10 ms for the delay between a PCEF and a radio base station should be subtracted from this PDB to derive the packet delay budget that applies to the radio interface.

NOTE 8: In both RRC Idle and RRC Connected mode, the PDB requirement for these QCIs can be relaxed (but not to a value greater than 320 ms) for the first packet(s) in a downlink data or signalling burst in order to permit reasonable battery saving (DRX) techniques.

NOTE 9: It is expected that QCI-65 and QCI-69 are used together to provide Mission Critical Push to Talk service (e.g., QCI-5 is not used for signalling for the bearer that utilizes QCI-65 as user plane bearer). It is expected that the amount of traffic per UE will be similar or less compared to the IMS signalling.

NOTE 10: In both RRC Idle and RRC Connected mode, the PDB requirement for these QCIs can be relaxed for the first packet(s) in a downlink data or signalling burst in order to permit battery saving (DRX) techniques.

NOTE 11: In RRC Idle mode, the PDB requirement for these QCIs can be relaxed for the first packet(s) in a downlink data or signalling burst in order to permit battery saving (DRX) techniques.

NOTE 12: This QCI value can only be assigned upon request from the network side. The UE and any application running on the UE is not allowed to request this QCI value.

NOTE 13: Packet delay budget is not applicable on NB-IoT or when Enhanced Coverage is used for WB-E-UTRAN (see TS 36.300 [19]).

NOTE 14: This QCI could be used for transmission of V2X messages as defined in TS 23.285 [48]. NOTE 15: A delay of 2 ms for the delay between a PCEF and a radio base station should be subtracted from the given

PDB to derive the packet delay budget that applies to the radio interface.

Table 27: Standardised QCI characteristics (including MC services) {Ref [11]}



Table 28: QoS Metrics for Voice over IP (quantitative) {Ref: [15]}