See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/314446551

NFV enabling network slicing for 5G

Conference Paper · March 2017

DOI: 10.1109/ICIN.2017.7899415

CITATIONS READS

54 2,311

3 authors, including:

Bruno Chatras Steve Tsang Kwong U

Orange Labs Orange Labs
28 PUBLICATIONS   120 CITATIONS    1 PUBLICATION   54 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Suryvey of Telecom Technologies View project

SS7 - Intelligent Networks View project

All content following this page was uploaded by Bruno Chatras on 07 January 2019.

The user has requested enhancement of the downloaded file.

 NFV Enabling Network Slicing for 5G
Bruno Chatras, Steve Tsang Kwong U, Nicolas Bihannic
Orange Labs Networks
Orange, France

Abstract— Network slicing is one of the most discussed

concepts for designing 5G networks. It is intended to enable II. NETWORK SLICING FOR 5G
operators to slice a single physical network into multiple virtual The concept of network slicing for 5G networks has been
networks optimized according to specific services and business first described in a White Paper on 5G developed by the Next
goals. Network Functions Virtualization (NFV), a technology Generation Mobile Networks (NGMN) alliance [3]. Figure 1
developed by the European Telecommunication Standards
illustrates this concept by showing different network slices
Institute (ETSI), will play a prominent role in implementing this
concept. This paper reviews the options that the NFV technology
addressing different types of usage requiring different levels of
offers to enable network slicing and highlights areas that may functionality, performance and reliability. For each type of
require further studies and standardization work. usage, the radio access technologies (RAT) and the list of
activated core network features in the control plane and the
Keywords—5G, NFV, network slicing user plane, as well as their dimensioning and the location
where they are deployed, can be different.
I. INTRODUCTION
The ability to create multiple logically isolated network
partitions on top of a single physical network was one of the
main drivers of the industry movement towards software
defined networking, well before the term “slicing” appeared in
literature. The excitement around 5G has revived the concept
of network slicing to the point of making it a buzzword.
Network slicing can be regarded as a new sophisticated form of
Virtual Private Network (VPN) technology.
The 5G community is using “network slicing” as a
catchword to refer to creating multiple logical network
instances (i.e. slices) over the same underlying network, each
optimized according to different criteria and possibly owned by
different tenants/organizations. As networks are made of
network functions and each network slice needs to be allocated
dedicated resources in a flexible manner, the Network Figure 1: Examples of 5G network slices
Functions Virtualization (NFV) technology is acknowledged as Figure 1 provides an example with three slices. The first
a promising enabler for transforming 5G network slicing into slice is intended to support the traffic typically generated by
reality [1], [2]. Implementing the concept of network slicing is smartphones. A wide range of Network Functions (NF) is
a 3-step process: design, instantiation and operation. The NFV activated and high-capacity virtual links are instantiated to
technology is primarily involved in the second and third steps. support the variety of broadband services smartphones have
It is expected to bring the needed support to adapt the slice’s access to. The second slice is dedicated to autonomous driving.
resources to the required quality of service and performance Autonomous driving requires very low end-to-end latency and
level, in an automated manner. high reliability to exchange traffic information and warning
This paper is organized as follows. Section 2 introduces the messages with the network and other vehicles. Supporting low
concept of network slicing in 5G networks and its motivations. latency requirements implies that some of the network
Section 3 provides background information on NFV with focus functions have to be deployed closer to the access nodes (as
on the aspects that are necessary to understand how to leverage illustrated for NF3), and achieving high-reliability implies that
this technology to implement the network slicing concept. some of them have to be instantiated multiple times on
Section 4 focuses on the interplay between slice control and different physical servers (as illustrated for NF6). The third
NFV management and orchestration. Section 5 highlights areas slice is intended to support a “Massive IoT” (a.k.a. Internet of
that may require further studies and standardization work. Things) use case, where smart metering devices generate a very
Finally, section 6 briefly discusses the implication of extending small volume of data intermittently and are not expected to
network slicing to the terminal device. move. The set of network functions to be included in this third
slice compared to the two previous cases is rather limited. For
example, there is no need for any of the mobility handling
functions usually deployed in a mobile network. Indeed, the
Massive IoT use case fits a simplified slice without support for on matching service requirements (list of network functions
“always-on” connection, mobility handling and low latency required, expected quality of service and security levels, etc.)
requirements. with the capabilities (i.e. list of network functions supported)
and capacity (e.g. available resources and performance) of
As a follow-up to the publication of the White Paper, existing slices, as well as operator-defined policies. These
NGMN provided more detailed definitions and terminology to mapping decisions may have to be revisited in the course of the
help understand the different aspects of a slice [4]. As depicted life cycle of services and network slices.
in figure 2, extracted from [4], three layers can be identified:
The 3rd Generation Partnership Project (3GPP) has
• The Service Instance layer, which represents the end- described several use cases that can benefit from the network
user services or enterprise services to be supported by slicing concept in a technical report on new services and
a slice. markets technology enablers [6]. In another technical report on
• The Network Slice Instance layer, where all the slice architectural aspects [7], 3GPP introduces the concept of
instances supporting the aforementioned services Network Slice Template (NST), as a logical representation of
reside. the Network Function(s) and corresponding resource
requirements necessary to provide the required
• The Resource layer, which represents all resources telecommunication services and network capabilities. This
(virtual or physical) from the underlying network technical report also provides a number of recommendations on
infrastructure made available to the network slice network slice selection and roaming architecture for network
instance layer. slicing.
Besides 3GPP, 5G NORMA, one of the 5G-PPP projects
under of the Horizon 2020 EU (European Union) research and
innovation program, develops an end-to-end architecture based
on network slicing, leveraging Software Defined Networking
(SDN) and NFV [8].

