5G Network Slicing for Vehicle-to-Everything Services

Abstract

The multitude of key vertical markets targeted by 5G networks calls for the support of multiple network slices on a common and programmable infrastructure. A network slice is intended as a collection of logical network functions and parameter configurations tailored to support the requirements of a particular service. In this article, we present our vision on the design of 5G network slice(s) customized for vehicle-to-everything services, which involve vehicles exchanging data with each other, with the infrastructure and any communicating entity for improved transport fluidity, safety, and comfort on the road. The suggested slicing solutions involve the partition(s) of the core network and the radio access network resources, as well as configuration of the vehicular end-device functionality, to support different vehicle-to-everything use cases. This research article aims to elaborate on the technological options and enablers, concerns, and challenges for the succesful deployment of 5G slice(s) for multitenant vehicle-to-everything services.

Full text

1
5G Network Slicing for Vehicle-to-Everything Services
Claudia Campolo1, Antonella Molinaro1, Antonio Iera1, Francesco Menichella2
1 University Mediterranea of Reggio Calabria, Italy, E-mail: name.surname@unirc.it
2 NTT Data Italy, E-mail: francesco.menichella@nttdata.com
Abstract
The multitude of key vertical markets targeted by 5G networks calls for the support of multiple
network slices on a common and programmable infrastructure. A network slice is intended as a
collection of logical network functions and parameter configurations tailored to support the
requirements of a particular service. In this article, we present our vision on the design of 5G
network slice(s) customized for Vehicle-to-Everything (V2X) services, which involve vehicles
exchanging data with each other, with the infrastructure and any communicating entity, for
improved transport fluidity, safety and comfort on the road. The suggested slicing solutions involve
the partition(s) of the core network and the radio access network resources, as well as configuration
of the vehicular end-device functionality, to support different V2X use cases. This research article
aims to elaborate on the technological options and enablers, concerns, and challenges for the
succesful deployment of 5G slice(s) for the multi-tenant V2X services.
Keywords:
Vehicle-to-everything (V2X), 5G, network slicing, autonomous driving, cooperative driving, eV2X,
3GPP
1. Introduction
Fifth generation (5G) systems are conceived as highly flexible and programmable end-to-end
communication, networking, and computing infrastructures that provide increased performance in
terms of throughput, latency, reliability, capacity, and mobility while meeting diversified
requirements from multiple services. The International Telecommunication Union (ITU) has
categorized these services in major use cases [1]: enhanced mobile broadband (eMBB) including
e.g., ultra-high definition (UHD) TV, massive machine-type communications (mMTC) for e.g.,
metering, logistics, smart agriculture, and ultra-reliable and low latency communications (URLLC)
for e.g., autonomous driving, automated factory. Also the Third Generation Partnership Project
(3GPP) [2] and other organizations such as the Next Generation Mobile Network Alliance [3], the
5G-Public-Private Partnership Association [4], have included the mentioned categories in their own
definition of use cases. All of them have agreed on the convergence of mobile broadband and
vertical sectors onto a common physical infrastructure, accessible by means of network slices. A
network slice [3] is referred to as a collection of core network (CN) and radio access network
(RAN) functions, whose settings are configured to meet the diverse requirements of given use cases
in terms of functionalities (such as security, mobility support) and delivery performance (e.g.,
latency, reliability, throughput).
An operator is allowed to compose and operate different network slices in parallel, e.g., to host
multiple enterprises, while guaranteeing slice isolation, so that data communication in one slice
does not negatively affect services in other slices [2].
© 2017 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media,
including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to
servers or lists, or reuse of any copyrighted component of this work in other works. Paper Published in IEEE Wireless Communications, Volume: 24
Issue: 6, DOI: 10.1109/MWC.2017.1600408

