2018 - 5G and Vertical Services, Use Cases and Requirements

5G Programmable Infrastructure Converging
disaggregated network and compUte Resources
D2.1 5G and Vertical Services,

use cases and requirements
This project has received funding from the European Union’s Framework Programme
Horizon 2020 for research, technological development and demonstration
5G PPP Research and Validation of critical technologies and systems
Project Start Date: 1st June 2017 Duration: 30 months

Call: H2020-ICT-2016-2 Date of delivery: 31st January 2018
Topic: ICT-07-2017 Version 2.0
Project co-funded by the European Commission

Under the H2020 programme
Dissemination Level: Public
Grant Agreement Number: 762057
5G Programmable Infrastructure Converging dis-

Project Name:
aggregated network and compUte REsources
Project Acronym: 5G-PICTURE
Document Number: D2.1
5G and Vertical Services, use cases and require-

Document Title:
ments
Version: 2.0
Delivery Date: 31st January 2018
Responsible: Telecom Italia (TIM)
Andrea DI GIGLIO (TIM), Annachiara PAGANO

Editor(s): (TIM), Alessandro PERCELSI (TIM), Laura SERRA
(TIM)
Authors: Azahar Machwe (ZEETTA), Crispin Dent-Young

(ZEETTA), Juan Agustí Moreno (COMSA), Paula
Ciria (FGC), Manuel Alfageme Alonso (COMSA),
George Lyberopoulos (COS), Helen Theodoropou-
lou (COS), Ioanna Mesogiti (COS), Konstantinos
Filis (COS), Adamantia Polydorou (COS), Christos
Tsironas (COS), Spilios Spiliadis (COS), Andrea Di
Giglio (TIM), Annachiara Pagano (TIM), Alessandro
Percelsi (TIM), Laura Serra (TIM), Jobin Francis
(TUD), Jens Bartelt (TUD, AIR), Jay-Kant
Chaudhary (TUD), Anna Tzanakaki (UNIVBRIS-
HPN), Markos Anastasopoulos (UNIVBRIS-HPN),
Dimitra Simeonidou (UNIVBRIS-HPN)
Keywords: Requirements, 5G, use cases, verticals.
Status: Final
Dissemination Level Public
Project URL: http://www.5g-picture-project.eu/

5G-PICTURE Deliverable
Revision History
Rev. N Description Author Date
Definition of table of contents and

0.1 Antonia Paolicelli 19th July 2017
distribution of work
Identification of verticals, definition
0.3 Andrea Di Giglio 8th September 2017
of parameters
Experts from TIM, TUD,
0.6 First draft of vertical description COS, UNIVBRIS, ZEETTA, 28th September 2017
COMSA
First complete draft including sec-
1.0 COS, UNIVBRIS, ZEETTA, 23nd November 2017
tion about stakeholders
COMSA
Enhanced version with more com- Experts from TIM, TUD,
1.6 plete description of vertical re- COS, UNIVBRIS, ZEETTA, 19th December 2017
quirements COMSA
1.10 First complete draft COS, UNIVBRIS, ZEETTA, 10th January 2018
COMSA
1.13 Version to be reviewed Andrea Di Giglio 16th January 2018
Version to be sent to the Project

1.15 Coordinator for approval, after Andrea Di Giglio 29th January 2018
comments from reviewers
2.0 Final version to be deliver to EC Project Coordinator 31st January 2018
H2020-ICT-2016-2017-762057 Page 3 of 88 31. Jan. 2018

Table of Contents
LIST OF FIGURES ......................................................................................................................................... 7
LIST OF TABLES ........................................................................................................................................... 8
1 EXECUTIVE SUMMARY .................................................................................................................... 10
2 INTRODUCTION ................................................................................................................................. 11
3 5G-PICTURE OVERVIEW ................................................................................................................. 12
3.1 5G-PICTURE vision ..........................................................................................................................................12
3.2 Terminology/Definitions ................................................................................................................................14
4 VERTICALS IN 5G ECOSYSTEM AND IN 5G-PICTURE ............................................................. 16
4.1 Rail .................................................................................................................................................................19

4.1.1 Rail operations critical support services ....................................................................................................... 21
4.1.1.1 Requirements............................................................................................................................................ 23
4.1.1.2 Challenges ................................................................................................................................................. 25
4.1.1.3 5G-PICTURE innovations ........................................................................................................................... 27
4.1.2 Rail operation non-critical support services ................................................................................................. 27
4.1.2.1 Requirements............................................................................................................................................ 27
4.1.2.2 Challenges ................................................................................................................................................. 31
4.1.3 Enhanced passenger experience .................................................................................................................. 33
4.1.3.1 Requirements............................................................................................................................................ 33
4.1.3.2 Challenges ................................................................................................................................................. 34
4.1.4 Requirements summary for Rail ................................................................................................................... 34
4.2 Smart city and IoT ..........................................................................................................................................36

4.2.1 Machine-type Communications .................................................................................................................... 37
4.2.1.1 Requirements............................................................................................................................................ 37
4.2.1.2 Challenges ................................................................................................................................................. 38
4.2.1.3 5G-Picture Innovations ............................................................................................................................. 38
4.2.2 Mission-critical Applications ......................................................................................................................... 38
4.2.2.1 Requirements............................................................................................................................................ 39
4.2.2.2 Challenges ................................................................................................................................................. 39
4.2.2.3 5G-PICTURE Innovations ........................................................................................................................... 39
4.2.3 Disaster Monitoring and Public Safety Services ............................................................................................ 40
4.2.3.1 Requirements............................................................................................................................................ 40
4.2.3.2 Challenges ................................................................................................................................................. 41
4.2.4 Tactile Internet ............................................................................................................................................. 41
4.2.4.1 Requirements............................................................................................................................................ 41
4.2.4.2 Challenges ................................................................................................................................................. 42
H2020-ICT-2016-2017-762057 Page 4 of 88 31. Jan. 2018


4.2.5 Requirements summary for smart city and IoT ............................................................................................ 42
4.3 Stadium and mega events ..............................................................................................................................43

4.3.1 High Speed Wireless Access .......................................................................................................................... 47
4.3.1.1 Requirements............................................................................................................................................ 48
4.3.1.2 Challenges ................................................................................................................................................. 48
4.3.2 URLLC/ Critical Communications (Big Red Button) ....................................................................................... 49
4.3.2.1 Requirements............................................................................................................................................ 49
4.3.2.2 Challenges ................................................................................................................................................. 50
4.3.3 Wireless Access Connectivity for Private/Local Events ................................................................................. 51
4.3.3.1 Requirements............................................................................................................................................ 51
4.3.3.2 Challenges ................................................................................................................................................. 52
4.3.4 IoT Services (Asset tracking, Power Management)....................................................................................... 52
4.3.4.1 Requirements............................................................................................................................................ 52
4.3.4.2 Challenges ................................................................................................................................................. 53
4.3.5 Next Generation Applications ....................................................................................................................... 53
4.3.5.1 Requirements............................................................................................................................................ 54
4.3.5.2 Challenges ................................................................................................................................................. 55
4.3.6 UHD Broadcasting Services ........................................................................................................................... 55
4.3.6.1 Requirements............................................................................................................................................ 56
4.3.6.2 Challenges ................................................................................................................................................. 56
4.3.7 Requirements summary for stadium and mega event ................................................................................. 57
4.4 Industry 4.0 ....................................................................................................................................................58

4.4.1 Robotics Arms Control .................................................................................................................................. 59
4.4.1.1 Requirements............................................................................................................................................ 59
4.4.1.2 Challenges ................................................................................................................................................. 60
4.4.2 Automated Guided Vehicles ......................................................................................................................... 61
4.4.2.1 Requirements............................................................................................................................................ 61
4.4.2.2 Challenges ................................................................................................................................................. 62
4.4.3 Video applications: Video-surveillance ......................................................................................................... 62
4.4.3.1 Requirements............................................................................................................................................ 62
4.4.3.2 Challenges ................................................................................................................................................. 63
4.4.4 Video applications: quality check ................................................................................................................. 63
4.4.4.1 Requirements............................................................................................................................................ 63
4.4.4.2 Challenges ................................................................................................................................................. 64
4.4.5 Video applications: augmented reality ......................................................................................................... 64
4.4.5.1 Requirements............................................................................................................................................ 64
4.4.5.2 Challenges ................................................................................................................................................. 65
4.4.6 Requirements summary for Industry 4.0 ...................................................................................................... 65
5 VERTICALS, STAKEHOLDERS AND ROLES ................................................................................ 67
H2020-ICT-2016-2017-762057 Page 5 of 88 31. Jan. 2018

6 NETWORK REQUIREMENTS .......................................................................................................... 69
6.1 Requirements’ Description Conventions ........................................................................................................69
6.2 Performance Requirements ...........................................................................................................................69
6.3 Functional Requirements ...............................................................................................................................71
6.4 Other Requirements.......................................................................................................................................74
7 CONCLUSIONS .................................................................................................................................... 77
8 APPENDIX A: DETAILS ON RAIL COMMUNICATION SYSTEMS ........................................... 79
9 REFERENCES ....................................................................................................................................... 84
10 ACRONYMS ...................................................................................................................................... 86
H2020-ICT-2016-2017-762057 Page 6 of 88 31. Jan. 2018

List of Figures
Figure 1: 5G-PICTURE concept leveraging on 5G-XHaul solution. ................................................................ 13
Figure 2: Vertical categories addressed by 5G [3]. ......................................................................................... 17
Figure 3: 5G Services (source ITU). ................................................................................................................ 17
Figure 4: Different groups of rail applications. ................................................................................................. 20
Figure 5: Signalling systems for train control transported over communication system. ................................ 22
Figure 6: FGC scenario (today). ...................................................................................................................... 24
Figure 7: New communications architecture for railway industry. ................................................................... 25
Figure 8: Ethernet TCN.................................................................................................................................... 29
Figure 9: Pictorial view of the requirements, following ITU-R for each group of applications. ........................ 35
Figure 10: Synthesis of the requirements, following ITU-R. ............................................................................ 35
Figure 11: Pictorial view of the requirements, following ITU-R........................................................................ 42
Figure 12: Synthesis of the requirements following ITU-R. ............................................................................. 43
Figure 13: Connectivity across the networks in a Stadium.............................................................................. 45
Figure 14: Mixed Stadium Network Deployment - Wi-Fi and Wired access.................................................... 46
Figure 15: 5G Enabled Stadium Deployment – pure wireless, no wired access............................................. 46
Figure 18: Pictorial view of the vertical “Industry 4.0”. ..................................................................................... 59
Figure 21: Moving blocks. ................................................................................................................................ 80
Figure 22: CBTC over Wi-Fi. ........................................................................................................................... 81
H2020-ICT-2016-2017-762057 Page 7 of 88 31. Jan. 2018

List of Tables
Table 1: Definition of requirements considered for the use cases/applications analysis. ............................... 14
Table 2: Features of operational voice service and their relevance. ............................................................... 22
Table 3: Requirements for rail operations critical support services. ................................................................ 24
Table 4: Real time requirements for ETB. ....................................................................................................... 30
Table 5: Real time requirements for ECN........................................................................................................ 30
Table 6: Real-time requirements for additional ECN’s sensor buses. ............................................................. 30
Table 7: Requirements for rail operations non-critical support services. ........................................................ 31
Table 8: Requirements for rail passenger experience. .................................................................................... 33
Table 9: Smart city applications [16]. ............................................................................................................... 36
Table 10: Requirements for machine-type communication [18], [19]. ............................................................. 37
Table 11: Requirements for mission-critical applications [18], [20]. ................................................................ 39
Table 12: Requirements for disaster monitoring and public safety [18][19][21]. ............................................. 40
Table 13: Requirements for tactile internet [18][22]. ....................................................................................... 41
Table 14: Stadium and Mega Events – Services Overview. ........................................................................... 47
Table 15: Stadium and Mega Event Requirements – High Speed Wireless Access. ..................................... 48
Table 16: Stadium and Mega Event Requirements – Critical Communications, Emergency Services. ......... 49
Table 17: Stadium and Mega Event Requirements – Wireless Access for Private/Local Events. .................. 51
Table 18: Stadium and Mega Event Requirements – IoT Services. ............................................................... 53
Table 19: Crowdsourced Video Application Scaling. ....................................................................................... 54
Table 20: Stadium and Mega Event Requirements – Crowdsourced Video. .................................................. 54
Table 21: Stadium and Mega Event Requirements – UHD Broadcasting. ...................................................... 56
Table 22: Requirements for industry 4.0 – robotics arms control. ................................................................... 60
Table 23: Requirements for industry 4.0 – automated guided vehicles. ......................................................... 61
Table 24: Requirements for industry 4.0 – Video-surveillance. ....................................................................... 62
Table 25: Requirements for industry 4.0 – Quality check use case. ............................................................... 63
Table 26: Requirements for industry 4.0 – Augmented reality. ....................................................................... 64
Table 27: Requirements Definition in Tabular Format. .................................................................................... 69
Table 28: Low delay latency requirement. ....................................................................................................... 70
Table 29: High bandwidth requirement............................................................................................................ 70
Table 30: High mobility requirement. ............................................................................................................... 70
Table 31: High connection density requirement. ............................................................................................. 70
Table 32: Traffic density requirement. ............................................................................................................. 70
Table 33: Air interface requirement. ................................................................................................................ 71
Table 34: BBUs virtualisation requirement. ..................................................................................................... 71
Table 35: High Capacity, Elastic Optical Network requirement. ...................................................................... 72
H2020-ICT-2016-2017-762057 Page 8 of 88 31. Jan. 2018
Table 36: HW Programmability requirement. .................................................................................................. 72

Table 37: Programmable Distributed Pools of (Compute/Network) Resources requirement. ......................... 72
Table 38: Management & Orchestration of Distributed Pools of Resources requirement. ............................. 73
Table 39: Synchronisation across Heterogeneous Access and Transport Networks requirement. ................ 74
Table 40: Multi-tenancy requirement. .............................................................................................................. 74
Table 41: Slicing requirement. ......................................................................................................................... 74
Table 42: Modularity requirement. ................................................................................................................... 75
Table 43: Extensibility/Upgradability requirement. .......................................................................................... 75
Table 44: Maintainability requirement. ............................................................................................................. 75
Table 45: Interoperability with Various Network Technologies requirement. .................................................. 75
H2020-ICT-2016-2017-762057 Page 9 of 88 31. Jan. 2018

1 Executive Summary
5G-PICTURE proposes a paradigm shift, from the traditional Distributed Radio Access Network (D-RAN) and
Cloud RAN (C-RAN) to the new concept of “Dis-Aggregated RAN” (DA-RAN), where hardware and software
components are disaggregated across the wireless, optical and compute/storage domains. Resource dis-
aggregation allows decoupling these components, creating a common “pool of resources” that can be inde-
pendently selected and allocated on demand to compose any infrastructure service. Key enablers for DA-
RAN are the network softwarisation, migrating from the conventional closed networking model to an open
reference platform, supported through hardware programmability, where hardware is configured directly by
network functions, to provide the required performance. This will enable provisioning of any service by flexi-
bly mixing-and-matching network, compute and storage resources without sacrificing performance and effi-
ciency.
The challenging ambition of 5G-PICTURE is to demonstrate both theoretically and experimentally the suc-
cess of the DA-RAN approach and that this architecture is suitable to satisfy the requirements of the most
important verticals (high speed rail, smart city and internet of things, stadium and mega event, and industry
4.0). Each of these verticals has specifically challenging requirements, whose identification together with the
delineation of stakeholders and their role in the 5G network allow to identify the requirements on the underly-
ing network. Work package 2 “5G and Verticals Services, Requirements and Architecture” of 5G-PICTURE
concentrates its effort on this topic and this deliverable reports about it.
The following step is the analysis of some functional requirements in order to support the idea that DA-RAN
can make a fundamental contribution to the development of the new 5G network. In fact, the analysis led to
consider as fundamental the hardware programmability and the programmable distribution of network re-
sources (to support different access and transport technologies and to deliver high Quality of Service (QoS)
network connectivity), the baseband unit (BBU) virtualisation (due to the different latency and jitter require-
ment for the verticals and the applications), multi-tenancy and slicing (in order to improve the efficiency of the
network) and finally the interoperation with various network technologies. All the listed characteristics are
cornerstones of the DA-RAN and of 5G-PICTURE project and are extensively reported in the deliverable.
H2020-ICT-2016-2017-762057 Page 10 of 88 31. Jan. 2018

2 Introduction
5G-PICTURE will develop and demonstrate a converged fronthaul (FH) and backhaul (BH) infrastructure in-
tegrating advanced wireless and novel optical network solutions. Τo address the limitations of the current
distributed Radio Access Network (D-RAN) and Cloud-RAN (C-RAN) approaches, 5G-PICTURE will exploit
flexible functional splits that can be dynamically selected, to optimise resource and energy efficiency.
This results in a paradigm shift from RAN and C-RAN to “Dis-Aggregated RAN” (DA-RAN). DA-RAN is a
novel concept where hardware (HW) and software (SW) components are disaggregated across the wireless,
optical and compute/storage domains. “Resource disaggregation” allows decoupling these components, cre-
ating a common “pool of resources” that can be independently selected and allocated on demand to com-
pose any infrastructure service. Key enablers for DA-RAN are:
1. Network “softwarisation”, migrating from the conventional closed networking model to an open
reference platform, supported through HW programmability, as described in the following point.
2. HW programmability, where HW is configured directly by network functions, to provide the required
performance. This will enable provisioning of any service by flexibly mixing-and-matching network,
compute and storage resources without sacrificing performance and efficiency as is the case in
today’s NFV-based solutions.
The 5G-PICTURE solution will enable the overall 5G vision, supporting any service, including operational
and end-user services for both Information and Communications Technology (ICT) and “vertical" industries.
Proof of concept demonstrators will be showcased in realistic environments including:
 A 5G-railway testbed located in Barcelona, Spain comprising three tracks covering scenarios with
the rolling stock. This will be the first 5G railway experimental testbed to showcase support of
seamless service provisioning and mobility management in high speed moving environments.
 A 5G-smart city testbed to experimentally validate the DA-RAN concept through the support of joint
BH and FH services. This testbed will be supported and hosted by the state-of-the-art 5G “City of
Bristol” network infrastructure.
 A 5G-stadium testbed located in Bristol, UK to address scenarios with increased density and static-
to-low mobility. In this environment media services associated with large venues will be
demonstrated.
These “verticals” are analysed in detail, form the definition of requirements point of view, together with a very
important and emerging service involving Industry 4.0, considering not only the robot control use case, but
also applications related to virtual reality and safety.
Organisation of the document

This deliverable, devoted to the definition of use cases and requirements, is structured in four main sections.
The first one (Chapter 3) is dedicated to introduce the 5G-PICTURE vision (since it is the first technical de-
liverable of the Project) and to state the main parameters that will be evaluated for each analysed vertical.
Chapter 4 is dedicated to the analysis of verticals. Taking into account that 5G-PICTURE will demonstrate a
5G railway experimental testbed, converged FH and BH services in a smart city environment, and stadi-
um/mega event vertical, the study will focus on these scenarios. Moreover, the analysis will also be comple-
mented with a very important and emerging service involving the Industry 4.0 environment.
Furthermore, Chapter 5 reports on the role of different stakeholders in the development of the novel chal-
lenging network, including traffic generated by innovative verticals.
Finally, an analysis of the requirements has been developed in Chapter 6. In particular, performance re-
quirements and functional requirements, that need to be addressed by the 5G-PICTURE network architec-
ture and technologies selection, have been highlighted in a tabular form.
H2020-ICT-2016-2017-762057 Page 11 of 88 31. Jan. 2018

3 5G-PICTURE Overview
3.1 5G-PICTURE vision
It is generally admitted that the explosive growth of mobile internet traffic will soon reach the limits of the cur-
rently deployed 4G technology networks, while future services’ QoS targets in terms of bandwidth per ser-
vice, latency, number of device connections, traffic density, mobility, etc., are far beyond the existing 4G
technologies’ capabilities. At the same time, the whole ICT ecosystem moves from technology-driven ap-
proaches to service-driven ones. In practice, this means that, unlike current network deployments, based on
the satisfaction of service-agnostic, abstract and (network-wide) cumulative requirements; next-generation
network deployments will need to satisfy more flexible and varied requirements which will be dictated by the
specific stakeholders/applications/services. Technology-wise there is no smooth migration from existing
closed, static and inelastic network infrastructures/technologies which can satisfy these service-level ad-
vancements, and this introduces the need to transform traditional network infrastructures into open, scalable
and elastic ecosystems that can support a large variety of dynamically varying applications and services. In
this context, current 5G-related efforts focus on the following main areas:
 High capacity wireless access network technologies to serve both the access network connections
and fronthaul (FH) / backhaul (BH) network links.
 Convergence of fixed access/FH/BH networks into common infrastructures exploiting optical net-
works offering abundant capacity, long reach transmission capabilities, carrier-grade attributes and
energy efficiency.
 Softwarisation of network functions (NFV and SDN).
 Integration of network HW components to large pools, exploiting cloud architectures and
technologies.
 Multi-tenancy over integrated network and compute/storage infrastructures.
Especially the EU funded project 5G-XHaul [1] – now reaching its final stage – is delivering a converged op-
tical and wireless network solution. It relies on a dynamically, high capacity, low latency, point-to-multipoint
5G wireless access network based on millimetre wave (mmWave) transceivers (implementing massive
MIMO techniques) cooperating with Sub-6 GHz systems, integrated with a hybrid optical network comprising
a Passive Optical Network (PON) and a dynamic optical network solution. The dynamic optical network solu-
tion employs the Time Shared Optical Network (TSON), offering dynamic, elastic and fine granular band-
width allocation. These components are controlled by a software-defined, cognitive, hierarchical control
plane – exploiting Software Defined Networking (SDN) – and can be reconfigured based on traffic demand
forecasts in time and space. In practice, 5G-XHaul focuses on the lower layers of future 5G deployments as
enablers for higher layer 5G technologies.
5G-PICTURE will rely on and extend the 5G-XHaul wireless access and transport technologies, as key tech-
nologies to satisfy the lower layer connectivity requirements offering converged FH and BH services [2]. Lev-
eraging on the 5G-XHaul solution, 5G-PICTURE aims at delivering a 5G network paradigm which:
 Will support different functional splits at the transport network layer (addressed in 5G-XHaul). The
functional splits will be flexibly decided depending on a number of factors such as the access
network technology and capabilities (e.g., wireless, optical, 4G/5G access network nodes), the
transport network performance (e.g., link capacity) and the service characteristics (latency
requirements, physical/virtual location of end devices, etc.).
 Will go beyond the currently widely addressed (even adopted) C-RAN and D-RAN approaches and
propose the innovative concept of DA-RAN. This will heavily involve disaggregation of resources
within the Data Centres (DCs) to most efficiently support FH/BH services and the concept of optimal
functional splits as well as disaggregation of network resources. This approach will allow to
interconnect, in a common infrastructure, a large number of “disaggregated” compute/storage and
network elements (e.g. VNFs, BBU processing functions) running practically on “pools of resources”.
These are distributed to different virtual or physical (geographical) locations applying different
models so that resource assignment is performed in the most efficient way, towards the realisation of
a large variety of very different services. This implies decoupling of HW and SW components to
enable the creation of a common “pool of resources” that can be independently selected and
H2020-ICT-2016-2017-762057 Page 12 of 88 31. Jan. 2018
allocated on demand to compose any infrastructure service. Due to its modular approach,
disaggregation offers increased flexibility, enhanced scalability, upgradability and sustainability
potential that are particularly relevant for 5G environments.
 Will provide the necessary resource management and orchestration layer, capable of performing on-
demand instantiation of disaggregated network/compute/storage components, satisfying their
stakeholder/service-defined QoS requirements.
Ultimately, 5G-PICTURE aims at providing a stakeholder/service-driven approach towards optimal infrastruc-
ture resource utilisation.
The 5G-PICTURE concept is depicted in Figure 1. This figure also indicates the relation between 5G-XHaul
and 5G-PICTURE development activities and how the baseline functional blocks/technologies available by
5G-XHaul can be adopted to serve the generic architecture of 5G-PICTURE introducing advanced features,
functionalities, and services.
In the context of 5G-PICTURE, a pool of disaggregated HW (network/storage/processing) components, de-
picted in Figure 1(a), can be used to instantiate virtual and physical network functions (VNF, PNF) potentially
selected from a pool of functions – see Figure 1(d). Among the disaggregated components, high capacity
wireless access technologies and optical links inherited from 5G-XHaul are considered. 5G-PICTURE will
extend the transport network technologies and the control plane (VNFs, PNFs) delivered by 5G-XHaul for
these network components.
e)
5G-PICTURE Monitoring and Profiling
Operations and Support
OS NFV Slicing
System
(OSS)
SDN Controller
Orhestrator Manager
PNF
(Synchronization)
PNF
(Signal Processing/ VNF VNF
d)
massive MIMO)
VNF
PNF (vEPC) controller
(beam tracking) VNF
PNF VNF VNF
(FFT, iFFT) (vMME, vCDN controller
vBBU)
VIM VIM VIM VIM
b) Fast
c) Fast
Switch Switch
module λ1 module λ1
BVT/ BV- BVT/
BV- MUX MUX R
R WSS MPI
MPI WSS Fast
Fast
Switch Switch
module λ2 module λ2
OPP MPI
MPI OPP
MPI BVT/ BVT/ MPI