III. REMINDERS ON NFV

Network Functions Virtualization (NFV) is a paradigm
shift in the Telecom industry, where the functions traditionally
hosted in purpose-built equipment become virtualized and run
on pools of standard Information Technology (IT) servers. The
European Telecommunications Standardization Institute
(ETSI) has defined an NFV architectural framework [9],
illustrated in figure 3, enabling virtualized network functions
(VNF) to be deployed and executed on a Network Functions
Figure 2: Layered representation of network slicing Virtualization Infrastructure (NFVI), which consists of pools of
hardware resources (computing, storage and network
A network slice instance is defined using a blueprint, which resources) wrapped with a software layer that abstracts and
specifies its characteristics in terms of functions needed and logically partitions them. An NFVI should be understood as a
business objectives (quality of service, security, etc.). It may distributed cloud infrastructure, where physical servers are
also include one or more sub-network instances. A sub- distributed across various locations, including both highly-
network instance is defined through its own blueprint and can centralized data centers and smaller server pools deployed in
be reused in several network slices. For instance, a sub-network points of presence (PoP) at the edge of an operator’s network.
slice gathering all IP Multimedia Subsystem (IMS) basic
functions can be used in all network slices supporting services
built on the IMS.
Slices can be created and operated by the 5G network
operator itself or created by the network operator and sold to
3rd parties, following the “as-a-service” paradigm. In other
words, as highlighted in [5], network slicing can be regarded as
a technology that enables both multi-tenancy and service-
tailored composition of networks.
The scope of a network slice can be one customer facing
service or a group of such services. Strategies for allocating a
service to a network slice need of course to be elaborated. This
includes deciding whether to allocate a service to an existing
network slice instance, possibly after expansion of the
underlying resources, or create a new instance of an existing
Figure 3: NFV architectural framework
slice, or to design a new slice. The decision is typically based
 ETSI defines a Network Service (NS) as a composition of VNF components and therefore has a direct influence on the