2
The automotive vertical market is an undoubted key driver for 5G systems. Vehicle-to-Everything
(V2X) communication and its enhancement (eV2X) have been included by 3GPP in Long Term
Evolution (LTE)-Release 14 [5], [6] and among the 5G use cases [2], [7], respectively. The interest
of mobile network operators (MNOs) in the automotive business case is also witnessed by the
recent formation of the 5G Automotive Association gathering major automobile manufacturers and
ICT players with the aim to promote interoperable solutions for cellular V2X, based on 5G and on
the enhancement of LTE.
The V2X umbrella term actually covers a multiplicity of use cases, characterized by single or multi-
tenancy and by diverging service requirements, spanning e.g., from a self-automated car moving in
a smart city, to a HD video streaming played on the in-vehicle infotainment system, to enhanced
real-time navigation systems on board. The potential benefits and the related business opportunities
for automotive and ICT players are still to be adequately disclosed, while network slicing for the 5G
era is rapidly shaping up. Such facts motivate this article, aimed at presenting our vision of 5G
network slicing as a key technological enabler of the future automotive market. After a brief
presentation of the 3GPP specified V2X services and related Key Performance Indicators (KPIs),
followed by an overview of network slicing, we debate on how to adapt this concept in view of
supporting V2X services. This is done by discussing technological and architectural options,
concerns, open issues and by pinpointing future research directions. Guidelines are provided on
slicing solutions concerning the RAN, the CN, and the vehicular end-device, with hints also on
management, security and business issues. Most of the mentioned issues have been and are
currently under investigation as stand-alone enhanced mechanisms and solutions for V2X services.
However, to the best of our knowlege, this is the first time that they are analyzed as crucial
components of the end-to-end 5G slicing for V2X services.
2. V2X services in 3GPP
So far, IEEE 802.11 OCB (Outside the Context of a BSS) mode (earlier amendment p, now
superseded and part of the IEEE 802.11-2012 standard) has been considered the de facto standard
access technology for vehicular networking [4]. Nonetheless the field-trials running worldwide, it
could take a decade or longer until a critical number of vehicles will be equipped with 802.11 OCB
on board devices. Meanwhile, 3GPP is defining the full set of V2X technical enablers in Releases
14 and 15.
2.1 V2X communication modes
3GPP identifies four types of V2X communication modes (Figure 1, bottom): vehicle-to-vehicle
(V2V), vehicle-to-pedestrian (V2P), vehicle-to-infrastructure (V2I), and vehicle-to-network (V2N)
[6].
V2V and V2P modes, respectively, cover direct communication between vehicular User Equipment
(UEs) and between vehicles and vulnerable road users (VRUs), such as pedestrians, bikers,
motorcyclists, wheelchair users. Direct links over the sidelink PC5 reference interface in Release 14
are based on the customization for the vehicular scenario of Proximity Services (ProSe), originally
specified in Release 12. Sidelink radio resources can be allocated in (i) scheduled mode (typical for
in coverage UE operations), under control of the cellular infrastructure, i.e., the eNodeB and (ii)

3
autonomous mode, with the UE autonomously selecting the sidelink resources from a
(pre)configured pool
1
(may be required for out-of-coverage UE operations).
V2I refers to communications between vehicles and the roadside infrastructure, e.g., a road-side
unit (RSU) implemented either in an eNodeB or as a stand-alone stationary UE. A vehicular UE and
the RSU exchange data over the LTE-Uu interface. The RSU can transmit towards multiple UEs in
a given area through the evolved Multimedia Broadcast Multicast Service (eMBMS).
V2N puts vehicular UEs into communication with a server supporting V2N applications, referred to
as V2X Application Server (AS), which provides a centralized control and the distribution of traffic,
road, and service information.
2.2 V2X use cases and related KPIs
The wide set of vehicular use cases (referred to as V2X in [6] and as eV2X in [7]
2
) is categorized as
follows for the discussion in this paper:
Safety and traffic efficiency. V2V/V2P event-driven and periodic messages carry the position and
kinematics parameters of the transmitting vehicle to allow other vehicles and VRUs to sense the
surrounding environment and support applications [6] such as: (i) forward collision warning that
notifies a driver of an impending rear-end collision with a vehicle ahead; (ii) cooperative adaptive
cruise control that allows a group of vehicles in proximity to share the same path (a.k.a.
platooning); (iii) VRU safety to alert a vehicle of the presence of a VRU.
Autonomous driving. Requirements in autonomous driving are stricter than those in V2V safety
applications; self-driving vehicles may drive very close to each other and at higher speeds (up to
200 km/h). Moreover, an autonomous vehicle requires full road network coverage to be driverless
in all geographies, with the network supporting (mainly V2V) communications under high vehicle
density. In some scenarios, video/data exchange over V2N links may further enhance the
autonomous driving efficiency and safety [2].
Tele-operated driving. In environments that are either dangerous or uncomfortable to human
beings, such as the area of a nuclear accident, an earthquake, road construction, snow plowing,
drones on wheels may be leveraged with driving tasks taken over by a human driver physically
located outside of the vehicle, which controls it by using camera, status, and sensor data. Such a use
case, as representative of extreme real-time communications, a.k.a. “tactile internet”, exhibits tight
requirements for the network to ensure fast vehicle control and feedback [2].
Vehicular Internet and infotainment. Web browsing, social media access, files/apps download,
and HD video streaming for passengers are considered a “must-have” for new cars and would
become even more relevant with an increased penetration of self-driving vehicles [2], in which also
the driver may be engaged in media consumption.
Remote diagnostics and management. A V2X AS owned by a car manufacturer or a vehicle
diagnostic center can retrieve information periodically sent by vehicles in V2N mode to track their
status for remote diagnostic purposes [6]. Similarly, fleet management applications may track the
vehicle status and position for forensic diagnostic activity and to avoid insurance fraud.
The identified categories, with relevant KPIs, are summarized in Table 1.
1
Information regarding the out-of-coverage operation may be (pre)configured by the Home Public Land Mobile
Network to ensure interoperability in case of multiple MNOs.
2
Hereafer, for the sake of simplicity, we will refer to the term V2X for both set of use cases.