BV- MUX BV- MUX R
R WSS WSS Tx
Tx Fast Fast
Switch Switch
module λΝ module λΝ
VIM VIM VIM VIM VIM VIM VIM
RRH mmWave PON

RAM Storage Processing (specific) Processing (general)
a)
5G-XHaul 5G-PICTURE
Figure 1: 5G-PICTURE concept leveraging on 5G-XHaul solution.
The connection between the HW components will be established on demand using a pool of edge nodes
with Multi-protocol, Multi-PHY interfaces (MPI) and fast packet/flow processing capabilities based on the
H2020-ICT-2016-2017-762057 Page 13 of 88 31. Jan. 2018

Open Packet Processor (OPP), exploiting HW programmability capabilities (see Figure 1(b)), and utilising
also an elastic optical network infrastructure (based on TSON and/or Flex-E) (see Figure 1(c)). The concept
of functional splits will be addressed taking into consideration not only transport network requirements, but
also compute/storage related aspects involving the comparison of General Purpose Units complimented with
HW accelerators as well and Specific Purpose Processors and Hybrid models.
The management of resources will be undertaken by an upper layer Network management and Orchestra-
tion platform, as shown in Figure 1 (e).
In a nutshell, 5G-XHaul addressed the network technologies to be utilised and extended in the context of
5G-PICTURE, while the latter project expands further to compute/storage technologies and their control.
3.2 Terminology/Definitions
Table 1 is the reference for the definition of parameters that are used to identify the requirements for the se-
lected use cases/applications for each vertical. For the purpose of completeness, a full set of parameters is
provided, even if, depending on the specific application, some of these may not be so relevant.
Table 1: Definition of requirements considered for the use cases/applications analysis.
Type of value,
Requirement Definition Reference
unit of measure
end-to-end latency: the time it takes to transfer a given piece
of information from a source to a destination, measured at the
communication interface, from the moment it is transmitted by
the source to the moment it is successfully received at the 3GPP TS22.261
latency ms
destination. [3]
It might be important as well to define as requirement the user
plane latency, with the same definition but different end-
points
frame loss ratio: defined as the percentage of frames that
packet loss Ratio, no units [4]
should have been forwarded by a network but were not.
the bit error ratio (BER) is the number of bit errors divided by
the total number of transferred bits during a studied time inter-
BER Ratio, no units [5]
val. BER is a unitless performance measure, often expressed
as a percentage
energy
the energy consumed for the end-to-end transport of a byte J/byte –
efficiency
security level of importance for attack prevention qualitative –
peak and average values of data rates should be provided (it

could be useful or mandatory to provide also the user experi-
data rate enced data rate: the minimum data rate required to achieve a
sufficient quality experience, with the exception of scenarios
(DL/UL data bit/s –
for broadcast like services, where the given value is the maxi-
rate)
mum that is needed). The data rate is a time-variable function.
It might be important to define some parameters (e.g. peak,
burst, average) in order to better describe the data rate
the short-term variations of a digital signal’s significant in-
jitter ms [6]
stants from their ideal positions in time
variation in latency as measured in the variability over time of
packet delay the packet latency across a network. Packet delay variation is
ms [7]
variation expressed as an average of the deviation from the network
mean latency
percentage value of the amount of sent network layer
packets successfully delivered to a given node within the
reliability time constraint required by the targeted service, divided by the [3]
total number of sent network layer packets. The reliability rate
is evaluated only when the network is available
H2020-ICT-2016-2017-762057 Page 14 of 88 31. Jan. 2018

connection availability: the percentage of available time

(w.r.t. total time) in a generic observation period of the connec-
tion across the transport network. A bidirectional path or con-
nection is in the unavailable state if either one or both direc-
tions are in the unavailable state. ITU-T G.827 [8]
availability
communication service availability: percentage value of the [3]
amount of time the end-to-end communication service is deliv-
ered according to an agreed QoS, divided by the amount of
time the system is expected to deliver the end-to-end service
according to the specification in a specific area.
fixed (no mobility: office, home ) or max speed in movement
mobility (pedestrian or on a transportation mean: train, road vehicle, km/h –
airplane, drone, …)
traffic
traffic in a specific area Mbit/s / km2 –
density
connection
number of devices in a specific area devices / km2 –
density
coverage area of application interest km2 –
Battery
time of battery duration Days, years –
lifetime
data size size of the atomic packet or frame (average, max) bytes –
H2020-ICT-2016-2017-762057 Page 15 of 88 31. Jan. 2018

4 Verticals in 5G ecosystem and in 5G-PICTURE

Contrary to the legacy network technologies (including 4G), for which all the activities related to technology
development and commercialisation, including requirements and specifications definition, design, standardi-
sation and deployment activities, were based on an abstract, application/service agnostic definition of the
network QoS requirements, the respective 5G development activities are based on a more stakehold-
er/application/service requirements aware approach. Practically this means that besides the general tech-
nical QoS Key Performance Indicators (KPIs) and target values for 5G technologies, the actual 5G network
deployments and operation will be tailored (automatically) to support the requirements of a range of stake-
holders and services in a holistic manner. For this purpose, technical activities around 5G are tightly coupled
with activities related to the analysis of stakeholders and their service requirements towards mapping them
to 5G network capabilities, functionalities, deployment strategies, etc. The ultimate goal worldwide is to de-
liver “a stakeholder driven, holistic ecosystem for technical and business innovation integrating networking,
computing and storage resources into one programmable and uniﬁed infrastructure”, “enabling the transport
of software to the data rather than the other way round, i.e. executing software on the device where the data
is produced instead of sending all data to a centralised data centre” [3].
To this end, 5G-related activities are converging to address the following major Vertical industries [3], [10],
[11]:
 Automotive, especially focusing on services provided in high mobility scenarios, Internet of Things
(IoT) applications/services, etc.
 eHealth, especially focusing on remotely provided health services with high latency and reliability
requirements,
 Energy, especially focusing on IoT based energy monitoring, management, and network control
scenarios,
 Media & Entertainment, especially focusing on next generation applications/services provisioning
such as UHD content, Crowdsourced/multi-user created content, highly interactive services, etc., as
well as,
 Factories of the future, referring to Industry 4.0 setups.
It becomes obvious, that these vertical industries involve large service groups, which can be provided by var-
ious business stakeholders depending on the specific market/social environment, and can include various
applications/services. For instance, Energy and Automotive services can be provided/supported by busi-
nesses specialising on IoT deployments, or by public authorities. In the context of media services, remote
monitoring and surveillance services can be considered, provided/supported by public authorities or private
companies.
H2020-ICT-2016-2017-762057 Page 16 of 88 31. Jan. 2018

Figure 2: Vertical categories addressed by 5G [3].
Figure 3: 5G Services (source ITU).
On top of these verticals, existing ICT services and business/stakeholder requirements are considered dur-
ing all steps of 5G technology development, including among others:
 Provisioning of 5G emergency communication services to individuals, first responders, etc.
 Efficient utilisation of ICT infrastructure and the minimisation of its deployment and operation cost.
 Effective support of multiple tenants over a single infrastructure.
Following the top-down approach, the vertical use cases can be broken down to services falling in the 5G
(3GPP, ITU) identified categories: enhanced Mobile Broadband (eMBB), massive Machine Type Communi-
cations (mMTC), Ultra-Reliable and Low Latency Communications (URLLC) and Network Operation ser-
vices.
The work conducted by ITU [12] has resulted in the production of its 5G recommendations, where future 5G
services are classified into three main categories, based on the nature of their QoS requirements (see Figure
3).
H2020-ICT-2016-2017-762057 Page 17 of 88 31. Jan. 2018

 eMBB (enhanced Mobile Broadband): including bandwidth intensive services/applications, i.e. with
(very) high data speed requirements such as streaming, video conferencing, and virtual reality. The
bandwidth requirements of this type of services are expected to be about 100 Mbit/s per user, while
in some cases it can be in the order of some Gbit/s, reaching even 10 Gbit/s.
 mMTC (massive Machine-Type Communications): extending LTE IoT capabilities—for example,
NB-IoT— to support huge numbers of devices with lower costs, enhanced coverage, and long
battery life. This type of services implies the provisioning of connectivity to thousands of end-
devices.
 URLLC (Ultra-Reliable, Low-Latency Communications): referred to as “mission-critical”
communications, including latency-sensitive i.e. services with extremely short network traversal time
requirements, such as applications/services enabling industrial automation, drone control, new
medical applications, and autonomous vehicles. The latency requirements for this type of services
are expected to range between <1 ms – 2 ms for the user plane and less than 10 ms for the control
plane.
In parallel, 3GPP’s work on 5G services and their requirements has resulted in an almost identical classifica-
tion corresponding to enhanced Mobile Broadband (studied in 3GPP TR 22.863), massive Internet of Things
(studied in 3GPP TR 22.861), Critical Communications (studied in 3GPP TR 22.862) services. On top of this,
Network Operation Services (studied in 3GPP TR 22.864) are distinguished as a separate class with a num-
ber of functional requirements such as multi-tenancy, energy efficiency, etc. 3GPP has already started con-
solidating the four Technical Reports into a single Technical Specification (TS 22.261 [13]), where specific
system requirements are reported.
Last but not least, towards addressing the automotive vertical requirements, 5G will consider also the provi-
sioning of services in very high mobility environments up to 500 km/h with acceptable QoS – corresponding
to train speeds.
Following the 5G top-down, from verticals to technologies approach, 5G-PICTURE aims at delivering a 5G
infrastructure able to support a wide variety of 5G ICT and "vertical" services, ranging from delay sensitive
video to infotainment services, and from best effort applications to ultrareliable ones such as M2M communi-
cations. According to the proposed solution, vertical service providers, currently relying on closed and pro-
prietary infrastructures, will be able to deploy any service without having to rely on HW/SW assets they have
to own. The 5G-PICTURE solution will allow end-users and third parties to access real or virtual equipment,
services, systems and tools on demand regardless of their geographical location. This will enable transfor-
mation of vertical sectors from closed inflexible environments into a pool of modular HW and SW compo-
nents that can be combined on demand.
The 5G-PICTURE Verticals that have been selected reflect those currently identified in the 5G ecosystem,
while they address all the main 5G services categories. More specifically:
 The Rail Vertical represents the “Automotive”, and includes eMBB, URLLC and mMTC services.
 The Smart City & IoT Vertical represents the “Energy”, “e-Health” and “Automotive” ones and will
focus primarily on mMTC services.
 The Stadium Vertical represents basically the “Media and Entertainment”, and include eMBB, mMTC
and URLLC (as “red button”, see section 4.3).
 The Industry 4.0 Vertical represents the “Factories of the Future”, and focuses on URLLC, mMTC
and eMBB services.
Network Operation Services, such as slicing and multi-tenancy, are relevant to all 5G-PICTURE verticals as
they facilitate the provision of the differentiated services required by each vertical.
The 5G-PICTURE Verticals and the addressed use cases/applications are described in detail in the follow-
ing sections.
H2020-ICT-2016-2017-762057 Page 18 of 88 31. Jan. 2018

4.1 Rail
Rail vertical introduction
Communications requirements needed by the railway vertical present a greater complexity than it might
seem at first sight. Its existing architecture was built with a mixture of different access technologies that re-
sults in inefficiencies in terms of investment, ease of deployment, versatility, interoperability, capacity, etc. As
such, a new architecture that overcomes many of these issues must be developed, and 5G capabilities are
expected to solve most of them.
The reasons that have led to this compendium of networks must be understood, because these are closely
related to the requirements that will be exposed in this section.
Main users description

A first insight is provided by the specific needs related to different types of transport services. It is easy to
imagine that there are a lot of differences between passengers’ and merchandises’ transport services, but
this is only a first rough division.
Passenger trains provide long-distance intercity travel, daily commuter trips, or local urban transit services.
Trains include a diversity of vehicles, operating speeds, right-of-way requirements and service frequency.
Usually, two types of operations are defined: intercity railway and intra city (urban) transit, with main differ-
ences in train speeds, route lengths, and frequencies (intercity railway involves scheduled, lower frequency
trains, while intra city transit involves higher frequency, especially during peak hours).
High-speed rail are special inter-city trains that operate at much higher speeds than conventional railways;
the limit being regarded at 200 to 320 km/h, with planning at 500 km/h in future. High-speed trains are used
mostly for long-haul service and most systems are in Western Europe and East Asia.
Freight trains may haul bulk material, intermodal containers or specialised freight in purpose-designed cars.
Rail freight practices and economics differ by country and region.
Over the last 25 years the European Commission has been very active in restructuring the rail transport mar-
ket. Since 2001, four legislative packages were adopted with the aim to gradually open rail transport service
markets for competition, making national railway systems interoperable and defining appropriate framework
conditions for the development of a single European railway area. Rail transport offers very significant ad-
vantages in environmental terms, but road freight still dominates the inland freight transport market with a
share of 76.38% against a figure of 17.25% for rail, while the remainder (6.37%) of the freight transported in
the EU-28 is carried along inland waterways [14].
Roles of the different stakeholders

These directives require that large European national railways independently manage the infrastructure and
the rolling stock. The goal is to allow the use of any rail infrastructure by any rail operator on equal terms,
promoting free competition.
Other stakeholders can play different roles within this model: most passenger stations, freight terminals,
marshalling yards and maintenance facilities are directly or indirectly owned and/or managed by holding
structures. To simplify this document, this typology of cases is not included, but these must be kept in mind
along the process of building a complete architecture for this vertical.
Each stakeholder manages their own infrastructure and services through an Operational Control Center
(OCC), a room (or a set of rooms) serving as a central space where a large physical facility or physically dis-
persed services can be monitored and controlled. Of course, the OCC’s of different stakeholders can share
information about some infrastructure if it is needed.
Additionally, most of the cases include telecommunication operators that, directly or indirectly, are providing
services to the end users (either passengers or staff). Many times, each telecommunication operator man-
ages his own infrastructure to provide the services, but this infrastructure can also be shared between them.
The simplest case is the one in which a single operator manages the rail service and the infrastructure; but
frequently, it can be found the case with separate rail's and infrastructure's operator, even with different
OCC’s, with several telecommunications operators behaving as explained in the previous paragraph. Even
such simplest case can be modified by the fact that some railway operators are providing their own tele-
H2020-ICT-2016-2017-762057 Page 19 of 88 31. Jan. 2018

communication services directly to the passengers (the most common example may be free Wi-Fi at sta-
tions).
Communication based services

All Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems (E/E/PE, or
E/E/PES) in railway systems comply IEC 61508. This recommendation includes four levels of Security Integ-
rity Level (SIL), SIL4 being the highest level of system security, SIL1 the lowest one.
We can build a classification of communication based services taking in mind the different stakeholders, the
criticality/nature of these services and their end users:
 Rail operation critical support services: this group of services cover all the aspects needed for the
proper operation of the rail transport service. Basically, they are mission-critical and safety related. It
may be possible that the information generated by these applications must be shared by different
stakeholders (example: one infrastructure operator and several railway operators). This group of sys-
tems requires the maximum Safety Integrity Level (i.e., SIL 4) to minimize the risk associated to the
equipment failure.
 Rail operation non-critical support services: it includes the rest of services related to rail transport ser-
vice. They can be sub-grouped into four categories: passenger information services, location operation
services, security services and maintenance infrastructure services. SIL 2 compliance is required by
this group.
 Enhanced passenger experience: telecommunications services only focused on passengers, with no
safety consequences. Typically, they will be provided by telecommunication operators.
Each of these groups of communication based services, their respective applications (graphically represent-
ed in Figure 4) and their requirements will be described in more detail in the next three sections of this doc-
ument.
Figure 4: Different groups of rail applications.
H2020-ICT-2016-2017-762057 Page 20 of 88 31. Jan. 2018

4.1.1 Rail operations critical support services

The following two subgroups of applications fall in this category, with a strong safety commitment (mission
critical):
1. Railway signaling-related services, currently provided through the Automatic Train Control (ATC)
system. ATC is composed by signaling systems that take care of the safe movement of the train
(telling the train how far it can go and how fast; helping the train to report its position and speed to
the wayside equipment; etc.). This system is composed of three functional subsystems and a set of
given performances:
a. Automatic Train Protection (ATP, mandatory): this subsystem continually checks that the
speed of a train is compatible with the permitted speed allowed by signaling. If it is not, ATP
activates an emergency brake to stop the train. ATP is also responsible about the safe train
separation.
b. Automatic Train Operation (ATO, optional): is an operational safety enhancement system
used to help automated operations of trains as speed regulation or doors control
c. Automatic Train Supervision (ATS, optional): is responsible for monitoring and controlling the
rail system to ensure that it conforms to an intended schedule and traffic pattern to optimize
railway operations and service reliability. ATS allows train systems to control trains from a
single OCC. Traffic patterns may be accorded to several criteria, for example, better energy
consumption.
Modern ATC systems must have these three main characteristics:

 High-resolution train location determination, independent of track circuits.
 Continuous, high capacity, bidirectional train-to-wayside data communications.
 Train-borne and wayside processors performing vital functions.
Numerical requirements are indicated in Table 3.

2. Operational voice services (complementary with ATC) responsible to provide a safe communication
voice channel that enables railway agents (drivers, OCC, maintenance and security staff, etc.) to
communicate appropriately. These services are used in several modes of operation (normal,
degraded or emergency).
ATC systems in Europe are classified, according to the serviced area, into systems that are being used by
intercity railway and systems used in urban transit. Railway mainline operations are using the European Rail
Traffic Management System (ERTMS), a set of standards for management and signalling for railways con-
ducted by the European Union Agency for Railways (ERA). On the other hand, the most common signalling
system used by urban transit operations is Communication Based Train Control (CBTC), defined by the IEEE
1474 standard. These two train signalling controls and their main supporting radio systems are represented
in Figure 5.
A detailed description of ERTMS and CBTC is provided in the Appendix A, in order to describe the main dif-
ferences between them. This comparison is useful when considering the rail user case chosen inside 5G-
Picture, that is Ferrocarrils de la Generalitat de Catalunya (FGC), whose infrastructure presently uses the
CBTC signalling mode, that will be presented in the following together with its requirements, its possible 5G
evolution and challenges, that could include the ERMTS control, and the innovation introduced by 5G-
PICTURE solution.
H2020-ICT-2016-2017-762057 Page 21 of 88 31. Jan. 2018

Figure 5: Signalling systems for train control transported over communication system.
For operational voice services, on the other hand, there are multiple situations in normal operation mode
where voice services are used: shunting, train preparation, platform staff’ needs, etc. But operational voice
services between train driver, traffic control and maintenance staff (trackside, rolling stock) are critical in
emergency or degrade operation modes, because there are human lives at stake.
Typically, operational voice services are provided by the same radio system used by the signalling systems,
i.e. GSM over Radio (GSM-R) or Terrestrial Trunked Radio (TETRA). Only in the case of CBTC over Wi-Fi1,
operational voice services rely on an exclusive infrastructure, usually a TETRA network. As the availability of
this system is critical, backup networks are required for these operational voice services, frequently through
a railway privately owned wired phone network or using the public mobile network.
Table 2 provides a comprehensive relation of voice features and their relevance to realize the above tasks
provided for a TETRA network.
Table 2: Features of operational voice service and their relevance.
Functionality Relevance
Group call
Group scanning
Individual call
Telephone call
Short Data Service
Status Messaging
Packet Data
Location services
Broadcast call
All call
Open voice channel mode
Priority call
Pre-emptive emergency call
Dynamic Group Number Assignment
1 CBTC may rely on different radio systems: TETRA, DMR or even Wi-Fi. In this last case, we are not talk-
ing about common commercial WI-Fi solutions. Instead, CBTC manufactures develop their own proprietary
solution, relying on Wi-Fi with appropriate complements.
H2020-ICT-2016-2017-762057 Page 22 of 88 31. Jan. 2018

Enable/Disable, Stun & Revive

Permanent Disable, MS Kill
Authentication
Mutual authentication
Air interface encryption
End to End encryption
Voice and data terminal
Data-only terminal
Direct Mode
Direct Mode Repeater
Direct Mode Gateway
Water proof, e.g. IP54
Intrinsic safe / ATEX approved
Man Down
High-res colour screen
JAVA applications
Integrated web browser
Built-in GPS receiver
Bluetooth
Legend of colours for applications relevance:
High Medium Low Not
In addition to the services listed in the table above, it should be taken into consideration that new services
are likely to be introduced that take advantage of the intrinsic multimedia capabilities of 5G once they are
available (for example the use of video streams).
Considering GSM-R, the offered services are as follows:
 Voice group call service (VGCS): VGCS conducts group calls between trains and base stations (BSs)
or conducts group calls between trackside workers, station staff and similar groups.
 Voice broadcast service (VBS): The BS broadcasts messages to certain groups of trains, or trains
broadcast messages to BSs and other trains in a defined area. Compared to VGCS, only the initiator
of the call can speak in VBS, and the others who join the call can only be listeners. VBS is mainly used
to broadcast recorded messages or to make announcements in the operation of high speed railways.
 Enhanced MultiLevel Precedence and Pre-emption (eMLPP): eMLPP defines the user’s priority and is
used to achieve high performance for emergency group calls.
 Shunting mode: Shunting mode provides an effective means of communication to a group of personnel
who are involved with a shunting operation, which regulates and controls user access to shunting
communications (a link assurance signal used to give reassurance to the train driver).
 Functional addressing: A train can be addressed by a number identifying the function for which it is be-
ing used, rather than a more permanent subscriber number.
 Location-dependent addressing: Calls from a train to certain functions can be addressed based on the
location of the train as the train moves through different areas of BSs.
4.1.1.1 Requirements
In 5G-PICTURE, the railway user case is supported by FGC. FGC encompasses both the rail infrastructure
administrator role and the passenger rail operator role, including urban metro activity in Barcelona, Barcelo-
na suburban area commuter transport and rural rail in some districts of Catalunya. FGC follows the ATC
H2020-ICT-2016-2017-762057 Page 23 of 88 31. Jan. 2018

model composed by ATC & TETRA, even if it has not implemented a completely full CTBC system. FGC’s
minimum headway is reached in Barcelona-Vallés line, with 112 seconds interval between trains (32 tph).
The main CBTC goal for FGC is not so much to increase the number of trains per hour but to improve their
behaviour in the restricted operational mode.
All FGC stations are provisioned with 1 Gbit/s connection to transmit all the info related to this location.
The FGC current scenario is represented in Figure 6, where both critical and non-critical communications are
summarised, the first one supported by CBTC over TETRA and the last one (as described in section 4.1.2)
by CBTC over Wi-Fi. The requirements for rail operational critical support services are shown in Table 3.
Figure 6: FGC scenario (today).
Table 3: Requirements for rail operations critical support services.

Requirement Value
- Maximum latency of 5 ms to achieve overall CBTC per-
formance (between on-board equipment and radio block
Latency centre / access point / 5G equivalent node)
- High sensibility to handovers (urban metro case) and
Doppler shift (high speed lines case)
-10-3
Packet loss - High sensibility to handovers (urban metro case) and
Doppler shift (high speed lines case)
BER Mission critical
Energy efficiency Not critical
Security Critical
Data rate 4 bidirectional Mbit/s stable throughput to support all
(DL/UL data rate) CBTC functions. Typical ATP function today: 100 Kbit/s
Jitter 10 ms (VoIP Max Quality for voice operational services)
1 ms (VoIP Max High Quality for voice operational ser-
Packet delay variation
vices)
Reliability 99.9999 % (SIL 4)
Availability 99.9999 % (SIL 4)
Mobility 500 km/h
Traffic density See note a)
Connection density See note a)
Coverage See note a)
H2020-ICT-2016-2017-762057 Page 24 of 88 31. Jan. 2018

Battery lifetime Not applicable

Data size 400 (max. 500) bytes for signalling
Notes on Table 3:
a) maximum 4 Mbit/s per train with a maximum of 50 trains per km2, CBTC needs SIL 4 compliance.
Figure 7: New communications architecture for railway industry.
4.1.1.2 Challenges
As discussed in the previous sections, current railway communication systems supporting operational and
passenger services rely on a complex scenario based on a mixture of multiple access network, including:
1. GSM-R/TETRA for operational communications & ATC.
2. Separated radio from ERTMS and CBTC.
3. Public GSM & others for maintenance, electricity meters, etc.
4. Wi-Fi for traffic offload in train stations.
5. Analog for shunting on low traffic lines & non-critical communication.
Through the 5G-PICTURE solution, a new communications architecture is proposed (Figure 7), drastically
simplifying the current network deployment, leading to significant cost reduction and introducing new busi-
ness models enabling:
1. 5G to become the standard for the railway radio infrastructure system industry (interworking)
2. 5G to become a driver for interoperability between different signalling systems (track to train)
3. 5G to improve the versatility of the system, expediting the path to deploy this architecture in new
scenarios (mixed passenger transport-freight transport lines, interurban traffic) or new methods of
operation (train formation through virtual couple wagons).
Thus, 5G appears as a major player in this new simpler architecture, based on a common infrastructure to
support all services (including also the services described in sections 4.1.2 and 4.1.3). This new communica-
tion network may be neutral from the various stakeholders viewpoints.
The new network provides different access types for the different applications, each one defined with a traffic
profile according to their characteristics such as QoS, bandwidth and other connection requirements or user
access (passengers or set of stakeholders).
There are some important benefits related to this new structure. First, it decreases the investments needed
to create the communications infrastructure and reduce overall structural costs, and also allows its easier
and faster deployment. All the current technologies will ultimately be superseded by all-IP networks, then the
use of a common network infrastructure based on mass deployment technologies from public networks and
the use of standard, non-specialised platforms, supporting the entire set of applications, must lead to reduce
the Total Cost of Operation (TCO).
Apart from TCO reduction, other factors will also be considered in the business case. The new architecture is
more efficient in capacity and 5G technology will provide better performance. The introduction of new ser-
vices and functionalities will also be benefited from this, as it will decrease their time-to-market and abridge
the cost to develop and test them. Note that a common computing solution for all applications is not required.
Thus, customisation capability to meet unique critical requirements of each stakeholder will be easily
reached.
H2020-ICT-2016-2017-762057 Page 25 of 88 31. Jan. 2018