network functions, where at least one of them is a VNF. To VNF performance and reliability. Selecting a VNF flavor may
avoid any misunderstanding, it should be highlighted that the also enable activating a chosen sub-set of the VNF
term “service” in Network Service should not be confused with functionality, providing the VNF software has been structured
a “service” supported by a network slice. The services so that each VNFC maps to a well-defined functionality.
supported by a network slice are in turn indirectly supported by Selecting a VL flavor enables selecting transport reliability and
the Network Services that, as explained in the next section, quality of service parameters. As we will see in the next
realize this network slice. As illustrated in figure 4, using the section, flavoring is a quite important mechanism in the context
TM Forum terminology, the former is a resource facing service of network slicing as it allows selecting only the needed
(RFS) while the latter is a customer facing service (CFS). features within an NS for a given network slice.

IV. NETWORK SLICING IN THE NFV FRAMEWORK

A. General
There is strong similarity between network slicing applied
to a mobile core network and the way NFV is typically used to
support use cases such as creating on-demand enterprise
customer networks. Indeed, network slices are on-demand
networks. In NFV parlance, a slice would typically be
Figure 4: CFS to RFS mapping
deployed as a Network Service instance. Different slices can
map to instances of the same Network Service (with different
The deployment, execution and operation of VNFs and flavors) or instances of different Network Services. In an NFV
Network Services in an NFVI are steered by a Management & framework, creating a network slice will typically involve
Orchestration (M&O) system, whose behavior is driven by filling a Network Service deployment template (a.k.a. NSD)
deployment templates (a.k.a. NFV descriptors) describing the and requesting the NFV Orchestrator to instantiate a Network
characteristics of the Network Services and their constituent Service according to the contents of this template. Everything
VNFs. The M&O system includes an NFV Orchestrator beyond that point, up to the creation of virtualized resources for
(NFVO) in charge of the lifecycle of Network Services, a set of supporting the slice, should just rely on standard NFV concepts
VNF managers in charge of the lifecycle of the VNFs and procedures. The mapping between the NGMN layers and
(including VNF scaling out/in) and a set of Virtualized the NFV architectural framework can be roughly summarized
Infrastructure Managers (VIM), which can be viewed as as follows, as illustrated in figure 5:
extended Cloud Management Systems responsible for
allocating and releasing NFVI resources upon requests of the • The Resource layer maps to the NFVI and the
VNFM and NFVO. The NFVO is also responsible for selecting VIM(s).
the NFVI PoPs where to deploy a network function, based on • The Network Slice Instance layer maps to the
operator’s policies and location constraints specified at NS collection of Network Services handled by NFV
instantiation time. Management & Orchestration functions.
The process for instantiating a Network Service is initiated • The Service Instance layer plays the role of an OSS
from service providers’ Operations Support Systems (OSS) by functional block with regards to the NFVO.
sending a request to the NFVO, using a Representational State
Transfer (REST) Application Programming Interface (API).
This request typically contains a pointer to a Network Service
Descriptor (NSD), a flavor selector and additional input
parameters (e.g. IP addresses to be assigned to some of the
network functions) and constraints (e.g. location where to
deploy all or some of the network functions). The NSD
provides a list of pointers to the descriptors (i.e. VNFDs) of its
constituent VNFs and additional information on the
connectivity between them together with the traffic forwarding
rules that may have to be installed in the NFVI network
domain.
The NSD includes a number of NS deployment flavor
descriptions, each referencing deployment flavors of all or a
subset of the NS’s constituent VNFs and Virtual Links (VLs).
The flavor mechanism not only enables selecting a subset of Figure 5: Mapping the NGMN layers to the ETSI architectural framework
the VNFs and VLs to be instantiated but also the actual flavor
for each of the selected objects and the number of instances to B. Slice Controller
be created for each selected VNF. Selecting a VNF flavor As illustrated in figure 5 slice control functionality must
enables selecting a level of resources to be allocated to the exist in the Service Instance layer. An example is provided in
[10]. In this paper, we will call “Slice Controller” the The complexity of the Slice2NS mapper depends on the
functional block that within the OSS is responsible for mapping strategy. As already alluded to, a slice would typically
interacting with the NFV M&O system to control slicing. The map to a Network Service instance. Different slices can map to
Slice Controller is a consumer of the REST APIs exposed by instances of the same type of NS with different deployment
the NFVO. Within a Slice Controller, one can identify two flavors or of instances of different types of NSs.
main functions. The first function is responsible for assigning
services to network slices and for managing the lifecycle of The first approach is suitable if the slices share the same
these slices. In the rest of this paper we will call it the “Slice types of VNFs (or a large common subset) but differ in terms
Manager”. The second function is responsible for mapping of the performance expected from the VNFs (and the virtual
network slices to NFV Network Services. In the rest of this links connecting them) and/or the number of instances to be
paper we will call it the “Slice2NS mapper”. deployed for each of them. If slices differ more significantly,
mapping to different Network Services, each with its own NSD
The Slice Manager function decides whether a customer should be more appropriate.
facing service is to be assigned to an existing network slice or
sub-network slice or whether a new network slice or sub- Scenarios where a network slice is mapped to a set of
network slice is to be created. In the former case, the slice concatenated or nested NSs can also be envisioned, in
particular where the NSs have been originally deployed
blueprint is updated while in the second case, a new blueprint
is generated. Blueprints, also known as a Network Service independently from each other.
Template (NST) in 3GPP documentation [7], are then The Slice2NS mapper functionality has to maintain an
converted by the Slice2NS mapper into NSDs and flavors, as association between slice blueprints, and NSDs with applicable
illustrated in figure 6. This might involve automatic generation deployment flavor identifiers, as well as an association between
of an NSD if the slice requirements do not map to an already slice identifiers and NS instance identifiers.
on-boarded NSD (i.e. available in the NSD catalogue). Indeed,
multiple network slice instances delivering exactly the same C. APIs and templates
optimisations and features but dedicated to different enterprise
The end-to-end process from the service deployment
customers would typically rely on the same NSD. On the other
request to the actual slice implementation must be automated.
hand a network slice intended to support totally new customer
This requires a standardization effort beyond what is being
facing services is likely to require a new Network Service and
done within the framework of NFV, in particular a service
thus the generation of a new NSD.
description template and an API need to be specified to enable
Once the NSD has been on-boarded, a slice instantiation off-the-shelf Slice Controllers to be sourced by operators from
request can be triggered, resulting in an NS instantiation different vendors or open-source communities, so as to connect
request with the appropriate flavor identifier being sent to the them to other components of the OSS (e.g. service order
NFVO. The Slice Manager is responsible for the entire management). The service description template should contain
lifecycle management (LCM) of the created network slice sufficient information to enable assigning the service to a slice
instance, until it is terminated. Subsequent lifecycle events (e.g. and generating an NSD, but should leave out technical details.
slice expansion request) are likely to have an impact on the When creating an NSD, it is assumed that the Slice Controller
lifecycle of the underlying Network Services but not will derive such technical details from a combination of
systematically. The management of the network applications information available in the service description templates and
hosted by the network functions (e.g. application-specific policy rules. For example, while an NSD specifies the quality
configuration of one or more network functions) is also under of service parameters applicable to a virtual link, a service
the responsibility of the slice manager but is outside the scope description template should just contain an abstract quality of
of NFV and therefore also outside the scope this paper. service class from which the Slice Controller can derive the
actual quality of service parameters. A service description
template does not even need to distinguish between VNFs and
Physical Network Functions (PNFs), the selection of a VNF or
a PNF to implement a network function can be left to the Slice
Controller. The need for a higher level of abstraction than that
exposed by an NFVO is further illustrated in Figure 7.