4
3. 5G Network Slicing
3.1 An overview
The main drawback of today’s networks is that multiple services are supported over the same
architecture, typically conceived with no elasticity in mind, and are processed by the same network
elements in the CN and by sharing the same resources in the RAN.
Network slicing logically isolates network functions (NFs) and resources that are specifically
tailored to a vertical market’s need on a single common network infrastructure. A slice potentially
spans all 5G network domains across CN and RAN segments [3], [8].
Slicing the CN segment affects control plane (CP) functionalities, such as mobility management,
session management, and authentication (as hosted in the MME, HSS), and user plane (UP)
functionalities (such as those in the S-/P-GWs), that become programmable and auto-configurable
[9].
Slicing the RAN is a less mature and challenging practice (mainly due to the shared nature of
wireless resources) and it encompasses various Radio Access Technology (RAT) parameter
configurations, e.g., time/frequency resources, frame size, hybrid automatic repeat request (HARQ)
options [9].
Although a network slice spanning both the RAN and the CN would complicate the overall slice
design, we are in favour of an end-to-end approach that ensures higher flexibility allowing e.g.,
some of the CN functions to be placed in the RAN (to meet the strict latency and scalability
constraints of some applications), thus blurring the boundaries between the CN and the RAN. An
end-to-end slice can be composed by different slice instances in the RAN and in the CN segments
with a proper binding mechanism among them to support the targeted service [8].
3.2 Technology enablers
The most promising way to implement network slicing is by decoupling CP and UP functionalities
and leveraging open application programming interface (API) principles and the programmability
of network functions, provided by paradigms like Network Function Virtualization (NFV) [10] and
Software Defined Networking (SDN) [11].
Decoupling CP and UP functionalities allows displacing them in convenient locations. UP functions
can be distributed close to the user, to reduce service access latency; CP functions can, instead, be
placed in a central site, which makes management and operation less complex.
In early 3GPP attempts, network slicing was conceived to deploy multiple dedicated core networks
(DÉCOR) running on purpose-built proprietary hardware hosting the related NFs to support
different services. Thanks to NFV, CP and UP NFs are not tied to the underlying hardware: they
can be deployed as virtual NFs (VNFs) and run independently and on different platforms (e.g., low-
cost hardware, general-purpose CPU), hosted either in the remote cloud or in edge cloud facilities,
according to the Mobile Edge Computing (MEC) paradigm [12]. VNFs can be dynamically
instantiated, relocated and horizontally/vertically scaled as virtual machines (VMs)/containers
according to the requirements of the services supported by a given slice, and in response to network
demands and to underlying infrastructure dynamics.
An SDN controller can configure VNF and physical NF (PNF) chains in a given slice and flexibly
interconnect UP/CP functionalities running over distributed hardware-based or virtual SDN-enabled