To successfully apply the concept of 5G in the railway industry a set of challenges need to be addressed.
These include:
 Redundancy of the new architecture: The new simplified-single network reduces the overall cost of
the network, but introduces the challenge to maintain the same resiliency levels (introducing the
appropriate redundancy of some elements). This needs to be supported for all the services that the
network support, especially the critical ones, but not exclusively. Operational voice services play an
important role in ATP degrade mode, as was explained before, and because of this, their
redundancy levels must be carefully designed, because an ATP degrade mode may be triggered by
some failure inside the network.
 End-to-end quality of service (QoS) is assured for every application. As it was seen in this section
(and it will be seen also in the following sections 4.1.2 and 4.1.3) the different applications generate
very different types of traffic: critical priority data (as in case of ATC), critical priority voice (as in case
of voice operational services), normal priority voice and data (for the non-critical operation services,
with relatively large bandwidth consumption, as in CCTV (Close Circuit TV for video surveillance)
case and passengers voice and data (also with relatively large bandwidth consumption, as in
Infotainment or Internet Access).
 Security: Notice that the rail operator communications must be considered as private
communications, that it is to say, their intended users belong to some specific stakeholders, hence
must not be public. Some of them have critical characteristics either from safety or security
perspective. Conversely, the services provided by telecommunication operators have public
characteristics. The new network will have to support both types of communications without
introducing security problems. This issue should be noted as an important requirement in the overall
telecommunications architecture.
 Backward Compatibility and coexistence between any new radio system and GSM-R is mandatory.
 Cost efficiency: We are therefore proposing the requirement for a single solution for all operational
critical support services, including the support of critical voice and the support of ATC. Introducing
this single solution must be cost competitive, in terms of TCO, not only for the support of all services,
but for the support of any single service to be migrated first. For example, if a rail infrastructure
manager wishes to expand the coverage of voices over TETRA using a new 5G based solution, this
solution must be competitive against a TETRA based solution for these voice services, and these
services interoperability across both networks, TETRA and 5G-based, must also be supported.
A trend has recently emerged in re-signalling projects, especially in Europe, where infrastructure managers
of large commuter rails are facing a dilemma: “should we deploy CBTC or EMRTS or both?”.
The main differences between these two systems are:
 Interoperability (Trackside and Train): In the ERTMS case, some national deployments were tested
with success, but there are still problems in international deployments. Interoperability is not yet
available for CBTC systems.
 Moving block principle: Available in CBTC systems. It allows for shorter headways and,
consequently, it increases the line capacity.
 Full ATC functionality: Available in CBTC systems. It is still in development in ERTMS.
As mentioned above, TETRA and GSM-R are the two current leading radio systems for the rail vertical, be-
cause they provide specific features mainly focused on their critical mission related with modern ATC and
operational voice services.
A single signalling system like ERMTS will be more easily adjusted with different features. Thus, some cases
that today cannot be covered by a complete ATC system can start to be included in new business cases in a
future, e.g. lines used for either freight or passenger trains, suburban lines, etc. Note that a common compu-
ting solution for all applications is not required. Thus, customisation capability to meet unique critical re-
quirements of each stakeholder will be reached in a more effective way.
H2020-ICT-2016-2017-762057 Page 26 of 88 31. Jan. 2018

4.1.1.3 5G-PICTURE innovations

A major benefit expected by 5G-PICTURE architecture is the massive and faster deployment of ERMTS or
the interoperability of the different ATC systems. With a massive deployment of complete ATC systems,
driverless demand oriented trains compete against driverless road, both for passenger and freight transport.
Then, also virtual coupled wagons will be available.
Based on the concept of self-propelled cars, a new method of train formation has been proposed: virtually
coupled trains. The concept is based on the idea of using modern electronics and data transmission to run
several self-propelled units, one behind the other, without physical contact but at distances as short as me-
chanically coupled cars.
Traditional freight service is time and cost intensive, partly due to complex coupling and train forming pro-
cesses which require costly facilities. The train modules could automatically join or leave the virtual train for-
mation when they reach a junction.
4.1.2 Rail operation non-critical support services
In this section, non-critical operational services are discussed. From the OCC operational perspective, the
set of applications can be sub-grouped into four categories (in addition to the critical ones): passenger infor-
mation services, locations operational services, security services and maintenance infrastructure services.
These categorisation is realised in the OCC through a control system. The most common of such systems is
a Supervisory Control and Data Acquisition (SCADA), used for high-level process supervisory management.
A system with these characteristics uses other peripheral devices such as Programmable Logic Controllers
(PLCs) and discrete Proportional Integral Derivative (PID) controllers to interface rail infrastructures (track-
side, rolling stock) or a location (station, depot, and maintenance facilities, etc.).
Hence, the applications of this group can also be classified from a “managed object” point of view. Certain
levels of the OCC control system (Services Oriented Architecture or SOA levels) will define if the information
provided by one managed object is related with one or more of these OCC categories. An example of this
may be a trigger sent by a station elevator. The control system can define that this trigger is mapped into two
events: one alarm that will be sent to the locations operational services group and a warning to the passen-
ger information group, even if these operational groups belongs to the different stakeholders that maybe lo-
cated in different OCC’s.
Attending to this “managed object” criteria, applications can be classified as follows:
 additional safety services based on CCTV or augmented reality apps (for example, on-board CCTV
or driver look-ahead video),
 operational staff communications in stations and depots,
 rolling stock remote diagnostics and fleet maintenance, and
 location-based services (electronic ticketing, megaphones, elevators, escalators, etc.).
Both criteria are referred in the following sections, depending on the adopted point of view (OCC or managed
object).
Additional safety services

There are two basic functions on CCTV systems for railways: real-time video and recordings. Real-time vid-
eo can be watched in the cabin of the train by the driver and/or in the OCC.
With the SOA architecture explained before, some operators/stakeholders have Security Centres where all
the security aspects of the system are centralised (access controls, CCTV, security staff management, etc.),
but in many cases this is part of the OCC. CCTV systems, besides being relevant for security purposes,
could also be helpful for operational ones (i.e., for driverless trains, cameras placed at the front of the train
pointing to the track, platforms).
H2020-ICT-2016-2017-762057 Page 27 of 88 31. Jan. 2018

As real-time CCTV (video streaming) systems are very demanding in terms of resources, the train-to-
wayside radio system shall be properly designed. This must be traduced in bandwidth and jitter requirements
depending on camera definition to be used.
The other major function is the viewing and downloading of video recordings. Some operators force their on-
board CCTV systems to download their recordings to be stored somewhere in the wayside (in a Network-
Attached Store, probably), while others prefer to store on the train itself and access them on demand through
the radio system. This second function has more relaxed requirements, because can be typified as a normal
file transfer.
Apart from the previous two functions, there are many other railway-related functions than usually enrich a
CCTV system. Some examples are having a video of the upcoming platform in the train cabin, that can be
very useful in case of crowed stations., or integrating the smoke detectors with the on-board CCTV (via
TCMS, see below), that can be useful because when a smoke alarm is triggered, the driver (or a OCC opera-
tor) can automatically watch the nearest camera to the smoke alarm/source.
CCTV systems in stations, depots or maintenance facilities are also equipped with cameras for similar pur-
poses. These CCTV systems will contain innovative features such as video analytics software to automati-
cally detect intrusions, strange behaviour or unattended baggage. These features may extend the use of
these systems to other areas in the future. An example of these uses will be video analytics to determine the
most crowded parts into a station, for commercial purposes or to enhance the passenger experience organ-
ising people flows inside them.
Augmented reality applications will be developed over the next ten years for similar operational purposes.
Today, it is not possible to provide exact requirements for these kind of applications, but it can be assumed
that they will be like to the HD CCTV’s ones, adding some grade of users’ interactivity.
Operational staff communications in stations and depots

As well as the mission-critical operational voice services defined in the previous section, additional voice
communications for additional operational staff are needed. They will be considered a subset of these ones
(relaxing their safety requirements). It can be considered that more than one VPN multimedia services co-
exist in the common user case of several stakeholders’ deployment.
TCN: Train Communication Network

To properly perform train communications functions, many different train elements must be interconnected
through digital buses or Ethernet switches. This type of systems usually follows the ANSI IEC 61375 family
of standards, relative to Train Communication Networks (TCNs). IEC 61375 also defines ECN (Ethernet
Consist Network) as well as Ethernet Train Backbone (ETB) requirements. As reported in Figure 8, the ECN
interconnects end devices (EDs) with Consist Switches (CSs). As one train may contain multiple ECNs,
these segments are interconnected via ETB Nodes (ETBNs).
H2020-ICT-2016-2017-762057 Page 28 of 88 31. Jan. 2018

Figure 8: Ethernet TCN.
TCN sometimes is referred as part of TMCS (Train Monitor & Control System). TCMS comprises all comput-
er devices and software, human-machine interfaces, digital and analogue input/output (I/O) capabilities and
the TCN itself. Today, TCMS is physically separated from Wi-Fi networks available to passengers for securi-
ty reasons, but eventually will be part of the same TCN, surely provisioned in different WLANs. Even more,
there are some ongoing projects to build the complete TCN via radio.
Further details on TCN are reported in Appendix A: Details on rail communication systems.
In a general case, Remote diagnostics on TCN are a common practise and a lot of sensors connected to this
TCN collect data of almost every single piece of the train. These telemetry data are transmitted out of the
train to some wayside system. IEC 61375 defines also a gateway with this function, which will typically be
deployed through TETRA o GSM-R radio systems. This data will be stored on an OCC database, to analyse
them and set alarms with defined triggers. Typically, some of this information will be integrated via SCADA
(or a similar system) with other maintenance information to take decisions based on them. There are two
main final users of this data: train maintainers and railway operators. These data may even be stored on a
database and integrated on the OCC or maintenance tools.
Similar telemetry data can be obtained in locations (stations, depots or maintenance facilities): escalators,
lifts, cameras, ticket expending machines, fire detectors, megaphones are integrated in the maintenance
OCC using their associated WLAN.
The feasibility to build a new TCN, based on new generation 5G radio systems, is a new trend shaking the
vertical railway. In fact, this topic is related with the entire Industrial Ethernet.
Industrial Ethernet is a general term that refers to the use of Ethernet in harsh environments, with extreme
temperature, humidity and vibration conditions. Also, it can be enhanced with protocols (or even products)
that provide the determinism, real time and low latency required for industrial communications.
To achieve real-time behaviour, Ethernet switches implement Precision Time Protocol (PTP), formerly IEEE
1588). The timestamp needed to measure the precise time of reception and sending of the PTP messages
can be installed in the hardware or in the software. The closer it is to the HW, the more precise is the syn-
chronisation and less important is the jitter. Works on this subject is under development in Task 4.3.
Table 4 shows the real-time communication requirements for ETB, according to the different train subsys-
tems. CCTV and Passenger subsystems are not included, because their RT requirements are very much re-
laxed than these ones. The most stressful values are bolded in the table.
H2020-ICT-2016-2017-762057 Page 29 of 88 31. Jan. 2018

Table 4: Real time requirements for ETB.

Clock synch
Subsystem BW (Kbit/s) Latency (ms) Jitter(ms) FER
(ms)
Lighting 50 2 10 10 10-6
Doors 100 40 20 10 10-6
Auxiliaries1 100 4 20 10 10-10
Brakes 50 4 10 10 10-10
Propulsion 50 4 10 10 10-10
HVAC2 100 1 10 10 10-6
Toilets 250 0.5 10 10 10-6
Tilting 50 2 10 10 10-10
ATC 50 20 10 (See 3) 10 (See 3) 10-10
1
Hydraulic, cooling unit for power and drive systems, fire protection, horn, etc.
2
Heating Ventilation Air Conditioning.
3
DDU connection (between driver’s display unit and the on-board European Vital Computer (EVC) requires 1 ms maximum delay and
maximum jitter).
Table 5: Real time requirements for ECN.

Clock synch
Subsystem BW (Kbit/s) Latency (ms) Jitter(ms) FER
(ms)
Auxiliaries 50 10 10 10 10-10
Brakes 25 16 10 1 10-10
Propulsion 25 16 10 1 10-10
Tilting 50 2 10 10 10-10
ATC 50 20 10 10 10-10
Table 6: Real-time requirements for additional ECN’s sensor buses.

Subsystem Clock synch BW (Kbit/s) Latency (μs) Jitter(μs) FER
(ms)
Auxiliaries 25 20 5000 500 10-10
Brakes 1 100 50 10 10-10
Propulsion 16 4 50 10 10-10
Tilting 1 250 50 10 10-10
Table 5 shows the real-time communication requirements for ECN, according to the different train subsys-
tems. CCTV and Passenger subsystems are not included, because their RT requirements are very much re-
laxed than these. The most stressful values are bolded in the table.
Table 6 shows the real-time communication requirements for additional ECN’s sensor buses, according to
the different train subsystems. The most stressful values are bolded in the table. Note that in this table laten-
cy and jitter units are in microseconds.
Anyway, wireless TCN will face some challenges before its deployment, even in simple cases. The Train To-
pology Discovery Protocol (TTDP) that finds open train’s configuration and figures out network topology,
cannot be directly used in the wireless communication environment, because it was designed assuming
each neighbouring vehicle are connected via a direct wired cable. Based on this, a wireless discovery proto-
col has been defined, but have not yet included in the TCN standard definition.
Supporting virtual coupling will also need specific features to recognize changes in the train topology.
Another issue that must be fixed is which method will be used by the trackside infrastructure (or the OCC’s)
to recognize the type of TCN used by each train.
H2020-ICT-2016-2017-762057 Page 30 of 88 31. Jan. 2018
The wireless TCN will imply a review of all the application designs of the vertical railway. An example may be
a CCTV camera: with a traditional TCN, any image recorded by the camera must traverse its own ECN,
cross the TCB to reach the gateway to the trackside radio network and then will be transmitted to certain
media anywhere. With a wireless TCN, this image can reach this media directly from ECN, without crossing
TCB. Similar implications will be expected in other applications. In fact, this document has been written from
a wired TCN perspective, and this wireless TCN implications have not minded in any other paragraph.
The general requirements for rail operations non-critical support services are reported in Table 7.
Table 7: Requirements for rail operations non-critical support services.
Requirement Value
- 10 msec for CCTV performance (between on-board equip-
ment and OCC’s
- High sensibility to handovers (urban metro case) and Doppler
Latency
shift (high speed lines case)
- 50 μs for some train subsystems (only with a complete 5G
TCN deployment; including sensor buses
-10-2
- High sensibility to handovers (urban metro case) and Doppler
Packet loss
- 10-10(in case of any 5G TCN deployment)
BER Not critical
Security High
10 bidirectional Mbit/s stable for CCTV (per camera). See notes
a) and b).
Data rate
4 Mbit/s for TCMS
(DL/UL data rate)
15 Mbit/s (in case 5G TCN will be implemented, without CCTV,
TCMS and passengers traffic)
1 ms (in case of any 5G TCN will be implemented)
Jitter 10 μs for some train subsystems (only with a complete 5G TCN
deployment; including sensor buses)
Packet delay variation –
Reliability 99.99% (SIL 2)
Availability 99.99% (SIL 2)
Mobility 500 km/h
Traffic density See note a) and b)
Connection density See note a) and b)
Coverage See note a) and b)
Battery lifetime 10 years for IoT narrowband devices
Data size 1 Mbyte length
Notes on Table 7:
a) same as that of Table 3. maximum 4 Mbit/s per train with a maximum of 50 trains per km2, CBTC needs SIL 4 compliance.
b) One camera inside every vehicle is considered, with a maximum of 32 vehicles per train all connected to the TCN, plus 2 additional
cameras at both sides of the train. For real-time CCTV purposes, only some of them (two, for example) will be necessary. Note that plat-
form TV (if it is used by the driver) flows traffic in track to train direction.
4.1.2.2 Challenges
All the services and applications detailed in this section must be included in the new common architecture
defined in the previous section and classified as private communications.
H2020-ICT-2016-2017-762057 Page 31 of 88 31. Jan. 2018

As it was explained in the previous section, due to the new architecture, a new business model emerges in-
troducing the possibility of the telecom operator, or the rail infrastructure, or a neutral operator to support the
services owned by the rest of the stakeholders.
Intelligent infrastructure support by IoT is another challenging application. It consists of massive support for
low energy powered IoT devices for various applications: security monitoring sensors (trackside & on-board
signalling), infrastructure and surroundings management (e.g., ground movements due to human activity or
natural landslides, hydraulic phenomena like watershed, natural hazards like vegetation barriers, and civil
engineering structures) or for metering (e.g., energy metering on train for traction, energy metering in traction
substations, people flow metering and so on).
A major challenge is to determine if it is possible to build a new TCN structure based on a 5G radio system.
At first glance some TCN levels based on 5G seem feasible, keeping the rest based on wired technology. In
particular, it seems possible to build ETB and CTN levels, based on their requirements, but some train sub-
systems (mainly brakes, propulsion and tilting), that rely on sensor buses below CTN level, require μs orders
for their jitter and latency values.
If the scenario described above is feasible, next question to solve is if it is necessary to continue with the im-
plementation of PTP or other Real Time over Ethernet solutions out of the sensor buses.
Wired TCN is being deployed with 100 Mbit/s bandwidth, but also 1 Gbit/s is possible and, without any doubt,
it will be useful in short term. A 5G Gigabit TCN as a clear channel scenario may be undesirable, especially if
it is combined with the new global railway architecture defined for the entire set of applications defined in this
document, which intensively uses IP QoS. Multiple WLANs approaches (using network slicing or similar
techniques) seem more reasonable. Even more, these techniques provide additional benefits, because they
are source of new business and opportunities:
 Physical separation: TCMS and Wi-Fi networks available to passengers, for security reasons, can be
replaced in 5G TCN by two different networks, a public one for the passengers and a private one for
TCMS. In this case, passengers’ traffic may flow directly to the Internet without traverse the ETB.
 Traffic management model has more coherence from QoS perspective.

The major innovation required is a new common communication architecture suitable to support all services
and exposed applications.
Additional benefits of this new architecture must be quantified in some way, increasing the values obtained in
the previous section:
 A comparison between TCO’s must be done to evaluate the efficiency of the new solution.
 Quality and performance of the new system must be checked and measured.
It must be determined if there are reasonable possibilities to build 5G TCN based on the requirements ex-
posed above.
Nowadays, CCTV is an operator-oriented service available in almost every subway and tram vehicle, but
with some limitations or restrictions. Sometimes the recordings are kept in the train until there is an available
connection between train and wayside. There is typically no train-to-wayside continuous connectivity availa-
ble and there is no OCC integration to manage the video on real time. There is only availability of these im-
ages at a limited number of sites, for example, inside tunnels with Wi-Fi. Improvements in this area will be
expected with 5G arrival, supporting HD continuous video streaming at any moment in time and centralised
image analysis. This capability allows the deployment of an early alert system, based on the detection of
safety issues raised from the analysis of frontal images by a centralised image processing system.
It must be determined if there are reasonable possibilities to build a smart track, as explained in the previous
section, i.e., low energy powered IoT devices that can be able to realize surroundings management (to de-
tect ground movements, hydraulic changes, natural hazards or maintenance modifications), explaining their
cost structure (investments, power consumptions, connections, etc.).
H2020-ICT-2016-2017-762057 Page 32 of 88 31. Jan. 2018

4.1.3 Enhanced passenger experience

The last group of services is focused on the client experience, with no safety implications:
 electronic ticketing and trip information: routes, timetables, delay notification,
 digital signage to provide wayfinding, exhibitions, marketing or outdoor advertising,
 high-speed Internet access, and
 on-board multimedia entertainment / infotainment.
Unlike the previous ones, this group of services has a public nature.
This group of services does not have special requirements related with specific applications that may essen-
tially differ from other public services.
This section is focused on Internet access and public voice services for on-board passengers. At first sight, it
might seem that it is not a very challenging service to be provided, but many difficulties appear, all of them
related with train environment.
If a telecom operator with mobile license tries to provide any service directly through his network, what will be
found is loss of signal due to the vehicle presence, which produces a Faraday cage effect. Vehicle penetra-
tion loss is usually between 15 dB and 25 dB, depending on the frequency of the signal and the type of vehi-
cle.
In addition to tunnel blocking signals, there are other problems related with the train speed, which require to
handle many cells and handovers. Because of this, connectivity drops and lower data rates w.r.t. target ones
are obtained, in a similar way explained in previous sections for other applications. Cell occupancy efficiency
is low, since most of the time the cells have no train/travellers.
These effects can be avoided in two alternate ways:
 Mass transit scenarios: installing repeaters in short trackside intervals, sometimes shared between
many telecommunication operators.
 Long-distance high speed intercity trains: converting mobile signal into Wi-Fi with an intermediate
device. This Wi-Fi infrastructure is independent of the CBTC over Wi-Fi discussed in the critical-
operation group of services.
The general requirements for rail passenger experience are summarised in Table 8.
Table 8: Requirements for rail passenger experience.
Requirement Value
- 10 ms for Passenger Internet Access

Latency - High sensibility to handovers (urban metro case) and Doppler
Packet loss 10-2
BER Not critical
Security Normal
today: 12 Mbit/s per passenger x 500 passengers
Data rate
2019 objective: 100 Mbit/s per passenger x 1000 passengers
(DL/UL data rate)
See note c)
Jitter 1 ms
Packet delay variation Not critical
Reliability 99.99%
Availability 99.99%
H2020-ICT-2016-2017-762057 Page 33 of 88 31. Jan. 2018

Mobility 500 km/h

Traffic density See note c)
Connection density See note c)
Coverage See note c)
Battery lifetime Not critical
Data size Not critical
Notes on Table 8:
a) and b) same as Tables 3 and 7.
c) To calculate different cases, use notes a), b) and the following numbers:
 1000 passengers per train (number provided by FGC).
 Train dimensions to be used as reference: 960 m total length x 4 m width; 32 vehicles (max TCN standard).
 3000 additional people in stations, with a percentage of 30 % using devices as if they were additional “resting” passengers
(numbers provided by FGC).
4.1.3.2 Challenges
All the services and applications detailed in this section must be included in the new architecture defined in
the previous section and classified as public communications.
It should be noted that this architecture has increased requirements in terms of security. Public communica-
tions (passengers) and private communications (railway operation services) share the same access media,
but the first group cannot access to the private part of the architecture.
The most important challenge is to provide an on-board broadband service with quality similar to the off-
board environment. Some throughput targets for a train (without applying any oversubscription percentage)
are the ones already reported in Table 8:
 today: 12 Mbit/s per passenger x 500 passengers.
 2019 objective: 100 Mbit/s per passenger x 1000 passengers.
Passengers access to TCN via Ethernet VLANs (or 5G WLANs, in case of 5G TCNs are supported) contrib-
utes in an effective way to enhance the passenger experience. The enabling technology is the continued 60
GHz wireless train-to-pole connectivity.
Due to the new architecture, a new business model emerges introducing telecom operators as partners of
railway operator infrastructure. In addition, railway operators will be able to provide this telecommunication
services portfolio.

The major innovation is the new communication architecture, based on 60 GHz connectivity between trains
and railway to provide broadband services.
4.1.4 Requirements summary for Rail
Figure 9 gives a visual representation of some of the railway requirements listed in the tables above. The ex-
ternal hexagon represents the most stringent requirements in terms of peak data rate, user plane latency,
number of connected devices per cell (i.e. connectivity density), energy saving, capacity (i.e. traffic density)
and mobility. The use cases requirements are represented by the internal coloured figures. The vertices of
the internal hexagons shows the requirements of each use case. If one vertex overlaps the external hexagon
means that the use case has a very stringent requirement.
The most significant requirement for rail is mobility. Today, high-speed intercity trains provided with GSM-R
and ETCS Level 2 can reach operational speed around 350 km/h. The speed record belongs to the Japa-
nese SCMaglev train, who has a top speed of 603 km/h.
For enhanced passenger experience (green line), capacity and number of devices are strongly influenced by
the fact that several trains can be found in a big station at the same time. Non-passenger’s resources must
also be allocated for station visitors, but the numbers for a unique train (even two, crossing in different direc-
tion) and the trackside are different. Notes a), b) and c) notes on requirements tables allow to properly di-
mension these networks. For this reason, the green line seems to contain the yellow one (critical support
H2020-ICT-2016-2017-762057 Page 34 of 88 31. Jan. 2018

services), but this is true only in some situations, for example a central station at peak hour. This pictorial
view assumes that ETB and CTN levels are built as part of a 5G TCN, but all the sensors buses below the
CTN level remain wired.
Figure 9: Pictorial view of the requirements, following ITU-R for each group of applications.
Figure 10 summarizes with an envelope area all the requirements for the use cases composing the rail verti-
cal with an envelope area. It is important to note that the vertex regarding mobility overlaps with the big hex-
agon (so it is very challenging for every application) and some other ones are in any case to be taken into
account (in particular the capacity).
Figure 10: Synthesis of the requirements, following ITU-R.
H2020-ICT-2016-2017-762057 Page 35 of 88 31. Jan. 2018

