Ref. Ares(2019)1779406 - 18/03/2019
(H2020 730840)
D4.2 – Report on Technical and Quality of Service Viability
Version 1.2
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 Final Version
Document version: 1.2 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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
Document version : 1.2 Page 2 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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.
Document version : 1.2 Page 3 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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
Document version : 1.2 Page 4 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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
Document version : 1.2 Page 5 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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 Exchange of information in the form of data via a network, including video communication transmission (excluding voice communication)
EIRENE An EIRENE network is a railway telecommunications network, based on the network ETSI GSM standard, which complies with all related mandatory requirements specified in the EIRENE FRS and SRS.
European The agency for railway safety and interoperability established by Regulation Railway Agency (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 Value of elapsed time from the request for registration to indication of registration successful registration by CREG response (GSM-R) delay Packet All transmitted data is grouped into packets, which are transmitted via a Switched Data medium that may be shared by multiple simultaneous communication (PSD) sessions.
Quality of QoS describes the quality of a communication service from the user's point Service (QoS) of view. The necessary QoS mechanisms must be implemented along the entire transmission path between the network elements.
Transmission A transmission interference period is the period during the data transmission interference phase of an existing connection in which, caused by the bearer service, no error-free transmission of user data units is possible.
Voice Exchange of information in the form of voice communication, regardless of communication the transmission method
Document version : 1.2 Page 6 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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
Document version : 1.2 Page 7 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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
Document version : 1.2 Page 8 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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.
Document version : 1.2 Page 9 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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.
Document version : 1.2 Page 10 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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.
Document version : 1.2 Page 11 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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.
Document version : 1.2 Page 12 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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)
Document version : 1.2 Page 13 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
• 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
Document version : 1.2 Page 14 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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.
Document version : 1.2 Page 15 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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,
Document version : 1.2 Page 16 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
• 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.
Document version : 1.2 Page 17 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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 UIC description Pre-emption priority 0 Railway emergency calls 1 and below 1 Control-commands (safety) 2 and below 2 Public emergency and group calls 3 and below between drivers in the same area 3 Railway operation 4 (calls between train drivers and controllers) and Control- command information 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).
Document version : 1.2 Page 18 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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).
Document version : 1.2 Page 19 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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.
Document version : 1.2 Page 20 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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.
Document version : 1.2 Page 21 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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.
Document version : 1.2 Page 22 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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 pre- defined 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.
Document version : 1.2 Page 23 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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 <5s mobile-to-fixed calls not covered by the above Other operational mobile-to-fixed <7s calls Other operational mobile-to-mobile <10s calls 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)
Document version : 1.2 Page 24 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
• 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).
Document version : 1.2 Page 25 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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.
Document version : 1.2 Page 26 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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.
Document version : 1.2 Page 27 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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 ERTMS Data/Voice Spec.Ref Functional Description Voice services EIRENE- This section describes the generic voice telephony services which are V FRSv7 to be supported by the railway communication system: 2.2.1 − point-to-point voice calls; − public emergency voice calls; − broadcast voice calls; − group voice calls; − multi-party voice calls.
Voice services EIRENE- All voice call services shall be able to operate between any V FRSv7 combination of fixed and mobile equipment users. 2.2.2 Voice services EIRENE- The system shall support point-to-point voice calls between any two V - Point-to- FRSv7 call parties. point voice 2.2.3 calls
Voice services EIRENE- The IP Communication System should support full duplex V - Point-to- FRSv7 communications. point voice 2.2.4 calls Voice services EIRENE- The system shall allow a user to make public emergency point-to- V - Public FRSv7 point voice calls. emergency 2.2.5 voice calls Voice services EIRENE- The system shall support broadcast voice calls. V - Broadcast FRSv7 voice calls 2.2.7
Voice services EIRENE- The composition of call groups shall be able to be modified within the V - Broadcast FRSv7 network. A single user shall be able to be a member of one or more voice calls 2.2.9 call groups.
Voice services EIRENE- The local area over which broadcast calls shall be implemented shall V - Broadcast FRSv7 be able to be modified within the network. voice calls 2.2.10
Voice services EIRENE- It shall only be possible for the user who initiated the call to talk, V - Broadcast FRSv7 other users can only listen. voice calls 2.2.11
Document version : 1.2 Page 28 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
Voice services EIRENE- The system shall support group voice calls. V - Group voice FRSv7 calls 2.2.12
Voice services EIRENE- The composition of call groups shall be able to be modified within the V - Group voice FRSv7 network. A single user shall be able to be a member of one or more calls 2.2.14 call groups.
Voice services EIRENE- The local area over which group calls are implemented shall be able V - Group voice FRSv7 to be modified within the network. calls 2.2.15 Voice services EIRENE- It is acceptable that only one mobile user involved in the group call V - Group voice FRSv7 may talk at any time. In this case: calls 2.2.16 − 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. Voice services EIRENE- Any radio can transmit and receive data to and from several V - Multi-party FRSv7 different IP sources and destinations addresses. voice calls 2.2.17 Voice services EIRENE- Any of the parties involved in a multi-party voice call shall be able to V - Multi-party FRSv7 talk simultaneously. voice calls 2.2.18 Data services EIRENE- The Communication System network will provide data services to D FRSv7 support the following data applications: 2.3.1 − text messages; (O) − general data applications; (M) − automatic fax; (O) − train control applications. (O)
Data services - EIRENE- The network should support the transmission of point-to-point and D Text messages FRSv7 point-to-multipoint text messages from the ground to mobile users. 2.3.2 (O) Data services - EIRENE- The network should support the receipt of mobile-originated text D Text messages FRSv7 messages by the ground. (O) 2.3.3 Data services - EIRENE- If the text message facility is implemented, it shall not interfere with D Text messages FRSv7 the ability of users to make or receive high priority voice or data 2.3.4 calls. (M)
Data services - EIRENE- The network shall support point-to-point data communications. D General data FRSv7 applications 2.3.6 Data services - EIRENE- The network shall support data rates of at least 2.4 Kbit/s. D General data FRSv7 applications 2.3.8 Data services - EIRENE- The network should support fax transmissions between the ground D Automatic fax FRSv7 and mobile users. (O) 2.3.11
Data services - EIRENE- Where fax functionality is provided, it shall be possible to interrupt D Automatic fax FRSv7 the fax to make or receive a high priority voice or data call. (M) 2.3.12
Data services - EIRENE- Where ERTMS/ETCS level 2 or 3 is implemented, the network shall D Train control FRSv7 be capable of supporting data communications for that train control applications 2.3.13 system. (M)
Document version : 1.2 Page 29 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
Call related EIRENE- The Communication System will support the following call related V services FRSv7 services: 2.4.1 − 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)
Call related EIRENE- It shall be possible for the equipment to display the identity of the V services - FRSv7 called or calling party in the form of a standard telephone number. Display of 2.4.2 identity Call related EIRENE- It shall be possible to display the identity of the called or calling V services - FRSv7 party as a textual description of their function. Display of 2.4.3 identity Call related EIRENE- It should be possible for the network to prevent the identity of V services - FRSv7 certain users from being displayed on the mobile, either when being Restriction of 2.4.4 called, calling or both. (O) display of identity Call related EIRENE- The network shall provide a mechanism whereby calls may be V services - FRSv7 assigned one of a number of different priority levels. Priority and 2.4.5 pre-emption Call related EIRENE- This mechanism shall allow calls with a higher assigned priority to V services - FRSv7 override (pre-empt) existing calls of a lower priority. Priority and 2.4.6 pre-emption Call related EIRENE- Pre-empted calls will be discontinued and the new call of a higher V services - FRSv7 priority shall be connected instead. Priority and 2.4.7 pre-emption Call related EIRENE- The group of users who may access the facilities of the V services - FRSv7 Communication System shall be limited. Closed user 2.4.8 group Call related EIRENE- Any user who is not within the list of allowed Communication System V services - FRSv7 users shall not be able to gain access to any of the functions and Closed user 2.4.9 services provided by the network. (M) group Call related EIRENE- It shall be possible for an incoming call or data message for one user V services - Call FRSv7 to be forwarded to another user using functionality provided by the forwarding 2.4.10 network. (M) Call related EIRENE- In the case of voice calls, it shall be possible for the user who is V services - Call FRSv7 attempting to forward a call to converse with the intended recipient forwarding 2.4.11 prior to forwarding. (M) Call related EIRENE- There are a number of sub-classes of call forwarding to be supported V services - Call FRSv7 by the network: forwarding 2.4.12 − 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) Call related EIRENE- The network shall allow the user to temporarily exit from an existing V services - Call FRSv7 call by putting the call on hold. (M) hold 2.4.13 Call related EIRENE- It shall be possible for the user to re-join the call which is on hold at V services - Call FRSv7 any time. (M) hold 2.4.14
Document version : 1.2 Page 30 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
Call related EIRENE- The network shall provide the ability to inform a user, who is V services - Call FRSv7 involved in an existing call, of attempts by other users to contact waiting 2.4.15 them. (M) Call related EIRENE- Where network services are chargeable, it should be possible for the V services - FRSv7 network to provide information about call rates and on-going call Charging 2.4.16 charges. (O) information Call related EIRENE- It shall be possible, using network management or maintenance V services - Call FRSv7 facilities, to prevent individual users from: (M) barring 2.4.17 − 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. Railway EIRENE- The System shall also provide support for the following railway V specific FRSv7 specific services: services 2.5.1 − 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)
Table 3: Functional requirements of railway communication system (Extracted from EIRENE FRS)
Document version : 1.2 Page 31 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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.
Document version : 1.2 Page 32 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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 < 8.5s (95%), ≤10s (100%) mobile originated calls Connection establishment error <10-2 ratio Maximum end-to-end transfer ≤ 0.5s (99%) delay (30 byte data block) 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.
Document version : 1.2 Page 33 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
• 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.
Document version : 1.2 Page 34 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
• 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.
Document version : 1.2 Page 35 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
• 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
Document version : 1.2 Page 36 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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 QoS parameters 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] 4 ( Up- and Downlink)
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
Document version : 1.2 Page 37 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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 ERTMS Functional Description Specification Ref Network configuration EIRENE-FRSv7 The level of coverage should be at least 95% of the time over - Coverage and 3.2.2 95% of the designated coverage area for a radio installed in a performance vehicle with an external antenna. (O) Network configuration EIRENE-FRSv7 The communication system shall provide communications for - Coverage and 3.2.4 mobiles when stationary and when travelling at speeds up to the performance maximum allowable line speed or 500 km/h, whichever is the lower. (M) Network configuration EIRENE-FRSv7 The required call set-up times shall be achieved in 95% of cases. - Call set-up time 3.4.2 (M) requirement Network configuration EIRENE-FRSv7 Call set-up times for 99% of cases shall not be more than 1.5 - Call set-up time 3.4.3 times the required call set-up time. (M) requirement Network configuration EIRENE-FRSv7 Set-up times shall include the time required for any translation - Call set-up time 3.4.4 of functional numbers internal to the IP communication system. requirement (M) Quality of Service SS-093 v230 The network shall provide a Quality of Service for ETCS data requirements 6.3.1.5 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.
Document version : 1.2 Page 38 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
Quality of Service SS-093 v230 The required QoS parameters shall not depend on network load. requirements 6.3.1.6
Quality of Service SS-093 v230 These performance figures reflect railway operational targets requirements 6.3.1.7 [EEIG 04E117].
Quality of Service SS-093 v230 QoS requirements are specified independently of the method of requirements 6.3.1.8 measurement (refer to [O-2475] for specification of testing).
Quality of Service SS-093 v230 Given the performance constraints of GSM-R, pre-conditions may requirements 6.3.1.11 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. Quality of Service SS-093 v230 Connection establishment delay is defined as: Value of elapsed requirements 6.3.2.1 time between the connection establishment request and the indication of successful connection establishment.
Quality of Service SS-093 v230 In case of mobile originated calls, the delay is defined between requirements 6.3.2.2 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 SS-093 v230 The connection establishment delay of mobile originated calls requirements 6.3.2.3 shall be <8.5s (95%), ≤ 10s (100%).
Quality of Service SS-093 v230 Delays >10s shall be evaluated as connection establishment requirements 6.3.2.4 errors.
Quality of Service SS-093 v230 The required connection establishment delay shall not depend on requirements 6.3.2.5 user data rate of the asynchronous bearer service.
Quality of Service SS-093 v230 The required connection establishment delay is not valid for requirements 6.3.2.6 location dependent addressing.
Quality of Service SS-093 v230 The Connection establishment error ratio is defined as: Ratio of requirements 6.3.3.1 the number of unsuccessful connection establishment attempts to the total number of connection establishment attempts.
Quality of Service SS-093 v230 “Unsuccessful connection establishment attempt” covers all requirements 6.3.3.2 possible types of connection establishment errors caused by end-to-end bearer service.
Quality of Service SS-093 v230 Connection establishment delays >10s shall be evaluated as requirements 6.3.3.3 connection establishment errors.
Quality of Service SS-093 v230 The GSM-R networks should be designed in such a way, that at requirements 6.3.3.4 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. Quality of Service SS-093 v230 If the operational QoS targets of [EEIG 04E117] are wanted, requirements 6.3.3.5 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). Quality of Service SS-093 v230 The connection establishment error ratio of mobile originated requirements 6.3.3.6 calls shall be <10-2 for each attempt.
Quality of Service SS-093 v230 The end-to-end transfer delay of a user data block is defined as: requirements 6.3.4.1 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 Quality of Service SS-093 v230 The delay is defined between the delivery of the first bit of the requirements 6.3.4.2 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. Quality of Service SS-093 v230 The end-to-end transfer delay of a user data block of 30 bytes requirements 6.3.4.3 shall be ≤ 0.5s (99%).
Document version : 1.2 Page 39 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
Quality of Service SS-093 v230 The Connection loss rate is defined as: Number of connections requirements 6.3.5.1 released unintentionally per accumulated connection time.
Quality of Service SS-093 v230 The requirements for connection loss rate varies depending on requirements 6.3.5.2 ETCS system variables such as T_NVCONTACT and the possible train reactions after connection loss (see section 10.5). Quality of Service SS-093 v230 If the operational QoS-targets of [EEIG 04E117] are wanted, requirements 6.3.5.3 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. Quality of Service SS-093 v230 If the connection establishment error ratio is <10-2, then the requirements 6.3.5.4 connection loss rate shall be <10-2/h.
Quality of Service SS-093 v230 A transmission interference period TTI is the period during the requirements 6.3.6.1 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. Quality of Service SS-093 v230 A transmission interference happens, if the received data units of requirements 6.3.6.2 30 bytes deviate partially or completely from the associated transmitted data units. Quality of Service SS-093 v230 The transmission interference period shall be < 0.8s (95%), <1s requirements 6.3.6.3 (99%).
Quality of Service SS-093 v230 An error-free period shall follow every transmission interference requirements 6.3.6.4 period to re- transmit user data units in error (e.g. wrong or lost) and user data units waiting to be served. Quality of Service SS-093 v230 The error-free period shall be >20s (95%), >7s(99%). requirements 6.3.6.5
Quality of Service SS-093 v230 The GSM-R network registration delay is defined as: Value of requirements 6.3.7.1 elapsed time from the request for registration to indication of successful registration by +CREG response.
Quality of Service SS-093 v230 The GSM-R network registration delay shall be ≤ 30s (95%), ≤ requirements 6.3.7.2 35s (99%).
Quality of Service SS-093 v230 GSM-R network registration delays > 40 s are evaluated as requirements 6.3.7.3 registration errors.
Table 6: QoS requirements on railway communication systems (Extracted from EIRENE FRS)
Document version : 1.2 Page 40 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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.
Document version : 1.2 Page 41 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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.
Document version : 1.2 Page 42 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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.
Document version : 1.2 Page 43 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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.
Document version : 1.2 Page 44 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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.
Document version : 1.2 Page 45 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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)
Document version : 1.2 Page 46 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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.
Document version : 1.2 Page 47 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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.
Document version : 1.2 Page 48 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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 Priority Packet Packet Services Type Delay Error Budget Loss Rate 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]}
Document version : 1.2 Page 49 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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 Priority Packet Packet Services Type Delay Error Budget Loss Rate 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.
Document version : 1.2 Page 50 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
• 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.
Document version : 1.2 Page 51 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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.
Document version : 1.2 Page 52 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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.
Document version : 1.2 Page 53 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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.
Document version : 1.2 Page 54 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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 Supports transparent handover between LTE applications 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.
Document version : 1.2 Page 55 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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.
Document version : 1.2 Page 56 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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
Document version : 1.2 Page 57 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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
Document version : 1.2 Page 58 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
Rel-13 MCPTT Rel-14 MC Services Rel-15 MC Services Rel-16 MC (completed 2016) (completed 2017) (completed 2018) Services (in progress) User authentication and User authentication Enhanced MCPTT MCCore Services service authorisation and service group call setup Common authorisation procedure with Functionalities MBMS bearer Enhancements
Affiliation and de- Extended Location Enhanced Location Enhancement of affiliation Features management, MCPTT information and (e.g. Enhanced triggers Broadcast group call, Multiple simultaneous users) Group calls on-network (Dynamic) Group Interconnection MCData additions and off-network (within Management between 3GPP (e.g. Emergency one system or multiple defined MC systems Alert, Enhanced systems, pre-arranged Status, or chat model, late Accessing list of entry, broadcast group deferred calls, emergency group communications) calls)
MCPTT security Group Call (including Interworking with MCVideo additions emergency group legacy systems (e.g. Emergency calls, imminent peril and imminent peril group calls, private emergency alerts) communications, Broadcast Group Call) Simultaneous sessions Transmission and Enhanced handling of for call Reception Control MCPTT Emergency Alerts
Pre-established sessions Short Data Service Enhanced Broadcast (SDS) group call
Location configuration, MC Security Broadcast Group Call reporting and triggering framework
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.
Document version : 1.2 Page 59 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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 Service Attribute Session Session Loss Category Latency Packet establishment Rate peer to peer Loss Rate Voice Low Normal Normal -
Critical Voice Low Low Immediate -
Video Normal Low Normal - Critical Video Low Low Immediate - Very Critical Ultra-Low Ultra- Low Immediate - Data
Critical Data Low Ultra- Low Immediate - (future applications) Critical Data Normal Low Normal <10-2/h (legacy applications) Non-Critical Normal Low Normal - data 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:
Document version : 1.2 Page 60 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
• 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 Service Requirement Attribute value (according 3GPP) Latency Ultra-Low ≤10ms Low ≤100ms Normal ≤500ms Best Effort >500ms Transport reliability - Ultra-Low 99.9999% Packet Loss (%) Low 99.9% Normal 99% Session Immediate <1s Establishment 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.
Document version : 1.2 Page 61 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
• 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.
Document version : 1.2 Page 62 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
Critical Support Description Applications Assured Voice Indication as soon as an end-to-end voice communication link is Communication broken or as long as the end-to-end communication link is active. Multi user talker Limits the number of simultaneous talkers in a multi-user voice control communication and mitigates the risk of miscommunication. Role management A user shall be able to register and deregister to one or more and presence functional identity/ies. Location services The system shall be able to store and provide the location of the user(s) or devices. Authorisation of The system shall be configurable, so that access to voice and communication data communications can be controlled QoS Class The system shall be able to assign different QoS classes in order Negotiation to fulfil the level of communication quality required by the applications. Safety application Authentication of the source of the messages received as a key management trusted source, and shall be able to detect corruption of the communication messages received.
Assured data Indication to the users as soon as an end-to-end data communication 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 Latency Bandwidth Reliability Setup Train Up/Down Speed
Voice Voice 50/50 Low Low High Normal High Communica tion Public Voice 50/50 Low Low High Normal High Emergency Call Railway Voice 50/50 Low Low High Immediate High Emergency Communica tion ATO Data 50/50 Normal Low High Immediate High Critical Data 95/5 Low High High Normal High Realt-time Video Wireless Data 20/80 Normal High Normal Normal High internet for passengers Table 14: QoS of different selected FRMCS application types (FRMCS) {Ref [10]}
Document version : 1.2 Page 63 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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 Service Requirement 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.
Document version : 1.2 Page 64 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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).
Document version : 1.2 Page 65 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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 Comm. Type of QoS Service Attributes Service/Application vector Trans- require- mission ments
List of innovative Application Late Pac- Session Band- services described Category ncy ket establis width in deliverable D2.1 (linked to Loss h-ment 3GPP TR22.889)
Moving Block Train-To- Data Critical Low Ultra- Immedi Low (signalling) Infrastruc communica Data Low ate ture tion (future application)
Data Very Ultra Ultra- Immedi Low communica Critical -Low Low ate tion Data (future application) GOAx (signalling) Train-To- Data Critical Nor Low Immedi Low - ATO - ATP Infrastruc communica Data mal ate ture tion (legacy application) Data Critical Low Ultra- Immedi Low communica Data Low ate tion (future application) Improved railway Train-To- Voice call Critical Low Low Immedi Medium emergency calls Infrastruc Voice ate
Document version : 1.2 Page 66 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
ture Video call Critical Low Low Immedi High Video ate Precise and Train-To- Data Non-critical Nor Low Normal Low certified timing Infrastruc communica data mal and train position ture tion (signalling) Voice, Data Voice, Non- Low- Low- Normal Medium communica critical Nor Norma tion, data, mal l Messaging Messaging IoT-enabled Train-To- Data Non-critical Nor Low- Normal Low maintenance in Infrastruc communica data mal Norma railways (real ture tion l time and smart monitoring TCMS)
Bidirectional real- Data Non-critical Nor Low- Normal Low time monitoring communica data mal Norma and recovery of tion l trains information and voice communication Monitoring Train-To- Data Critical Nor Low Normal Medium infrastructure Infrastruc communica data mal ture tion Real-time video Train-To- Video Video Nor Low Normal High surveillance (on- Infrastruc mal board) ture Cost analysis of Train-To- Data Non-critical Nor Low Normal Low operational and Infrastruc communica data mal maintenance ture tion (Big-Data) Statistical analysis Train-To- Data Non-critical Nor Low Normal Low of safety-related Infrastruc communica data mal failures of ture tion systems and devices Ad-hoc Train-To- Data Non-critical Nor Low Normal Low operational data Infrastruc communica data mal dispatching ture tion
Automated Train- Train-To- Data Non-critical Nor Low Normal Low to-Train Infrastruc communica data mal communication ture tion (information about track conditions, obstacles, weather, etc.) Additional Train-To- Data Non-critical Nor Low Normal Medium information Infrastruc communica data, mal (multi-modal ture tion, seamless Messaging experience) Messaging Messaging Best Low Normal Effor t Electronic Train-To- Data Non-critical Nor Low Normal Low ticketing Infrastruc communica data mal ture tion On board Train-to- Data Non-critical Nor Low Normal High entertainment mobile communica data mal tion One-stop Train-to- Data Non-critical Nor Low Normal Medium
Document version : 1.2 Page 67 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
shopping gateway mobile communica data mal application tion Context aware Train-to- Data Non-critical Nor Low Normal Medium marketing and mobile communica data mal services tion Context aware Train-to- Data Non-critical Nor Low Normal Medium shopping mobile communica data mal tion Railway services Data Non-critical Nor Low Normal Low elicited from the communica data mal metro context tion Assisted decision- Data Non-critical Nor Low Normal Low making: Optimal communica data mal choice for the tion transport and route (criteria: more comfortable, faster, cheaper, better connections, etc.) Real-time Data Non-critical Nor Low Normal Medium timetable communica data mal information tion (enhanced connection and routing information) Provide precise Train-to- Data Non-critical Nor Low Normal Low positioning data of mobile communica data mal trains(e.g. for tion maps/guides in emergency cases) Seamless services Train-to- Data Non-critical Nor Low Normal Medium available on board mobile communica data mal and at the station tion (business) 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 Network coverage: 98% and performance Communication up to a train speed of 500 km/h
Document version : 1.2 Page 68 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
Handover seamless data transmission, success handover success rate shall be 99% Connection drop a call disconnection rate less than 0.01 times per rate hour
Train control data >99% data reliability to transmit data for train control transmission Train control data shall have highest priority.
Network network equipment, core equipment and server shall redundancy 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 Service Attributes Session QCI Category Latency Reliability Priority establishment peer to peer Critical Data ≤100ms 99.9999% 0.5 <1s 69 (future applications) Critical Data ≤500ms 99.9% 5.5 <3s 70 (legacy applications) 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
Document version : 1.2 Page 69 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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
Document version : 1.2 Page 70 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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
Document version : 1.2 Page 71 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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 Service Attribute Session QCI class Category Latency Reliability Priority establishment peer to peer
Voice ≤100ms 99% 2 <3s 1
Critical ≤100ms 99.9% 0.7 <1s 65 Voice Video ≤150ms 99.9% 4 <3s 2 Critical ≤100ms 99.9% 1.5 <1s 67 Video 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.
Document version : 1.2 Page 72 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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,
Document version : 1.2 Page 73 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
• 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).
Document version : 1.2 Page 74 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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 GSM-R 4G (Rel. 12) 5G (Rel. 15,16) implementation incl. MC capabilities Mandatory Priority and Pre- Access Class Barring Enhanced QoS emption mechanisms (ACB), mechanisms (ARP) QoS mechanisms (eMLPP) (ARP). Mandatory Fast Calls Set-up IMS based VoLTE + MC Voice functionality Access Class Barring (MCPTT) Mandatory Railway Emergency and MC Emergency Emergency Calls critical safety voice priority call, (REC, e-REC) services (IMS) MC Localisation Services Mandatory Voice Group Call IMS based VoLTE + MC Group call Service (VGCS) IMS based Push to functionality, talk Over Cellular MC Broadcast calls (PoC) + Enhanced Multimedia Broadcast Multicast Service (eMBMS) Mandatory Voice Broadcast VoLTE + eMBMS: IP MC Broadcast calls Calls (VBS) multicast of voice services Mandatory Functional Session Initiation Session Initiation Addressing (FN) Protocol (SIP) Protocol (SIP) Addressing Addressing Mandatory Location Localisation Services MC Localisation Depending (3GPP Rel. 10) Services Addressing (3GPP Rel. 15) (LDA, eLDA) Optional Data Exchange IMS based SMS IMS based SMS (SMS) Service Service
Optional Direct Mode N/A On-/Off-network communication functionality
Document version : 1.2 Page 75 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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
Document version : 1.2 Page 76 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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 Data size Data rate Cycle Latency Class need time max max min max TCMS Process 1432 Bit 10 Mbit/s 16ms 80ms Message 65388 Bit 10 Mbit/s Not 250ms relevant Supervision Not 10 Mbit/s 50ms 250ms relevant Best Effort Not 10 Mbit/s N/A N/A relevant 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 250ms relevant
Document version : 1.2 Page 77 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
Supervision Not 10 Mbit/s 50ms 250ms relevant Best Effort 4 GByte 10 Mbit/s N/A N/A Streaming Not 100 Kbit/s – 0.1s relevant (Audio), (Audio), 8 Mbit/s 0.5s (Video) (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.
Document version : 1.2 Page 78 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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.
Document version : 1.2 Page 79 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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
Document version : 1.2 Page 80 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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
Document version : 1.2 Page 81 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
9 ANNEX
Items Description Remarks
Coverage Coverage shall be continuous from a time and space and performance 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) External PSTN Broadcasting or group call <1s (90%), <2.5s(99% or connection not more) considered All voice/video calls that do not correspond to the Handover The network shall be able to have seamless data above success transmission, and the handover success rate shall < 3.5s(90%), < 5s(99% or more) Call access success Thebe 99% call access or more. 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 The network shall guarantee more than 99% data transmission reliability to transmit data for train control. Train control data shall have top priority.
Network redundancy The network including eNB equipment, core equipment However, the and server shall be designed to be redundant for application scope stability and availability. of redundancy is determined by the operator.
Broadcasting and group Radio equipment in a restricted area can participate in call area 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]}
Document version : 1.2 Page 82 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
Detailed Mandatory/Op Service Description service tional (M/O) Voice Individual The system shall support voice calling between M service voice call two callers.
Public The system shall allow the user to make a M emergency public emergency call. call Broadcasting The system shall support a broadcasting call. M voice call
Group voice The system shall support a group call. M call
Multi-party The system shall support a multi-party call M voice call between at least 3 different parties.
Data Multimedia The network shall support point-to-point and M service message point-to-multi-point message transmission from service the ground to mobile radio equipment users.
General data The system shall support broadband data M service communication between ground and mobile radio equipment users.
Train control The system shall support seamless data M service communication for stable train control.
Video Individual The system shall support video calling between M service video call two callers.
Group video The system shall support group video calling. M call
Video The system shall support the video information M information transmission function related to safe train transmission operation.
Call Receiver The equipment shall display the receiver or M related /Caller caller ID in the form of a standard telephone service ID display number. Receiver The system shall allow the ID of a specific user O /caller ID to be prevented from being displayed on the display mobile radio equipment. restriction Priority and A function in which a call is allocated to the M pre-emptive member who has top priority among the right members who have different priority levels shall be provided. Closed user The user group who can access the Korean M group railway integrated radio network from outside shall be restricted.
Document version : 1.2 Page 83 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
Detailed Mandatory/Op Service Description service tional (M/O) Call transfer The incoming call or data message for one user M shall be transferred to other devices in the network. Call holding The network shall allow the user to hold a call M temporarily from an existing call.
Call waiting The network shall be able to notify the user of M the existing call that another user is attempting to access. Charging When there is a network service charge, the O information network shall be able to provide the information on call charge and ongoing call charges.
Call The system shall be able to restrict a call using M restriction the network management or maintenance facility. Automatic A call shall be answered automatically M answering according to the priority of an incoming call. service
All voice/ A call shall be answered automatically M Video call according to the priority of an incoming call. recording
Railway Functional The system shall provide the addressing system M specializ addressing in which the Controller can set communication ed with the train driver using train number service Location- The system shall provide the location- M dependent dependent addressing system in order to addressing identify the destination number, which varies depending on the location of users Railway The network shall provide the system to handle M emergency a voice call with high priority for a railway call emergency call
Shunting The network shall provide the system to M mode regulate and control the user’s access to the function and features of mobile radio equipment being used for shunting mode Direct Thecommunication system shall support direct communication O communicati between terminals in the event that an LTE- on based railway communication service is not normally available due to a failure in eNB.
Table 24: Minimum functional requirements for LTE based railway communication system {Ref [14]}
Document version : 1.2 Page 84 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
Application Service Attribute Session Session Loss Category (according to Table establishment Rate 12.10-1) Latency Packet peer to Loss Rate peer Voice Low Normal Normal NA
Critical Voice Low Low Immediate NA
Video Normal Low Normal NA Critical Video Low Low Immediate NA Very Critical Ultra-Low Ultra- Low Immediate NA Data (Note 1) Critical Data Low Ultra- Low Immediate NA (future applications) Critical Data Normal Low Normal <10-2/h (legacy applications) Non-Critical Normal Low Normal NA data 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 FRMCS – System Service Requirement Requirement Attribute value Latency Low Ultra-Low ≤10ms Low ≤100ms Normal Normal ≤500ms Best Effort >500ms Transport reliability - High Ultra-Low 99.9999% Packet Loss (%) Low 99.9% Normal Normal 99% Table 26: FRMCS – Service attribute mapping (quantitative) {Ref [10]}
Document version : 1.2 Page 85 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
QCI Resource Priority Packet Packet Example Services Type Level Delay Error Loss Budget Rate Conversational Voice 1 2 100 ms 10-2 (NOTE 3) (NOTE 1, NOTE 11) Conversational Video (Live Streaming) 2 4 150 ms 10-3 (NOTE 3) GBR (NOTE 1, NOTE 11)
-3 Real Time Gaming, V2X messages 3 3 50 ms 10 Electricity distribution - medium voltage (e.g. (NOTE 3, (NOTE 1, TS 22.261 [51] clause 7.2.2) NOTE 14) NOTE 11) Process automation - monitoring (e.g. TS 22.261 [51] clause 7.2.2) Non-Conversational Video (Buffered Streaming) 4 5 300 ms 10-6 (NOTE 3) (NOTE 1, NOTE 11) Mission Critical user plane Push To Talk 65 0.7 75 ms voice (e.g., MCPTT) (NOTE 3, (NOTE 7, 10-2 NOTE 9, NOTE 8) NOTE 12) Non-Mission-Critical user plane Push To 66 100 ms Talk voice (NOTE 3, 2 (NOTE 1, 10-2 NOTE 12) NOTE 10) Mission Critical Video user plane 67 100 ms (NOTE 3, 1.5 (NOTE 1, 10-3 NOTE 12) NOTE 10) V2X messages 75 2.5 50 ms 10-2 (NOTE 14) (NOTE 1) IMS Signalling 5 1 100 ms 10-6 (NOTE 3) (NOTE 1, NOTE 10) Video (Buffered Streaming) 6 -6 TCP-based (e.g., www, e-mail, chat, ftp, p2p (NOTE 4) 6 300 ms 10 file sharing, progressive video, etc.) (NOTE 1, NOTE 10) Voice, 7 Non-GBR -3 Video (Live Streaming) (NOTE 3) 7 100 ms 10 Interactive Gaming (NOTE 1, NOTE 10)
8 Video (Buffered Streaming) (NOTE 5) 8 300 ms -6 TCP-based (e.g., www, e-mail, chat, ftp, p2p (NOTE 1) 10 file sharing, progressive video, etc.) 9 9 (NOTE 6)
-6 Mission Critical delay sensitive signalling 69 0.5 60 ms 10 (e.g., MC-PTT signalling, MC Video (NOTE 3, (NOTE 7, signalling) NOTE 9, NOTE 8) NOTE 12)
-6 Mission Critical Data (e.g. example 70 5.5 200 ms 10 services are the same as QCI 6/8/9) (NOTE 4, (NOTE 7, NOTE 12) NOTE 10) V2X messages 79 6.5 50 ms 10-2 (NOTE 14) (NOTE 1, NOTE 10)
-6 Low latency eMBB applications (TCP/UDP- 80 6.8 10 ms 10 based); (NOTE 3) (NOTE 10, Augmented Reality NOTE 15)
Document version : 1.2 Page 86 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
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]}
Document version : 1.2 Page 87 of 88 Submission date: 2019-03-12 MISTRAL D4.2 – Report on Technical and Quality of Service Viability
Table 28: QoS Metrics for Voice over IP (quantitative) {Ref: [15]}
Document version : 1.2 Page 88 of 88 Submission date: 2019-03-12