5
switches, through the set-up of paths that can be automatically reconfigured either to handle traffic
engineering requirements or to react to possible network failures.
Figure 1 illustrates some representative functionalities/entities in the V2X ecosystem deployed as
VNFs, in the remote/edge cloud, and interconnected through SDN in the device, the RAN and the
CN device.
4. 5G slicing for V2X services
In the V2X ecosystem, network slicing can effectively cope with a wide variety of use cases with
divergent demands provided over the 5G infrastructure (typically) by multiple tenants. Besides
traditional Internet and service providers, new players, such as road authorities, municipalities, and
vehicle manufacturers, will enter the scene. The unique, heterogeneous and complex features of
V2X services do not either allow the straightforward mapping into reference slice types supporting
eMBB, URLLC and mMTC services [8] or the mapping into a single V2X slice. Therefore, based on
the main KPIs and functional requirements of the identified V2X use case categories in Section 2,
we propose the following set of slices (as illustrated in Figure 2):
- The slice for Autonomous driving and other safety-critical services (e.g., platooning) relies
on ultra low-latency V2V as the prevalent RAT connection mode and on additional
RAN/CN functions, e.g., for network-controlled resource allocation over the PC5 interface
(in the eNodeB) and mobility, authentication, authorization and subscription management
(i.e., in the MME and HSS). Moreover, low-latency and reliable video/data exchange needs
to be supported with a V2X AS, deployed at the network edge, that helps vehicles in 3D-
map processing of the surrounding area and to build an augmented vision beyond their
visual perception.
- The slice supporting Tele-operated driving should ensure ultra-low latency and highly-
reliable end-to-end connectivity between the controlled vehicle and the remote operator who
is typically hosted outside the CN (with data flows passing through a P-GW). Unlike the
autonomous driving slice, such kind of services will be limited to a few vehicles and
activated under particular circumstances only, hence resulting in a light load over CN
entities, e.g., in the MME.
- The slice for Vehicular Infotainment applications is expected to use multiple RATs for a
higher throughput, and to host contents either in the remote cloud or close to the user (e.g.,
with the server co-located at the eNodeB). According to the users basin, multiple MME
instances may be required.
- The slice for Vehicle remote diagnostics and management has to be configured to support
the exchange of low-frequency small amounts of data between many vehicles and remote
servers outside the CN. To this purpose, UP functionalities should handle multiple
interactions (e.g., through multiple S/P-GW instances) and CP functionalities (e.g., the
MME) should be instantiated accordingly.
Table 2 summarizes the main configuration for the identified V2X slices, whose design is driven by
the following main issues:
- The design of an end-to-end V2X slice should allow the dynamic composition of different
slice instances in the RAN and in the CN segments. An example is given by the slice for
autonomous driving, which may share a set of common CN functions (e.g., those related to
authentication/authorization) with other slices, but entails slice-specific customizations over
the RAN to account for V2V interactions.
- The 3GPP multi-dimensional slice descriptor [8] should be enriched with other parameters
that better identify the slice configurations. Besides the Tenant ID (e.g., the car
manufacturer, the road authority) and Slice Type (e.g., vehicular infotainment, remote

6
diagnostic), the slice description could account also for position/kinematics parameters, so
that e.g., different resource pools may be allocated to vehicles moving in opposite directions
[13].
- Vehicular devices would likely be conceived as multi-slice devices, i.e., devices able to
attach to multiple slices, possibly simultaneously. A driver could start her self-driving car
that relies on the autonomous driving slice for V2V messages exchange, whereas babies in
the back seat request the HD streaming of a cartoon that is offered e.g., as a vehicular
infotainment slice, and remote diagnosis applications are running in background over the
corresponding slice.
- Multi-tenancy is a typical feature of the V2X scenario: different services e.g., V2V-based
safety data exchange and HD cartoon streaming, mapped onto different slices, may be
offered by different providers over the infrastructure owned by different network operators.
This may, for example, complicate slice subscription and attachment operations.
- Different types of UE could request the slice activation: slice customization should also be
related to the UE type; it could be e.g., a smartphone for a VRU, a transceiver unit
embedded into the vehicle, an on-board infotainment platform.
5. Slicing the RAN for V2X
Slicing the RAN functionalities may span from the selection of the RAT and RAN architecture and
the communication mode/primitive to the choice of the radio resource allocation policy and the
configuration of a subset of more fine-grained air-interface parameters.
RAT selection. 5G will be deployed as a mashup of existing and novel 3GPP (4G, 5G New Radio)
and non-3GPP (e.g., 802.11) access technologies. In the V2X context, cellular technologies provide
nearly ubiquitous coverage, whereas 802.11 OCB, mainly conceived for localized V2V
communications over unlicensed spectrum, may be desiderable to offload 3GPP networks. A V2X
slice configuration entails (i) the selection of the RAT (or combination of RATs) able to satisfy its
KPIs and (ii) its modification to adapt to changing network conditions. In particular, the usage of
multiple RATs may be configured to increase the V2I connectivity capacity for the vehicular
infotainment slice or to provide redundant connectivity to the tele-operated driving slice.
RAN architecture. V2X slices could benefit from the on-demand deployment of RAN functions
achieved through the Cloud-RAN (C-RAN) technology, which splits the radio and baseband
processing functionalities, with the latter ones migrated to the cloud and forming a BBU pool. By
leveraging virtualization, C-RAN resources in the pool can be dynamically allocated to eNodeBs
according to the network load. This ensures adaptability to the non-uniform traffic, which
characterizes vehicular scenarios (e.g., during off-peak/rush hours, in urban/rural environments).
Moreover, a centralized processing of the pooled BBU functionalities, compared to a distributed
processing in each eNodeB, reduces the time (and the signalling) for handovers.
Communication mode and primitive selection. The V2X slice configuration requires the mapping
of a traffic flow onto a communication mode (sidelink or cellular) and a primitive (unicast,
multicast or broadcast). For instance, the slice for autonomous driving may rely by default on
sidelink communications for localized interactions, but mobility and time-varying density
conditions could trigger the slice reconfiguration to switch from the PC5 to the LTE-Uu interface.
This would be the case of safety data dissemination spanning large areas under low vehicle density.
Vice versa, the interface could be switched from LTE-Uu to PC5 when vehicles, initially far and in
non-line of sight, approach at intersections within the reciprocal sidelink communication range.
Release 14 specifies broadcast primitives to match V2V/V2P safety services; however we believe
that reliable unicast would also play a crucial role in safety-critical applications, like platooning.
Unicast is used for V2I and V2N uplink communications and for tele-operated driving in both