4.2 Smart city and IoT

As per ITU [15], a smart city is defined as follows. “A smart sustainable city is an innovative city that uses in-
formation and communication technologies (ICTs) and other means to improve quality of life, efficiency of ur-
ban operation and services, and competitiveness, while ensuring that it meets the needs of present and fu-
ture generations with respect to economic, social and environmental aspects.” Thus, in a smart city, data
from multiple domains (transportation, public administration, emergency services, weather sensing, etc.) are
brought together within IT systems to facilitate better planning and better, faster (real-time and automated)
responses to changing situations. Critical to this is IoT and the underlying communication infrastructure that
enables connections between infrastructure, devices, and people, and gather data and deliver services to
myriad endpoints.
Smart city applications are extremely varied. We summarize the main applications in Table 9 and briefly dis-
cuss them below.
Table 9: Smart city applications [16].
Intelligent parking, traffic management, fleet tracking, road

Transportation
condition sensing
Smart grid, smart metering, storage and load manage-

Energy
ment, demand response charging stations
Smart home, smart build- Home/Building air quality control, event responsive lighting
ings, smart lighting and alarms
Emergency response, remote monitoring and diagnosis,

Health care
disease control, health records
Tourism and government Citizen-centric services, municipal planning, access to

services government records
Emergency dispatch, real-time incident response, surveil-

Public safety
lance, authorised subject tracking
Education eLearning, virtual classrooms, cross-institutional learning
Water and waste Water quality monitoring, storage and distribution, waste
management sensing, collection, treatment, and recycling
Smart transport systems are services that facilitate the transport of people or goods and improve the effi-
ciency of the use of various resources by making transport methods more easily managed or more easily
available. Examples of services and functions include various types of smart traffic monitoring, parking sys-
tems, traffic planning and systems for pricing transport. This is essential because traffic congestion during
peak travel hours is a key factor that affects the citizen’s liveability perception of a city. A smart transport sys-
tem might exploit the knowledge of commuter routes, timing, and other location-based information together
with city transportation grids to improve transportation flow and efficiency.
Energy represents an intersection of industrial IoT developments and the needs of a city. Smart energy ser-
vices include those that primarily enable more efficient and smarter use of various types of energy. These
services may involve, for example, smarter ways to deliver energy, more energy-efficient functions and
smarter ways to map energy usage. Services like smart electricity grids and smart electricity meters, which
can communicate with each other, can lead to efficient use of energy and are classed as smart energy ser-
vices. An essential characteristic of smart grid is demand response wherein the users’ energy consumption
is rescheduled to reduce operating expenditure and to defer increasing the capacity of the power plant or
adding new sources of energy [17].
H2020-ICT-2016-2017-762057 Page 36 of 88 31. Jan. 2018

Smart buildings can be described as systems that make it possible for buildings to learn and predict various
needs, such as for lighting, temperature, and space availability. Examples of these functions might be smart
lighting, predictive heating, water and sanitation systems and building automation. Smart lighting can reduce
energy usage and decrease maintenance costs. For example, intelligent LEDs can control and activate lights
on/off, dim lighting as needed, and react to user movements.
Smart health care includes services that use ICT solutions to increase access to health care, services that
can remotely diagnose or prevent illness and other services that can enable effective health care at lower
cost. Examples of these are telemedicine, connected medical devices and various methods to prevent the
spread of illness. Further, smart city sensors can offer greater real-time information to citizens on health-
related factors such as air quality, pollen level, and temperature warnings.
Smart administrations and agencies are often mentioned in connection with solutions aimed at improving the
efficiency of public services. This applies, for example, to various types of digital interactions between gov-
ernment agencies and citizens, businesses or government employees. Smart solutions may increase trans-
parency among administrations and make it easier for various actors to interact with them. In smart tourism,
tourists are guided by sending information related to restaurants, attractions, sports venues, and other user-
customised needs specific to the users’ location.
Improving education involves connecting students with the information and resources that can advance their
learning experience. The ability to connect students, educators, and resources will be a key component of
any smart city.
Smart water solutions employ intelligent sensors that can measure and report water flow, pressure, and de-
livery. The smart waste management involves the collection of waste and recyclables by using intelligent
sensors to monitor and report waste accumulation levels. It also calls for advancements in recycling and im-
proved handling of hazardous waste materials. The future demands of urbanisation will place significant de-
mands on cities to take steps in water conservation and waste management.
Based on the requirements placed on the network, the smart city applications can largely be classified into
the following four families.
4.2.1 Machine-type Communications
Huge volumes of end-points and connections, using low-cost devices and modules, characterize applications
of this type. The objective is to provide ubiquitous connectivity with relatively low software and hardware
complexity and low-energy consumption. Examples include sensors attached to track items in a warehouse,
package delivery system; event-driven alarms such as fire alarms and security alarms; and devices embed-
ded in a building, bridge, or other structure to monitor motion, air quality, moisture, etc. Another application is
bio-connectivity in which wearable sensors enable continuous and automatic telemetry of body temperature,
blood pressure, heart rate, blood glucose, etc. Upon activation, each sensor or a group of sensors via a cen-
tral node (e.g. IoT concentrator for domestic home monitoring or a smart phone for wearable sensors) identi-
fies itself with the network and registers with the sensor monitoring service/application. Each sensor sends
its information infrequently. The application can request information from a sensor as needed.
The communication from each sensor is, in general, at low bit rate with moderate latency requirement but
needs to be reliable. Communication would be predominately in the uplink. The network should support traf-
fic prioritisation to distinguish between regular operation and an alarm. Because the devices are low power,
sufficient coverage is needed to ensure accessibility. Further, the network should support efficient authenti-
cation, maintain confidentiality and integrity of data (e.g. wearable device), and seamless handovers be-
tween different RATs in case of mobility (e.g., inventory tracking service).
Some of the typical performance requirements are given in Table 10.
Table 10: Requirements for machine-type communication [18], [19].
Requirement Value
Latency Seconds to hours
H2020-ICT-2016-2017-762057 Page 37 of 88 31. Jan. 2018

Packet loss 10-2

BER 10-6
Energy efficiency 0.015 µJ/bit
Security Important
Data rate (DL/UL data rate) Low (1-100 kbit/s)
Jitter Non-critical
Packet delay variation Non-critical
Reliability >99%
Availability >99%
Mobility On demand: 0-500 km/h
Traffic density Non-critical
Connection density 1 million devices per km2
Coverage Nationwide
Battery lifetime Up to 10 years
Data size Very small
4.2.1.2 Challenges
The current 3GPP access model requires a UE to attach to a network and establish a bearer for data com-
munication. In the case of a large number of devices with low data throughput such as sensors, this places
undue strain on the network resources. Provisioning and state information is required for each device, and
signalling overhead can eclipse the amount of data being sent. A method by which large numbers of possibly
mobile sensors may be deployed and data may be uploaded while avoiding unnecessary network attach-
ment and bearer management signalling overhead is one of the main challenges. Currently, the pricing poli-
cy of mobile services is applied per terminal or connection. The number of terminals is expected to increase
exponentially; therefore, a new criterion for billing is required. Some of the other challenges are priority han-
dling, efficient resource management given the massive number of sensors, and support for synergies that
might be required between applications.
4.2.1.3 5G-Picture Innovations

The main 5G-PICTURE innovation regarding machine-type communications are:
 The current 4G deployments might be inadequate to cope with the huge number of sensors.
 Flexible BH / transport network and SDN-based control plane will be necessary to meet the periodical
and unpredicted demand from millions of sensors in a cost and energy efficient manner.
 Event-based traffic may require reconfiguring the transport network.
An important innovation point is the convergence between Smart City infrastructure and 5G infrastructure.
For instance, to achieve this convergence Small Cells should be installed outdoors in sites owned by city
councils. Since this is too redundant, expensive and highly environmental impacting technological solutions
might help, like the adoption of virtualisation or slicing, so that a single small cell site can be reused by differ-
ent operators or Smart City services. This work is under development in WP4.
4.2.2 Mission-critical Applications
In this type of application, monitoring and control occur in real time, E2E latency requirements are very low
(at millisecond levels), and the need for reliability is high. Some example applications include autonomous
vehicle control; intelligent transport systems facilitating efficient traffic management, dynamic traffic routing
and so on; navigation of drones and unmanned aerial vehicles (UAVs) used for package delivery; industrial
control and collaboration between robots to execute sensing tasks in uncertain and hazardous environments;
and telemedicine applications such as remote monitoring, diagnosis and treatment, pre-hospital emergency
services in the ambulance; protection and control of substation and smart grid; public safety such as opera-
tion of first responders in case of fire or other kinds of emergency situations. In telemedicine, the medical
records of patients are made available to the physician anywhere and at any time. They improve healthcare
H2020-ICT-2016-2017-762057 Page 38 of 88 31. Jan. 2018
in remote areas and reduce the associated costs. For pre-hospital emergencies, the patient’s data including
diagnostics sounds, video and high-resolution images might have to be transmitted to the hospital staff. The
medical equipment in the ambulance may interface directly with the telemedicine tools at the hospital.
Substation protection and control involves automatic fault detection and isolation to prevent large-scale pow-
er outage. Smart grids add the capability to manage power demand more intelligently (both by the consumer
and, through tariff incentives, the supplier) – by reaching beyond the meter or home gateway to devices and
appliances in the home.
The network must efficiently multiplex the data traffic in order to provide higher priority for data traffic from
critical applications compared to normal data traffic. Real-time control calls for connectivity even with highly
mobile end-users (e.g. 120 km/h for UAVs) and high positioning accuracy. Seamless handover between dif-
ferent RATs should be possible to maintain connectivity and high availability. Further, end-to-end integrity
and confidentiality of user data (for e.g., for telemedicine) needs to be ensured.
The key performance requirements for this family of applications are reported in Table 11.
Table 11: Requirements for mission-critical applications [18], [20].
Requirement Value
Latency 10-150 ms
Packet loss 10-3 – 10-5
BER 10-6 – 10-8
Energy efficiency Non-critical
Security Very important
> 20 Mbit/s for UAV in UL
Data rate 2-25 Mbit/s for telemedicine in UL and DL
(DL/UL data rate) Substation: ~ 12.5 Mbit/s per sensor
Smart grid: 200 to 1521 bytes reliably delivered in 8 ms
Jitter Non-critical
Reliability 99.999%
Availability 99.999%
Mobility < 300 km/h
Traffic density Potentially high
Connection density Not critical
Coverage Nationwide
Data size Not applicable
4.2.2.2 Challenges
The key challenge is to design a network that meets the reliability and latency requirements of these applica-
tions. Sensor traffic may not be continuous, which can be exploited to reduce energy consumption by shut-
ting down links in the transport network (e.g., telemedicine, event-triggered sensors). For confidential data as
well as control signals, security and integrity of the data are of high importance. Some of the other challeng-
es are traffic priority handling, detecting congestion and re-routing the backhaul capacity, and achieving high
positioning accuracy especially in the absence of GPS.
4.2.2.3 5G-PICTURE Innovations

5G-PICTURE will provide to this use case some technical solutions capable to:
H2020-ICT-2016-2017-762057 Page 39 of 88 31. Jan. 2018

 Support for transport network reconfiguration, mostly its wireless segment, according to the traffic pat-
tern and traffic priorities. For example, provisioning additional transport resources when data transmis-
sion is event-triggered.
 Improve reliability by:
o Provisioning multiple paths in a meshed transport BH network, instead of the single-path tree
based BH networks deployed today.
o Detecting congestion at any point of the transport network, and re-routing the data accordingly.
 Optimize computing functions and service characteristics with DA-RAN, thus reducing latency. The
network can further reduce latency by exploiting real world information such as the route to the hospital
for an ambulance. 5G-PICTURE architecture allows for distributed computing, so servers can be in-
stalled very close to the sensors and data can be processed locally instead of transporting information
to a remote data centre.
4.2.3 Disaster Monitoring and Public Safety Services
These services calls for a resilient network with high availability that can facilitate reliable communication
even if parts of the network have been damaged in a disaster (e.g., earthquake, tsunami, flood, hurricane,
etc.). The effectiveness of the rescue and safety operations depend critically on the ability to acquire data,
integrate, and communicate data. For example, the network may be used for locating victims and broadcast
alerts. Minimal communication services such as voice and text messages must be available even in the af-
termath of a disaster. This allows survivors to contact family members, find rescue shelters, etc. and rescue
teams to coordinate their activities. The energy consumption of both terminals and network infrastructure
must be reduced.
The network should have the ability to recognize its topology after a disaster and reorganize itself to meet
the requirements. It should be flexible enough to incorporate new elements as they become available. The
traffic from these services, in general, requires preferential treatment compared to normal traffic. Efficient
network and UE energy consumptions are critical in emergency cases. Several days of operation should be
supported. Further, the network should provide support for user positioning. Some of the service specific re-
quirements are as reported in Table 12.
Table 12: Requirements for disaster monitoring and public safety [18][19][21].
Requirement Value
Latency Not critical
Packet loss 10-2
BER 10-6
Energy efficiency High
Security Important
Data rate (DL/UL data rate) 0.1 – 1 Mbit/s in UL and DL
Jitter Non-critical
Reliability > 99%
> 99.999% (available even after highly unlikely
Availability
disaster events)
Mobility 0 – 120 km/h
Traffic density 10-100 Mbit/s/km2
Connection density 10,000/ km2
Coverage Nationwide
Battery lifetime Several days to a week in case of emergency
H2020-ICT-2016-2017-762057 Page 40 of 88 31. Jan. 2018

4.2.3.2 Challenges
The key challenge in enabling these services is ensuring ultra-high reliability, even when the functionality of
parts of the network infrastructure have been compromised by the disaster event itself. Planning for is quite
difficult given the different levels of infrastructure damage that is possible. In order to provide the most relia-
ble service possible, the network might have to integrate diverse communication infrastructures such as sat-
ellites, multi-hop communication through various terminals, etc. Supporting these functionalities may not be
economically feasible given the lack of synergy between applications with similar requirements [2].
5G-PICTURE provides a highly programmable and flexible network infrastructure. This allows the network to:
 Route FH and BH traffic according to the demands of a disaster scenario and configuration of the net-
work after a disaster.
 Prioritize safety critical communications.
 Provide flexibility to add new network nodes.
Ongoing activities in WP3, WP4 and WP5 are developing these concepts.
4.2.4 Tactile Internet
Tactile internet involves real-time control of remote objects and systems. It is characterised by the combina-
tion of extremely low latency, high availability, reliability, and security. Some of the example applications in-
clude truly immersive, proximal cloud-driven virtual reality, remote control of robots (e.g., automatic precise
instruments assemble a car co-ordinately), real-time control of flying/driving things, remote surgery, and au-
tonomous driving cars. Fully autonomous vehicles can eliminate potential human errors as long as infor-
mation is exchanged between adjacent vehicles and central controller with very low latency even at high
mobility.
The network should ensure very low latency and nearly 100% reliability. The target delay is 1 ms and the
endpoints must be physically close in order to achieve it. Further, high data rates both in the downlink and
uplink is required (e.g., virtual reality, remote surgery). For autonomous cars, the network needs to ensure
connectivity even at speeds more than 200 km/h and high positioning accuracy (e.g. 0.1 m). The connec-
tions must be robust to attempts to block, modify, or hijack (also relevant for remote surgery), as reported in
Table 13.
Table 13: Requirements for tactile internet [18][22].
Requirement Value
Latency 1 ms
Packet loss 10-7
BER 10-8
Energy efficiency Non-critical
Security Important
Data rate (DL/UL data rate) 0.3 - 10 Mbit/s
Jitter 500 µs
Packet delay variation In the order of μs
> 99.999% for remote surgery, autonomous driving
Reliability
> 95% for augmented reality, gaming
Availability > 99.999%
Mobility Low
Traffic density 0.03 – 1 Mbit/s/m2
Connection density Non-critical
Coverage Nationwide
H2020-ICT-2016-2017-762057 Page 41 of 88 31. Jan. 2018


4.2.4.2 Challenges
To achieve an E2E latency target of 1 ms, the latency introduced in the transport network should be well be-
low this target. The transport network should support traffic prioritisation and rerouting to avoid congestion in
the backhaul. The latency target of 1 ms is quite challenging to achieve, at least in the near-term.

5G-PICTURE provides the following features over legacy networks:
 The transport network programmability allows for fine control on the latency introduced by it. This is
through on-demand dynamic resource allocation and utilisation (compute, storage, network, and ra-
dio). Thus, it can be configured in real-time during network service provisioning for a given UE and
based on information such as UE location, application characteristics. For this purpose, the Project is
developing technologies that support FH such as X-Ethernet, TSON or Ethernet TSN. Given the FH
delay requirements are very low (< 250 μs) the same technologies can provide the required delays for
tactile services.
 Traffic awareness, flexibility in physical and virtual resource assignment in the transport network as
well as QoS mechanisms enabled by the overall 5G-PICTURE architecture can ensure high priority for
these applications. In any case, the end-points must be physically close to support such low latencies.
4.2.5 Requirements summary for smart city and IoT
Figure 11 and Figure 12 summarize all the requirements for the use cases composing the smart city and IoT
vertical. As can be seen, data rate and capacity are not the main focus here. Instead, especially latency, en-
ergy efficiency and number of connected devices are in-line with the most challenging requirements of 5G.
Figure 11: Pictorial view of the requirements, following ITU-R.
H2020-ICT-2016-2017-762057 Page 42 of 88 31. Jan. 2018

Figure 12: Synthesis of the requirements following ITU-R.
4.3 Stadium and mega events

One of the major 5G challenges is the support of the envisaged huge traffic/services demands with extreme
irregular and seasonal characteristics at ultra-dense hotspots, such as stadiums, concert halls, parks, open
areas, etc. This use case focuses on the provisioning of telecommunication services at a large (foot-
ball/basketball, etc.) stadium in order to support, in an efficient way:
 The huge traffic demands generated in specific time-windows (i.e., during a football match or a con-
cert) from the use of a wide number of applications/services (critical and value-added services, over
the top (free) and metered access (by subscription), etc.) with specific, versatile QoS performance re-
quirements.
 The demands of the business related support systems (security/surveillance, energy management,
new services, etc.) besides the usual/low daily traffic needs (see stadium employees, stadium offices,
shops).
 A high number of stakeholders (service providers, tenants, subscribers, etc.) with diverse require-
ments.
Services
During an event, especially considering the 5G era, high capacity eMBB services, mMTC services, URLLC/
Critical Communications and/or other interactive services shall be offered. Indicatively:
High capacity eMBB services:
 Uploading of Ultra High Definition (UHD) videos/photos by the fans to their private cloud or to social
media (Facebook/YouTube).
 Replaying (UHD streaming) of previous scenes, esp. during the breaks or after an incident in doubt, by
the fans.
 Live TV broadcast services (IPTV) to fans at home, e.g. by cameras installed at specific locations by
the media companies which could be also “managed” remotely.
 Business related services inside and outside the stadium, e.g. real-time UHD video streams from re-
mote surveillance cameras (CCTV).
H2020-ICT-2016-2017-762057 Page 43 of 88 31. Jan. 2018

mMTC services:
 Massive push notifications to fans for contests, bidding, advertisement issues (e.g., bid online, stadium
shop advertisements, online contests for winning an item with the logo of the team).
 Massive IoT services for energy management (incl. lights, sound, heating/cooling, etc. management)
and control services (incl. control of security devices, presence sensors, ticketing).
URLLC/ Critical Communications:
 Emergency calls in the case of e.g. a health issue of a fan, fire, an attack incident, etc.
 Evacuation services at the fans’ smartphones (offered by the stadium owner) in case of a fire, a terror-
ist attack, etc.
Other interactive services:
 Location-based services, especially a couple of hours before and after the event, e.g. “Where is your
friend”, “Where R U”, directions to nearest Gate/ Gate #N/ shop/ service desk, “Find a parking Space”.
On a daily basis, on the other hand, the following will be required:
 High speed connectivity services to support the stadium employees in their work.
 IoT services for energy management (incl. lights, heating/cooling/air-refreshing, etc. management) and
control services (incl. control of monitoring/surveillance/security devices such as cameras, CCTV), alt-
hough for a smaller number of devices compared to that during an event.
 In cases of hosting a small scale private/local event at the stadiums’ rooms the provisioning of connec-
tivity with specific guaranteed QoS characteristics (e.g. dedicated bandwidth, latency, etc.) could be
required.
Construction limitations
The stadiums’ construction environment is quite challenging for wireless deployments. More specifically, the
environment of a stadium bowl presents “open air” characteristics; however, there is a lot of metal used in
the stadium construction which significantly impacts on the signal radiation and interference. It is also techni-
cally challenging to deploy Wi-Fi in the Stadium bowl as specialised equipment and fitters are required to ac-
cess the roof and other hard to reach places. The spaces between the different concourses also create a
‘blank spot’ as there are no easy attachment points for wireless access points. Moreover, conformance with
international standards, introduces further limitations in the output power of radio access nodes, at the same
time limiting their coverage range.
In addition, given the fact that stadiums are usually private constructions, deployment restrictions are posed
by the stadium owners in terms of cabling, space, location of access network nodes and cost which need to
be taken under consideration. From the stadium owner’s side it is of utmost importance to reduce the net-
work equipment (access network nodes/RRH, cabling, cabinets for BBUs, etc.) of different telecom providers
and other tenants to a single shared infrastructure, that can be easily scalable in terms of capacity and sup-
port various types of services efficiently, which implies multi-tenancy support over a programmable stadium
network infrastructure.
Interoperability with various access network technologies and devices
A wide variety of devices need to be supported at a stadium (e.g. sensors, smartphones, and handheld de-
vices like card machines). Barriers to entry have to be low so that connectivity is provided to all – if possible-
commercially available devices; specifically, different classes of Wi-Fi, spectrum (2.5 GHz / 5 GHz) and soft-
ware network stacks (e.g. IoT devices, smartphones, PCs) shall be supported.
Vendor-agnostic deployments
Any deployment needs to work with the existing managed services provider (which might change)–i.e. the
business entity managing the network. Therefore, any technology deployment should be easy to manage by
third-parties (e.g. training and support should be available) and should not create lock-ins or dependencies
on specific tools/software.
Bottlenecks throughout the network
The stadium network represents a small-scale model of a city network topology. It has its own ‘last mile’ ac-
cess (both wired and wireless), aggregation and gateway devices/network components. Applica-
H2020-ICT-2016-2017-762057 Page 44 of 88 31. Jan. 2018
tions/services provided over the network define the QoS requirements that need to be met, e.g. in terms of
bandwidth, latency, jitter, etc. However, constraints exist in all parts of the network deployment.
Figure 13: Connectivity across the networks in a Stadium.

In the access network, the end-user experience (QoE) is affected and determined by the access network di-
mensioning and topology, i.e. the grade to which the total offered traffic is served which depends on the
available spectrum bandwidth, the permitted output power per node, the interference level, the available
fixed network cabling, etc. see Figure 13.
The BH network may also introduce bottlenecks depending on factors such as the related technology and
capacity, the physical network topology, the fixed lines’ quality of wiring, etc.
Assuming BH network is sized enough to match (if not exceed) the QoS requirements of the access network
and that most traffic is bound to the public network (e.g. Internet), then the next potential bottleneck comes at
the point where the Private and Public networks connect (labelled the Gateway in Figure 13).
Network and Applications’ Elasticity

For 5G Networks the focus is on providing both Network level elasticity (bandwidth variable resource alloca-
tion, slicing, NFV, etc.) and Application level elasticity (Edge Compute, Cloud Computing, etc.). The
Crowdsourced Video application is one such use-case that requires this fine tuning of the control and data
plane given the physical network constraints and application requirements.
One way of making applications flexible (i.e. decentralised) to overcome network constraints is by exploiting
(for example) ‘edge’ computing so that traffic carried through different networks is minimised. There are three
logical places for processing to be performed:
1. On the Device
2. On Local Server(s)
3. On Remote Servers - there could be several classes of remote servers based on Geographical lo-
cation/Public network latency but to keep things simple these are ignored.
There are two main deployment options for network applications:
1. Applications running on an end-user device (smartphone, PC, etc.) (connected to an Access net-
work) accessing backend Server somewhere in a Public network - here both the Access and the
Gateway switches have the same traffic and QoS requirements since all the traffic has to be deliv-
ered to the Public network.
2. Applications running on an end-user device (connected to an Access network) accessing backend
‘aggregation’ server within the Private network which in turn accesses another Server somewhere
in the Public network. Here the traffic and QoS requirements might be different for the Access and
the Gateway (i.e. requirements may be asymmetric) – this can be used in case the backhaul net-
H2020-ICT-2016-2017-762057 Page 45 of 88 31. Jan. 2018
work is the bottleneck. There can be multiple aggregation points (software) at each interconnection
point.
Evolving the Stadium Network