Figure 6: From service requirements to network service instantiation

 Furthermore, network slicing might have an impact on the
NFVO implementation, as the average level of complexity of
the tasks it has to perform is likely to increase compared to
conventional NFV deployments. First because, with network
slicing, the number of NS instances to be managed will be
significantly higher than what can be expected today when
applying the NFV transformation to existing Network Services
(e.g. IMS or Evolved Packet Core (EPC)) in a conventional
manner, where the number of instances per service type in a
given country, can be counted on the fingers of one hand. This
is not only due to the per-service nature of the slicing approach
but also to the ability to create per-tenant slices (i.e. same
Network Service instantiated multiple times for different
enterprises, campus, smart cities, etc.). Secondly, because the
scenarios where the NS supporting a network slice is itself a
Figure 7: Slice Manager APIs
composition of nested or concatenated NSs, each provided by
different operators might become more frequent than with
D. Re-using network functions across slices today’s mainstream NFV use cases. In this context, NFVO
Multiple slices are likely to share some common functions hierarchies might need to be deployed, where a top-level
(e.g. mobility management, authentication, etc.). It is therefore NFVO responsible for a parent NS would delegate to lower-
essential that VNF reusability across multiple NSs be level NFVOs the management of nested NSs. A report
supported. Obviously multiple NSs can be built using the same addressing options for revisiting the NFVO architecture has
type of VNF since multiple NSDs can reference the same been published by ETSI [13] and a follow-up work on this
VNFD. 5G network slicing requires more: sharing a VNF topic has been started in 2016. Similarly, within the 5G-PPP
instance across multiple NS instances of the same or different framework, the 5GNORMA [8] and 5GEX [14] projects
types. This can be achieved by including the identifier of the include a study involving multiple levels of orchestration.
VNF instance to be reused in the input parameters of the NS
instantiation request issued by the OSS towards the NFVO. C. VNF granularity
The NFV framework also provides the ability to include in the
The granularity of the functional architecture to which
design of a Network Service another Network Service (nested
network slicing is applied will determine the level of flexibility
NS). This will enable a straightforward implementation of the
service providers will have to design the slices. This is actually
concept of sub-network slice (i.e. a group of re-usable network
calling for standardizing 5G core network functional entities
functions), by including the identifier of the to-be-nested NS
with a smaller functional scope than what was done for the
instance in the API used to request NS instantiation from the
EPC for instance. For example a Packet Data Network (PDN)
NFVO.
gateway in an EPC network contains many elementary
functions bundled together and the network operator can hardly
V. NEW REQUIREMENTS ON NFV STANDARDS activate or deactivate dynamically one of them. Rethink the
granularity of the 5G core network functional architecture is
A. General actually one of the design goals of the 3GPP ongoing work [7].
Most features required to enable network slicing are already Similarly, the approach followed by a VNF provider to
incorporated in the NFV architectural framework and specified arrange the overall VNF software into VNFCs and VNF
in the relevant deliverables published by ETSI over the past flavors has also a direct influence on the level of granularity of
four years. Support of network slicing is unlikely to bring what can be selected by the network operator when designing a
fundamentally new requirements on an NFV system. However, slice. For example, a manufacturer may decide to structure the
this section highlights a number of aspects that deserve special software of an HSS in two components: a front end containing
attention. the HSS processing logic and the actual database. Such a
design is useful for scalability and reliability purposes but does
B. Multi-layer orchestration not help in terms of slicing flexibility, as both pieces have to be
NFV involves multiple levels of orchestration, each of them instantiated in all network slices. As an alternative design,
acting at different levels of abstraction of the virtualized other manufacturer could decide to split its HSS into a front
resources they manage. Network slicing is likely to require end providing the interface to the rest of the network, a set of
even more levels. First of all, the aforementioned Slice authentication modules supporting different authentication
Controller is an orchestration layer in itself. Multi-slice schemes and the actual database. Different VNF deployment
orchestration functionality might even be required from a Slice flavors could then be defined each enabling selecting only one
Controller to automate coordinated deployment and lifecycle of the authentication modules. A core network slice dedicated
management of multiple slices belonging to the same tenant or to a specific radio access technology would then be using the
involved in supporting the same commercial bundled offer. VNF deployment flavor corresponding to the authentication
Indeed, the ITU-T report on standards gap analysis for scheme supported on this radio technology. While the software
IMT2020 systems [12] acknowledges multi-slice orchestration architecture of a VNF is not intended for standardization, a set
as an important issue.
of common industry guidelines would certainly help ensure virtualization is indeed one of the research priorities identified
most VNFs become slice-ready. in the NetWorld2020 White Paper [2].
Some types of devices may need to connect to several slices
D. Multi-site services simultaneously so as to access services supported by different
Network services can involve network functions deployed slices. The 3GPP study on the architecture for Next Generation
at different sites, thereby requiring virtual connectivity to be Systems [7] provides an example of a car needing simultaneous
established across sites, possibly through a Wide Area Network access to information from both a vehicle to infrastructure
(WAN). Network slicing in the context of 5G is likely to make (V2x) network and from infotainment services embedding
this scenario more frequent, due to roaming configurations. high-definition video streaming. Those two types of services
In such cases, the NFVO will typically rely on a WAN have very different requirements with regard to network
Infrastructure Manager (WIM). As this functionality has been resources (i.e. ultra-low latency vs high throughput) and are
underspecified so far, ETSI has started a study within the thus likely to use two different network slices. Two approaches
framework of its 3rd specification release to identify potential for assigning outgoing traffic to a slice can be envisioned to
new requirements that such scenarios could bring on NFV enable such use cases: With the first approach, the device is
management and orchestration functions [15]. seen as several virtual devices, one per slice, thus extending the
concept of slice in the device itself. With the second approach,
the traffic is assigned to a slice by the network.
E. Security and isolation
In the short term, all aspects of a network slice are likely to The first approach requires appropriate configuration so
be under the control of the 5G network operator. In a longer that the activation of an application triggers the activation of
term, some network slices might be made available to 3rd the appropriate virtual device within the physical device. NFV
parties according to the “as-a-service” model or might even be can help automating the creation of virtual devices, providing
dynamically created by a 3rd party as a composition of network that physical devices be considered as part of the NFVI and
features selected from a customer care portal. In the latter case, that their resources be visible to NFV management and
isolation between slices will become even more crucial to the orchestration functions. This would imply a highly distributed
success of the concept. The ability for a slice to share or not NFVI, with millions of micro-NFVI nodes, each of them being
underlying resources with another slice will be a key input to a mobile device equipped with an hypervisor or another form,
the lifecycle management of the underlying NSs. presumably lighter, of virtualization layer. This would in some
way lead to a new form of NFV, close to the concept of fog
Upon creating of a new slice, appropriate measures will computing rather than conventional cloud computing. A
have to be taken to prevent any undesired effects on other hierarchy of VIMs would probably be required to manage such
running slices with regard to security or quality of service. virtualized resources, and the VIM functionality itself would
Examples of such measures include real-time analysis of the have to be extended to cope with host mobility.
slice blue prints and/or generated NSDs, deployment of VNFs
on dedicated and isolated security zones, automated The second approach is linked to ongoing 3GPP
instantiation of security functions within the slice, etc. discussions on network slice selection [7]. It would either
require some form of explicit slice control signaling so that the
This will require advanced security monitoring and device can assist the network in the selection process, or Deep
management features to be tightly coupled with NFV Packet Inspection (DPI) capabilities to enable the network to
management and orchestration. The specification of these identify the type of traffic and therefore the slice to handle it.
features is ongoing work in ETSI as part of the 3rd NFV The slice control signaling function and the DPI functions
specification release. Moreover, NFV already provides two would typically be deployed as VNFs and would have to be
mechanisms preventing excessive resource consumption. shared across all slices.
Quota management enables preventing excessive resource
consumption in the VIM by a given consumer (e.g. a group of
VII. CONCLUSION
slices in the 5G context). The quota is set by the NFVO and
enforced by the VIM. Permitted allowance is a mechanism NFV, as a technology, provides a solid platform to support
maintained at the NFVO level to control resource consumption 5G network slicing. The concepts of NFV Network Services
by VNFMs at various levels of granularity (e.g. per VNFM or and deployment flavors can be leveraged in a quite
per VNF or NS instance). Beyond security and isolation issues, straightforward manner to deploy and manage network slices in
this on-demand model in which a 3rd party customer can be an automated and flexible way. Indeed, although the concept of
strongly active in the design of network features raises the network slicing is promising to enable on-demand offerings,
question of responsibility management when setting Service operations for such specialized networks are likely more
Level Agreements (SLAs) between the operator and 3rd complex and therefore components reusability and full process
parties. automation are then essential to preserve profitability. NFV
management and orchestration functions need to be
complemented with a Slice Controller whose features are
VI. EXTENDING SLICES TOWARDS THE DEVICE
sketched in this paper. Few areas would deserve further
Though, as the name implies, network slicing is primarily attention and standardization work, in particular multi-layer
intended as a network technology, an open question is whether orchestration and security orchestration. The extension of
network slices should extend to end-user devices. Terminal network slicing up to end-user devices raises a number of
challenges as well, in particular if NFV were to be used to [8] A Novel Radio Multiservice adaptive network Architecture for the 5G
support dynamic creation of per-slice virtual devices on one era based on Network slicing, Cinzia Sartori & al.
https://5gnorma.5g-ppp.eu/wp-content/uploads/2016/03/20160317-5G-
physical device. Finally, it should be noted that there are other NORMA-Network-Slicing.pdf
areas beyond network slicing for which NFV can facilitate the [9] ETSI GS NFV 002: Network Functions Virtualisation (NFV);
deployment of advanced capabilities in 5G networks; for Architectural Framework.
example the ability to move a VNF instance from one location http://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.02.01_60/gs_n
to another in a transparent manner is a powerful tool enabling fv002v010201p.pdf
some of the 5G services to follow the movement of their users [10] Future Mobile Core Network for Efficient Service Operation - Takuya
so as to maintain constant performance and latency. Shimojo and al. – 1st IEEE Conference on Network Softwarization
(NetSoft), 2015.
[11] ETSI GS SOL NFV-SOL 005: Network Functions Virtualisation (NFV);
REFERENCES Protocols and Data Models; RESTful protocols specification for the Os-
[1] View on 5G Architecture, 5GPPP Architecture Working Group, Version Ma-nfvo Reference Point.
1.0, July 2016 https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL005_Os-Ma-
https://5g-ppp.eu/wp-content/uploads/2014/02/5G-PPP-5G-Architecture- nfvo_APIs
WP-July-2016.pdf [12] ITU-T FG IMT2020; Report on Standards Gap Analysis.
[2] 5G: Challenges, Research Priorities, and Recommendations, http://www.itu.int/en/ITU-T/focusgroups/imt-2020/Documents/T13-
Networld2020 ETP, September 2014 SG13-151130-TD-PLEN-0208!!MSW-E.docx
http://www.networld2020.eu/wp-content/uploads/2015/01/Joint- [13] ETSI GR NFV-IFA 009: Network Functions Virtualisation (NFV);
Whitepaper-V12-clean-after-consultation.pdf Management & Orchestration; Deployment options.
[3] NGMN 5G white paper. http://www.etsi.org/deliver/etsi_gs/NFV-
http://ngmn.org/5g-white-paper/5g-white-paper.html IFA/001_099/009/01.01.01_60/gs_nfv-ifa009v010101p.pdf
[4] NGMN Description of Network Slicing Concept. [14] Multi-domain Network Virtualization; IRTF NFVRG, October 2016,
http://ngmn.org/uploads/media/160113_Network_Slicing_v1_0.pdf Work in progress.
https://datatracker.ietf.org/doc/draft-bernardos-nfvrg-multidomain/
[5] Mobile Network Architecture Evolution towards 5G,” P. Rost and al. -
IEEE Communications Magazine, vol. 54, no. 6, June 2016. ETSI GR NFV-IFA 022: Network Functions Virtualisation (NFV);
Management and Orchestration; Report on Management and
[6] 3GPP TR 22.891: Feasibility Study on New Services and Markets Connectivity for Multi-Site Services.
Technology Enablers; Stage 1 https://docbox.etsi.org/ISG/NFV/Open/Drafts/IFA022_Multi-
[7] 3GPP TR 23.799: Study on Architecture for Next Generation System. Site_Services

View publication stats