7
directions. Multicast could be used by RSUs/eNodeBs to reach multiple UEs over a wide area (e.g.,
for accident/congestion warnings dissemination).
Radio resource allocation. Although the scheduler of a RAT (e.g., in an eNodeB) is typically
shared among multiple slices, it plays a key role since it is in charge of allocating resources to
different slices (inter-slice) and to different UEs within a slice (intra-slice). Slicing of radio
resources can occur in the time/frequency domains (e.g., LTE resource blocks). Geo-location based
resource assignment may facilitate intra- and inter-V2X slice isolation [13]. Additionally, slicing
can be enforced by specifying a set of packet forwarding treatments (e.g., priority, throughput), as
captured by the Quality of Service class identifier (QCI) of a bearer.
Besides the QCIs defined in [5] to meet the V2X requirements of latency (50 ms packet delay
budget) and reliability (10-2 packet error rate) over the LTE-Uu interface, further QCIs should be
conceived for V2X slices with stricter requirements (e.g., 1 ms latency for autonomous and tele-
operated driving).
Among the 3GPP scheduling schemes, dynamic scheduling, which adaptively allocates radio
resources based on each UE’s buffer status and channel state information, well matches the
requirements of the vehicular infotainment slice. Whereas, semi-persistent scheduling, which
allocates resources periodically without any additional signaling [14], is particularly indicated for
traffic patterns with a predictable frequency and packet size, like for autonomous driving and
remote diagnostic slices.
Numerology. V2X support will be achieved in 5G through different time/frequency numerology
(e.g., flexible frame structure to match high Doppler effects under high speeds and variable
Transmit Time Interval, TTI, length) [14]. For instance, large TTI (e.g., 1 ms-long) may be used to
deliver throughput-demanding applications mapped onto the vehicular infotainment slice, while
short TTIs (e.g., 0.125 ms-long) can be used to provide fast feedback/retransmission for the tele-
operated driving slice.
6. Slicing the CN for V2X
Network slicing over the CN affects the design and placement of CP/UP functionalities and servers
that support V2X communications.
MME. The MME plays a key role in the CN by managing mobility, session, authentication, and
authorization procedures. The high vehicle speed in all V2X slices may either overload the mobility
management (MM) functionalities of the MME of a legacy CN, with consequent increase in
latency, or inefficiently use them if configured based on the peak rate (i.e., expected at peak hours
on the road). To avoid the two mentioned cases, while ensuring isolation with other (non-V2X)
slices leveraging the same functionalities but less aggressively (e.g., for pedestrian/indoor UEs), the
V2X network slicing design shall enable multiple MME instances to be flexibly deployed as VNFs
and interconnected to meet the needs of the V2X slices (Figure 2). In particular, by decomposing
MME functionalities, MM functions can be co-located with the eNodeB, to ensure low-latency
signaling procedures, as shown in Figure 3 for the autonomous driving slice. Such a decomposition
entails the design of new lightweight interfaces to let the splitted MME functionalities interact with
each other and other network entities through the configuration of paths, e.g., established by an
OpenFlow SDN controller. In Figure 3, the MM is interconnected to the authentication and
authorization (AU) module and to the HSS, to manage subscription/authorization procedures of
devices on board of self-driving cars. AU and HSS can be deployed as VNFs common to other V2X
slices.
eMBMS. The autonomous driving slice may require the on-the-fly activation of multicast flows to
allow the dissemination of road safety information concerning an accident. Nodes supporting