In the future, Stadium networks need to move to more flexible deployments with increased reliance on virtual
resources and functions deployed as a Cloud instance (locally or remotely). This will require increased resili-
ence at the boundary between the Private and Public network. One of the early targets for virtualisation may
be the Wi-Fi Access Controller, IoT Controller, some Network Functions (e.g. Firewalls) and local Data
Warehouse (Figure 14).
Figure 14: Mixed Stadium Network Deployment - Wi-Fi and Wired access.
Figure 15: 5G Enabled Stadium Deployment – pure wireless, no wired access.
Further down the line, the Stadium could become a pure wireless client venue where only the Radio Access
points are present in the Stadium, connected via a wireless FH to the virtualised Private network (a Stadium
slice) and the Public network. For the pure wireless solution the different types of stakeholders (individual
end users, other tenants, etc.) will use the appropriate Radio Access Technologies (RATs) (Figure 15). In
this case, the constraints introduced by the stadium construction -as presented in previous paragraphs- need
to be overcome.
This transition will underpin all the use-cases presented in the following subsections.
H2020-ICT-2016-2017-762057 Page 46 of 88 31. Jan. 2018

Figure 13 to Figure 15 are broadly mapped to use-cases using KPI clustering defined in [28] where, broadly
speaking, three levels are defined for numeric values: Low, Medium and High. Further use-case specific la-
tency requirements are taken from [24].
4.3.1 High Speed Wireless Access
As aforementioned, the stadium use case is characterised by high variation of traffic/services requirements
due to seasonality, ranging from loose requirements on a daily basis to extreme hot spot -like requirements
during the events (ultra-high traffic and users’ density) both in open area environment and/or indoors, includ-
ing the stadium surroundings (parking, entrance, nearby public transport stations, etc.)
For instance, during an event there is a time window in which the following sessions need to be served sim-
ultaneously:
 ~5% of max. 27000 spectators perform an eMBB session simultaneously (~ 5%*27000*100 Mbit/s =
~135 Gbit/s).
 ~30% of spectators perform phone calls (30%*25000*(~40 Kbit/s) = ~300 Mbit/s).
 ~5% of spectators perform data sessions (on-line bidding/contest/messaging) (10%*27000*(~25
Kbit/s) = ~70 Mbit/s).
 > 5 Gbit/s slice provisioned for surveillance/security services.
 3 tenants requesting > 5 Gbit/s each for broadcast and other communication services.
 Additional 5 Gbit/s slice reserved for emergency services/first responders and users/spectators.
These services end up to a network capacity of ~160 Gbit/s required over a 19000 m2 stadium bowl area
plus a complementary ~1000 m2 area hosting management services, which corresponds to the IMT-2020
envisioned capacity of ~10 Mbit/s/m2.
These figures are summarised in Table 14.
Table 14: Stadium and Mega Events – Services Overview.
Data rates Total Data
Users Service
per instance Rates
>5% of total
eMBB (e.g. for Crowd-Sourced Video, etc.) 100Mbit/s ~135Gbit/s
spectators
~30% of total
Phone Calls 40 Kbit/s ~300 Mbit/s
spectators
~10% of total Data services (e.g. On-line bidding/ con-
25 Kbit/s ~30 Mbit/s
spectators test/ messaging, etc.)
Surveillance/ Security ~5 Gbit/s
Other Services (e.g. broadcast & other
3 Tenants > 5 Gbit/s ~15 Gbit/s
communication services
Emergency Services > 5 Gbit/s ~5 Gbit/s
SUM > 160 Gbit/s
On the contrary, for the daily operations:

 A 10 Gbit/s link is required to support < 100 employees in having internal network and internet connec-
tivity for various services, including, IP voice calls, data sessions, and surveillance/security services,
as well as massive IoT services for energy management (lights, sound, heating/cooling, etc. manage-
ment) and control services (control of monitoring/surveillance/security devices such as cameras).
 For the Massive IoT services, latency between 1-50 ms is required.
Towards reducing OPEX, it shall be possible to scale up network resources upon request. For instance:
 Each spectator/visitor will be given an option to upgrade their wireless connection to a high speed, low
latency one.
H2020-ICT-2016-2017-762057 Page 47 of 88 31. Jan. 2018

 This could also unlock a set of value-add services (to be defined) which could be deployed on-site or
as a cloud instance (depending on various factors) and scale with demand.
In Table 15 the main requirements related to high speed wireless access use case, under the Stadium and
mega event vertical umbrella is reported.
Table 15: Stadium and Mega Event Requirements – High Speed Wireless Access.
eMBB services to
Requirement Phone Calls Data services
Spectators
Latency 2 ms – 10 ms (a) < 10 ms (b) 2 ms – 1 s (a)
Resiliency Essential Essential Important
Packet loss 10-2 10-2 10-2
Energy efficiency Not Critical Not Critical Not Critical
Security Essential Essential Essential
20-100 Mbit/s/user,
Bandwidth
(Total ~135 Gbit/s over the 40 Kbit/s 25 Kbit/s
(DL/UL data rate)
bowl area)
Jitter <20 ms (c) <20 ms (c) <20 ms (c)
Reliability > 99.9% > 99.999% > 99.9%
Availability > 99.9% > 99.999% > 99.9%
Mobility Yes-Very Low Yes- Very Low Yes- Very Low
traffic density ~7,5 Mbit/s/m2 ~0,01 Mbit/s/m2 ~0,005 Mbit/s/m2
Rely on sensor
Not applicable Not applicable Not applicable
network
Connection
0.07/m2 0.4/m2 0.14/m2
density
Device direct Not applicable Not applicable Not applicable
Coverage > 99.9% > 99.999% > 99.9%
Battery lifetime Not applicable Not applicable Not applicable
Update time Not applicable Not applicable Not applicable
Data size Not applicable Not applicable Not applicable
Notes on Table 15:
 (a) Depending on the service can range from 2-4 ms for interactive audio and video services, 20 ms for collaborative gaming,
tactile internet, etc., up to 1 s for non-real time applications.
 (b) In 5G a latency of <10 ms is desirable, considering that in 4G systems a latency of 20-80 ms is achieved.
 (c) The maximum allowed jitter values are highly application dependent. In general, for non-critical real-time applications they
can be as high as 20 ms-100 ms.
4.3.1.2 Challenges
This use case poses a number of challenges mainly related to the special environment of the Stadium as
afore described. More specifically, the major challenge to be faced is to serve this extremely high traffic den-
sity with wireless access solutions, which implies:
 overcoming access network capacity limitations and mitigating interference issues, and
 providing a high capacity access/FH/BH network,
while respecting the construction restrictions of the stadium owner regarding:
 the deployment of network equipment; in terms of reducing cabling, of placement of access network
nodes/RRHs/BBUs, etc.,
 the operation of a vendor agnostic solution, and
H2020-ICT-2016-2017-762057 Page 48 of 88 31. Jan. 2018

 the minimisation of CAPEX/OPEX investment through “on-demand” network scaling given the occa-
sional occurrence of such high traffic.

Current 4G solutions and deployments are incapable of serving such high traffic density use cases. At ac-
cess network level, 4G networks face capacity and interference limitations which are closely related to their
operation on bandwidth-limited spectrum bands, to the usage of low MIMO schemes, and the insufficient in-
terference mitigation algorithms. At this point 5G access network solutions are required in order to deliver an
access network layer based on massive MIMO, interference coordination/mitigation and operation on larger
bandwidth, higher frequency bands.
Moreover, deploying 4G implies high CAPEX investment stemming from the static mapping of the radio ac-
cess resources to base-band units/resources. This means practically that each LTE (Advanced) radio unit
requires the deployment of a dedicated eNodeB BBU either on-site or remotely located, along with the de-
ployment of a static BH connection. However, given the occasional appearance of such high traffic demand,
virtualisation of BB processing and “leasing” on-demand compute resources from a disaggregated cloud in-
frastructure as needed –as proposed in the context of 5G-PICTURE – can significantly reduce CAPEX and
increase infrastructure monetisation.
In this context, also flexible functional splits, as proposed and designed by 5G-PICTURE WP4, can lead to
more efficient resource utilisation in support of both FH and BH services utilising available fibre link capacity
over one or multiple wavelengths.
Last but not least, the high versatility and number of services and tenants to be served over a single network
infrastructure can be better isolated and managed – with less QoS compromises – by employing network
slicing, which is an ongoing work in WP5.
4.3.2 URLLC/ Critical Communications (Big Red Button)
Especially in crowded places, the provisioning of mission critical communications is of outmost importance.
Such services require extremely short network traversal time (URLLC) and in the context of a 5G scenario
may include besides the Big Red Button services the operation/control/support of industrial automation,
drone control, and new medical applications. The support of such applications in crowded places involves
the automatic (re)configuration of the network to provide priority access to certain types of end-
users/tenants/applications (e.g. Security and Operational Staff) in case of emergency situations (see also
Table 16). As an exemplary usage scenario in case of a stadium event the following sessions can be re-
quested simultaneously e.g. in case of a fire/terrorist attack/earthquake:
 70% of 27000 spectators (incl. first responders) perform emergency phone calls (e.g. 911, red-button
calls, etc.) (70%*27000*(~40 Kbit/s)=750 Mbit/s) requiring low latency < 1 ms.
 5% of spectators have emergency data sessions (e.g. messaging) (5%*27000*(~25 Kbit/s) = ~30
Mbit/s).
 3-4 Gbit/s is required for HD video sessions (each requiring ~100 Mbit/s) performed by ~30-40 first re-
sponders in place.
Therefore, a > 5 Gbit/s slice is required for emergency services/first responders, requiring low latency < 1 ms.
On top of this, a 5 Gbit/s slice is required for surveillance/security services which actually corresponds to a
number of HD/UHD cameras and IoT sensors scattered over the Stadium area.
In Table 16 the main requirements related to critical communications, emergency services, under the Stadi-
um and mega event vertical umbrella is reported.
Table 16: Stadium and Mega Event Requirements – Critical Communications, Emergency Services.
Emergency Phone Calls
Requirement First Responders Services
(incl. red-button)
<10ms (a) Error! Refer-
Latency <10 ms (a)
ence source not found.
H2020-ICT-2016-2017-762057 Page 49 of 88 31. Jan. 2018

Resiliency critical critical

Packet loss 10-4 10-4
Energy efficiency Not applicable Not applicable
Security (b) Critical critical
Bandwidth
40 Kbit/s/User ~100 Mbit/s/User
(DL/UL data rate)
Jitter Non Critical Non Critical (c)
Reliability > 99.999% > 99.999%
Availability > 99.999% > 99.999%
Mobility Yes-Low Yes-Low
traffic density (c) n/a n/a
Rely on sensor network Yes (optional) Yes (optional)
Connection density Depends on Situation Depends on Situation
Device direct (d) Depends on Deployment Depends on Deployment
Coverage > 99.999% > 99.999%
Battery lifetime Not applicable Not applicable
Update time Not applicable Not applicable
Data size Not applicable Not applicable
Notes on Table 16:
 (a) There should be no observable lag between clicking the emergency service request (e.g. the click on the ‘big red button’) and
network being reconfigured.
 (b) Access to emergency services should be restricted to authorised personnel and/or specific applications.
 (c) For voice and video emergency services jitter shall be low but it is not critical; for IoT based emergency services jitter shall be
< 10 μs.
 (d) Optional extension where smart sensors could trigger localised emergency services (mitigation actions, alerts, etc.).
4.3.2.2 Challenges
The key challenge associated with the provisioning of critical communication services is the delivery of a
network solution/deployment capable of satisfying the ultra-low latency requirements. At the same time, net-
work reconfiguration shall be performed within fractions of ms in order to support traffic priority handling irre-
spective of the network traffic, while fulfilling the latency requirements. The latter is a challenge to be faced
especially for advanced emergency services with high bandwidth requirements such as HD video sessions
and surveillance/security services based on HD/UHD camera. Last but not least, accurate indoor positioning
– in absence of GPS – is another challenge that needs to be addressed.
Current 4G solutions and deployments are incapable of serving such low latency use cases, since the rout-
ing of calls/sessions is performed at a remote network node – MME side. Actually, such low latency can be
achieved only by transferring network functions to the edge in order to allow routing of calls/sessions within
the same access node or between neighbour access nodes without reaching the remote core network
nodes. Moreover, for emergency data services sessions such low latency can be achieved by placing the
service, i.e. logic/processing/data/etc. (or part of it) to the edge network nodes. Towards this end, 5G-
PICTURE introduces the “on-demand” utilisation of edge network compute resources through the “DA-RAN”
concept. In case of emergency calls routed outside the hotspot network, latency can also reduce by exploit-
ing real world information such as the route to the hospital for an ambulance.
DA-RAN is especially useful also in the case of advanced emergency services with high bandwidth require-
ments terminated within the dense hotspot area nodes such as HD video sessions and surveillance/security
services based on HD/UHD camera. More specifically DA-RAN allows routing of high traffic only within the
network nodes dedicated to the dense hotspot area, thus saving network resources towards the core net-
work side – otherwise required as in case the service (logic/processing/data/, etc.) is deployed at core net-
work nodes or even outside the network.
H2020-ICT-2016-2017-762057 Page 50 of 88 31. Jan. 2018

Last but not least, increased reliability for such services can be ensured by allocating a dedicated network
slice; also included in the 5G-PICTURE concept.
These subjects are under study in WP3, WP4 and WP5.
4.3.3 Wireless Access Connectivity for Private/Local Events
Besides the games taking place at the Stadium bowl, other private/local events can be hosted at comple-
mentary Stadium spaces. ‘Event’ in this context means a smaller (private/local) event that is hosted only at
part(s) of the Stadium complex (e.g. meeting rooms, lounge, cafeteria). This use case focuses on the dynam-
ic, ad-hoc provisioning of the required connectivity through a web interface/application allowing a user (non-
technician) to create a localised Wireless Access network based on the Event timings and location within the
stadium (see also Table 17). This maps to the Education and Culture category [24] for latency requirements.
More specifically, as first step of the process, the Event registrar will log into the web application and select,
from a floor map of the stadium, the rooms required for hosting the event and provide other details such as
Service Set Identifier (SSID) required along with the schedule. This could be extended to a full ‘self-serve’
Event management website where the Event Organizer does everything from selecting the rooms to adding
services, etc. Then, through the web-app the Wi-Fi network will be (re)configured so as an event specific
wireless network, with the specified SSID available in the event area during the scheduled time period. It
would be possible to run multiple such events in parallel (up to a certain maximum limit).
Such service can significantly reduce OPEX by not requiring human intervention/support to configure the
wireless access networks, and it contributes to the more efficient monetisation of the stadium network infra-
structure.
In Table 17 the main requirements related to wireless access for private/local events, under the Stadium and
mega event vertical umbrella is reported.
Table 17: Stadium and Mega Event Requirements – Wireless Access for Private/Local Events.
Wireless Access Connectivity for
Requirement
Private/Local Events Service
Latency <10 ms [24]
Resiliency (a) essential
Packet loss 10-2
Energy
Not applicable
efficiency
Security (b ) essential
Bandwidth
20-100 Mbit/s/user
(DL/UL data rate)
Jitter Depends on Service
Reliability > 99.99%
Mobility No
traffic density Not critical
Rely on sensor network No
Connection density Not critical
Device direct Yes
Coverage > 99.999% at requested location
Update time Not applicable
Notes on Table 17:
H2020-ICT-2016-2017-762057 Page 51 of 88 31. Jan. 2018

(a) To avoid financial implications (e.g. issuing refunds) being imposed in case of failure.
(b) Access network security at a corporate level could be provided in support of business transactions (processing payments, etc.).
It is important to underline that different classes of Wi-Fi devices (e.g. 2.5 GHz/ 5 GHz) should be supported.
4.3.3.2 Challenges
The key challenge associated with this use case is the delivery of a scalable, low cost network solution ca-
pable of satisfying the spatio-temporarily fluctuating connectivity requirements on-demand through efficient
network (re)configuration and allocation of access and BH/FH network resources. In cases of hosting multi-
ple events, the major challenge is to satisfy the very high bandwidth requirements with high QoS. This im-
plies overcoming access network capacity limitations and providing a high capacity access/FH/BH network
while respecting the construction restrictions of the stadium owner described in previous sections.
Current network solutions are based on a more or less static allocation of resources at access and separate
FH and BH networks; thus requiring the deployment of a high capacity (over-dimensioned) network (thus
high investment) to support the peak traffic occasions which is under-utilised during the rest (perhaps most
of) period of time. Given the occasional appearance of such high traffic demand, adopting a common
transport network that can jointly support FH and BH as proposed by 5G-PICTURE can provide increased
efficiency in terms of resource requirements and the associated costs. This benefit can be further increased
exploiting virtualisation of network/compute resources and their “leasing” on-demand from a disaggregated
cloud infrastructure – as proposed in the context of 5G-PICTURE – can significantly minimise this invest-
ment.
Moreover, at the access network level, 4G networks face capacity and interference limitations as already
mentioned, which is especially visible in cases of hosting multiple events. At this point, 5G access network
solutions are required to deliver an access network layer of higher capacity. 5G-PICTURE access network
solution, i.e. the massive MIMO unit developed by Airrays (AIR) in WP3, addresses exactly this requirement.
In addition, the adoption of flexible functional splits as proposed and designed by 5G-PICTURE can provide
a more flexible solution facilitating the advanced 5G access technologies required and offering further bene-
fits in terms of efficiency as mentioned in previous sections.
4.3.4 IoT Services (Asset tracking, Power Management)
A large number of IoT services need to be supported in the Stadium area, the most common being Asset
Tracking and Power Management services.
Asset Tracking may involve tracking of objects (e.g. Tills, Wireless Tills) or people (e.g. staff, first respond-
ers, etc.). Asset Tracking can be managed by an application web-interface displaying the location of a num-
ber of end-devices/entities based on their access network anchoring i.e. with respect to the wireless access
point or data port they are associated with. Tracked entities are actually wired or wireless (IoT) devices con-
nected to the Stadium network, whose MAC addresses are registered to the service and probably catego-
rised by nature (e.g. objects, humans). Their location can be displayed on a floor wise map of the Stadium.
Such service would reduce OPEX related to personnel costs and minimise resource waste by having busi-
ness critical devices such as tills located and tracked.
Power Management Services can include (among others) remote monitoring of power consumption and
possibly power production/generation (e.g. in case there are solar energy generators/panels’) sources as
well as remote/automated management of the Stadiums’ lightning, heating, air-conditioning, and even net-
working end-points. The latter, corresponds to remote on-off switching of access network nodes depending
on the traffic demand. Such services will enable the Stadium owner to reduce the OPEX related to utility bills
and minimise resource waste.
Although such services have low delay and bandwidth requirements, there is a large number of connections
that need to be handled by the network.
In Table 18 the main requirements related to IoT services, under the Stadium and mega event vertical um-
brella is reported.
H2020-ICT-2016-2017-762057 Page 52 of 88 31. Jan. 2018

Table 18: Stadium and Mega Event Requirements – IoT Services.
Requirement Asset Tracking Power Management

Latency (a) <100 ms <100 ms [24]
Resiliency Critical Critical
Packet loss 10-2 10-2
Energy efficiency Important Important
Security (b ) Critical Critical
Bandwidth Low- Not critical Low- Not critical
(DL/UL data rate) (Depends on Service) (Depends on Service)
Jitter Not Critical Not Critical
Reliability (c) > 99.99% > 99.999%
Availability (c) > 99.99% > 99.999%
Mobility Yes - Low No
traffic density Low- Not critical Low- Not critical
Rely on sensor network (d) Yes Yes
Relatively Low-
Connection density (e) High (<1/m2)
Depends on Deployment
Device direct (f) No Yes
Coverage > 99.99% > 99.99%
Battery lifetime Not applicable Not applicable
Update time Not applicable Not applicable
Data size Not applicable Not applicable
Notes on Table 18:
(a) Locations should be updated as soon as possible.
(b) Service should be accessible only to authorised users – a breach could result in loss of privacy, etc.
(c) For a mega-event or match – where location tracking would be critical.
(d) Possible use of iBeacons and other sensors to fine tune location.
(e) This is at the peak rate for a mega-event or matches.
(f) Should cater to different classes of Wi-Fi devices (e.g. 2.5 GHz/ 5 GHz).
4.3.4.2 Challenges
The major challenge associated with this use case is the management of a large number of connected de-
vices and the real-time update of their status.
In general, IoT use cases can be well supported by current 4G/Wi-Fi/etc. technologies in terms of service
and network level QoS requirements. 4G technologies, however, are incapable of supporting massive IoT
deployments due to the large number of connections incurring a lot of signaling traffic. Especially in this use
case, signaling traffic corresponds mainly to tracking of a large number of devices. At the same time, network
slicing – as proposed by 5G-PICTURE – can satisfy the high availability/reliability requirements.
4.3.5 Next Generation Applications
This use-case refers to a significant sub-category of eMBB services discussed in section 4.3.1. It includes
applications that make heavy use of the ‘programmable’ network offered by various Northbound APIs at dif-
ferent levels of abstractions. One of the most important application is the Crowdsourced Video. It implies
that hundreds or even thousands of network connected users create and upload live video streams using a
smartphone application. These video streams are processed in a later stage to offer end users a manual or
automatic production that alternates different source video streams, as usual in any video production. In ad-
dition to that, beyond the produced view, end users have also the possibility to select which source video
H2020-ICT-2016-2017-762057 Page 53 of 88 31. Jan. 2018

stream want to see (multi-camera feature). Such service is applicable in any scenario where multiple mobile
phones are recording a specific content. In the present project we consider a use case scenario of match or
mega-event (e.g. music concert) taking place.
The major constraint here are the bandwidth and latency (latency dependent applications makes QoS very
important), especially in the ‘first mile’ connectivity (i.e. the wireless network). A large concentration of users
streaming high quality video (via the Crowdsourced video app) from their phones can quickly saturate the
bandwidth of the local wireless network and lead to other users’ pre-emption. More specifically, in current
deployments the transmission of a HD video stream (optimised by the Application to select the best com-
pression) requires a 3 Mbit/s bandwidth, at minimum2 and in the future the upper limit (Blu-ray quality 1080p)
is expected to reach 8 Mbit/s. Assuming a mega-event with large number of visitors, the aggregate band-
width requirement can reach tens of Gbit/s as presented in Table 19.
Table 19: Crowdsourced Video Application Scaling.
Number of Content Aggregate Bandwidth Requirement Aggregate Bandwidth Requirement

Creators (@ 3 Mbit/s) (@ 8 Mbit/s)
100 300 Mbit/s 800 Mbit/s
1000 3 Gbit/s 8 Gbit/s
10000 30 Gbit/s 80 Gbit/s
As a solution to network saturation, application specific network slicing can be employed in order to isolate –
in terms of ensuring security and mitigating interference to/from other communication services in case of
network congestion- and manage the application generated traffic (e.g. blocking hosts with low quality con-
tent, etc.).
In Table 20 the main requirements related to Crowdsourced Video, under the Stadium and mega event verti-
cal umbrella is reported.
Table 20: Stadium and Mega Event Requirements – Crowdsourced Video.
Requirement Value
Latency (a) <5s
Resiliency Important
Packet loss 10-2
Energy efficiency (b) Important
Security (c) Critical
Bandwidth (d)
3-8 Mbit/s/user
(DL/UL data rate)
Jitter n/a
Reliability > 99.9%
Mobility Yes
traffic density Hundreds of thousands of Mbit/s per km2.
Connection density Tens to Hundreds of thousands per sq. km.
2compression (codec), resolution (HD in this case, typically 1080*720) and frames per second (24 fps min-
imum).
H2020-ICT-2016-2017-762057 Page 54 of 88 31. Jan. 2018

Device direct Yes

Coverage Not applicable
Notes on Table 20:
(a) There should be no observable lag between a user making a video and upload to server (assumption - videos are restricted in
size) – this is based on the application layer.
(b) Saving smart phone batteries.
(c) Only selected hosts should be allowed to participate, ability to kick hosts.
(d) Standard upper limit for Blu-Ray quality 1080p (24fps) stream.
4.3.5.2 Challenges
The challenges posed by this use case have already been discussed in section 4.3.1, and they are mainly
related to the special environment of the Stadium and the satisfaction of extremely high traffic density re-
quirements with wireless access solutions, implying overcoming access network capacity limitations and mit-
igating interference issues, and providing a high capacity access/FH/BH network, while respecting the con-
struction restrictions of the stadium owner.
The most important challenge to be addressed is the minimisation of CAPEX/OPEX investment on network
infrastructure to serve the extremely high amount of traffic, through effective, flexible, fast, “on-demand” net-
work reconfiguration to enable resources scaling for the specific application, given the occasional occurrence
of such high traffic.

Current 4G solutions and deployments are incapable of serving such high capacity use cases. As aforemen-
tioned, at access network level, 4G networks face capacity and interference limitations. Therefore, 5G ac-
cess network solutions are required employing massive MIMO, interference coordination/mitigation and op-
eration on larger bandwidth, higher frequency bands, as addressed by 5G-PICTURE both in terms of the ac-
cess and transport network technologies.
Moreover, unlike the static mapping of the radio access resources to base-band units/resources in 4G, virtu-
alisation of BB processing, “leasing” and scaling up/down on-demand resources as proposed in the context
of 5G-PICTURE, can significantly minimise network costs, given the occasional appearance of such high
traffic demand. At the same time, flexible functional splits can further facilitate the deployment of advanced
wireless access technologies such as massive MIMO and support their increased transport capabilities de-
ploying also optical fibre deployments.
Moreover, network slicing as addressed by 5G-PICTURE can provide the means to isolate and manage the
application generated traffic, avoiding interference from/to other communication services.
4.3.6 UHD Broadcasting Services
Lossless ultra-high definition (UHD) (e.g. 4K) video streams is one of the services to be supported over 5G
networks, in the case of the Stadium corresponding to the support of immersive experience services (e.g.
VR) especially during mega-events and matches. A major creator of such services could be Broadcasters
and/or content providers while a major consumer of such services/streams could be either the fans in the
stadium logged in to the Wireless Access network (via the Fan App perhaps) or end-users located else-
where. This includes Augmented Reality applications as well.
These services are bandwidth and processing intensive with requirements ranging between 1 Gbit/s – 10
Gbit/s; practically, 2-3 Gbit/s seems sufficient for the VR UHD video services’ upstream, and more or less the
same for the broadcast downstream ([31], [32]). Low latency and high reliability are also required. For the
support of such services, a temporarily fixed resource allocation would be needed, satisfying the service
specific QoS requirements. This corresponds to allocating a network slice to such services for a specific
time-period i.e. during the event; while any network optimisation shall take into consideration these require-
H2020-ICT-2016-2017-762057 Page 55 of 88 31. Jan. 2018

ments. To this end, virtualisation of common traffic processing functions (such as load balancers) can pro-
vide a highly reliable and low-latency data feed.
On the other hand, the low-latency requirement can be met also by moving all or part of the video processing
and storage functions as close to the end-user as possible, i.e. to be performed using compute resources lo-
cated at network edge.
In Table 21 the main requirements related to UHD Broadcasting, under the Stadium and mega event vertical
umbrella is reported.
Table 21: Stadium and Mega Event Requirements – UHD Broadcasting.
Requirement Value
Latency (a) < 10 ms [29]

Resiliency Essential
Packet loss 10-5
Energy efficiency Important
Security (b) essential
Bandwidth 1-10 Gbit/s (average 2-3
(DL/UL data rate) (c ) Gbit/s)
Jitter < 20 ms
Reliability (d) > 99.999%
Availability (e ) > 99.999%
Mobility Very Low
Not applicable
traffic density
(broadcast service)
Not applicable (broadcast
Connection density
service)
Device direct No
Coverage 99.99%
Notes on Table 21:
(a) There should be minimum latency as this would be a live video feed.
(b) Only identified hosts should be allowed to access video stream.
(c) Ultra-HD (4K-8K) video stream.
(d) Failures can cause significant damage to revenue and reputation.
(e) Only during a live event.
4.3.6.2 Challenges
This use case poses a number of challenges mainly related to provisioning this high capacity, low latency
connectivity with wireless access solutions, since this implies:
 overcoming access network capacity limitations and mitigating interference issues,
 providing a high capacity access/FH/BH network,
 separating the traffic belonging to different tenants, while preserving QoS,
 satisfying the low latency requirements,
H2020-ICT-2016-2017-762057 Page 56 of 88 31. Jan. 2018

, and, at the same time, respecting the construction restrictions of the stadium owner regarding:
 the deployment of network equipment; in terms of reducing cabling, of placement of access network
nodes/RRHs/BBUs, etc.,
 the operation of a vendor agnostic solution, and
 the minimisation of CAPEX/OPEX investment through “on-demand” network scaling given the occa-
sional occurrence of such traffic.

Current 4G solutions and deployments are incapable of serving such high capacity, low-latency use cases.
As aforementioned, at access network level, 4G networks face capacity and interference limitations. Actually,
a single broadcast service of 2 Gbit/s pushes existing 4G access network nodes at their limits. Therefore, 5G
access network solutions are required in order to deliver an access network layer of bandwidth higher than 2
Gbit/s per node.
Moreover, given the occasional appearance of such high traffic demand, the static mapping of the radio ac-
cess resources to base-band units/resources implies high CAPEX investment to serve this traffic with 4G
technologies. For this purpose, as already mentioned in previous sections, 5G-PICTURE focuses on the vir-
tualisation of BB processing and “leasing” on-demand network and compute resources. Flexible functional
splits, as proposed and designed by 5G-PICTURE, can lead to more efficient optical network utilisation.
On the other hand, in current 4G solutions routing of sessions is performed at a remote network node – MME
side – while processing and storage servers are located at the core network side, if not outside the wire-
less/mobile network. This poses limitations in the latency achieved, while it consumes a lot of network re-
sources, unnecessarily in case of data sessions originating and terminating within the same access node or
between neighbour access nodes. Low latency and efficient network resources utilisation can be achieved
by transferring network functions as well as service/application processing and storage functions to the edge
in order to allow routing of data sessions within the same access node or between neighbour access nodes
without reaching the remote core network nodes. Towards this direction 5G-PICTURE proposes the DA-RAN
concept.
Last but not least, traffic belonging to different tenants (to be served over a single network infrastructure) can
be better managed -with less QoS compromises- by employing network slicing as proposed by
5G-PICTURE.
4.3.7 Requirements summary for stadium and mega event
Figure 16 and Figure 17 summarize all the requirements for the use cases composing the Stadium and
Mega-event vertical. It is important to note that four vertices overlap with the big hexagon, i.e., peak data
rate, user plane latency, number of connected devices per cell and capacity, which means that they are very
challenging.
H2020-ICT-2016-2017-762057 Page 57 of 88 31. Jan. 2018

4.4 Industry 4.0

The term Industry 4.0 indicates a trend of industrial automation that integrates some new production tech-
nologies to improve working conditions and increase productivity and production quality of the plants.
Figure 18 briefly describes the Industry 4.0 vertical.
H2020-ICT-2016-2017-762057 Page 58 of 88 31. Jan. 2018

Figure 18: Pictorial view of the vertical “Industry 4.0”.
The described industry 4.0 vertical refers to a factory in the automotive field with a size of about 1 km 2 and
some hundreds robots working in it. The total number of sensors is some thousands.
Due to the high complexity of the scenario, it is important to note that, from a network requirement point of
view, the industry 4.0 vertical can be split in different services or applications, presenting different require-
ments.
In brief, the “applications” to be considered within the Industry 4.0 umbrella are:
 Communication network for robot arms controllers (Ultra-Reliable Low Latency Communication –
URLLC service category).
 Automated guided vehicles inside the factory, to transport manufacturing (URLLC service category).
 Video-surveillance (Ultra Mobile Broad Broadband UMBB 5G service category3).
 Quality check video / images (UMBB service category).
 Augmented reality (UMBB service category).
4.4.1 Robotics Arms Control
Robotics arms control is one of the key elements of the so-called factory cell automation. It consists of re-
mote control of sensors mounted over the arms of the robots acting along the automated line production of a
4.0 Industry. The sensors are connected to mechanical actuators and a reliable, real-time control is required
in order to achieve precise manipulation of the items that are automatically produced.
With regards to remote control, in general in “Mobile Cloud Robotics” [27] the robots intelligence is moved to
the cloud, with the support of 5G mobile communication. In this way, the individual robots have much less
hardware and software for low level controls, sensors and actuators w.r.t. conventional robots, while the
whole smart robots system has unlimited computing capacity running on dedicated servers and/or DCs lo-
cated into the cloud. Robots generally have also sensors that can directly interact with each other via, e.g.,
Bluetooth communication, and can also coordinate themselves with the product line, while a general control
system permits the remote control.
In Table 22 the main requirements related to this application of the Industry 4.0 vertical are reported.
Robotics arms control is one of the Internet of Things functions provided through the 5G network called “Ul-
tra Reliable Low Latency (URLLC)” application.
Reliability, that is generally defined as the probability that a certain amount of data has been successfully
transmitted from a transmitting end to a receiving end before a certain deadline expires, in this case amounts
3Normally, video-surveillance would not be included in Ultra Mobile BroadBand services, except in the case
of massive adoption of safety-oriented or enhanced security applications like facial-recognition.
H2020-ICT-2016-2017-762057 Page 59 of 88 31. Jan. 2018

to more than 99,9999999%. In 5G the term “Reliability” may also be intended as the ability to guarantee a
packet loss of less than 10-9, as indicated in Table 22.
Low Latency means a user plane latency in the order of 1 ms, pushing the latency limit of current 5G perfor-
mances estimation. At the moment, latencies below 1 ms could only be covered by fibre connection.
With respect to the parameters defined in par. 3.2, for the robotics arms control application a further parame-
ter is considered, named “Rely on sensor network”, referring to the direct communication system between
sensors.
Table 22: Requirements for industry 4.0 – robotics arms control.
Requirement Value
Latency [34] 1 ms
Packet loss [33] 10-9
BER
Energy efficiency Not applicable
Security Non essential
Data Rate
around 100 Kbit/s
(DL/UL data rate)
Jitter 0.01-0.1 ms
Packet delay variation order of μs
Reliability [35] > 99.9999999%
Availability [35] > 99.9999999%
Mobility [33] No
traffic density 1000 Mbit/s per km2
Rely on sensor network Yes
Connection density > 2000 per km2
Coverage 1-2 km2
4.4.1.2 Challenges
The most challenging requirement for this application is the latency limit of 1 ms. Today, available LTE im-
plementations can push latency from a typical value of 50 ms down to a limit of 20 ms in case of traffic cen-
tralisation at Core Network for security purposes (Security Gateway at EPC) [36] and 10 ms for the 2-way
RAN [37].
Reliability and availability are the other challenges. With respect to the LTE requirements, the maximum ac-
ceptable packet loss would be 10-9 instead of 10-6 [36]. Also, high availability is required especially in terms
of proper delivery of network slices and virtual network functions.
Robotic arms control involves a lot of sensors which are used both for monitoring (non-mission critical) and
control (mission critical) purposes. Sensors can be managed via gateways (especially the monitoring ones in
order to allow reduced cost) or directly managed one-by-one, but in both cases it seems correct to consider
each sensor as a contributor to the overall connection density. So, connection density requirement is also a
bit challenging with respect to the current one supported by LTE, because it is typically around 2000 per km 2.
5G-PICTURE should exploit innovative solutions to have a scalable “over-the-air” latency, depending on the
application considered. Flexible and shorter transmission time interval (TTI) and reduced round-trip time
(RTT) should be considered between the 5G devices and the antennas for URLLC applications [38]. Also,
H2020-ICT-2016-2017-762057 Page 60 of 88 31. Jan. 2018

local-source applications available via virtualisation are another innovative solution to be considered in order
to reduce latency.
5G-PICTURE should also bring innovation into the NFV architecture to improve reliability and availability in
URLLC services, exploiting new solutions to have stateless VNFs that can be easily recovered by dedicated
5G Data Storage Network Functions in case of VNF software download or hardware malfunctions [39].
4.4.2 Automated Guided Vehicles
Automated Guided Vehicles (AGV) are part of a scenario in which driverless vehicles transport materials
and/or goods within a factory. They are totally integrated with all the elements of the existing production line
in order to optimize different aspects of logistic, such as distance, time, space and energy.
The idea of including AGV solutions in a factory is strictly linked to the need to improve safety, efficiency,
flexibility and cost savings. For these reasons, AGV can be considered as part of URLLC service category,
especially looking at the required reliability.
Several forms of navigation are currently available for the AVG, in some cases more than one application is
used by the same vehicle, and it is sure that each vehicle must rely on a very dense sensor network. Fur-
thermore, an efficient control system is required to manage and control paths and instructions imposed on
the vehicle.
In Table 23 some requirements for this application are listed. In particular, key points are the challenging
level of availability (99.99999%, i.e. 3 s per year of unavailability) and reliability. Mobility is important, but the
speed of vehicles is limited to 10 m/s, i.e. 36 km/h. Interesting but not challenging points are the number of
devices (about 100 vehicles and hundreds of sensors per km 2) and the service rely on sensors. For this last
reason, with respect to the parameters defined in section 3.2, the parameter “Rely on sensor network” is also
considered.
Table 23: Requirements for industry 4.0 – automated guided vehicles.
Requirement Value
Latency [27] 10 ms
BER
Energy efficiency Non critical
Security Non critical
Data Rate
around 100 Kbit/s
(DL/UL data rate)
Jitter Non critical
Packet delay variation order of μs
Reliability [27] > 99.99999%
Availability [27] > 99.99999%
Mobility [27] 36 km/h
traffic density tens of Mbit/s per km2
Rely on sensor network yes
Connection density hundreds per km2
Coverage 1-2 km2
H2020-ICT-2016-2017-762057 Page 61 of 88 31. Jan. 2018

4.4.2.2 Challenges
The 10 ms of latency is still a challenging requirement, even if today proper LTE architecture implementa-
tions can push latency from a typical value of 50 ms down to a limit of 20 or 10 ms (d). With respect to Relia-
bility and Availability, which are the other two challenging requirements for this application, the related con-
siderations already reported in paragraph 4.4.1.2 can be taken into account.
5G-PICTURE exploits innovative solutions to have a scalable “over-the-air” latency, depending on the appli-
cations, as considered in WP3, WP4 and WP5. A disaggregated architecture allows to reduce the distance
and the number of crossed devices between the user and the core network, permitting to achieve challeng-
ing level of latency and availability.
4.4.3 Video applications: Video-surveillance
In a 4.0 factory, the Video-surveillance will be used not only for traditional purpose related to security, but al-
so for increasing the safety of the plant and to enable new levels of automation. A lot of applications can be
envisaged due to the capability to automatically analyze images and reacting consequently. For instance, a
camera covering a portion of the plant could send images to an application able to recognize un-authorised
(or unexpected) people or vehicles in that island, properly triggering alarms or actions. Also, the application
could monitor factory actions and activate a service accordingly (i.e. counting vehicles access in the island
and asking for a cleaning service when the counter hits a threshold).
Considering the traditional application of video-surveillance, resiliency and security are important require-
ments that the solution must guarantee. However, the new applications described above also slightly push
requirements in terms of bandwidth, traffic and connection density, as well as latency: for this aspects, video-
surveillance could be included in uMBB service category.
Current High Definition video cameras (1 or 2 Megapixels resolution) are good enough to enable this kind of
applications. In terms of required bandwidth, using the video encoding H.264 standard, less resolution-
demanding tasks would be satisfied with a bandwidth of about 1 Mbit/s per camera, up to about 5 Mbit/s per
camera considering resolution-challenging services like “facial recognition”. For a medium-size factory cover-
ing around 1 km 2, if these innovative features are widely deployed, the impact in terms of traffic density can
be estimated in hundreds of Mbit/s, generated from tens of cameras.
Also latency requirements become important in order to enable an “almost real time” reaction to events re-
lated to safety applications. An acceptable latency value can be estimated to be around 10 ms, as for the
AVG service.
Table 24 summarizes the requirements for video-surveillance application.
Table 24: Requirements for industry 4.0 – Video-surveillance.
Requirement Value
Latency 10 ms
BER
Security Important
Data Rate 1-5 Mbit/s per camera
(DL/UL data rate) (H.264)
Jitter Non critical
Packet delay variation Non critical
Reliability >99.9%
Availability >99.9%
Mobility No
H2020-ICT-2016-2017-762057 Page 62 of 88 31. Jan. 2018

traffic density Hundreds of Mbit/s per km2

Connection density Tens per km2
Coverage 1-2 km2
8-64 kB per frame (H.264)
Data size
[40]
4.4.3.2 Challenges
The video-surveillance service is not particularly challenging in terms of 5G requirements, especially if a tra-
ditional security-only application is implemented. If innovative safety-oriented applications are foreseen, the
low latency requirement of about 10 ms should be considered, since the video captured by the camera must
quickly trigger alarms or actions.
4.4.4 Video applications: quality check
An important application of the Industry 4.0 vertical is to check the quality of products or semi-finished ones
by comparing a high resolution picture or video of the object with a perfect, without failures, one stored in a
centralised data base. If the comparison matches, the work can go ahead, if not, some actions should be
taken, depending on the level of mismatching. In any case an alarm is raised. The traffic coming from a qual-
ity check camera is a periodic signal, similar to a square-wave characterised by a high peak (about 1 Gbit/s)
and a very short duty-cycle.
From a network perspective point of view, a quite huge data (high definition picture or video) should be sent
to a server where the original picture (or video) resides.
As reported in Table 25, the most challenging requirement is the traffic density that can achieve tens of
Gbit/s per km 2 and the single connection up to 1 Gbit/s. Packet loss and reliability / availability are not ex-
tremely challenging.
Table 25: Requirements for industry 4.0 – Quality check use case.
Requirement Value
Latency Non critical
Packet loss 10-9 [30]
BER 10-12
Security Important
Data rate
1Gbit/s
(DL/UL data rate)
Jitter Non critical
Packet delay variation Non critical
Reliability > 99.999%
Mobility No
traffic density 10-5 of Mbit/s per m2
Connection density 50-100 per km2
Coverage 1-2 km2
Data size TBD w.r.t. protocol/signal
H2020-ICT-2016-2017-762057 Page 63 of 88 31. Jan. 2018

4.4.4.2 Challenges
High data rate up to 1 Gbit/s for single connection is not available today with current LTE-A implementation,
even if future evolutions can lead to such a target. Despite the high data rate required, the impact on the traf-
fic density requirement is mitigated because the camera density is not huge.
4.4.5 Video applications: augmented reality
The overlaying of virtual information on the real world view is called “Augmented Reality” (AR), and applying
this concept makes it possible to enhance a human’s perception of reality [18]. In the fourth industrial revolu-
tion, where smart factories use new technologies and production philosophies to realize short product life-
cycles and extreme mass customisation in a cost-efficient way, operators’ work will no longer be static and
predetermined, but instead dynamic and constantly changing [23] [19]. This will put high demands on opera-
tor ability to be flexible and adaptable [25]. Moreover, they must be equipped with efficient technology that
supports optimal decision making and action. In recent years, augmented reality smart glasses, for example,
have been identified as a powerful technology supporting shop-floor operators undertaking various tasks
such as assembly, maintenance, quality control and material handling.
Presenting remote information at eye level, just where it is needed in a hand free situation, using camera-
based object recognition, the specific object the user is looking at is detected, providing context-aware infor-
mation dynamically adjusted to the specific situation [20]. Real time video transmission and information
gained from a sensor network are acquired and provided to the operator, who itself defines and generates
video streaming and camera images to proper acceptance tools and quality control databases.
High availability, fast response (i.e. low latency), strong security and high reliability are key elements in so-
phisticated production processes that are running based on huge investments and technological challenges.
Being hand free, wearable products [26], augmented reality smart glasses technology is strongly focused on
energy efficiency issues and low battery power consumption. To complete the overall list of requirements,
video transmission asks for high bandwidth and low jitter data transfer, leading to include this application in
uMBB service category. Table 26 details all these requirements for this augmented reality application.
Table 26: Requirements for industry 4.0 – Augmented reality.
Requirement Value
Latency [41] < 7 ms
Packet loss 10-9
BER 10-12
Energy efficiency Important (saving batteries)
Security Important
Data rate [41]
1 Gbit/s [42]
(DL/UL data rate)
Jitter 0.01-0.1 ms
Packet delay variation Order of ms
Reliability >99.999%
Availability >99.999%
Mobility No
traffic density 10-5 of Mbit/s per m2
Rely on sensor network Yes

Connection density Hundreds per km2
Coverage 1-2 km2
Battery lifetime Days (rechargeable)
Data size TBD w.r.t. protocol/signal
H2020-ICT-2016-2017-762057 Page 64 of 88 31. Jan. 2018

4.4.5.2 Challenges
Today a 4K 360° video at 30 fps can be handled by 4G infrastructure in terms of bandwidth (typically less
than 50 Mbit/s is required): however to fully support the AR application in the Industry 4.0 vertical, adoption
of Six Degrees of Freedom (6DoF) video should be considered, in order to compute and analyse the position
and orientation of a rigid body using only a single camera. Such a kind of videos pushes bandwidth require-
ments around 1 Gbit/s or more.
However, together with bandwidth requirement, latency is also critical for augmented-reality, especially con-
sidering remote machinery control in industry: in this case values below 10 ms (typically 5 ms) are required.
Last but not least, as power supply for AR devices will be provided by rechargeable small batteries, the
communication with the 5G network should be optimised in terms of energy efficiency, to allow a working pe-
riod of at least 12 hours before recharging.

To cope with the very high bandwidth need for this application, 5G-PICTURE (in particular WP3, WP4 and
WP5) will look into advanced Radio Access solutions. To reduce latency, evolutions of communication proto-
cols between devices and base station/network edge could reduce the overall round-trip time: moving the
application access point to the network-edge, leveraging network slicing and NFV features, which can be
beneficial.
4.4.6 Requirements summary for Industry 4.0
Figure 19 collects all the use cases figures for Industry 4.0 vertical.
In more detail, the robotics arms control (green) shows that the most stringent requirement is the user plane
latency at 1 millisecond, while the other parameters are not so critical, while there is not a specific parameter
that has stringent value influencing the AGV (light blue line). The unique aspect that influences the AVG ser-
vice is mobility, in fact vehicles can reach speeds of some tens of kilometers per hour. The control and man-
agement of signals that interact with sensors network have to be accurate, considering that they are moving
vehicles, but it doesn’t imply critical constraints because of low peak speeds.
About the video-surveillance use-case requirements (yellow line), it seems that this application is not impact-
ing heavily the network requirements: only latency and capacity can become a bit challenging, depending on
how much the innovative services are deployed with respect to the traditional approach only focused on se-
curity. The hexagon reporting the quality-check video application shows immediately that the requirements
are not really challenging.
On the other hand, the area of the red hexagon representing augmented reality is quite big, i.e. this means
that some requirements are challenging. The high data rate required for this application (augmented reality),
even in a quite low number of devices, implies a huge total capacity of the network. Mobility is not important
but energy saving is mandatory.
H2020-ICT-2016-2017-762057 Page 65 of 88 31. Jan. 2018


Figure 20 summarizes all the requirements for the use cases composing the Industry 4.0 vertical. It is im-
portant to note that 2 vertices, regarding peak data rate and latency overlap with the big hexagon (so they
are very challenging) and some other ones are in any case to be taken into account (in particular the number
of connected devices, that is more than 2000 per km 2 and the capacity above 10 Gbit/s per km2).
H2020-ICT-2016-2017-762057 Page 66 of 88 31. Jan. 2018

5 Verticals, stakeholders and Roles

As already mentioned, 5G follows a top-down (from verticals to technologies) development and deployment
approach, thus leading to a complete transformation of the ICT and other businesses ecosystem. In this con-
text, 5G-PICTURE aims at delivering a 5G solution to transform verticals and ICT asset owners from closed
inflexible environments into a pool of ICT infrastructure and stakeholders having access to it on demand. In-
evitably, this transformation will incur changes in the current market stakeholders’ and roles, while it implies
the creation of additional ones.
More specifically, the main roles that have been identified in the 5G-PICTURE value chain are the following:
5G-PICTURE Operator. By this definition, we refer to the role of practically operating the 5G-PICTURE solu-
tion/framework, and having access to the HW/SW pool of resources to enable (instantiate) the dynamic pro-
visioning of infrastructure resources to various Tenants based on their needs and requirements. The role of
the 5G-PICTURE Operator, can be undertaken either by the infrastructure owner(s) such as by a Mobile
Network Operator (MNO), a private 5G network owner (e.g. Stadium owner), or by a third party having ac-
cess to Infrastructure Providers’ resources under specific agreement (terms and conditions).
Infrastructure Providers, merely providing infrastructure resources (network resources, storage space,
compute resources) to third parties (to be utilised in a dynamic way in the 5G-PICTURE framework) by ex-
posing programmable interfaces to the 5G-PICTURE operator for the support of the 5G-PICTURE frame-
work. Depending on the nature of the infrastructure resources, we can identify:
 Telecommunication Infrastructure Providers, providing network resources for connectivity purpos-
es. Particularly, either they perform the programmable dynamic provisioning of network resources via
5G-PICTURE solution or they expose programmable network interfaces to the
5G-PICTURE operator. This role is expected to be undertaken by Telecom (Mobile and/or Fixed- net-
work) infrastructure providers operating a programmable 5G network infrastructure spanning from the
radio and/or fixed access to the edge, transport and core network.
 Cloud Infrastructure Providers, providing cloud -compute and storage- resources (either directly via
5G-PICTURE or by exposing programmable interfaces of the cloud deployment to 5G-PICTURE oper-
ator). This role can be either played by the Telecom (Mobile and/or Fixed- network) infrastructure pro-
viders, or by a third party-cloud infrastructure provider operating centralised (local) or distributed (in
multiple locations) cloud/edge deployments and offering compute and storage resources in a pro-
grammable way.
Equipment Vendors, manufacturing the physical equipment (e.g. massive MIMO antennas, optical compo-
nents) as well as the software (SDN, NFV, Physical interfaces) for the 5G network.
VNF/PNF Developers, developing virtual (VNFs) or physical (PNFs) network functions, thus practically im-
plementing the 5G-PICTURE programmable network layer functions, and delivering these compo-
nents/functions to the Infrastructure providers or to the 5G-PICTURE Operator. This role can be played ei-
ther by Telecom Equipment Vendors or by Infrastructure providers, by accessing the 5G programmable inter-
faces.
5G-PICTURE Tenants, who request the provisioning of network and compute/storage resources of the 5G
infrastructure in the dynamic and efficient way that the 5G-PICTURE framework allows, to be able to offer
the services that fall into its business (activities of interest). Charging of this resource provisioning will be on
a contract basis, including Service Level Agreements (SLAs), depending on the utilisation of the resources
which may vary throughout the day or the year (in a foreseeable or not foreseeable way). A
5G-PICTURE tenant could be a MNO, an ISP, a Vertical like the ones described in Chapter 3, a third party
providing services to a Vertical, etc.
End Users. These are stakeholders who enjoy the 5G services while being static or on the move. As end-
users are considered the subscribers (corporate or individuals) of a Telecom operator or a Vertical, or the
Verticals themselves in case they make use of 5G services in support of their specific business activities.
It is important to note that in case of a commercial 5G-PICTURE deployment, the boundaries between
stakeholders and roles may be blur. More specifically:
H2020-ICT-2016-2017-762057 Page 67 of 88 31. Jan. 2018

 A stakeholder may undertake more than one roles (e.g. the same Telecom operator can be responsi-
ble for both the operation of the 5G-PICTURE solution and the provisioning of the infrastructure re-
sources), or
 A stakeholder role may be shared among more than one stakeholders, depending on the assets that
they possess and their business activities (e.g. instead of one Infrastructure provider, the model could
be that a Telecom Operator provides connectivity resources to MNOs, Tenants, etc., while a Cloud in-
frastructure provider provides the storage/processing resources to them).
H2020-ICT-2016-2017-762057 Page 68 of 88 31. Jan. 2018

6 Network requirements
6.1 Requirements’ Description Conventions
The satisfaction of stakeholder/ tenant/ service/ application requirements – identified in Chapter 4 – poses
specific technical requirements to the underlying network. This chapter aims at translating the user and ap-
plication requirements into specific technical requirements that need to be addressed by the 5G-PICTURE
network architecture and technology selection, actually by any 5G network deployment. To this end, the de-
rived requirements refer to the overall network performance, to network capabilities and functionalities, as
well as to operational (non-functional) aspects such as network security/privacy, equipment modularity, archi-
tecture/system extensibility/maintainability, interoperability with multiple technologies/applications, etc.
For the purpose of having a homogeneous reading of 5G-PICTURE requirements, each requirement has
been specified by the contents of Table 27.
Table 27: Requirements Definition in Tabular Format.
<Req. ID> <Requirement Title>
Priority Essential/Optional
The ‘Description’ field contains the specification of the requirement (descrip-
Description tion of the purpose and goals to be fulfilled), written in a preferably concise,
yet clear way.
The ‘KPIs/Parameters to be measured’ field contains:
 for measurable requirements, the definition of the parameters to meas-
KPIs/Parameters ure the satisfaction of this requirement,
to be measured  for immeasurable requirements, the qualitative criteria (or de-
signed/deployed functionalities) to indicate the satisfaction of this re-
quirement.
Network Compo- The ‘Component(s)’ field defines the 5G-PICTURE component(s) to which
nent(s) the requirement is applicable. (It may not apply to user requirements.)
<Req. ID>: This field provides a unique code to exclusively identify each individual requirement and ease
tracking of its fulfilment in the next steps of the project. This field has the following generic format: U/S-
TYPE-RQT#. In this format, the following sub-fields are identified:
 U/S indicates whether this is a user or system requirement.
 TYPE indicates the type of the requirements and may take the following values:
o FUNC – functional requirement.
o PERF – non-functional performance requirement.
o OTH – other (non-functional) requirement, i.e. related to security/privacy, modularity, extensi-
bility, maintainability, interoperability requirement.
 RQ# is an incremental number uniquely identifying the requirement.
Priority: This element specifies the criticality of the requirement.

Other fields have been considered, such as the description of the requirement, which are the main parame-
ters and KPIs to be measured and which are the network components that this requirement is implying.
A more detailed description of these fields is reported in Table 27.
6.2 Performance Requirements

Tables 28 to 32 summarize the most important performance requirements resulting from studies in chapter 3.
H2020-ICT-2016-2017-762057 Page 69 of 88 31. Jan. 2018

Table 28: Low delay latency requirement.
U-PERF-1 Low Delay/Latency

Priority Essential
Low Delay/Latency is required. The targeted value depends on the use case, rang-
Description
ing between 1ms (device to device delay) to tens of ms for end-to-end delay.
KPIs/Parameters
KPI: Delay time in ms for each link, at the testing phase.
to be measured
Network
End-to-End
Component(s)
Table 29: High bandwidth requirement.
U-PERF-2 High Bandwidth

Priority Essential
High Bandwidth is required. The targeted bandwidth depends on the use case,
Description
ranging from hundreds of Mbit/s up to some Gbit/s for each connection.
KPIs/Parameters
KPI: Throughput for various use cases, at the testing phase
to be measured
Network
End-to-End
Component(s)
Table 30: High mobility requirement.
U-PERF-3 High Mobility

Priority Essential
High Mobility needs to be supported without compromise on the perceived QoS (La-
tency/Throughput). The targeted maximum speed value depends on the use case,
Description
ranging from static (some Stadium/Mega Event use cases) up to hundreds of Km/h
in the Rail use cases.
KPIs/Parameters
KPI: Performance (Latency/Throughput) under various mobility patterns/speeds.
to be measured
Network
End-to-End
Component(s)
Table 31: High connection density requirement.
U-PERF-4 High Connection Density

Priority Essential
High Connection Density needs to be supported without compromise on the per-
ceived QoS (Latency/Throughput). The targeted density depends on the use case,
Description
ranging from a few up to thousands of devices per km2 in the Smart City and Stadi-
um use cases.
KPIs/Parameters
KPI: Number of devices to be supported from a single access node.
to be measured
Network
End-to-End
Component(s)
Table 32: Traffic density requirement.
U-PERF-5 Traffic Density

Priority Essential
H2020-ICT-2016-2017-762057 Page 70 of 88 31. Jan. 2018

High Traffic Density needs to be served at some verticals’ use cases (e.g. Stadium)
Description
reaching up to hundreds of Gbit/s per Km2.
KPIs/Parameters KPI: Total capacity offered (by a number of access network nodes) over a specific
to be measured hotspot area.
Network Com-
End-to-End
ponent(s)
6.3 Functional Requirements

Tables 33 to 41 summarize important functional requirements resulting from studies in Chapter 3.
Table 33: Air interface requirement.
S-FUNC-1 Air Interface Characteristics

Priority Essential
Towards delivering the required capacity (both at 5G access and wireless BH/FH
links), it is needed to design and develop antennas operating at high frequency
bands (mmWave, Sub-6 GHz), at high bandwidth – in the order of GHz – utilising
massive MIMO techniques in various modes for capacity enhancement, interference
Description mitigation/cancelation, etc.
At the same time it is required to design and develop high performance Baseband
Processing units capable to support the processing of this high capacity traffic within
fractions of ms.
KPIs:
 Antenna operation at mmWave & Sub-6 GHz bands, using massive MIMO
KPIs/Parameters schemes in various modes
to be measured  Antenna performance for various configurations
 Access nodes’ (Antenna & BB unit) capacity and processing performance for
various configurations
Network Com-
Antennas, BBUs, Access Nodes
ponent(s)/ Level
Table 34: BBUs virtualisation requirement.
S-FUNC-2 BBUs Virtualisation

Priority Essential
Towards delivering a flexible allocation of compute resources for BB processing of
access nodes, BBUs shall be Soft-developed (vBBUs) and HW-agnostic, with the
Description
capability to be instantiated on-demand, at any location where resources are availa-
ble.
KPIs:
 Delivery of soft-BBUs; to be verified by design, and tested in terms of delivering
KPIs/Parameters
the required BBU functionality.
to be measured
 On-demand instantiation of BBUs at various resource pools (various edge data
centres).
Network Com-
vBBUs, Distributed pools of resources/data centres
ponent(s)/ Level
H2020-ICT-2016-2017-762057 Page 71 of 88 31. Jan. 2018

Table 35: High Capacity, Elastic Optical Network requirement.
S-FUNC-3 High Capacity, Elastic Optical Network
Priority Essential
A high capacity optical network is required to support FH/BH of the high capacity
access network. To this end, existing WDM-PON network solutions need to be ex-
tended towards Hybrid WDM PON/dynamic elastic optical network/ time-sensitive
Description Ethernet packet transport technologies that will improve resource utilisation, and
sharing. The use of ROADM and elastic optical network based on BVT can help in
this direction. To this end, various functional splits (for BH/FH) and radio functions
need to be addressed.
KPIs:
 Support of various functional splits.
KPIs/Parameters  Delivery of hybrid optical network solutions including dynamic elastic optical
to be measured network technology integrated with WDM-PON.
 Improvement of PON utilisation through dynamic allocation of PON resources.
 On-demand instantiation of FH/BH links.
Network Compo-
Converged Optical BH/FH
nent(s)/ Level
Table 36: HW Programmability requirement.
S-FUNC-4 HW Programmability
Priority Essential
Towards delivering a technology interoperable, protocol agnostic, dynamic, on-
demand instantiated access and BH/FH network, the implementation of the access
and BH/FH network physical and virtual functions shall be based on programmable
HW. This shall include:
Description  programmable radio processing platforms,
 programmable optical network components to support different types of func-
tional splits and protocols among the layers, and
 reconfigurable access network nodes, to be configured based on specific de-
ployment scenarios.
KPI: Capability of programming HW on-demand, enabling:
 the support of different access network technologies,
KPIs/Parameters
 the support of different functional splits over an optical link,
to be measured
 the support of different transport network protocols, and
 the support of different data rates over a link.
Network Com-
Access nodes, optical network components
ponent(s)/ Level
Table 37: Programmable Distributed Pools of (Compute/Network) Resources requirement.
S-FUNC-5 Programmable Distributed Pools of (Compute/Network) Resources
Priority Essential
Description Towards achieving the stringent QoS targets as well as efficient resource utilisation,
H2020-ICT-2016-2017-762057 Page 72 of 88 31. Jan. 2018

it is necessary to enable on-demand instantiation of network, compute and storage

resources optimally selected from a common resource pool (that can be physically
distributed). This requires that the deployment is based on distributed (at different
geographical locations, e.g. in the notion of edge computing) pools of resources (i.e.
data centres) consisting of dynamically programmable HW:
 on top of which VNF and SDN capabilities can be deployed per service/tenant,
 on-demand and for a specific time period (after which resources are released
for use by other services)
 taking into account the QoS targets that need to be met,
 which can be managed/ orchestrated by a common management platform,
 which are capable of publishing information about their resources/ capabilities,
planned/ expected utilisation, etc.
KPI:
 On-demand instantiation of network and compute resources for a specific ser-
vice/tenant.
KPIs/Parameters
 Delivery of high QoS network connectivity based on optimal SDN and VNF in-
to be measured
stantiation of resources.
 Monitoring of distributed resources pools from a common platform (see also S-
FUNC-6).
Network Com-
Distributed HW components, data centres
ponent(s)/ Level
Table 38: Management & Orchestration of Distributed Pools of Resources requirement.
S-FUNC-6 Management & Orchestration of Distributed Pools of Resources
Priority Essential
Towards delivering a solution capable to support efficient utilisation of network and
compute resources through dynamic, flexible, on-demand instantiation of them,
while meeting the 5G services stringent QoS requirements, it is necessary to have
a flexible overacting management and orchestration platform, spanning across all
distributed pools of resources. This Management and Orchestration platform shall
be able to:
Description  monitor and manage the physical and virtual resources (i.e. compute and net-
work components) of distributed pools/data centres,
 control the SDN components,
 perform the orchestration of VNFs, and
 support and perform the logic towards the optimal instantiation of resources for
each tenant/slice/service.
KPI:
 Monitoring of Network and Compute resources in terms of utilisa-
KPIs/Parameters tion/availability/planned reservations.
to be measured  Management, automated allocation of resources upon request taking into ac-
count optimisation of resource utilisation and required QoS.
 Instantiation of VNFs.
Network Com-
All the complex management and orchestration platform (e.g. 5G-PICTURE OS)
ponent(s)/ Level
H2020-ICT-2016-2017-762057 Page 73 of 88 31. Jan. 2018

Table 39: Synchronisation across Heterogeneous Access and Transport Networks requirement.
S-FUNC-7 Synchronisation across Heterogeneous Access and Transport Networks

Priority Essential
Synchronisation is required across heterogeneous access (based on different
wireless technologies/configurations/etc.) and transport networks (e.g. optical,
wireless packet-based). Therefore, existing synchronisation protocols based on
Description
packet round trip time measurements are inefficient as they are subject to con-
gestion, especially in the wireless BH. Therefore, novel approaches need to be
considered such as PHY layer synchronisation.
KPIs/Parameters to KPI: Synchronisation is performed accurately across a heterogeneous network
be measured deployment.
Network Compo-
Access, BH, FH network levels
nent(s)/ Level
Table 40: Multi-tenancy requirement.
S-FUNC-8 Multi-Tenancy
Priority Essential
The 5G-PICTURE framework needs to support multiple tenants, with various,
Description access network technologies, functional splits, QoS, requirements, etc., over a
single network deployment.
KPIs/Parameters to KPI: Delivery of services with the requested QoS to multiple tenants over a sin-
be measured gle network deployment.
Network Compo-
End-to-End
nent(s)/ Level
Table 41: Slicing requirement.
S-FUNC-9 Slicing
Priority Essential
Towards supporting multi-tenancy over the 5G-PICTURE framework, slicing is re-
Description quired in order to preserve security and isolation between tenants, and to maintain
the QoS guarantees.
KPIs:
KPIs/Parameters  On-demand instantiation/deletion/configuration of an end-to-end network slice
to be measured and delivery of services over it.
 QoS guarantees (e.g. latency, bandwidth, etc.) of a slice shall be met.
Network Com-
End-to-End
ponent(s)/ Level
6.4 Other Requirements

Not all the requirements can be classified as “performance” or “functional” requirements but may relate to the
flexibility, simplicity and how futureproof the proposed solution is. In this context, this section summarises
some important requirements that have not been already discussed. Tables 42 to 45 summarize them.
H2020-ICT-2016-2017-762057 Page 74 of 88 31. Jan. 2018

Table 42: Modularity requirement.
S-OTH-1 Modularity
Priority Essential
The 5G-PICTURE framework will be designed according to the most recent design
principles and architectures. The different functionalities/features/components will
be assembled in one or more logical blocks, thus implementing a modular architec-
Description
ture (in terms of SW and HW) that will help improving solution development and
maintainability. Each block must interoperate with the others by means of one or
more well-documented interfaces, thus enhancing their conceptual separation.
This requirement cannot be quantified but can dictate the design rules and be vali-
KPIs/Parameters dated at the 5G-PICTURE system design and development phases.
to be measured
KPI: Function diagrams are used to indicate design patterns and improve code.
Network Com-
All the components
ponent(s)/ Level
Table 43: Extensibility/Upgradability requirement.
S-OTH-2 Extensibility/Upgradability
Priority Essential
The 5G-PICTURE framework will constitute a future-proof solution by continually
keeping pace with state-of-the-art developments and innovations. Therefore, the
various components/units shall be extensible/upgradable in terms of:
Description  supporting software/hardware enhancements,
 advanced features/functionality, and
 new technologies.
KPIs/Parameters This requirement cannot be quantified but can be validated at the 5G-PICTURE
to be measured system design and development phases.
Network Com-
All the components
ponent(s)/ Level
Table 44: Maintainability requirement.
S-OTH-3 Maintainability
Priority Essential
Maintainability is critical mainly at the commercial deployment stages of 5G-
PICTURE, which means that all 5G-PICTURE components shall be maintainable,
Description so that development and deployment of changes shall be performed with minimal
risk of regression, and no changes to the system would negatively affect currently
working functionalities.
KPIs/Parameters This requirement cannot be quantified, but it can be validated at the 5G-PICTURE
to be measured system design and development phases.
Network Com-
All the components
ponent(s)/ Level
Table 45: Interoperability with Various Network Technologies requirement.
S-OTH-4 Interoperability with Legacy Network Technologies

Priority Essential
Description The 5G-PICTURE framework will be interoperable with various existing (3G/4G/Wi-
Fi) technologies as well as with future 5G ones. Especially 5G-PICTURE will be in-
H2020-ICT-2016-2017-762057 Page 75 of 88 31. Jan. 2018
teroperable with existing access network technologies that are currently country-
wide deployed (in most countries), and will leverage on them.
KPIs/Parameters This requirement is not quantifiable, but it can be validated at the 5G-PICTURE sys-
to be measured tem design and development phases.
Network Com-
All the components
ponent(s)/ Level
H2020-ICT-2016-2017-762057 Page 76 of 88 31. Jan. 2018

7 Conclusions
The 5G-PICTURE project cornerstone is an architectural evolution, from D-RAN and C-RAN to the novel
concept of “Dis-Aggregated RAN” (DA-RAN). DA-RAN defines a paradigm where hardware and software
components are disaggregated across the access, transport and compute/storage domains. Resource dis-
aggregation allows decoupling these components and creating a common “pool of resources” that can be in-
dependently selected and allocated on demand to compose any infrastructure service. The main enablers for
DA-RAN are the network softwarisation, migrating from the conservative closed networking model to an open
reference platform, supported through hardware programmability. In this vision the hardware elements are
configured directly by network functions, in order to provide the required performance. This will enable provi-
sioning of any service by flexibly mixing-and-matching network, compute and storage resources without sac-
rificing performance and efficiency.
The challenging objective of 5G-PICTURE is to develop the required technologies that can support the archi-
tectural vision of the project and demonstrate the notion of DA-RAN both in a conceptual way as well as by
experimental validations. In particular, the project aims to prove the suitability of the proposed solution to sat-
isfy the requirements of the most important verticals (high speed rail, smart city and internet of things, stadi-
um and mega event and industry 4.0). Each of these verticals has specifically challenging requirements that
have been extensively studied in this deliverable, considering the potential of being benefited by the 5G
technologies introduction, and the related technological issues. The identification of these requirements and
the delineation of stakeholders and their role in the 5G network allow to identify the technical requirements to
the underlying network and its performance.
The railway vertical, for example, needs a new communication architecture based on a common radio sys-
tem that simplifies the current complex scenario, expediting the path to the stakeholders interworking and
application suppliers interoperability and enhancing the portfolio of operational and passengers services,
now highly depending on network capabilities.
In addition, stadium/mega event is a very complex vertical as it has most of the characteristics of a telecoms
network (e.g. access - fixed and wireless, core, etc.). Moreover, stadium is also an important vertical from the
requirement definition point of view since it includes many challenging limits (capacity, latency, number of
user devices per cell and peak data rate). In any case, all of the use cases for stadiums/mega event are
highly dependent on the particular stadium (and its features such as capacity, sport type, business focus, lo-
cation, etc.). The descriptions provided in this report made an effort to generalise various specific use cases.
The following step of this work has been the translation of these specific technical requirements in the 5G-
PICTURE network architecture and technologies selection, actually by any 5G network deployment. To this
end, the derived requirements refer to the overall network performance, to network capabilities and function-
alities, as well as to operational (non-functional) aspects. The result of this analysis was that some functional
requirements are to be considered as fundamental. In particular the hardware programmability and the pro-
grammable distribution of network re-sources are indispensable to support different access and transport
technologies and to deliver of high QoS network connectivity. On the other hand, the BBU virtualisation is
really useful for complying the different latency and jitter requirements. Furthermore, it is essential to guaran-
tee multi-tenancy and slicing in order to improve the efficiency of the network and, finally, the interoperation
with various network technologies and the security features are critical to satisfy the requirements of emerg-
ing verticals.
Summarising the concept, all the listed functional requirements, reported in this document as very important
(essential in the preponderance of cases), and in line with the fundamental principles of the DA-RAN archi-
tecture and the technologies proposed by 5G-PICTURE. This document is a preliminary verification that
moving towards disaggregated architectures can provide huge benefits to 5G networks, as well as enable
complex service bunches (synthetically verticals) that otherwise would not be easily feasible. Moreover, this
work also defines the KPIs to be measured to verify the success of the solution envisaged by the project.
This document is a result of the effort of Work Package 2 “5G and Verticals Services, Requirements and Ar-
chitecture”. The results represent the input (vertical industry services, requirements, use cases and KPIs) to
further tasks devoted to identify a set of high level functional requirements that the overall 5G-PICTURE ar-
chitecture should support.
H2020-ICT-2016-2017-762057 Page 77 of 88 31. Jan. 2018

Future work, benefitting from the outcomes reported in this document, will be the definition of a complete ar-
chitecture, able to support the 5G vision in the most efficient, flexible, scalable, sustainable and future proof
manner. This functional architecture will take a layered approach and will include definition of the data plane
(characterised by the integration of a set of heterogeneous and programmable technologies offering a con-
verged FH and BH network interconnecting storage and computing systems, with local controllers), control
plane (able to control a variety of heterogeneous resources in support of the 5G and vertical industry end-to-
end services) and management plane.
H2020-ICT-2016-2017-762057 Page 78 of 88 31. Jan. 2018

8 Appendix A: Details on rail communication systems

European Rail Traffic Management System (ERMTS)
Railway mainline operations are using ERTMS. Its main target is to promote the interoperability of trains
across EU. It aims to greatly enhance safety, increase efficiency of train transports and enhance cross-
border interoperability of rail transport in Europe. This is done by replacing former national signalling equip-
ment and operational procedures with a single new Europe-wide standard for train control and command
systems.
The ERTMS European Deployment Plan (EDP) sets deadlines for the implementation of ERTMS and its aim
is to ensure the progressive deployment of ERTMS along the main European rail routes, known as ERTMS
corridors, designed to transport passengers and freights.
ERTMS is in turn composed by:
 European Train Control System (ETCS): the signalling element of the system which includes the con-
trol of movement authorities, automatic train protection and the interface to interlocking. ETCS is
based on cab signalling and spot and/or continuous track to train data transmission. It ensures that
trains always operate safely in providing safe movement authority directly to the driver through the cab
display and in continuously monitoring the driver’s actions.
 European Train Management Layer (ETML): the operation management level intended to optimize
train movements by the interpretation of timetables and train running data. It involves the improvement
of real-time train management and route planning.
 GSM–R (Global System for Mobiles for Railway): the communication element containing both a voice
communication network between driving vehicles and line controllers and a bearer path for ETCS data.
It is based on the public standard GSM with specific rail features for operation, like Voice Group Call
(VGC) or Emergency Calls. GSM-R implements several applications and requirements specific to the
railway environment.
From a functional perspective, ETCS matches with ATP/ATO subsystems. ETCS is specified at three num-
bered levels. Many times, these levels are referred as “ERTMS levels”, which is formerly incorrect.
ETCS Level 1 has been deployed in many inter-city high-speed rail lines along countries in Europe. Their
main benefits are interoperability (between suppliers and countries) and safety, since the train will automati-
cally brake if exceeding the maximum speed allowed under the movement authority.
ETCS Level 2, which allows continuous communications between the train and the radio block centre, ena-
bling greatly reduced maintenance costs through the removal of lineside signals. Also, it presents the possi-
bility for substantial line capacity increase, by enabling higher operational speeds and offering reduced
headways (defined as the time interval between trains). Level 2 has been deployed with great efforts in some
countries, with certain grade of interoperability between suppliers.
ETSC Level 3 and ETML (functionally, the ATS subsystem) are in a conceptual phase.
GSM for railways (GSM-R) is the only mandatory radio communication system for ERTMS. It is an ETSI
standard that defines the use of GSM as a network for rail transport infrastructure operators. It is the data
communication bearer for ETCS Level 2 and 3. It also implements several applications and requirements
specific to the railway environment.
GSM-R uses a frequency band around 800-900 MHz, specifically for railway use, assigned to UIC (Union In-
ternationale des Chemins de fer or International Union of Railways). GSM-R is typically implemented using
dedicated base station masts close to the railway, with tunnel coverage effected using directional antennas
or leaky waveguide. The distance between the base stations is 7–15 Km.
It also implements several applications and requirements specific to the railway environment, including data
and voice communications at speeds of up to 350 km/h, such as:
 Operation in specific, dedicated frequency bands (800-900 MHz).
 Extensive use of functional addressing for call handling.
H2020-ICT-2016-2017-762057 Page 79 of 88 31. Jan. 2018

 Private Mobile Radio (PMR) features such as Voice Group Call Service, Voice Broadcast Service, Pri-
ority and Pre-emption.
 Location-dependent addressing.
The train always maintains a circuit switched digital modem connection to the train control centre. This mo-
dem operates with higher priority than normal users, through the GSM feature known as enhanced Multi
Level Precedence and Pre-emption service, eMLPP. If the modem connection is lost, the train will automati-
cally stop.
More details on GSM-R will be given in paragraph 4.1.2 related to the non-critical support services.
Since 2000, GSM-R has been introduced all over Europe, as well as in many other parts of the world and its
implementation is still ongoing. It is expected that it will remain available and supported by the industry until
at least 2030. The European Union Agency for Railways (ERA), in its task as System Authority for ERTMS,
leads the essential activities to enable the timely introduction of new radio systems to mitigate the risk of
GSM-R obsolescence, but regardless of other factors, it is clear that one of the known requirements is the
smooth transition from GSM-R to the new system to protect the realised investments. To assure this goal,
ERA has defined the Control, Command and Signalling Technical Specifications for Interoperability (CCS
TSI), introducing the necessary provisions in enabling migration of technologies that can be used by the
trackside and on-board systems from GSM-R to a next generation system.
This means that the co-existence of any additional system with GSM-R is mandatory.
ETCS Level 2 allows to increase the speed of the train higher than 300 km/h. To do this, radio block centre
must update the train position every 100 ms and the train must receive the corresponding movement author-
isation. If movement authorisation is not received during 1 second, there will be an emergency process re-
ducing the speed of the train to a safe value. Note that the BER increases with the increasing train speed,
because of the Doppler shift.
Packet loss has critical impact on ETCS Level 2 system performance as it essentially means train control
cannot be sent to the train in time. Similarly, packet delay must be smaller than the control message interval
to make sure that the train control information is received in real-time.
Communication Based Train Control (CBTC)

As already mentioned, urban transit operations use another signalling system named CBTC (Communication
Based Train Control), defined in the IEEE 1474 standard. From a functional point of view, it is a complete
ATC system. It’s defined as a continuous data communications link between the train-borne CBTC equip-
ment and CBTC wayside equipment. However, CBTC standard serve as mere guidelines, since it is not
strictly followed by the suppliers. As a result, nearly all existing CBTC installations are incompatible. CBTC
use is not exclusive for urban transit operations but it is used also in other cases.
From the ATP perspective, CBTC is a moving block system: the train position and its braking curve is contin-
uously calculated by the trains, and then communicated via radio to the wayside equipment. Thus, the way-
side equipment can establish protected areas (see Figure 21).
Footprint Footprint
Headway
Figure 21: Moving blocks.
This status includes, among other parameters, the exact position, speed, travel direction and braking dis-
tance. This information allows calculation of the area potentially occupied by the train on the track. It also
enables the wayside equipment to define the points on the line that must never be passed by the other trains
on the same track. These points are communicated to make the trains automatically and continuously adjust
their speed, while maintaining the safety and comfort requirements.
H2020-ICT-2016-2017-762057 Page 80 of 88 31. Jan. 2018

Notice that the maximum capacity of the urban lines is up to 40 trains per hour based on CBTC (90 seconds
minimum interval between trains), or even more. This is one of the reasons for its success: it has become a
reference to maximize the capacity of the lines by reducing the headways (the time interval between trains).
But CBTC is also the leading enabling technology providing semi-automatic unattended train operation and
different levels of ATO defined by IEC 62267 for urban transport. CBTC additionally provides the ATS prima-
ry functions: train identification, tracking, routing and regulation, station stop functions, restricting train opera-
tions and fault reporting.
For radio communication, in addition to GSM-R, CBTC mostly uses Wi-Fi or TErrestrial Trunked RAdio
(TETRA), which will be described in the following.
CBTC over Wi-Fi

CBTC mostly employs proprietary solutions based on IEEE 802.11 Wireless LAN (popularly known as Wi-Fi)
for radio communications (see Figure 22), mainly due to its cost-effectiveness.
The typical size of a CBTC control message is 400-500 bytes. IEEE 1474 specifies a nominal delay from 500
ms to 2 s, but a message transmission shorter than 100 ms is normally supported. Given that the typical fre-
quency of these messages is about 100-600 ms, data rates requirement for a CBTC system is in the range
between 20 and 40 Kbit/s, and not more than 100 Kbit/s. However, a complete set of all ATC functions will
increase this throughput to 4 Mbit/s (symmetric).
Figure 22: CBTC over Wi-Fi.
Packet loss has critical impact on CBTC system performance, as it essentially means that train control can-
not be sent to the train in time. Similarly, packet delay must be smaller than the CBTC message interval to
make sure that the train control information is received in real-time.
A typical value for the timeout interval before emergency brakes are applied is between 5 and 10 s, but even
this value varies in every deployment, depending on multiple factors, including the frequency of CBTC con-
trol messages.
In contrast with usual cellular communications, roaming in a railway environment is inevitable, due to the
train movement. CBTC over Wi-Fi needs Access Points (APs) closely together, because Wi-Fi is a short
range network. This means APs are placed at regular intervals on the trackside network, so that their cover-
age areas overlap, and a train must continuously find a new suitable AP and reconnect as it moves along. A
H2020-ICT-2016-2017-762057 Page 81 of 88 31. Jan. 2018

critical aspect of roaming in CBTC is thus how a radio communications system smoothly switches from one
AP to another (that is the handover), without causing interruptions and delays in the communication. A large
handover latency might result in a delayed reception of the movement authority information, and the train
might have to apply emergency brakes and then drive it in manual mode.
The number of CBTC lost packets due to handover is much larger that due to radio propagation. Then,
packet loss rate is closely related to the handover time, the AP coverage range and the overlapping cover-
age between APs. Handover time in CBTC over Wi-Fi is typically in the range of 70-120 ms, with 1 second
as an upper limit. If this time is shorter than the CBTC control message interval, it does not impose a serious
threat, as it only means one lost message in the worst case. Packet loss rate must be minimised without ex-
ceeding certain latency limits. As with other real-time applications, CBTC control messages are sent at short
intervals, then UDP is preferred to TCP as transport layer protocol. The overhead caused by TCP’s hand-
shake and error checking and correction functions can thus be avoided. Number of retransmissions parame-
ters at the radio level, as IEEE 802.11 retry limit parameter, will be carefully adjusted. As in GSM-R case,
methods directed to solve these issues, like soft handovers or similar techniques are required.
CBTC over TETRA (TErrestrial Trunked RAdio)

It is possible to use other radio communications systems in conjunction with CBTC. Another common de-
ployment is based on TETRA (TErrestrial Trunked Radio).
TETRA is an ETSI standard trunk radio system, two-way transceiver specification, specifically designed for
public safety networks, with the additional features required by the railway sector related in the GSM-R. Its
air interface is encrypted, providing confidentiality. It also supports terminal registration and authentication.
Compared with GSM-R, it allows very high levels of geographic coverage with a smaller number of transmit-
ters, resulting more cost-effective. TETRA requires continuous control channel availability on every base sta-
tion to allow roaming and handover, as well as continuous ability to setup emergency calls and to transmit
and receive data and status messages. Just switching off the transmitter to save energy is thus not relevant
for both TETRA operation.
Power Saving techniques to switch off unused carriers in TETRA are already commonplace and have been
available since the first deployed TETRA networks.
Operational modes for long distance and urban trains and for different train control systems
In any deployment (mainline or urban), three operational modes are possible:
 Normal: train services are operated according to time table.
 Degraded: operation resulting from an unplanned event that prevents the normal delivery of train ser-
vices according to the time table. Some examples of this events is a single train failure, passenger in-
cident or speed restriction.
 Emergency: a dangerous situation that requires immediate attention. Resolving the incident is part of
this mode.
As more ATC components are implemented, a greater performance in the global service is obtained. This is
true in all the operational modes. A local incident has greater difficulties to expand to the rest of the railway
service because ATC reduces the time elapsed in operational degrade mode, alleviates the consequences
of such incident and minimizes its impact on the rest of the system.
A failure on the ATP systems implies different reactions, depending on the automatisation level of the sys-
tem:
 In traditional train control (or even in ETCS level 1), the railway is split into control blocks with signals
in each one. Blocks are sized to allow the heaviest or fastest trains to stop fully within them. In this
way, if a train is stopped in the next block, the following train will always have time to fully stop before
reaching it.
 In upper levels of ATP (CBTC and ETCS level 3) failure enforces train speed reduction and manual
driving (with the grades of automation - GoA level 4 exception in CBTC case). Careful tuning of block
spacing is needed: if they are signals that are placed too close from each other, train speeds must be
reduced so they can still stop in time, but spacing them out further means the trains are also spread
H2020-ICT-2016-2017-762057 Page 82 of 88 31. Jan. 2018

out and the route capacity drops. In the worst case, this could trigger a chain-reaction with the follow-
ing trains, all stopping.
There are multiple causes for an ATP failure, but notice that loss of communication between the different
ATC elements (in train-borne, wayside or even on OCC, depending on the ATC system) produces that oper-
ations enter in degrade mode.
TCN: Train Communication Network

Modern trains use multiple-unit train controls methods (often abbreviated as MU) to control all the traction
equipment from a single location, comprising several self-powered vehicles or a set of locomotives. Today's
modern MU control utilizes pneumatic elements for brake control and electric elements for throttle setting,
dynamic braking and fault lights. This allows them to be driven from both end sides of the train, whether hav-
ing a locomotive at each end side or not (what is named as a push-pull train). In US, a set of vehicles under
multiple unit control is referred as a consist.
Vehicles often utilize a specialised coupler that provides both mechanical, electrical and pneumatic connec-
tions between them. These multi-function couplers permit trains to be connected and disconnected automat-
ically, without the need for human intervention on the ground. Most of the trains fitted with these types of
couplers are multiple units, especially in our two main user cases described along this document (mass
transit operations and long distance high-speed passenger trains).
To properly perform all these functions, many different train elements must be interconnected through digital
buses or Ethernet switches. This type of systems usually follows the ANSI IEC 61375 family of standards,
relative to Train Communication Networks (TCN’s). The TCN has a hierarchical structure with two network
levels of, a train backbone (for interconnecting vehicles in trains) and a consist network (for connecting
standard on-board equipment inside a vehicle). IEC 61375 establishes the rules for interconnecting consist
networks with train backbones, defining the principles on how train topology changes can be discovered, and
a communication profile between consist networks. IEC 61375 also defines the communication between any
device connected to a consist network, detailing addressing schemes, communication protocols and an ap-
plication layer defined by a device profile.
Since some years ago, devices in a consist network uses CAN (Controller Area Network), a communication
protocol and device profile specification for embedded systems frequently used in automation. The CANopen
standard comprises an addressing scheme, several small communication protocols and an application layer
defined by a device profile. IEC 61375 defines CCN’s, CANopen Consist Networks, within TCN architecture.
But ultimately, Ethernet technologies (the chosen low-cost industrial technology) will eventually replace the
majority of CANopen applications. In fact, IEC 61375 also defines ECN’s (Ethernet Consist Network) as well
as Ethernet Train Backbone (ETB) requirements.
Within a segment, the ECN interconnects end devices (EDs) with Consist Switches (CSs). As one train may
contain multiple ECN’s, these segments are interconnected via ETB Nodes (ETBN’s).
TCN sometimes is referred as part of TMCS (Train Monitor & Control System). TCMS comprises all comput-
er devices and software, human-machine interfaces, digital and analogue input/output (I/O) capabilities and
the TCN itself. Today, TCMS is physically separated from Wi-Fi networks available to passengers for securi-
ty reasons, but eventually will be part of the same TCN, surely provisioned in different WLANs. Even more,
there are some ongoing projects to build the complete TCN via radio.
Additionally, a local sensor bus (in this document, equivalent to the “rely on sensor network” parameter) can
be used to connect sensors and actuators to CSs instead of point-to-point EDs.
H2020-ICT-2016-2017-762057 Page 83 of 88 31. Jan. 2018

9 References
[1] 5G-XHaul Project, http://www.5g-xhaul-project.eu/
[2] 5G-XHaul, “Requirements Specification and KPIs Document”, Deliverable D2.1, 2016, http://www.5g-
xhaul-project.eu/download/5G-XHaul_D2_1.pdf
[3] Specification # 22.261 - 3GPP, http://www.3gpp.org/DynaReport/22261.htm
[4] Kurose, J.F. & Ross, K.W. (2010). Computer Networking: A Top-Down Approach. New York: Addison-
Wesley. p. 36.
[5] Digital Communications, John Proakis, Massoud Salehi, McGraw-Hill Education, Nov 6, 2007.
[6] Signal Degradation – Jitter, https://optiwave.com/resources/applications-resources/optical-system-signal-
degradation-jitter/
[7] Igor Levin Terms and concepts involved with digital clocking related to Jitter issues in professional quali-
ty digital audio, http://www.antelopeaudio.com/en/digital_clocking.html
[8] ITU-T G.827, Availability performance parameters and objectives for end-to-end international constant
bit-rate digital paths, https://www.itu.int/rec/T-REC-G.827-200309-I/en
[9] 5G-PPP Program, European Commission, “5G empowering vertical industries”, white paper, 2016/ URL:
http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=14322 (visited on 5/12/2017).
[10] 5G-PPP Program, European Commission, Living document on “5G-PPP use cases and performance
evaluation models”.
[11] 5G Americas, “5G Services and Use Cases”, White paper, November 2017. URL:
http://www.5gamericas.org/files/6214/3569/1603/4G_Americas_Mobile_Broadband_Evolution_Toward_5
G-Rel-12_Rel-13_June_2015.pdf, (visited on 5/12/2017).
[12] Recommendation ITU-R M.2083-0 (09/2015) "IMT Vision – Framework and overall objectives of the fu-
ture development of IMT for 2020 and beyond”.
[13] 3GPP TS 22.261 V16.1.0 (2017-09) 3rd Generation Partnership Project; Technical Specification Group
Services and System Aspects; Service requirements for the 5G system; Stage 1 (Release 16).
[14] Energy, transport and environment indicators, 2017 Edition.
[15] ITU, “Smart Sustainable Cities: An Analysis of Definitions”, 2014.
[16] ATIS, “ATIS Smart Cities Roadmap“, [Online]. Available: https://www.atis.org/smart-cities-roadmap/.
[17] R. Deng, Z. Yang, M. Y. Chow and J. Chen, "A Survey on Demand Response in Smart Grids: Mathemat-
ical Models and Approaches," in IEEE Transactions on Industrial Informatics, vol. 11, no. 3, pp. 570-582,
June 2015.
[18] METIS, “Scenarios, requirements and KPIs for 5G mobile and wireless system”, Deliverable D1.1, 2013.
[19] NGMN Alliance, “5G white paper,” Mar. 2015. [Online]. Available: http://www.ngmn.org/5g-white-
paper.html.
[20] P. Schulz, M. Matthe, H. Klessig, et al., “Latency critical IoT applications in 5G: Perspective on the de-
sign of radio interface and network architecture,” IEEE Commun. Mag., vol. 55, no. 2, pp. 70–78, Feb.
2017.
[21] Yu H, Lee H, Jeon H. What is 5G? Emerging 5G Mobile Services and Network Requirements. Sustaina-
bility. 2017; 9(10):1848.
[22] M. Simsek, A. Aijaz, M. Dohler, J. Sachs and G. Fettweis, "5G-Enabled Tactile Internet," in IEEE Journal
on Selected Areas in Communications, vol. 34, no. 3, pp. 460-473, March 2016.
[23] R. Azuma, “A Survey of Augmented Reality,” Presence: Teleoperators and Virtual Environments, vol. 6,
no. 4, 1997.
H2020-ICT-2016-2017-762057 Page 84 of 88 31. Jan. 2018

[24] I. Parvez, A. Rahmati et al. “A Survey on Low Latency Towards 5G: RAN, Core Network and Caching
Solutions”, IEEE Communications Surveys and Tutorials, 2017, (available at: arXiv:1708.02562v1).
[25] A. Syberfeldt, O. Danielsson, M. Holm and L. Wang, “Dynamic operator instructions based on aug-
mented reality and rule-based expert systems,” in Proc. of the 48th CIRP Conference on Manufacturing
Systems Research and Innovation: Key Enabling Technologies for the Factories of the Future, 2016, pp.
346-351, Elsevier.
[26] W. Barfield, Fundamentals of Wearable Computers and Augmented Reality, 2nd ed. Florida: CRC Press,
2015. ISBN 9781482243505.
[27] A. Osseiran, J. Sachs, M. Puleri et al., Manufacturing reengineered: robots, 5G and the Industrial IoT”,
Ericsson Business Review, Issue 4, 2015.
[28] Michał Maternia, Salah Eddine El Ayoubi et al. “5G PPP use cases and performance evaluation models”,
Revision 1 (2016), 5G-PPP document (available at: https://5g-ppp.eu/wp-content/uploads/2014/02/5G-
PPP-use-cases-and-performance-evaluation-modeling_v1.0.pdf).
[29] GSMA Report “Understanding 5G: Perspectives on future technological advancements in mobile”,
GSMA Intelligence, December 2014, (available at:
https://www.gsmaintelligence.com/research/?file=c88a32b3c59a11944a9c4e544fee7770&download)
[30] TIM Technical paper: “Evoluzione della Core Network verso il 5G”, Edited by S.Di Mino, M.Madella,
G.Mazzarella, R.Procopio
[31] Nokia, OZO LIVE Online Documentation, Technical Specifications. URL:
https://docs.ozo.nokia.com/#live_best_practice (visited on 5/12/2017)
[32] Deutsche Telekom, “Future of digital 5G entertainment unveiled in Berlin“, Press Release, 9/3/2016.
URL: https://www.telekom.com/en/media/media-information/consumer-products/future-of-digital-5g-
entertainment-unveiled-in-berlin-435936 (visited on 5/12/2017)
[33] Google book: “5G Mobile and Wireless Communications Tecnology”, Edited by A. Osseiran, J.F.
Monserrat, P. Marsch.
[34] https://www.sciencedaily.com/releases/2017/04/170412091232.htm
[35] Intended as Communication service availability. A. Osseiran, J. Sachs, M. Puleri et al., Manufacturing
reengineered: robots, 5G and the Industrial IoT”, Ericsson Business Review, Issue 4, 2015.
[36] “Easy LTE”, P. Semenzato, TIM handbook.
[37] Ivo Maljevic, “Evolution to 5G: An operator’s perspective”, TELUS team, IEEE 5G Summit, Nov 2015
[38] “VR and AR pushing connectivity limits” – Qualcomm Technologies, Inc., May 2017.
[39] S.Di Mino, M. Madella, G. Mazzarella, Roberto Procopio “EVOLUZIONE DELLA CORE NETWORK
VERSO IL 5G” Notiziario tecnico TIM , Feb 2017
http://www.telecomitalia.com/content/dam/telecomitalia/it/archivio/documenti/Innovazione/MnisitoNotiziar
io/2017/1-2017/capitolo-6/capitolo%2006.pdf.
[40] https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Video/pktvideoaag.html.
[41] Augmented Reality Smart Glasses in the Smart Factory: Product Evaluation Guidelines and Review of
Available Products”, Edited by A.Syberfeldt, O.Danielsson.
[42] Qualcomm “augmented and virtual reality: the first wave of 5G Killer apps”.
H2020-ICT-2016-2017-762057 Page 85 of 88 31. Jan. 2018

10 Acronyms
Acronym Description
AGV Automated Guided Vehicles
AP Access Points
AR Augmented Reality
ATC Automatic Train Control
ATO Automatic Train Operation
ATP Automatic Train Protection
ATS Automatic Train Supervision
BBU Base Band Unit
BER Bit Error Ratio
BH Backhaul
BVT Bandwidth Variable Transponder
CAN Controller Area Network
CAPEX CAPital EXpenditure
CBTC Communication-Based Train Control
CCTV Remote Surveillance Cameras
C-RAN Cloud Radio Access Networks
DA-RAN Dis-Aggregated Radio Access Networks
DL Download
DMR Digital Mobile Radio
DoF Degrees of Freedom
D-RAN Distributed Radio Access Networks
E/E/PE Electrical-Electronic-Programmable Electronic
ECN Ethernet Consist Network
EDP European Deployment Plan
eMBB enhanced Mobile BroadBand
Emlpp Enhanced multilevel precedence and preemption
ERA European Union Agency for Railways
ERTMS European Rail Traffic Management System
ETB Ethernet Train Backbone
ETCS European Train Control System
ETML European Train Management Layer
EU European Union
FB Facebook
FH Fronthaul
GoA Grades of Automation
GPS Global Positioning System
GSM–R Global System for Mobiles for Railway
H2020-ICT-2016-2017-762057 Page 86 of 88 31. Jan. 2018

HD High Definition
HW Hardware
ICT Information and Communication Technologies
IEC International Electro-technical Commission
IEEE Institute of Electrical and Electronic Engineers
IoT Internet of Things
ISP Internet Service Provider
ITU International telecommunication Union
ITU-R International Telecommunication Union Radiocommunication Sector
KPI Key Performance Indicator
LED Light Emitting Diode
LTE Long Term Evolution
LTE-A Long Term Evolution Advanced
M2M Machine to Machine
MAC Media Access Control
MIMO Multiple-input and multiple-output
MME Mobility Management Entity
mMTC massive Machine Type Communications
MNO Mobile Network Operator
MPI Multi PHY Interfaces
MU Multiple-Unit
MVNO Mobile Virtual Network Operator
NB-IoT Narrow Band Internet of Things
NFV Network Function Virtualisation
OCC Operational Control Center
OPEX OPerational EXpenditure
OPP Open Packet Processor
OSS Operating and Support System
PHY Physical
PLC Programmable Logic Controllers
PMR Private Mobile Radio
PNF Physical Network Functions
PON Passive Optical Networks
PPP Public Private Partnership
PTP Precision Time Protocol
QoS Quality of Service
RAT Radio Access Technologies
ROADM Reconfigurable Optical Add and Drop Multiplexer
RRH Remote Radio Head
RTT Reduced round-trip time
H2020-ICT-2016-2017-762057 Page 87 of 88 31. Jan. 2018

SCADA Supervisory Control and Data Acquisition

SDN Software Defined Networks
SIL Security Integrity Level
SLA Service Level Agreements
SOA Services Oriented Architecture
SSID Service Set IDentifier
SW Software
TCN Train Communication Networks
TCO Total Cost of Operation
TCP Transmission Control Protocol
TETRA TErrestrial Trunked RAdio
TMCS Train Monitor & Control System
TSON Time Shared Optical Network
TTI transmission time interval
UAV Unmanned Aerial Vehicles
UDP User Datagram Protocol
UHD Ultra High Definition
UIC Union Internationale des Chemins de fer
uMBB Ultra Mobile BroadBand
UP Upload
URLLC Ultra-Reliable and Low Latency Communications
vBBU Virtual BroadBand Unit
VBS Voice broadcast service
VGC Voice Group Call
VGCS Voice Group Call Service
VLAN Virtual Local Area Network
VNF Virtual network function
WDM-PON Wavelength Division Multiplexing passive Optical Networks
Wi-Fi WIreless FIdelity
WLAN Wireless Local Area Network
H2020-ICT-2016-2017-762057 Page 88 of 88 31. Jan. 2018

2018 - 5G and Vertical Services, Use Cases and Requirements

Uploaded by

Copyright:

Available Formats

2018 - 5G and Vertical Services, Use Cases and Requirements

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2018 - 5G and Vertical Services, Use Cases and Requirements

Uploaded by

Copyright:

Available Formats

5G Programmable Infrastructure Converging

disaggregated network and compUte Resources

D2.1 5G and Vertical Services,

5G PPP Research and Validation of critical technologies and systems

Project Start Date: 1st June 2017 Duration: 30 months

Project co-funded by the European Commission

5G Programmable Infrastructure Converging dis-

Project Acronym: 5G-PICTURE

Document Number: D2.1

5G and Vertical Services, use cases and require-

Delivery Date: 31st January 2018

Responsible: Telecom Italia (TIM)

Andrea DI GIGLIO (TIM), Annachiara PAGANO

Authors: Azahar Machwe (ZEETTA), Crispin Dent-Young

Keywords: Requirements, 5G, use cases, verticals.

Dissemination Level Public

Project URL: http://www.5g-picture-project.eu/

Rev. N Description Author Date

Definition of table of contents and

1.13 Version to be reviewed Andrea Di Giglio 16th January 2018

Version to be sent to the Project

2.0 Final version to be deliver to EC Project Coordinator 31st January 2018

H2020-ICT-2016-2017-762057 Page 3 of 88 31. Jan. 2018

LIST OF FIGURES ......................................................................................................................................... 7

LIST OF TABLES ........................................................................................................................................... 8

1 EXECUTIVE SUMMARY .................................................................................................................... 10

3 5G-PICTURE OVERVIEW ................................................................................................................. 12

3.1 5G-PICTURE vision ..........................................................................................................................................12

3.2 Terminology/Definitions ................................................................................................................................14

4 VERTICALS IN 5G ECOSYSTEM AND IN 5G-PICTURE ............................................................. 16

4.1 Rail .................................................................................................................................................................19

4.2 Smart city and IoT ..........................................................................................................................................36

H2020-ICT-2016-2017-762057 Page 4 of 88 31. Jan. 2018

4.2.4.3 5G-PICTURE Innovations ........................................................................................................................... 42

4.3 Stadium and mega events ..............................................................................................................................43

4.4 Industry 4.0 ....................................................................................................................................................58

5 VERTICALS, STAKEHOLDERS AND ROLES ................................................................................ 67

H2020-ICT-2016-2017-762057 Page 5 of 88 31. Jan. 2018

6 NETWORK REQUIREMENTS .......................................................................................................... 69

6.1 Requirements’ Description Conventions ........................................................................................................69

6.2 Performance Requirements ...........................................................................................................................69

6.3 Functional Requirements ...............................................................................................................................71

6.4 Other Requirements.......................................................................................................................................74

8 APPENDIX A: DETAILS ON RAIL COMMUNICATION SYSTEMS ........................................... 79

H2020-ICT-2016-2017-762057 Page 6 of 88 31. Jan. 2018

H2020-ICT-2016-2017-762057 Page 7 of 88 31. Jan. 2018

Table 36: HW Programmability requirement. .................................................................................................. 72

H2020-ICT-2016-2017-762057 Page 9 of 88 31. Jan. 2018

H2020-ICT-2016-2017-762057 Page 10 of 88 31. Jan. 2018

Organisation of the document

H2020-ICT-2016-2017-762057 Page 11 of 88 31. Jan. 2018

VIM VIM VIM VIM

MPI BVT/ BVT/ MPI

VIM VIM VIM VIM VIM VIM VIM

RRH mmWave PON

Figure 1: 5G-PICTURE concept leveraging on 5G-XHaul solution.

H2020-ICT-2016-2017-762057 Page 13 of 88 31. Jan. 2018

Table 1: Definition of requirements considered for the use cases/applications analysis.

security level of importance for attack prevention qualitative –