8
eMBMS functionalities, i.e., the BM-SC, the MBMS-GW and the MME, are typically located in the
CN. The backhaul delay between the BM-SC and the eNodeB may be non-negligible. Thanks to
CP-UP decoupling, the user plane of MBMS CN functions (BM-SC, MBMS-GW) can be moved
closer to the eNodeB to ensure safety data to be promptly distributed over a large area, as proposed
in [5] (Figure 4), e.g., by leveraging NFV techniques.
Application Servers. Typically, AS are deployed outside the LTE network, e.g., in cloud facilities
owned/rented by a transportation authority, a municipality, a car repair center, a service provider.
Thanks to the MEC enabling technology, V2X AS instances can run close to the users, e.g., at the
eNodeB premises, to provide services with a short latency. This would be particularly beneficial in
case of a traffic AS collecting sensor and vehicle-generated data, and locally processing them to
track the road congestion status and promptly notify vehicles in an incident area through RSUs. A
V2X AS supporting the operations of autonomous vehicles could be also preferably deployed at the
network edge (Figure 3). The placement of the V2X AS in remote cloud facilities, outside the
operator’s network, is still convenient, instead, for delay-tolerant services, such as remote
diagnostics. Infotainment servers may also benefit from NFV and MEC solutions to move the UP
functions closer to the UE. Due to vehicle mobility, a vehicular infotainment slice configured to
allow caching at the edge can be more effective if coupled with pre-fetching strategies that let the
content follow the vehicular UEs. Contents are moved from edge node to edge node, e.g., eNodeBs,
so to ensure service continuity. To this aim, the slicing functionalities could be enriched with
vehicle mobility prediction models, as part of a large set of network data analytics tools aimed to
optimise V2X resource planning and traffic engineering.
7. Slicing the user device for V2X
Slicing may encompass also the configuration of some settings/functions in the vehicular device.
Vehicular and VRUs’ UEs exhibit different capabilities. Thus, traffic pattern parameters should be
differently configured in the two device types for the same slice supporting safety services, e.g., the
frequency of exchanged messages for the VRU must be lower than in the vehicular UEs.
Besides, though the network is expected to retain the control over the V2V/V2P sidelink
communications at least in the scheduled mode (e.g., for the autonomous driving slice instantiated
in Figure 3, the RRM module in the eNodeB decides the resource pool allocation), some control
functionalities could benefit from being splitted between the RAN/CN and the UE. For instance:
 retransmissions can be locally handled by the vehicular UEs over the PC5 links in the
autonomous driving slice, to match the high-reliability and ultra-low latency requirements
over V2V links (see HARQ PNF in Figure 3);
 adaptation of link parameters (e.g., transmission power, modulation and coding scheme)
may autonomously be performed by the UE;
 when out-of-coverage, the UE should be capable of autonomously selecting the set of slices
configuration, which better matches the services of interest (e.g., it can decide which
sidelink resource pools among the (pre)configured ones to allocate to different V2X
services).
As a last indication, it may be convenient in some situations to extend the UP to the extreme edge of
the network, until the UE, and beyond communication procedures. For instance, a vehicular UE can
locally host a lightweight V2X AS instance (e.g., as a container) to serve other UEs in proximity
(e.g., a pedestrian UE owning a smartphone). A slice should be able to support the operations of a
vehicular UE that could alternatively act as a storage unit, to disseminate locally-relevant
infotainment contents, and as a processing unit, to perform local cloud operations (e.g., data fusion
and processing from multiple sensors for autonomous driving) [14].

9
8. Operational and business open issues for V2X slicing
Slicing management and orchestration require the following main capabilities:
 slice description, which captures the requirements of a given SLA as agreed by vertical
segments, whose assurance is tracked by the OSS/BSS. Such a description needs to be
translated to network elements;
 slice instantiation, which encompasses the identification of: CP/UP architecture, interfaces,
sets of slice-specific and common VNFs/PNFs in the CN and their interconnection (e.g.,
configured by an SDN controller), parameter settings in the RAN/device;
 slice lifecycle management, which entails configuration, adaptation and monitoring to fulfil
isolation constraints and agreed SLAs.
A per-slice manager is in charge of the two latter functionalities. It interacts with the slicing
orchestrator, which, in its turn, communicates with the ETSI NFV MANO platform [10], and
enables the brokering of NFV resources (hosted in the device, at the network edge, and in the
remote cloud) between multiple slices, as illustrated in Figure 3.
When requesting a given service, a V2X device should be either able to select the required slice
(when the slice identifier is pre-stored in the device itself), or receive from the network an
indication about the activated slice, e.g., according to what subscribed and stored in the HSS profile.
As for other (non-V2X) slices, a network entity recognizes the requested slice, confirms the
attachment request, after checking the authentication and subscription data of the UE, and
reconfigures the slice to accommodate the demands of the new attached UE [8].
Due to the high dinamicity of the reference environment, the complex nature of V2X services, and
the expected edge-dominated network infrastructures, such operations will get much more
complicated than in other 5G contexts. For instance, the slicing orchestrator will have to configure
multiple slices per device simultaneously and to adapt a slice configuration at run-time (e.g., by
moving VNFs at the edge network, not only to manage SLA degradation, but also to promptly
follow a vehicular UE, through proper migration prediction mechanisms).
Network slicing in 5G is expected to overturn traditional business models. Operators may agilely
provide a tailored network slice for their customers from different vertical markets as a Service [9].
On the other hand, the business model behind 5G-based V2X for MNO is still under debate [4].
New partnerships will likely emerge between automotive players, focused on meeting the needs of a
specific service without owning network infrastructure, and the MNO offering it. To this aim,
suitable open APIs must be designed to offer network programmability to vertical segments.
User authentication, non-repudiation and data integrity, confidentiality, and user privacy should be
guaranteed in 5G V2X with low overhead and latency [4], [6]. In addition, security threats could
specifically emerge through the network slicing usage in 5G V2X. Security procedures should be
tailored to the needs of the different use cases, which means that network slices with different
security assurance requirements may coexist, while ensuring adequate isolation between them.
Moreover, trust relationships between the slice manager and the provider owning the infrastructure
are required before any negotiation for slice instantiation may take place.
9. Conclusions

10
This article elaborated on the role of network slicing to enable the isolated treatment and guaranteed
performance of V2X services as crucial 5G use cases. Suggestions are provided to contribute to the
design of dedicated V2X slices. Such a choice is meant to better address their unique peculiarities
and not to create a bottleneck in existing reference slices, while specifically supporting vertical
applications. However, we do not disregard the possibility to properly customize slices belonging a
set of basic reference slices, to manage them, e.g., as subtypes or proper composition of different
slice instances. In this case as well, the provided guidelines still apply.
References
[1] ITU-R Recommendation M.2083, "IMT Vision - Framework and overall objectives of the
future development of IMT for 2020 and beyond," 2015.
[2] 3GPP, TR 22.891 v.14.2.0, Technical Specification Group Services and System Aspects;
Feasibility Study on New Services and Markets Technology Enablers, Stage 1 (Release 14),
September 2016.
[3] NGMN Alliance - Next Generation Mobile Networks, White paper, 2015.
[4] White Paper on Automotive Vertical Sector, 5G Automotive Vision, 5GPPP, October 2015.
[5] 3GPP TR 23.785 V1.1.0, Technical Specification Group Services and System Aspects;
Study on Architecture Enhancements for LTE support of V2X services (Release 14), July
2016.
[6] 3GPP TR 22.885 V14.1.0, Technical Specification Group Services and System Aspects;
Study on LTE support of Vehicle to Everything (V2X) services (Release 14), December
2015.
[7] 3GPP TR 22.886 V15.0.0, Technical Specification Group Services and System Aspects;
Study on enhancement of 3GPP Support to 5G V2X Services (Release 15), December 2016.
[8] 3GPP TR 23.799 V0.6.0, 3rd Generation Partnership Project; Technical Specification Group
Services and System Aspects; Study on Architecture for Next Generation System (Release
14), July 2016.
[9] X. Zhou, et al. "Network slicing as a service: enabling enterprises' own software-defined
cellular networks." IEEE Communications Magazine, vol. 54, no. 7, 2016, pp. 146-153.
[10] European Telecommunications Standards Institute (ETSI) GS NFV 001, V1.1.1,
Network Functions Virtualisation (NFV); Use Cases, October 2013.
[11] T. Chen, et al. "Software defined mobile networks: concept, survey, and research
directions." IEEE Communications Magazine, vol. 53, no. 11, 2015, pp. 126-133.
[12] European Telecommunications Standards Institute (ETSI), “Mobile-edge computing
- Introductory Technical White Paper, September 2014.”
[13] 3GPP TS 36.300, v 14.2.0, Technical Specification Group Radio Access Network;
Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial
Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 14), March 2017.
[14] 3GPP TR 36.881 V1.0.0, Technical Specification Group Radio Access Networks;
LTE study on latency reduction technique (Release 14), May 2016.
[15] M. Amadeo, C. Campolo, and A. Molinaro. "Information-centric networking for
connected vehicles: a survey and future perspectives."IEEE Communications Magazine, vol.
54, no. 2, 2016, pp. 98-104.

11
Figure 1. V2X communication modes and 5G slicing concept in the device, the RAN and the
CN for V2X services

12
Table 1. V2X categories and main KPIs
V2X category
Communication type
Latency
Data rate
Reliability
Safety and traffic
efficiency [6]
V2V, V2P
100 ms
Not a concern
Not yet
explicited
Autonomous driving
[2]
V2V, V2N, V2I
1 ms
10 Mbps
(downlink/downlink)
Nearly 100%
Tele-operated driving
[2] (under discussion
in [7] as Teleoperated
Support, TeSo)
V2N
20 ms (end-to-
end)
25 Mbps for video
and sensors data
(uplink)
1 Mbps for
application-related
control and
command
(downlink)
99.999%
Vehicular Internet
and infotainment [2]
V2N
100 ms (for web
browsing)
0.5 Mbps (web
browsing)
Up to 15 Mbps for
UHD video
streaming
Not a concern
Remote diagnostics
and management [6]
V2I, V2N
Not a concern
Not a concern
Not a concern

13
Figure 2. High-level overview of the proposed slices for the identified V2X service categories

14
Table 2. Configuration for the main identified V2X slices
Autonomous
driving
Tele-operated
driving
Vehicular
Infotainment
Vehicular remote
diagnostics and
management
RAT settings
4G/5G NR
4G/5G NR,
802.11 OCB
4G/5G NR, 802.11
OCB
4G/5G NR, 802.11
OCB
Main communication
mode
V2V over PC5
V2N over LTE-
Uu (for 4G/5G)
V2I/V2N over LTE-
Uu (for 4G/5G)
V2I/V2N over
LTE-Uu (for
4G/5G)
Main communication
primitive
Broadcast
Unicast
Unicast
Unicast
QoS treatment
Additional QCIs
to meet strict
packet delay
budget and loss
Additional QCIs
to meet strict
packet delay
budget and loss
QCI 4
QCI 9
HARQ support
Local among UEs
for V2V
communications
Network-assisted
Network-assisted
Network-assisted
Scheduling
mechanism
Semi-persistent
Dynamic
Dynamic
Semi-persistent
TTI length
Short
Short
Large
Short
V2X/infotainment
AS placement
Not required for
V2V interactions
At the remote
driver premises
Edge cloud/remote
cloud
Remote cloud

15
Figure 3. The case of autonomous driving slice: management and orchestration of V2X slices
coupled with ETSI NFV.

16
Figure 4. Moving the user plane (UP) of MBMS CN functions (BM-SC, MBMS-GW) close to
the eNodeB [5]

17
Biographies of the Authors
Claudia Campolo [M] (claudia.campolo@unirc.it) is an Assistant Professor of
Telecommunications at University Mediterranea of Reggio Calabria, Italy. She received a Ms
degree in Telecommunications Engineering (2007) and a Ph.D. degree (2011) at the same
University. She was a visiting Ph.D. student at Politecnico di Torino (2008) and a DAAD fellow at
University of Paderborn, Germany (2015). Her main research interests are in the field of vehicular
networking and future Internet architectures.
Antonella Molinaro [M] (antonella.molinaro@unirc.it) is an Associate Professor of
Telecommunications at the University Mediterranea of Reggio Calabria, Italy. Before, she was an
Assistant Professor with the University of Messina (1998-2001), with the University of Calabria
(2001-2004), and a research fellow at the Polytechnic of Milan (1997-1998). She was with Telesoft,
Rome (1992-1993), and with Siemens, Munich (1994-1995) as a CEC Fellow in the RACE-II
program. Her current research focuses onto vehicular networking and future Internet architectures.
Antonio Iera [SM] (antonio.iera@unirc.it) graduated in computer engineering from the University
of Calabria, Italy, in 1991, and received a master diploma in information technology from
CEFRIEL/Politecnico di Milano, Italy, in 1992 and a Ph.D. degree from the University of Calabria
in 1996. Since 1997 he has been with the University of Reggio Calabria and currently holds the
position of full professor of telecommunications. His research interests include next generation
mobile and wireless systems, RFID systems, and Internet of Things.
Francesco Menichella (francesco.menichella@nttdata.com) graduated in electronic engineering
from the University of Rome “La Sapienza”. After an experience as software developer in 2001 he
joined Siemens Communication Mobile Networks in R&D department. In 2007 as Senior System
Architect for Nokia Siemens he worked for definition of functional architecture of Mobile Radio
Access Network Elements. From 2010 he is in NTT Data Italia as Senior System Architect and
Project Manager, he is currently involved in Core Network Architectures.