Slicing 5G Networks - An Architectural Survey - in - Wiley 5G Ref Online

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/341437156
Slicing 5G Networks: An Architectural Survey
Chapter · May 2020

DOI: 10.1002/9781119471509.w5gref095
CITATION READS
1 132
5 authors, including:
Alex Galis Stuart Clayman

University College London University College London
236 PUBLICATIONS 3,311 CITATIONS 64 PUBLICATIONS 1,396 CITATIONS
SEE PROFILE SEE PROFILE
Christian Esteve Rothenberg

University of Campinas
147 PUBLICATIONS 5,754 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
PORVIR-5G - programabilidade, orquestração e virtualização de redes em 5G View project
Soft Failure Localization in Optical Networks Using Machine Learning View project
All content following this page was uploaded by Christian Esteve Rothenberg on 19 May 2021.
The user has requested enhancement of the downloaded file.

1
Slicing 5G Networks: An Architectural Survey

Galis Alex 1 , Tusa Francesco 1 , Clayman Stuart 1 , Rothenberg Christian 2 , and Serrat
Joan 3
1 University College London, London, England
2
University of Campinas, Campinas, Brazil
3
Universitat Politècnica de Catalunya, Barcelona, Spain
Introduction
5G networks (H2020 2018) are conceived as extremely flexible and highly programmable
end-to-end connect-and-compute infrastructures that are both application- and
service-aware, as well as being time-, location-, and context-aware. These 5G networks
represent: (i) an evolution, over 4G networks, in terms of capacity, performance, and
spectrum access in radio network segments and (ii) an evolution of native flexibility and
programmability conversion in all radio and non-radio 5G network segments: Radio
Access Network, Fronthaul and Backhaul Networks, Access Networks, Aggregation
Networks, Core Networks, Mobile Edge Networks and Clouds, Software Networks,
Cloud Networks, Satellite Networks and Edge IoT Networks.
5G networks represent a shift in networking paradigms: namely a transition from
today’s “network of entities” toward a “network of functions.” Indeed, this “network
of functions,” and its most likely manifestation, a “network of virtual functions,” will
in some cases result in the decomposition of current monolithic network entities
into network functions. These functions will constitute the unit of networking for
next-generation systems and should be able to be composed in an “on-demand,”
“on-the-fly” basis. One of the current research challenges consists of devising the
architecture and design of solutions that identify the set of elementary functions or
blocks from which to compose network functions, which are today implemented as
monolithic elements.
In addition, 5G networks rely on a set of new concepts and techniques. Among them,
the following aspects can be highlighted: (i) Realizing network slicing in a cost-efficient
way, (ii) Addressing both end-user and operational services, (iii) Supporting softwariza-
tion natively, (iv) Integrating communication and computation, and (v) Integrating het-
erogeneous technologies (including fixed and wireless technologies).
5G networks are expected to present a number of advantages. One in particular is
a high degree of flexibility. They enforce the necessary degree of flexibility, where and
when needed, with regards to capability, capacity, security, elasticity, and adaptability.
Wiley 5G Ref. Edited by Rahim Tafazolli, Chin-Liang Wang and Periklis Chatzimisios.
Copyright © 2020 John Wiley & Sons Ltd.
DOI: 10.1002/9781119471509.w5GRef095
2 Slicing 5G Networks: An Architectural Survey
These networks will serve highly diverse types of communication – for example between
humans, machines, devices and sensors – with different performance attributes.
Network technologies are making rapid progress in supporting new 5G com-
munications (e.g. URLLC – Ultra Reliable and Low Latency Communication,
mMTC – massive Machine Type Communication, eMBB – enhanced Mobile Broad-
band, and UDN – Ultra Dense Networking) and IoT trends. Emerging vertical industry
applications, such as autonomous/cooperative driving, drone surveillance, remote
sensing, and data analytic, are causing the conventional cloud computing model to
evolve toward edge computing, by utilizing these advanced communications so that
obtaining ultra-low latency, high broadband, and customized data transport service.
In light of this observation, the native integration of advanced networking and cloud
computing domains is one of the research and engineering goals of 5G networks and
beyond. One of the critical driving issues for such integration and interworking is the
simple fact that is extremely inefficient and expensive to build a separate computing and
networking infrastructure for each and/or new service. Further advantages of 5G emerge
in the areas of management, control of systems and resources. 5G networks enable
uniform management and control operations that are becoming part of the design of
dynamic software architectures. They can thereby host and execute services in one or
more distinct network slices (NS).
This article is a survey of the main developments in 5G network slicing. The article is
organized as follows: section titled “Introduction” provides a 5G network overview and
the main characteristics of network slicing; section titled “Network Slicing: A Primer”
introduces the network slicing concepts, including key characteristics, key roles and
slicing viewpoint. Section titled “Surveying the Network Slicing Landscape” presents
the survey of the network slicing landscape, that includes the early definitions of
slicing and Standards Developing Organizations (SDOs’) definitions of slicing (ITU-T
(ITU-T Y.3011 2011), NGNM (NGMN Alliance 2016), IETF (Galis et al. 2017a), 3GPP
(3GPP TR23.799 2016), ETSI (ETSI 2018a), ONF (ONF Recommendation TR-526,
2017)), and key examples of network slicing architectures as developed in EU research
projects. Section titled “Slicing Enablements and Mechanisms” presents advanced
slicing concepts that include slicing operational modes, slice lifecycle, slice control
loops, and end-to-end slicing. Section titled “Outstanding Challenges in Network
Slicing” identifies and presents the remaining key challenges in full realization of
slicing in 5G Networks and beyond; section titled “Concluding Remarks” wraps up
remarks of the slicing in the context of networks and beyond; finally, sections titled
“Acknowledgement, Acronyms, and References” conclude the article.
Network Slicing: A Primer

Slicing is a move toward segmentation of resources and deployment of networking and
servicing elements for the purpose of enhanced services and applications on a shared
infrastructure. Many standardization groups including ITU-T (ITU-T Y.3011 2011),
NGNM (NGMN Alliance 2016), IETF (Galis et al. 2017a), 3GPP (3GPP TR23.799
2016), ETSI (ETSI 2018a), ONF (ONF Recommendation TR-526 2017) and more are
currently considering it.
Slicing 5G Networks: An Architectural Survey 3
Slices are expected to considerably transform the networking perspective and enhance
network architectures by: (i) Abstracting away the lower level elements, in various ways;
(ii) Isolating connectivity at a subnetwork level; (iii) Separating logical network behav-
iors from the underlying physical network resources; (iv) Allowing dynamic manage-
ment of network resources by managing resource-relevant slice configuration; (v) Sim-
plifying and reducing the expenditure of operations; (vi) Supporting for rapid service
provisioning; and (vii) Supporting for Network Services deployment.
Although there is no commonly accepted comprehensive definition of Slice yet, the
network slice key concepts discussed below can be utilized as a reference to discuss
and analyze the different slicing models, approaches, and techniques that will be dis-
cussed in the rest of the article. Now there is an overview of the key concepts in slicing,
the key characteristics of slicing, the roles organizations can take, and the viewpoint it
gives them.
The key concepts utilized in the 5G architecture and system design cover the network
slice and the infrastructure slice:
Network Slice: A set of infrastructures (network, cloud, data center (DC)), com-
ponents/network functions, infrastructure resources (i.e. connectivity, compute, and
storage manageable resources) and service functions that have attributes specifically
designed to meet the needs of an industry vertical or a service. As such, a network slice
is a managed group of subsets of resources, network functions/network virtual func-
tions at the data, control, management/orchestration, and service planes at any given
time. The behavior of the network slice is realized via network slice instances (NSIs)
(i.e. activated slices, dynamically and nondisruptively reprovisioned). The network slice
key concepts are the following: (i) A network slice supports at least one type of service;
(ii) A network slice may consist of cross-domain components from separate domains in
the same or different administrations, or components applicable to the infrastructure;
(iii) A resource-only partition is one of the components of a network slice; however on
its own does not fully represent a network slice; (iv) A collection of cloud slice parts
from separate domains is combined, connected through NS, and finally aggregated to
form an end-to-end network slice; and (v) Underlays/overlays supporting all services
equally (with “best effort” support) are not fully representing a network slice.
Infrastructure Slicing: A management mechanism that a resource provider can use
to allocate dedicated infrastructure resources and service functions to users. Broadly,
partition strategies can be classified into three categories: (i) Physical separation, such
as dedicated backbones or dedicated DCs. However, this strategy is not cost-efficient;
(ii) Underlays/overlays supporting all services equally (“best effort” support), such as
underlays/overlays, in the form of virtual private network (VPN) as overlay solution.
These solutions are neither flexible nor agile and (iii) Slicing, through network resources
allocation, where dedicated resources per customer/service ensure both isolation and
customization on top of the same infrastructure.
The key characteristics of network slicing include:
1) The concurrent deployment of multiple logical, self-contained, and independent

shared or partitioned slices on a common infrastructure platform.
2) Dynamic multiservice support, multitenancy, and the integration means for vertical
market players.
3) The separation of functions, simplifying the provisioning of services, the manageabil-

ity of networks, and integration and operational challenges especially for supporting
communication services.
4) The means for network/cloud operators/ISP and infrastructure owners to reduce
operations expenditure, allowing programmability and innovation necessary to
enrich the offered services, for providing tailored services, and allowing network
programmability to over-the-top (OTT) providers and other market players without
changing the physical infrastructure.
5) Slicing capability exposure: through a utilization model, the providers can offer
Application Programming Interfaces (APIs) to the vertical business customers for
granting the capability of managing their own slices. Such management actions can
include dimensioning and configuration.
6) Integration at customer premises: complementary network segments, in some cases
pertaining to the vertical business customer, become an integral part of the solution,
requiring a truly convergent network including the integration in existing business
processes as defined by the vertical customer.
7) Hosting applications, offering the capability of hosting virtualized versions of net-
work functions or applications, including the activation of the necessary monitoring
information for those functions.
8) Hosting on-demand third parties/OTTs, empowering partners (third parties/OTTs)
to directly make offers to the end customers augmenting operator network or other
value creation capabilities.
Within the context of provisioning of slices, there are three key roles that a participant
in the slicing arena can undertake. These roles are the following:
1) Resource Provider: A resource provider owns the physical resources and infrastruc-
ture, in any of network/cloud/datacenter, and provides or leases them to operators
who wish to be slice providers. The resource is presented as slice parts, which can be
composed together to form a full slice.
2) Slice Provider: A slice provider is the organization from which NS can be procured
and created. They are typically a telecommunication operator, but could be any orga-
nization that can participate in the slicing market.
3) Slice Tenant: A slice tenant is the owner of a specific slice, in which customized ser-
vices are hosted. Slice tenants make requests for the creation of new slices, from
a slice provider, through a service slice model specification. The tenant runs their
services in the slice on behalf of their users.
For any role, an organization can take a viewpoint on sharing and partitioning of
resources. From a business point of view, a network slice includes a combination of all
the relevant network and compute resources, functions, and assets required to fulfill a
specific business case or service.
From the infrastructure point of view, NSIs require the partitioning and assignment of
a set of resources that can be used in an isolated, disjunctive or nondisjunctive manner
for that slice.
From the tenant point of view, NSI provides different capabilities, specifically in
terms of their management and control capabilities, and how much of them the
network service provider hands over to the slice tenant. As such, there are two types of
slices: (i) Internal slices, understood as the partitions used for internal services of the
provider, retaining full control and management of them and (ii) External slices, being
those partitions hosting customer services, appearing to the customer as dedicated
networks/clouds/DCs.
From the management plane point of view, NS refer to the managed fully functional
dynamically created partitions of physical and/or virtual network resources, network
physical/virtual and service functions that can act as an independent instance of a con-
nectivity network and/or as a network cloud. Infrastructure resources include connec-
tivity, compute, and storage resources.
From the date plane point of view, NS refer to dynamically created partitions of net-
work forwarding devices with guarantees for isolation, customization, and security.
Surveying the Network Slicing Landscape

In this section, we provide a survey on the evolving work on network slicing and identify
key intellectual contributions from different initiatives. First, an historical review on
pioneering work around network slicing, starting with early definitions is presented.
Second, relevant standardization activities (e.g. ITU-T, NGMN, IETF, 3GPP, ETSI,
ONF) are considered, and, finally, there is an overview of relevant collaborative research
projects. The survey projects (5GEx, 5G SONATA, 5G NORMA, 5G-TRANSFORMER,
5G-PAGODA, 5G-SLICENET, 5G-MoArch, and NECOS) are selected as they have had
design, and implementation facets that are focused on slicing.
Early Definitions of Slicing

Slicing itself as segmentation of resources and deployment of networking elements for
the purpose of enhanced services and applications is not new. It has been considered
in the past since 1995 and it is being progressively included in the 5G standards. The
following initiatives and bodies make use of the concept of slicing or slicing precursors
over time.
Resource control frameworks were developed as part of Active/Programmable Networks
research (1995–2005) (Galis et al. 2004).
Resource frameworks were developed as part of Federated Testbed research: Planet Lab
USA (2002), PlanetLab EU (2005), OneLab EU (2007), PlanetLab Japan (2005), Open-
Lab EU (2012).
GENI Slice (2008): GENI (GENI 2019) is a shared network testbed, i.e. multiple exper-
imenters may be running multiple experiments at the same time. A GENI slice is:
(i) the unit of isolation for experiments; (ii) a container for resources that are used in
an experiment. GENI experimenters add GENI resources (compute resources, net-
work links, etc.) to slices, and run experiments that use these resources; (iii) a unit
of access control. The experimenter that creates a slice can determine which project
members have access to the slice, i.e. are members of the slice.
Identification of Slice Capabilities (2009): (Galis et al. 2009) as (i) Resource allocation
to virtual infrastructures or slices of virtual infrastructure; (ii) Dynamic creation and
management of virtual infrastructures/slices of virtual infrastructure across diverse
resources; (iii) Dynamic mapping and deployment of a service on a virtual infras-

tructure/slices of virtual infrastructure. Additionally, 17 Orchestration capabilities 19
Self-functionality mechanisms, and 14 Self-functionality infrastructure capabilities
were defined.
Cloud Manifest (2009): As defined in one of the first cloud publication (Rochwerger
et al. 2009), the cloud manifest specifies the structure of the service application in
terms of component types that are to be deployed as virtual elements. The manifest
also specifies the grouping of components into virtual networks and tiers that form
the service applications.
ITU-T Slicing (2011): As defined in ITU-T Y.3011 (2011), it is the basic concept of the
Network Softwarization. Slicing allows Logically Isolated Network Partitions (LINP)
with a slice being considered as a unit of programmable resources, such as network,
computation, and storage.
NGMN Slice Capabilities (2016): NGMN Alliance (2016) consists of three layers: (i) Ser-
vice Instance Layer, (ii) NSI Layer, and (iii) Resource layer. The Service Instance Layer
represents the services (end-user service or business services), which are to be sup-
ported. Each service is represented by a Service Instance. Typically, services can be
provided by the network operator or by third parties. An NSI provides the network
characteristics, which are required by a Service Instance. An NSI may also be shared
across multiple Service Instances provided by the network operator. The NSI may be
composed by none, one, or more Sub-network Instances, which may be shared by
another NSI.
IETF (2017): Network slicing is defined in Galis et al. (2017a) as managed partitions of
physical and/or virtual network and computation resources, network physical/virtual
and service functions that can act as an independent instance of a connectivity net-
work and/or as a network cloud. Network resources include connectivity, compute,
and storage resources. As such, NS considerably transform the networking and servic-
ing perspectives by abstracting, isolating, orchestrating, softwarizing, and separating
logical network components from the underlying physical network resources and as
such they enhance Internet architecture principles.
Additional characteristics, standard and research activities on infrastructure slicing
and references are presented in a network slicing tutorial (Galis 2018a).
Cloud Slicing
Different models are being developed for federated cloud computing. One such model,
the Reservoir model (Rochwerger et al. 2009), provides a clear separation between the
functional roles of service providers and infrastructure providers. RESERVOIR (Rochw-
erger et al. 2009) is one of the first cloud papers with the highest number of architectural
citation out of approximately 25 000 published cloud papers as stated in the review paper
(Heilig and Voss 2014). Service providers are entities that understand the needs of a par-
ticular business and offer service applications to address those needs. Service providers
do not own the computational resources needed by these service applications; instead,
they lease resources from infrastructure providers who provide them with a seemingly
infinite pool of computational, network and storage resources.
Infrastructure providers operate cloud sites that own and manage the physical infras-
tructure on which service applications execute. The federation of collaborating sites
Service application 1 Service application 2 Service application 3
Virtualizer Virtualizer Virtualizer
Computational resource Computational resource Computational resource
VEE host VEE host VEE host

Reservoir site 1 Reservoir site 2
Figure 1 Partitioning clouds by a virtualization layer into virtual execution environments.
forms a composite cloud. To optimize resource utilization, the computational resources

within a site are partitioned by a virtualization layer into virtual execution environments
(VEEs). VEEs are fully isolated runtime environments that abstract the physical charac-
teristics of the resource and enable sharing. The virtualized computational resources
along with the virtualization layer and all of the management enablement components
are referred to collectively as the VEE Host (VEEH).
Service applications are executed by a set of VEEs (represented by squares) dis-
tributed across the VEE hosts in a Reservoir cloud. VEEs for a particular service
application may all be collocated in the same VEEH (as in service application 1), they
may be spread across VEEHs within the same site (as in service application 2), or they
may be spread across sites (as in service application 3).
A service application is a set of software components that works collectively to achieve
a common goal. Each component of such service applications executes in a dedicated
VEE. The VEEs are placed on the same or different VEE hosts within the site or on
different sites (Figure 1). A service application is deployed on the composite cloud using
the contract and service level agreement (SLA) between the service provider and the
infrastructure provider – the service manifest.
ITU-T Slicing
According to ITU-T Y.3011 (2011), slicing allows LINP with a slice being considered as
a unit of programmable resources, such as network, computation, and storage. LINPs
are isolated from each other, and when combined with programmability in virtual
resources, users of LINPs can program the virtual resources on above the virtual-
ization layer (Key References: ITU-T Y.3011 2011; ITU-T IMT-2020 2019a; ITU-T
IMT2010/SG13 2019; ITU-T 2017a; ITU-T 2017b; ITU-T 2017c; ITU-T IMT-2020
2019b). In other words, each LINP can provide the corresponding users with services
similar to those provided by traditional networks without network virtualization.
The users of LINPs are not limited to the users of services or applications but can
include service providers. For example, a service provider can lease an LINP and can
provide emerging services or technologies such as cloud computing service. The service
providers can realize the emerging services as if they own a dedicated physical network.
To facilitate the deployment of network virtualization, it is necessary to provide control
and management procedures, such as creating, monitoring, and measuring the status
of LINPs.
Various services
LINP3 manager
LINP2 manager
LINP3
LINP1 manager
Virtual
networks LINP1 LINP2
Virtual resources
Virtual
manager
resources
Physical NW 1 Physical NW 3
Physical NW 4 manager
Physical resources
Physical NW 2 Physical NW 4
(router, switch,
hosts, etc.)
Figure 2 Conceptual architecture of network virtualization.
Figure 2 represents the conceptual architecture of network virtualization, which con-

sists of LINPs over physical resources supporting network virtualization. A single phys-
ical resource can be shared among multiple virtual resources and each LINP consists of
multiple virtual resources. Each LINP is managed by individual LINP manager.
NGMN Slicing
According to NGMN slicing model (NGNM: White Paper on 5G 2016; NGMN Alliance
2016), it consists of three layers (i) the Service Instance Layer, (ii) the NSI Layer, and (iii)
the Resource layer. They do the following:
1) The Service Instance Layer represents the services (end-user service or business ser-
vices), which are to be supported. Each service is represented by a Service Instance.
Typically, services can be provided by the network operator or by third parties.
2) An NSI provides the network characteristics, which are required by a Service
Instance. An NSI may also be shared across multiple Service Instances provided by
the network operator.
3) The NSI may be composed by none, one or more Sub-network Instances, which may
be shared by another NSI.
The NSI may be composed by none, one or more Sub-network Instances, which
may be shared by another NSI. Similarly, the Sub-network Blueprint is used to
Service
instance 5
Service
instance Service Service Service
Service
layer instance 1 instance 3 instance 4
instance 2
Network slice Network slice Network slice Network slice

instance 1 instance 2 instance 3 instance 4
Network
slice instance
layer Sub-network instance Sub-network instance
Sub-network
instance
Sub-network Sub-network (nonvirtualized)
Sub-network instance
instance instance
Resource
layer Resources/network infrastructure/network functions
Figure 3 Network slicing conceptual outline. Source: NGMN Alliance (2016). Reproduced with
permission of NGMN.
create a Sub-network Instance to form a set of Network Functions, which run on the
physical/logical resources (Figure 3).
IETF Slicing
According to the IETF network slicing architecture (Galis et al. 2017b) (Key References
including work in progress: Galis et al. 2017b, 2017c, 2018c; Geng et al. 2018a, 2018b;
Homma et al. 2019; Makhijani et al. 2017; Qiang et al. 2018, 2019; de Foy et al. 2018),
the following terms are defined:
Resource Slice: A grouping of physical or virtual (network, compute, storage) resources.
It inherits the characteristics of the resources, which are also bound to the capability
of the resource. A resource slice could be one of the components of network slice,
however on its own does not represent a network slice fully.
Network Slice: A network slice is a managed group of subsets of resources, network
functions/network virtual functions at the data, control, management/orchestration
planes and services at a given time. Network slice is programmable and has the ability
to expose its capabilities. The behavior of the network slice is realized via NSI(s).
End-to-End Network Slice: A cross-domain network slice, which may consist of
access network (fixed or cellular), transport network, (mobile) core network, etc.
End-to-end network slice can be customized according to the requirements of
network slice tenants.
NSI: An activated network slice. It is created based on a network template. A set of
managed runtime network functions, and resources to run these network functions,
forming a complete instantiated logical network to meet specific network character-
istics required by the service instance(s). It provides the network characteristics that
are required by a service instance. An NSI may also be shared across multiple service
instances provided by the network operator (Figure 4).
3GPP Slicing
According to 3GPP TR 28.801 (3GPP TR23.799 2016), the network slice concept
includes the following aspects: (i) Completeness of an NSI: An NSI is complete in the
sense that it includes all functionalities and resources necessary to support a certain set
of communication services thus serving a certain business purpose; (ii) Components of
an NSI: The NSI contains NFs. If the NFs are interconnected, the 3GPP management
system contains the information relevant to the connections between these NFs such
as topology of connections, and individual link requirements (e.g. Quality of Service
(QoS) attributes). For the part of the TN (Transport Network) supporting connectivity
between the NFs, the 3GPP management system provides link requirements (e.g.
topology, QoS attributes) to the management system that handles the part of the TN
supporting connectivity between the NFs; (iii) Resources used by the NSI: the NSI is
realized via the required physical and logical resources; (iv) Network Slice Template
(NST): The network slice is described by an NST. The NSI is created using the NST
and instance-specific information; (v) NSI policies and configurations: Instance-specific
policies and configurations are required when creating an NSI network characteristics
examples are ultra-low latency, ultra-reliability, etc. NSI contains a Core Network
part and an Access Network part; (vi) Isolation of NSIs: an NSI may be fully or partly,
logically and/or physically, isolated from another NSI.
The network slice stakeholders involved in 3GPP network slice management (Key
References published and work in progress on slicing includes: 3GPP TR23.799 2016;
3GPP SA2 2016, 2017a,b; 3GPP SA3 2017; 3GPP SA5 2018a) are depicted in the follow-
ing Figure 5.
There is also a collaboration between IETF and 3GPP, where it has been suggested that
the best approach is to ensure that the 3GPP engineers are involved in the IETF work
they are interested in, and that 3GPP states clearly what their requirements (rather than
solutions) are IETF also noted that the work in 3GPP is ongoing.
ETSI Slicing
ETSI’s E2E Network Slicing (ETSI 2018b) identifies a next-gen network slicing (NGNS)
framework defined here as a generalized architecture that would allow different network
service providers to coordinate and concurrently operate different services as active
NS, including slicing design principle (service-oriented approach, slice abstraction, slice
reusability, slice autonomy), an information model, network slice function specification,
and slice enablement.
The network slicing (NS) methods are aimed at providing custom design of networks
suitable for a specific use case (vertical market). Such methods need to be able to trans-
late a service requirement into normalized description of resources across different type
of network domains based on NGMN’s description of network slicing. The three-layer
approach is explained in Figure 6.
According to ETSI NGP there are three key areas of consideration for the NS archi-
tecture (ETSI 2018b, ETSI-2017a, ETSI 2018b). (i) Service description (corresponds to
Service component
Network slice management and orchestration
Template NS Life cycle management

management repository and monitoring
E2E Domain NS Resource

orchestration orchestration manager Registrar
Resource component
NE1 NE3 NE5 NE6
NE2 NE4
Created network slice instance
NS–subnet 1 NS–subnet 3 NS–subnet 6 SBC
NS–subnet 2 NS–subnet 4
Network slice
instance 1
Network slice
instance N
Figure 4 IETF network slicing.

Communication service customer (CSC) CSC

Consumer
Network operator (NOP)
Provider
Communication service provider (CSP) CSP

Consumer
Network equipment provider (NEP)
Provider
Consumer Equipment
Virtualization infrastructure service NOP Provider supplier
provider (VISP) Consumer
Data centre service provider (DCSP) Provider
VISP Consumer NFVI

Provider supplier
NFVI (network functions virtualization Consumer
infrastructure) supplier
Provider
Hardware supplier Consumer HW
DCSP
Provider supplier
Figure 5 3GPP network slice stakeholders. Source: ITU-T IMT2010/SG13 (2019). Reproduced with
permission of 3GPP.
Service instance layer
Describe network aspects of service
Network slice instance layer
Describe resource mapping and attachment
Resource layer
Figure 6 Three-layer network slice and service concept.
service instance layer): A sketch of services instantiated, independent of any technology

or underlying control plane; (ii) Network slice to abstract resource mapping (corre-
sponds to NSI layer); and (iii) Resource allocation (across different networks).
ONF Slicing
The ONF Slicing (ONF Recommendation TR-526 2017) adopts the NGMN terminology
of network slicing.
Applying slicing to the Software Defined Networking (SDN) architecture, the client
context provides the complete abstract set of resources (as Resource Group) and sup-
porting control logic that constitutes a slice, including the complete collection of related
client service attributes. As such, a 5G slice is comparable to, if not the same as, an
SDN client context, isolated by the controller’s virtualization and client policy functions
and continuously optimized by the orchestration and global policy functions. Going a
step further, a 5G controller is an SDN controller or vice versa. Both 5G and SDN con-
troller manage–control combinations of all relevant network resources/functions/assets
required to serve client-specific purposes. The client context also offers to the client
functions to manage–control the slice resources, including administration and mainte-
nance (OAM) related-functions, as visible by/available to the client according to admin-
istrative policy (Key Reference: ONF Recommendation TR-526 2017).
Recursion in the SDN architecture allows for a high-level client context to be
virtualized and orchestrated over a number of lower-level resource groups, spanning
geographic, business, and technology boundaries as needed. Each lower-level resource
group may itself be exposed by the client context of a lower-level SDN controller. The
SDN architecture thereby naturally supports a recursive composition of slices.
The SDN controller, at the center of a feedback loop and acting autonomously accord-
ing to administratively configured policies, enables dynamic allocation, modification,
and optimization of resource usage. The resources provided to the controller’s clients are
virtualized (abstracted views and services) from the underlying resources and presented
to slices through resource groups. Figure 7 shows a mapping of the SDN architecture,
terminology, and abstractions to 5G slicing.
5GEX EU Project
5GEx project (http://www.5gex.eu) focused on the transition from dedicated physical
networks with dedicated control and dedicated services and resources for different
applications to a “network factory,” where resources and network functions are traded
and provisioned.
The Inter-Provider NFV orchestrator (NFVO) represented in Figure 8 implements
service decomposition by mapping network service components on its current resource
view. The resource view consists of the Inter-Provider topology, potentially augmented
with detailed provider internal topologies and resource locations and capabilities. At
first, the Inter-Provider NFVO selects providers that may need to be involved in deliv-
ering the network service. This decision is policy based considering the Inter-Provider
topology and service catalogues advertised by other service providers on interface
I2-RTadvertise (resource topology) and I2-Cadvertise (service catalogues).
If needed, the multiprovider NFVO may collect further details on charging, offered
capabilities, network services, resources, and topology from selected providers and
may establish/update bilateral (or direct) business relationship to some of them as
decided/necessary. Then, the network service components are mapped on the inter-
provider, or optionally on more detailed topology, based on the information collected
bilaterally from involved providers. Then, the multiprovider NFVO sends the network
service/resource requests to other providers using the I2-S/I2-RC interfaces.
In 5GEx, a slicer management function (Figure 8) is designed with the view to enrich
the resource orchestrator functionality with multitenancy resource slicing and generic
Governs the Governs its slice

SDN controller via server context
Administrator Application/SDN controller

Client
Server context Server context Server context Server context
SDN
controller Resource Resource Server
Administrative
group group
client context
Client context Client context
Resource
orchestration and
Orchestration
virtualization
Virtualization
Server context Server context Server context Client
Resource Resource Resource Resource Resource

group group group group group
Server
Client context = Slice
Support Virtual
Client resources resources
support Resource group
Client context
Figure 7 ONF slicing. Source: ONF TR-526 (2017).
Customer
I1-S, I1-F, I1-RC l1-RT l1-C l1-RC
OSS/BSS Order Service l2-Cbilateral Service

Charging Auctioning
manager catalogue catalogue
Service agnostic Topology l2-S, l2-F (Os-Ma-nfvo’) Inter provider

abstraction NFVO
l2-RC (Or-Vi’)
Inter provider
NSO RO VNF
NFVO
l2-F & l2-RC (Vi-VnFm’) manager
Service
SLA mgmt
SLA l2-SLA SLA
manager manager
Element VNF Resource l2-Mon Resource

manager manager-G monitoring monitoring
VNFM-S l2-RCnetwork
MD-WM
MD-WIM
MD-PCE
MD-PCE
Element
Policy Resource VNF manager
database repository catalogue
l2-RTbilateral Topology
Service Topology
distribution
specific distribution
l2-RTadvertised
l3-S l3-Mon l3-RT l3-C
Topology
MD-WM
Resource Topology VNF distribution
For provider
internal monitoring abstraction catalogue
orchestration MD-PCE
Vnfm-Vi’ l3-RC Remote
hierarchy
Neighbor (or neighbor)
administrative administrative
l3-RC
NFVO VIM WIM PCE domain domain
(Or-Vi’)
Figure 8 Functional model of 5GEx multidomain orchestration.

life cycle virtual network function (VNF) management functionality. Additionally, the
slicer function coordinates and integrates multivendor/third party-specific life cycle
VNF management functions.
5G-SONATA EU Project
5G SONATA project (http://sonata-nfv.eu) focused on flexible programmability of
software networks and the optimization of their deployments. This was achieved via
a customizable Service Platform (SP) with a Network Functions Virtualization (NFV)
Orchestrator that supports Network Service Software Development Kit (SDK) for
developers and specialized DevOps workflows. One major component of the SONATA
architecture (see Figure 9) is the SDK, which provides service developers with both a
programming model and a set of software tools. The SDK allows developers to define
complex services consisting of multiple VNFs. A service provider (which can also be
the service developer) can then deploy and manage the created services on one or more
SONATA SPs through the corresponding Gatekeeper components.
A second major component of the system is the SONATA SP. Due to the modular
design of its management and orchestration (MANO) framework, the SP offers
customization opportunities by replacing components of the loosely coupled MANO
framework (MANO plugins).
As far as SONATA is concerned, a slice is an aggregated set of resources that can be
used in the context of an end-to-end networked service composed of VNFs. Slices are
composed of multiple resources, which are isolated from other slices and allow LINP,
with a slice being considered as the basic unit of programmability using network, com-
putation, and storage.
5G-NORMA EU Project
The 5G-NORMA project (http://www.it.uc3m.es/wnl/5gnorma) focused on: (i) Adap-
tive (de)composition and allocation of NFs Joint; (ii) Optimization of RAN and Core
Network, and (iii) SW-defined Mobile Control. This involved the design for service
management; mapping of customer-facing services and procedures to resource-facing
services and procedures; network slicing (service and resource); orchestration; interslice
and intraslice and network programmability as depicted in Figure 10. The same picture
provides a high-level functional perspective of the 5G NORMA system architecture and
shows the separation into four layers as well as the differentiation into intraslice and
interslice functions.
The Service Layer comprises Business Support Systems and business-level Policy
and Decision functions as well as applications and services operated by the tenant.
The MANO Layer realizes 5G NORMA’s Software-defined Mobile Network Orches-
tration (SDMO) concept by extending the ETSI network functions virtualization
management and orchestration (NFV MANO) architecture toward multitenant and
multiservice networks. The Control Layer accommodates the two main controllers:
(i) the Software-Defined Mobile Network Coordinator (SDM-X) for the control
of common (shared) NFs and (ii) Software-Defined Mobile Network Controller
(SDM-C) for dedicated NFs. SDM-X and SDM-C abstract from the technological and
Development Orchestration
SONATA SDK SONATA service platform
MANO framework
Editors
NFVO (Network service management) VNFM (VHF management)
Monitoring
Packaging tool
FSM1
FSMn
FSM1
FSMn
SSM1
SSMn
SSM1
SSMn
Default
Default
Default
Default
Debugging & testing
FSM/SSM
tools
Monitoring data analysis Message broker Message broker Message broker Message broker
(...)
Platform catalogues
tools
(executive) (executive) (executive) (executive)
Service
Conflict resolution
Conflict resolution
Catalogue access VNF lifecycle
Information mgmt.
Slice management
Service lifecycle Service lifecycle VNF lifecycle
Repositories
Service manifest mgmt.

execution
Monitoring management
decision execution decision

NF
Private catalogues
Plugin management Message broker
Infrastr.
Infrastructure abstraction Infrastructure adaptor VNF adaptor
Gatekeeper
Public catalogues
la-Vi la-Wi la-Vi Ve-Vnfm

Infrastructure
VIM WIM VIM
VNF PoP 1 PoP 2 VNF
VNF
Services users
Figure 9 SONATA high-level architecture.

Service
Applications & services
layer
BSS & policies decision
Service management
Management &
orchestration
SDM-O
layer
Domain-specific application
management
(e.g., 3GPP network management) VNF
VIM
manager
Control applications & policies

Control
layer
SDM-X SDM-C
Common control layer functions Dedicated controI layer functions

PNF VNF PNF VNF VNF VNF
VNF VNF VNF

layer
Data
PNF PNF PNF VNF

PNF
Common data layer functions Dedicated data layer functions
Figure 10 5G NORMA functional architecture.
implementation-related details of controlled network functions. Finally, the Data Layer

comprises the VNFs and PNFs needed to carry and process the user data traffic.
Figure 10 further depicts the split into common or so-called interslice functions and
dedicated (intraslice) functions. This split is maintained from the MANO Layer down to
the data layer, i.e. dedicated NFs are controlled (and managed, respectively) by the ten-
ant’s own instances of SDM-C and MANO Layer functions (i.e. ETSI NFV functions
as well as domain-specific application management functions). Shared functions are
controlled (and managed, respectively) by the SDM-X and the respective MANO Layer
functions, which are usually in the domain of the Mobile Network Operator (MNO) or
the Mobile Service Provider (MSP).
5G-TRANSFORMER EU Project
The 5G-TRANSFORMER project (http://5g-transformer.eu) explores how the network
can better serve the needs of vertical industries by offering the abstraction, flexibility,
and dynamic management capabilities they require via network slicing as the key archi-
tectural concept. The term network slice aligns network functionality to business needs,
since it allows customers to request not just functions, but also business objectives (e.g.
QoS, security, etc.) as a sort of intent. The scope of a slice may be a single customer fac-
ing service or a group of such services. In terms of deployment, NS can be implemented
by means of ETSI NFV network services.
The design of the 5G-TRANSFORMER architecture is presented in Figure 11. It
is conceived to support multiple combinations of stakeholders by introducing open
API among components. Through these APIs, the system hides unnecessary details
from the verticals, allowing them to focus on the definition of the services and the
required SLAs. 5G-TRANSFORMER envisions a system of three major components:
Vertical / MVNO Vertical / MVNO

Ve-Vs Ve-Vs
OSS/BSS Mgt-Vs OSS/BSS Mgt-Vs
5GT 5GT Network slice manager
Network slice manager
-VS -VS
Vs-So Vs-So
5GT Single-/multi- Single-/multi- 5GT Single-/multi- Single-/multi-
-SO domain domain -SO domain domain
So-So
NFVO-NSO NFVO-RO NFVO-NSO NFVO-RO
Federation
VNFM(s) VNFM(s)
So-Mtp So-Mtp
5GT NFVO-RO SLPOC 5GT NFVO-RO SLPOC
-MTP (resource advertisement, resource -MTP (resource advertisement, resource
abstraction, resource orchestration) abstraction, resource orchestration)
NFVO PNFs NFVO PNFs

VNFs PNFs VNFs PNFs
VNFM VNFs VNFM VNFs
VIM/WIM VIM/WIM
VIM/WIM VIM/WIM
NFVI NFVI NFVI NFVI
TD 1-1 TD 1-2 TD 2-1 TD 2-2
Administrative domain 1 Administrative domain 1

across multiple technology domains (TDs) across multiple technology domains (TDs)
Figure 11 5G Transformer slice architecture.
vertical slicer (5GT-VS), service orchestrator (5GT-SO), and mobile transport and
computing platform (5GT-MTP). The 5GT-VS is the entry point for the vertical
requesting a service and it handles the association of these services with slices as well as
network slice management. The 5GT-SO is responsible for end-to-end orchestration of
services across multiple domains and for aggregating local and federated (i.e. from peer
domains) resources and services and exposing them to the 5GT-VS in a unified way.
Finally, the 5GT-MTP provides and manages the virtual and physical IT and network
resources on which service components are eventually deployed. It also decides on the
abstraction level offered to the 5GT-SO.
5G-TRANSFORMER project (http://5g-transformer.eu) focuses on (i) Vertical Slicer
as the logical entry point for verticals to support the creation of their respective trans-
port slices; (ii) Service Orchestrator to orchestrate the federation of transport network-
ing and computing resources from multiple domains and manage their allocation to
slices, and (iii) Mobile Transport and Computing Platform or integrated fronthaul and
backhaul networks as depicted in Figure 11.
5G-Pagoda EU Project
The 5G-Pagoda project (https://5g-pagoda.aalto.fi) proposal is based on: (i) scalable
5G slicing architecture; (ii) extending the current NFV architecture toward support
of different specialized NS composed of multivendor virtualized network function
scalable 5G slicing architecture, and (iii) extending the current NFV architecture
toward supporting different specialized NS composed of multivendor virtualized
network functions.
The generalized 5G-Pagoda (https://5g-pagoda.aalto.fi) architecture for single-domain
slicing is illustrated in Figure 12. The Infrastructure consists of resources that are
Orchestrator
operator
Intra-domain Slice #n
operator
slicing
(single operator)
Dedicated
slice #n
Slice data plane

Common Slice Slice
Slice #1
slice management Slice data plane operations
operator
operator support
plane
Slice data plane
Slice owned Slice sofware layer (SSL)

Dedicated Domain-
HNS Slice resource layer (SRL) slice #1 specific
slice
Common application plane orchestrator
(DSSO)
Slice Slice
management Common control plane operations
plane support
Common data plane
Common slice owned Slice sofware layer (SSL)

Common
HNS Slice resource layer (SRL)
slice
Infrastructure
Virtual computing/storage/connectivity infrastructure layer (VCSCI)

Hardware nodes (PNFs) and
subsystems (HNS) Physical computing/storage/connectivity infrastructure layer (PCSCI)
Figure 12 5G PAGODA intradomain slicing architecture.
separated into two main groups: Virtual Computing/Storage/Connectivity Resources

(i.e. interconnected DCs) that are build atop of respective Physical Resources; Hardware
Nodes and Subsystems (HNSs) that can be used by the Common Slice or Dedicated
Slices. HNS may include RAN or Radio Nodes evolved node B (eNBs) and specific
transport nodes. These nodes can also be programmed, but they offer different services
than virtual connectivity/storage or computing.
Both types of resources can be dynamically allocated to slices. The allocation of Infras-
tructure resources to the Slice Resource Layer is done by the Intra-Domain Slice Orches-
trator and is optimized during whole life cycle of the slice. The architecture allows for
two different generic slice types: Common Slices and Dedicated Slices. All the slices can
cooperate; because of this, they share a similar internal structure (Control, Data, Appli-
cation and Management Planes, and Slice Operations Support functions). Both types of
slices, despite they have similar architecture, have different roles or are complementary
ones – it can be said that the Dedicated Slice is a client of the Common Slice.
5G-MoNArch EU Project
In 5G-MoNArch project (https://5g-ppp.eu/5g-monarch), the concept of slice is
analyzed in the context of elasticity, i.e. it refers to the ability to serve multiple slices
over the same physical resources while optimizing the allocation of computational
resources to each slice based on its requirements and demands. The algorithms/policies
for slice aware elasticity reside at the E2E service M&O Layer and more precisely at the
Cross-Slice M&O entity, which triggers the abovementioned resource optimization via
the 3GPP Network Management or the NFV MANO entities.
Lifecycle of a network slice instance
Preparation Instantiation, configuration, and Run-time Decommisioning

activation
Supervision
Design Pre-provision
Instantiation/ Modification Deactivation Termination
Activation
Network environment configuration
Reporting
preparation
Slice aware elastcity through Slice aware elastcity through Slice aware elastcity through
slice behavior analysis admission control resource allocation
Figure 13 Slice aware elasticity support in different phases of the life cycle of network slice instances.
Slice-aware elasticity is supported in 5G-MoNArch through three different

approaches that can be mapped to three different phases of the life cycle of a
slice instance (Figure 13). Approaches are the following: (i) Preparation-time approach:
Slice behavior analysis can be a critical asset for elasticity provisioning, since statistics
can be exploited in the slice preparation phase to efficiently decide the basic config-
urations and set the network environment; (ii) Instantiation-time approach: Flexible
slice admission control and network slice blueprint 1 or template 2 are applied during
the slice instantiation and configuration phase, so as the activated slices have reduced
probability to experience a computational resource outage; and (iii) Runtime approach:
Advanced sharing of computation resources among VNFs of multiple slices provides
resource elasticity as the involved slices are in operation, by exploiting multiplexing
capabilities.
NECOS EU Project
NECOS project (http://www.h2020-necos.eu) is grounded around a specific slicing
model that has as its foundation a mechanism to partition the underlying infrastructure
into constituent slice parts and then combine these slice parts into a full end-to-end
slice.
NECOS is particularly focused on a set of layered abstractions using slicing elements,
ensuring that they all fit together for the purpose of service provisioning. The combi-
nation of the right abstractions, the right layering, and a separation of concerns in the
architectural design allows NECOS to create a powerful and flexible slice-as-a-service
mechanism. In particular, the slice-as-a-service approach provides an adaptable con-
trol plane, having features for creating, growing, shrinking, and closing slices, as well
as adapting slices at the runtime, while considering service requirements and current
cloud resource conditions.
The architecture contains three main high-level subsystems. These are: (i) the NECOS
(Lightweight Software Defined Cloud (LSDC)) Slice Provider (colored in blue); (ii) the
Resource Marketplace (colored in yellow); and (iii) the Resource Providers (colored in
green). These subsystems are provided to support the tenants of NECOS who wish to
use slice-as-a-service. The NECOS (LSDC) slice provider is the subsystem that allows
for the creation of full end-to-end slices from a set of constituent slice parts. In NECOS,
a slice looks the same as the full set of federated resources, with the main attribute being
that the domains look a lot smaller, as they have been sliced. The Resource Marketplace
in NECOS is the way that the NECOS (LSDC) Slice Provider is able to find the slice parts
to build up a slice. Rather than having a predetermined set of providers that have been
configured in a federation, it has been selected a more flexible model of a marketplace
Tenant’s Slice Service Slice

domain description Service
orchestrator activator
level
monitonng
Slice provider
NECOS (LSDC)
Client to cloud interface Resource

marketplace
Service orchestrator Slice Spec. Slice request interface Slice
adaptor processor broker
Slices Slice builder Slice instantiation interface
Slice Slice marketplace interface
resource Slice runtime interface
Cloud to cloud interface

orchestrator
Slicing orchestrator
Infr. & Mon Abstraction
Domain orchestrator
Domain orchestrator
Domain orchestrator
Resource & VM mgmt Resource & VM monitoring
Slice agent
Slice agent
Slice agent
WAN Slice
controller
DC Slice
controller
controller
DC Slice
Adapters
VIM / WIM specific VIM / WIM specific

control interface monitoring interface
VIM l Mon WIM Mon VIM 2 Mon

Domain Mgm Domain Mgm Domain Mgm
Slice
Edge DC Net Central DC
Resource domains
Figure 14 NECOS functional architecture.
from which slice parts can be provisioned. The Resource Providers are those organiza-
tions that can provide the resources required for the slice parts – namely, DC resources
in the form of servers and storage, and network resources.
The tenant of NECOS is expected to be an organization that requires slices for running
their own services. Figure 14 presents these main elements, how they are grouped, and
the way they interact with the tenants (colored in red) who use NECOS.
Evolving Slicing Landscape and Characteristics

After analyzing different definitions and concepts about slicing, observe that early
definitions of slicing have a diverse scope as well as significant differences in the
enabling technological underpinnings (e.g. SDN, NFV, etc.). Ongoing standardization
efforts around slicing are closer to recent broadly scoped definitions of slicing and the
key characteristics of network slicing. However, standardization activities are too siloed
off from each other and present fundamental divergences on their approach (i.e. where
slicing is done and functional scope). Observe that existing approaches do not fully
attend the current and foreseeable needs of network slicing in its broadest capabilities.
Furthermore, from reviewing the evolving slicing concepts, it becomes clear that there
is a lack of common terminology and consistent concepts to clearly characterize the
scope and approach of each work embracing network slicing principles. As an effort to
provide some qualitative comparison on how each work is approaching network slicing,
this article uses a (nonexhaustive) list of 14 key characteristics at a high and common
level, sufficient to provide a comprehensive snapshot on the state of affairs toward net-
work slicing. The distinguishing characteristics are as follows:
1) Connectivity resource only slicing

2) Connectivity service slicing
3) Network cloud slicing
4) E2E slicing
5) Multidomain slicing
6) Uniform life cycle management
7) Tenant slice management
8) Slice-as-a-service
9) Virtual Infrastructure Manager (VIM) on demand
10) Wide-area network Infrastructure Manager (WIM) on demand
11) Resource Marketplace for slices
12) Network elasticity
13) Network cloud elasticity
14) Infrastructure monitoring
It can be observed that some characteristics (Figure 15), namely (i) connectivity
resource only slicing, (ii) connectivity service slicing, (iii) uniform life cycle manage-
ment, and (iv) tenant slice management have been majorly more worked out by different
initiatives. This is sensible considering the initial standpoint of network slicing was from
network connectivity-oriented initiatives and the common management requirements
of resources and tenant slices. In contrast, we note that few works address cloud slicing,
jointly address cloud and network slicing, consider end-to-end and multiadministrative
domain scenarios, or embrace the slice-as-a-service paradigm.
One of the limitations observed is related to the recurrent peer-to-peer interaction
between different providers/domains sharing resources for the slicing. We expect the
implementation of an alternative approach where sliced resources are directly accessible
Initiative EU project
RESERV Transfor
ITU-T NGMN IETF 3GPP ETSI ONF 5GEX SONATA NORMA PAGODA Slicened MoArch NECOS
OIR mer
slicing slicing slicing slicing slicing slicing slicing slicing slicing slicing slicing slicing slicing
cloud slicing
Slicing
characteristics
Connectivity
resource only
slicing
Connectivity
service slicing
Network cloud
slicing
E2E slicing
Multi-domnin
slicing
Uniform
lifecycle
Management
Tenant slice
Management
Slices as a
service
VIM on
demand
WIM on
demand
Resources
Marketplace for
slices
Network
elasticity
Network cloud
elasticity
Infrastructure
monitoring
Figure 15 Evolving slicing landscape and characteristics.

and attached to an end-to-end slice by a provider initiating the slice creation workflow.
This will overcome the need for peer-to-peer interactions among different providers
after the end-to-end network slice has been put in place.
NECOS seems to be the only initiative that goes beyond the state of the art by consid-
ering a number of unique features, namely the VIM on-demand and WIM on-demand
slicing models, and the Marketplace approach, which have not been considered by other
slicing approaches. These will help deliver a more flexible concept of slicing which goes
beyond the peer-to-peer orchestration and management interactions on which most of
the above initiatives are based.
Slicing Enablements and Mechanisms

After reviewing the state of the art on slicing, including the academic literature, the very
much fragmented standardization landscape, as well as the enabling technologies and
early realizations of slicing concepts, one relevant observation is the lack of a unique
approach (even at the conceptual level) to afford network slicing. This section covers
advanced topics on cloud network slicing by presenting and discussing (i) slicing oper-
ational modes, i.e. different ways to perform slicing, (ii) slice orchestration, (iii) slice life
cycles, (iv) slice control loops, and (v) end-to-end slicing considerations.
These topics have been worked out and presented here after the research conducted
in the NECOS project above mentioned. All components that are mentioned hereafter
refer to those depicted in the architecture of Figure 14.
Slicing Operational Modes

The quest of providing sliced services by logically partitioning resources of a (mul-
tidomain) software-defined infrastructure can be pursued through different slicing
approaches depending at which level (and entry point) of the stack slicing is performed.
These different options are what we call slicing operation modes (modus operandi).
The choice of the slicing operational mode has a critical impact on the amount and
type of components that need to be slice-aware, i.e. requiring software changes to
support the slicing functionality, as well as the degrees of freedom on implementation
choices, the isolation properties, and the control and management responsibilities of
both slice providers and slice tenants.
Figure 16 presents a high-level layered view of software-defined infrastructure orga-
nized in the three planes: (i) the infrastructure consisting of resources of different types
(e.g. computing, networking); (ii) the control and management realm encompassing
resource management entities (e.g. VIM, WIM, virtual network function manager
(VNFM)), control and orchestration functions; and (iii) the business plane featuring
the applications and functions of an end-to-end service composed from an arbitrary
number of network-related and application-specific end- or middle-point functions.
Monitoring functionalities are assumed on each plane.
As illustrated by the dark orange boxes, labeled with slicing in Figure 16, the logi-
cal partition of resources and their control and management functions to provide the
slices can be realized at different architectural points. One fundamental question arises
when considering the different plausible alternatives, which revolves around the need for
Business (application and service) plane
Monitoring
Application services
Vertical S
Service Mode 3: service-based
i
NFs L7 Apps S [Service slice aaS]
Network service orchestration
Control and management plane Slicing Mode 2: MANO-based
Monitoring
(R) Orchestration [NFV aaS]
Slicing Slicing Mode 1: VIM-dependent
NIM VIM [Platform slice aaS]
Infrastructure Slicing
Mode 0: VIM-independent
Monitoring
[Infra slice aaS]
Network Compute [Bara-metal slice]
resources resources
Figure 16 Candidate alternative slicing approaches.
changes. So, do we change all the software to deal with slices or do lower layer abstrac-
tions suffice to present a slice that all software just runs on?
Slicing at lower layers means that upper layers, such as VIMs and Orchestrators, do
not need to know about slicing. If a slice is presented to them, they can carry on working
with no change or minimal change. If slicing is done otherwise, then all the main soft-
ware elements need to be updated and adjusted to know about slices, i.e. all the APIs, the
modules, and internal function paths need to be adjusted and adapted to factor in slices.
Hence, there are inherent trade-offs when selecting one or the other slicing operational
mode. Ultimately, the actual decision on which slicing approach will depend on multiple
criteria on key aspects of the use-case scenario under consideration, dominated by the
technical footprint of the provider, and the technical abilities and technological choices
of the tenants and interest in opting for more or less control and responsibilities includ-
ing customized software components. In the following, we discuss the key aspects of
each slicing approach before we conclude the best fits to the goals and scope of 5G.
These points show how candidate approaches (slicing modes) and the architecture
meet, discussing the main characteristics, the software (SW) dependencies, and impact
of slice-ready APIs:
Mode 0 – VIM-Independent Slicing: The VIM on-demand model with DC slicing that
allows direct interdomain orchestrator to VIM interaction using a specific allocated
VIM. Multitenancy happens at the lower resource layers. Being a VIM-independent
approach, tenants can choose and have direct control of the VIMs, which can be as
lightweight as desired. However, the freedom of choice and level of control come along
potentially heavyweight operational responsibilities that the tenant must take by him-
self. Slicing support at resource providers can be considered lightweight since they do
not need to run large slicing-capable VIM instances:
Mode 1 – VIM-Dependent Slicing: The slicing in the VIM model, in contrast, is based
on multitenancy at the VIM level and allows direct interdomain orchestrator to
VIM interaction using a specific allocated shim object. The tenant (service/resource)
orchestrator may require changes to use the slice-ready APIs of the providers’
VIM, which may also require profound software changes and customization to
support slicing. This VIM-dependent approach requires arguably heavyweight
VIMs – becoming a lock-in choice of the provider – but frees the tenant from the
VIM responsibility.
Mode 2 – MANO-Based Slicing: The slicing in the orchestrator model, which uses the
interdomain orchestrator API interaction, a peer-to-peer approach, where a slice is a
set of data structures in the orchestrator. From the tenant’s perspective, depending on
the actual split between a service orchestrator and a resource orchestrator, different
software changes and standardized interfaces may be required. Eventually, the ten-
ant (business support system) BSS/OSS (operations support system) interfaces to the
slice-ready APIs of the provider orchestrator may also need some adaptation.
Mode 3 – Service-Based Slicing: Slicing at the application layer will not provide the
relevant slice as a service. This mode of slicing is constrained by the nature of a
service-specific vertical solution, requiring per-service tenant-provider APIs plus
eventual slicing support in the underlying layers, including multidomain interactions.
Slice Orchestration
A Slice Resource Orchestrator (SRO) is the component responsible for combining dif-
ferent slice parts (i.e. different resource segments) into a single aggregated slice. It is also
responsible for orchestrating the service elements across the slice parts that make up the
full end-to-end slice, and as such it is the component that handles the actual placement
and embedding of virtual machines (VMs) into the resource domains.
The SRO gathers data on the overall view of the slice in terms of allocated computing
resources and network topologies, and stores this in the Slice Database, which is the
component holding such knowledge. The SRO will be the component interacting with
the DC/Wide-area network (WAN) Slice Controllers (returned by the Slice Builder) to
complete the creation of the end-to-end slice. This will be performed by interconnecting
each VIM/WIM instance to its closest domain network edge points and taking care of
setting up the interdomain network connectivity between the different slice parts.
The SRO will take care of performing the slice life cycle management, i.e. continuously
checking whether the allocated slice is capable of fulfilling the requirements that were
initially requested by the tenant. With this goal in mind, the SRO must have access to a
set of monitoring measurements (coming from each slice part) that provide information
about respective slice resource utilization patterns (e.g. the number of available cores,
memory, network delay/loss, etc.). This information sets will be at the granularity of the
slice and will not directly be linked to any of the service instances running on that slice.
The monitoring information is expected to be propagated to the SRO via the underlying
monitoring abstraction implemented by a Slice Monitoring Abstraction layer. Multiple
elasticity scenarios as discussed later in the section titled “Scaling and Elasticity.”
The SRO may (will) also perform the allocation of the resource elements that are
required for the instantiation of the service instances (possibly described by Forward-
ing Graphs) on the global resource view available in each end-to-end slice. This will be
performed by embedding service elements (e.g. a Container, a VM, a VNF, or a virtual
link), on the slice resource view. The orchestrated instantiation of the different service
virtual elements will happen via the northbound interface of an Infrastructure and Man-
agement Abstraction layer. The latter will take care of adapting the above instantiation
requests to the specific underlying VIM/WIM technology. The SRO will have to request
to that abstraction layer the allocation of different adapters required to interact with the
different Infrastructure Managers running in the slice parts. This will happen via an API
that will provide the entry point to a VIM/WIM the adapter should interact with.
Slice Life Cycle

A slice is a dynamic entity that has its own life cycle management and operation. These
life cycle operations are divided into four phases as depicted in Figure 17. Each phase of
the slice life cycle will trigger actions on different components of the slice orchestration
and management functions that are represented in Figure 18. These tasks should be
coordinated by a slicing orchestrator to provide ways of handling workflows in scenarios
of success or failure.
Each of these four life cycle phases is further broken down into subphases, in which a
specific workflow will be performed by different components. The presentation of these
Slice instance life-cycle
1 - Preparation 2 - Instantiation 3 - Run-time 4 - Decommissioning

configuration and activation
Design Pre-provision
Supervision De-activation
Upgrade,
Instantiation / reconfiguration,
configuration Activation
Infrastructure environment scaling
preparation Reporting Termination
Figure 17 Life cycle phases of a slice instance.
Resource marketplace
Slice builder Slice broker

1 - Preparation 1 - Preparation
Design Pre-provision Design Pre-provision
Slice resource orchestrator 2 - Instantiation, configuration and activation

Instantiation /
1 - Preparation configuration Activation
Pre-provision
3 - Run-time
Slice controller Slice agent
Upgrade, reconfiguration, scaling 1 - Preparation 1 - Preparation
Infrastructure environment
preparation Design Pre-provision
4 - Decommissioning
2 - Instantiation, configuration and activation
De-activation Termination
Instantiation /
3 - Run-time
configuration Activation
Reporting
3 - Run-time
IMA Upgrade, reconfiguration, scaling
3 - Run-time
4 - Decommissioning
Supervision Reporting
Deactivation Termination
Figure 18 Mapping of slice life cycle operations to slicing components.

phases is described with respect to an end-to-end slicing architecture to highlight how

each phase and process relates to orchestration and management components.
The main tasks that need to be performed in each of the four phases are as follows:
• Preparation Phase: This starts with the specification of slice templates performed by
the tenant; it is followed by the discovery and preprovisioning of resources involving
the Slice Builder, Slice Broker, and Slice Agents via the Slice Request Interface and
Slice Marketplace Interface; continues with the preparation of the allocated infras-
tructure for the instantiation and support of the slice performed by the Slice Builder
interacting with the Slice Controllers via the Slice Instantiation Interface.
• Instantiation, Configuration, and Activation Phase: As soon as all the resources
shared/dedicated to the slice instance have been created and are configured, the
SRO will complete and activate the slice using the handles to the different slice parts
received by the Slice Builder.
• Runtime Phase: Normal operation of the slice and monitoring of its performance (via
an Infrastructure and Monitoring Abstraction (IMA)), allowing the SRO to perform
the slice’s reconfiguration or scaling as necessary using the Slice Runtime Interface.
• Decommissioning Phase: Deactivation of the slice, releasing its allocated resources is
carried by the SRO at the end of the Slice lifetime via the Slice Runtime Interface.
Preparation Phase
This phase starts with the specification of slice templates, followed by the discovery and
preprovisioning of resources, then the preparation of the allocated infrastructure for the
instantiation and support of the slice, and the exchanging of agreement between tenants
and providers. It is divided into three subphases:
• Design: The Slice Builder uses the slice blueprints/descriptors to design a new slice
instance. Here, the different slice parts are described as well as their features, config-
urations, resources needed, and associated workflows.
• Preprovision: The Slice Builder together with the Slice Broker and the Slice Agents
makes an on-demand request of resources via the Slice Request and Marketplace
Interfaces using admission control, resource negotiation, and charging. Net-
work resource availability, latency, and resiliency, as well as polices, are taken in
consideration before doing the allocation.
• Infrastructure Environment Preparation: The Slice Builder uses the Slice Instantiation
Interface to prepare all the infrastructure resources needed for the instantiation and
support of the new slice to be created, via contacting the relevant DC or WAN Slice
Controllers, with the offer from the related Slice agent.
Instantiation/Configuration and Activation Phase

In this phase, all resources of the slice instance are created and configured and become
ready for operation. These tasks occur in the resource domains.
• Instantiation/Configuration: The Slice Controller finalizes the allocation of the
resources for the slice: the required infrastructure resources (shared and/or
dedicated) are configured and instantiated but not yet activated. Allocating the
VIMs.
• Activation: The SRO finalizes the activation of the slice performing the steps required
to complete its topology; any pending service deployment is processed; service
instances are activated and becomes ready to start their operation.
Runtime Phase
In this phase, the slice instance is normally operating and has a feedback loop provided
to the SRO via the IMA that is used to monitor the slice performance as well as the
overall infrastructure needs.
• Supervision and Reporting: The performance and status of the slices are monitored
and reported to the SRO through the IMA component. According to the require-
ments of each slice and also to the overall status of the system, the SRO can take
the decision of performing reconfiguration and/or scaling on (some of ) the running
slices.
• Upgrade, Reconfiguration, Scaling: If required, a slice instance is reconfigured and/or
scaled according to its specific requirements and to the overall status of the system.
This process allows performing resource optimization via slicing elasticity.
Scaling and Elasticity

Supported by the monitoring data, the management of the slice instance involves
strategies to provide elasticity, adding or removing resources from the slice according
to its workload, and ensuring optimized service performance with efficient resource
usage. These methods may be applied both by the Slicing Orchestrator to add/remove
or replace resources allocated to a given slice.
The 3GPP approach considers two scaling methods which, when adapted, can be per-
formed as follows:
• Horizontal Scaling: This scaling is appropriate when new slice parts are needed
or when an existing slice part can be shutdown. To add a new slice part, the slice
builder/slice broker mechanism needs to be triggered to find the relevant part. When
doing a shutdown of an existing part, the SRO can use the Slice Runtime Interface to
tell the relevant DC Slice Controller to close the slice part.
• Vertical Scaling: This scaling is appropriate for resources in existing slice parts. It
involves adding/removing resources from a slice part (e.g. computing, memory, or
storage) or network part. The slicing orchestrator might add/remove physical devices
or resources from a slice part to better support its current demand. This is achieved
by the SRO using the Slice Runtime Interface to make a request to the relevant DC
Slice Controller.
• Migration: For a slice, migration needs to be analyzed and defined.
Two elasticity models regarding the triggering event can be defined:
• Reactive: The elasticity procedures are triggered by thresholds in resource usage or

SLA violations, reacting to the current workload.
• Proactive/Predictive: Uses predictive mechanisms, possibly based on workload his-
tory, to trigger the elasticity procedures according to anticipated load.
Decommissioning Phase
After a slice instance is no longer needed, the SRO proceeds to finish the life cycle of the
slice.
• Deactivation: The slice instance is deactivated, stopping all its operations and services.
• Termination: The slice instance is terminated and all the allocated resources are
released and reclaimed.
Slice Control Loops

In ETSI (2018a), ETSI defines architecture for network slice management systems that
allow different network service providers to coordinate and concurrently operate dif-
ferent services as active NS. The network slice methods are aimed at providing custom
design of networks suitable for a specific use case (vertical market). Such methods need
to be able to translate a service requirement into a normalized description of resources
across different type of network domains based on NGMN’s description of network
slicing.
Resources are partitioned, connected through different domains and organized with
the purpose of serving a particular high-level service; this is, a particular set of functional
and nonfunctional requirements. As in traditional virtualization services, it is expected
that the slice orchestration keeps honoring those requirements in front of workload
changes or failures with the additional complexity of dealing with the same dynamics
in each slice that is providing.
When considering the assurance processes involved in such an organization, it is pos-
sible to identify several overlapping control loops. First, it is easy to think that different
loads in the service, for example, more users requesting more video plays, may trigger
an elasticity process that will boot more VMs running streaming servers. That would
include monitoring metrics from the top service and actions to be performed on top
of the slice. However, more VMs running on top of the slice will consume more CPU,
memory, etc. adding pressure on the physical resources reserved for the slice. Thus, an
increasing physical CPU usage may need the triggering of a lower level elasticity pro-
cess in which more resources have to be added to the slice, locally or remotely in some
parts of a federation. Such a control loop will need monitoring data acquired from the
physical devices and take actions on the physical layer and on the slicing organization of
those physical resources. Those two loops may be seen, in a simplified way, in Figure 19.
However, when we consider that a slice is a partition of physical resources that are
shared among other slices, we have to see more complex interactions such as those in
Figure 20. It is the task of an orchestrator to coordinate all those control loops in a stable
and fair manner.
Figure 19 Simplified view of the assurance loops in a network
slicing framework. Service layer
Slicing layer
Physical layer
Service Service Service Service
Slicing instance Slicing instance
Physical layer
Figure 20 Interconnected assurance loops.
The Internet-draft in Homma et al. (2019) presents three types of provision

models: SaaS (Software-as-a-Service), PaaS (Platform-as-a-Service), and IaaS
(Infrastructure-as-a-Service):
In the SaaS-like model, a network slice provider (NSP) designs NSTs in advance, and
a tenant selects and uses one which fulfills most its requirement among the tem-
plates. The specifications of NS are abstracted to Key Performance Indicators (KPIs)
as networks and servers and shown to tenants. In short, detailed parameters of infras-
tructure network are hidden from tenants.
In the PaaS-like model, a tenant makes its request, including connected area, path
routes, the KPIs, and included service functions, and an NSP designs a template and
instantiate a network slice based on the request dynamically. The configurable values
would vary depending on the policy of each NSP.
In the IaaS-like model, a tenant designs its own NSTs and instantiates NSs by indicating
concrete resources to infrastructure operators. In other words, infrastructure opera-
tors provide just their resources, and NSs are coordinated by the tenant.
The management of the elasticity and assurance control loops needs to address a
hybrid model in which the slice orchestrator is responsible for monitoring and con-
trolling platform-related variables, and the tenant is responsible for monitoring and
controlling the top services variables and to request the needed scaling actions.
It is straightforward to observe that the two loops are inherently related, and events
happening on the external one are likely to affect the behavior of the components of
the internal one. For example, when the measured service-related KPIs received by the
components of the tenant’s domain indicate a possible violation of the expected QoS or
SLA for a given service instance, the Service Orchestrator might interact to the SRO via
the Service Orchestrator Adaptor to request a change of topology (service elasticity) for
that service via the IMA (e.g. adding an additional service component).
This request can result in the execution of two different workflows, according to the
status of the resources of the end-to-end slice on which that service is running.
1) A new service element can be added to one of the existing slice parts: the SRO embeds
the service element in the right slice part and interacts with the specific VIM via the
resource adaptation.
2) A new service element cannot be instantiated in any of the available slice parts due
to the lack of resources. In this case, the SRO will trigger the proper slice elasticity
workflow, namely either increasing the resources of an existing slice part or adding
additional slice parts to the end-to-end slice.
End-to-End Slicing
A slice provides an addressable and manageable end-to-end abstraction and a unit of
orchestration and service deployment with different attributes and requirements. Such
that: (i) end-to-end slices can encapsulate core, edge, IoT, slice parts and (ii) we can use
slices for control, for precise attributes, for isolation, for end-to-end operation, for per
service separation, etc. For example, a Telco Cloud slice will be different to a Content
Distribution Network (CDN) slice or a voice over IP (VoIP) slice.
The creation of an end-to-end slice is one of the most important operations in frame-
works dedicated to NS. The creation of an end-to-end slice involves all the slice MANO
subsystems. Network slicing is getting attention due to the possibility of diverse offer-
ings in terms of services and requirements, standing as one of the main concepts of the
upcoming 5G networks, in which several business models are expected to provide NS
as a service for on-demand vertical clients.
To aid in flexibility of creating the parts for end-to-end slices, we consider that differ-
ent Marketplaces can be available and accessed, based on the use cases of the various
participants. The Marketplaces access resource providers who are those organizations
that can provide the resources required for the slice parts – namely, DC resources in
the form of servers, storage, and network resources. Further resources can be provided
by organizations that have Mobile Edge, Sensor Networks, Wireless, etc. Each resource
provider will be capable of providing slice parts, which will be part of a full end-to-end
slice. The Resource Provider also needs to provision the relevant manager for each slice
part, meaning a VIM for a DC slice part, or a WIM for a network slice part. Examples
of Marketplaces include:
The Telecoms Marketplace, which is a limited setup between close cooperating telecoms
providers, i.e. allowing the creation of slices across each other’s infrastructure.
The Contract Marketplace, which is a setup between partners with a level of trust based
on signed contracts, i.e. allowing their resources to be used by others for slices.
The Open Marketplace, which allows any provider to offer resources and register their
offerings for users.
Frameworks such as the one described in ETSI (2018a) dedicated to NS allow
infrastructure providers to create and operate slice subnets to create/activate an
end-to-end network slice. In ETSI (2018a), three entities interact for the use of a
network slice: the tenant, the NSP, and the Network Slice Agent (NSA). The former uses
the network slice; the NSP provides network slice as a service to tenants, while the NSA
is a component in the infrastructure provider’s domain that maps NSP’s information
and operations within its domain. In ETSI (2018a), NS are defined in terms of two
types of resources: links that relate to traffic or path-related constraints, and nodes
that represent either compute or store resources. End-to-end NS are then created and
setup by a set of managed objects responsible for resource discovery, slice provisioning
based on NS service profiles, and NS instantiation from NS service profiles. Operations
related to the network slice are grouped into two types: NS service operations that
create, remove, modify, and augment an end-to-end network slice, and NS subnet
operations that take place in the context of resources (e.g. monitoring).
Tenants are the users of the slice. The slice provider subsystem maps to the NSP entity
and it is responsible for slice provisioning based on the tenant’s service description.
The slice controllers (DC and WAN) execute similar functions performed by the
NSA, understanding the slice provider requests and translating them into concrete
actions (e.g. resource allocation, VIM instantiation, etc.) inside the domain, so that
an end-to-end slice can be created, removed, modified, and augmented accordingly.
The resource discovery function is performed by the Marketplace subsystem, the
only subsystem that does not have a direct mapping to the entities described in ETSI
reference framework.
According to the Homma et al. (2019), the provision models for network slicing are
similar to the basic ones adopted in the cloud computing market. More specifically,
they are categorized into the three basic *-as-a-Service (*aaS) provision models:
Software-aaS, Platform-aaS, and Infrastructure-aaS. Certainly, it affords hybrid models
for the provisioning of resources and shares the same abstraction levels established in
the cloud computing market, as explained below:
In a SaaS-like provision model, an NSP designs models in advance. The tenant is respon-
sible for selecting and using the one that fits mostly its requirements. The network
slice specifications are abstracted in the form of KPIs and detailed parameters of the
infrastructure are not exposed to the tenants.
In a PaaS-like provision model, the tenant exposes its request and the NSP creates
a model to be instantiated dynamically based on this request. The tenant’s request
may include technical parameters, such as connected area, paths, KPIs, and service
functions.
In an IaaS-like provision model, the tenant is responsible for designing his own mod-
els and instantiating the NS. The infrastructure operators only provide the resources
indicated by the tenant, who is also responsible for coordinating these resources.
As mentioned before, a hybrid scenario can be provided as, for example, by a bro-
ker coordinating a PaaS type model in a SaaS-like manner. This way, the broker acts
recursively and becomes an NSP as well.
For the Decommissioning End-to-End Slice, the slice owner contacts the list of all slice
controllers obtained informing them appropriately to release the indicated resources.
Slicing KPIs
SDOs and community fora like ETSI NFV Industry Specifications Group, 3GPP, and
others have been concerned with the definition of KPIs for slicing. In particular, for 5G
network slicing the 3GPP has issued the Specification 28 554 (3GPP 2019). This docu-
ment defines several KPIs that are classified into three categories, namely accessibility,
integrity, and utilization KPIs.
Accessibility KPIs: Give a figure of how well the resources provided through slices are
accessible. Specific KPIs are how many customers are registered to a given slice as
well as the ratio between the number of successful registries and the total number of
registration requests.
Integrity KPIs: Integrity is related to the capability of the network slice to deliver informa-
tion end to end. The specific KPIs consist of the end-to-end delay and the throughputs
that can be achieved in a slice instance between particular reference points of 5G
networks.
Utilization KPIs: These KPIs represent how much used are the resources of a slice.
Specifically, these KPIs are the mean number of sessions that are successfully estab-
lished per slice and the usage of the virtualized resources, i.e. virtual processor, virtual
memory, and virtual disk, in the slice.
Recently, Kuklinski and Tomaszewski (2019) proposed a reclassification of network

slicing KPIs that are split into slice runtime and slice life cycle management related.
For slice runtime, this work considers three types of resources that may be used by a
single slice, namely connectivity, computing, and memory. For each type of resources,
it defines two thresholds, namely underutilization threshold and overutilization thresh-
old. The underutilization threshold is an arbitrary percent of the capacity of a given type
of resource. For example, the underutilization threshold for connectivity could be set to
20% and that means that if the bandwidth of a particular virtual link that is being used
during a given observation time window is little or equal than the 20% of the capacity of
that link, then the link is marked as underutilized. In a similar way, the overutilization
threshold is defined. As there are three different types of resources that are consumed by
a slice and two thresholds for each, a total of six KPIs come out. These six KPIs are com-
puted independently per slice. In addition, the authors of Kuklinski and Tomaszewski
(2019) propose a summarization of these KPIs for all (aggregated) connectivity, comput-
ing, and memory resources. Therefore, six more KPIs are defined that can complement
the behavior of the management system in charge of allocation of resources.
For life cycle related KPIs, the work of Kuklinski and Tomaszewski (2019) proposes a
total of four additional KPIs, namely the slice deployment time, slice deployment time
scalability, reconfiguration execution time, and slice termination time. Indeed, all these
four KPIs are related to every single slice.
In the last few years, many projects have been launched in the framework of 5GPPP
or Cloud Computing that explicitly or implicitly are addressing the definition of slicing
KPIs. In particular, NECOS (2018) defines KPIs to evaluate the performance of a set of
proofs of concepts (PoCs) of the slice as a service paradigm. In total, there are defined 18
KPIs for seven PoCs. Some of these KPIs fit well within the types defined in the previous
related initiatives, but others are beyond these classifications because they are service
or use-case specific KPIs reflecting capabilities of the system that is pretended to be
characterized.
Slice Marketplace
A resource marketplace is defined as an actual or nominal place where forces of demand
and supply operate, and where buyers and sellers interact (directly or through intermedi-
aries) to trade slice components or parts, which are computational and communication
resources belonging to one or many resource providers, which will be the constituting
elements of an end-to-end slice (Market Places 2019). The ultimate forces of demand
in that case are the slice providers who act on behalf of the slice tenants to find the
concatenation of slice parts that satisfy determined constraints. On the other hand, the
supply forces can be configured in different ways. First, it can be limited to a set of close
cooperating telecom providers, i.e. allowing the creation of slices across each other’s
infrastructure. Second, it can be constituted by a set of partners with a level of trust
based on signed contracts, i.e. allowing their resources to be used by others for slices.
Finally, it can be a completely open market where any supplier can participate.
The marketplace is an approach to materialize the same goals as a federation of
resource providers, i.e. allowing for the participation of different suppliers in the pro-
visioning of a service. The reason to opt for a marketplace instead of a static federation
of resource providers is twofold: First, to build end-to-end slices, a mechanism is
needed to reach and interact with providers in multiple geographic places – including
mobile edge and sensor networks – which are often not covered with existing feder-
ation approaches. Second, slice creation is generally more dynamic than federation
agreements, so a highly dynamic runtime mechanism for finding providers is needed.
Observe that there are online marketplaces for flights and for hotel rooms that provide
a good operational model to follow. In these cases, there is a broker which can go to
multiple agents, dynamically, and get a collection of offers for the required resource.
The end-user can then make a choice as to which offer is best suited. The agents can be
a division of the resource provider, or they may be an external aggregator that provides
compound offers. From the perspective of the broker and the end-user, the agent just
provides offers at a price point with certain conditions. Such an approach fits with the
creation of end-to-end slices very well.
In general, markets include mechanisms or means for (i) determining price of the
traded item, (ii) communicating the price information, (iii) facilitating deals and trans-
actions, and (iv) effecting distribution (Market Places 2019). The market for a particular
item is made up of existing and potential customers who need it and have the ability and
willingness to pay for it. Each resource provider may have the freedom to use its own
pricing functions that establish the prices of resources as a function of the resource class
and time. Therefore, when a resource provider participating in the marketplace receives
a request for a slice part, it will be able to answer if it is willing to participate and what
will be the cost of using its resources. The interaction of a resource provider with the
marketplace is done through a specialized agent that receives request and sends replies
to the market broker.
The resource discovery mechanism is meant to locate the appropriate resources that
compose a slice and constitutes the core of the marketplace. The central component of
these mechanisms is the market broker, which receives request from the slice provider
and contacts resource provider agents to check their availability. The broker is a dis-
tributed component. A given slice provider may contact several brokers and each broker
may have registered several resource providers. The interaction of the slice provider
and the broker is through a messaging system. This messaging system defines the gen-
eral slice requirements and acts as the input to the resource discovery mechanism. This
message is created by the slice provider to fulfill the tenant’s requests. The content of
the message will be generally based on a template. The parameters specified in the tem-
plate can specify the different components or parts of the slice with constraints like
geographical location, hosts, storage capacity, connections bandwidth, and others. The
slice broker is responsible to locate resources and prepare a corresponding response,
namely a slice resource alternative message. In practice, the message containing the slice
resource alternatives consists of annotations of the request message with alternative slice
component options.
Outstanding Challenges in Network Slicing

Many aspects have been considered during the architectural and realization work in
Network Slicing in 5G environments as depicted in the previous sections of this article.
Many characteristics have been discovered and designed, but there is still a significant
amount of work to be undertaken before slices can be utilized in an easy and effective
manner.
Challenges in Full Deployment of Economic Benefits

Here is a consideration of the deployment and economic aspects when slicing is utilized.
Deployment Options: There are architectural, engineering, performance, flexibil-
ity, and service agility without disruption challenges in terms of support of many
next-generation services in a network cloud–enabled infrastructure. In terms of
deployment options, an operator could deploy a single multiservice network, with a
shared physical layer supporting a shared functional layer. Alternatively, the operator
could deploy separate physical Sub-networks, each with their own physical resource
layer and functional layer on top of that; or the operator could deploy discrete virtual
networks, built on one shared physical resource layer, with multiple functional layers
dedicated to each application or service type.
Economy of Scale in Slicing: The benefits of slicing grow as the number of service types
that you are trying to launch grows. In addition, significant investment is needed in
automation to be able to do this at scale, otherwise the complexity and operational chal-
lenges are likely to mount up. It is key that the rest of the organization gears up to support
this ambition – development, delivery, marketing, operations and so on – otherwise the
operator will not be able to exploit the technology commercially.
Service Diversity: The key challenge is how to support and operate different kind of
services with very distinct needs, KPIs, QoS characteristics onto the same infrastruc-
ture. One practical approach is to position segregated services on specialized partitions,
designed and optimized for the type of service to be provided.
Interaction with the Vertical Customers: Proper abstractions and templates have to be
defined for ensuring the provision of a consistent service portfolio and their integration
with the internal network MANO.
Challenges in Realizing Full-Slice Capabilities

In pursuit of effective solutions for slicing, new types of networking, computing, and
servicing, there is a need to address additional challenges and outcomes, which are
identified in Galis (2018b). The following list presents the set of challenges for realizing
full-slice capabilities:
A Uniform Reference Model for Large-Scale Network Cloud Slicing: That describes all
the functional and nonfunctional elements and instances of a slice. It also describes
shared nonsliced parts.
Uniform Slice Templates: Providing the design of slices to different scenarios. This
outlines an appropriate slice template definition that may include capability exposure of
managed partitions of network cloud resources (i.e. connectivity compute and storage
resources), physical and/or virtual network and service functions that can act as an inde-
pendent network cloud.
Full Networks Isolation: Highly efficient slice creation with guarantees for isolation in
each of the Data/Control/Management/Service planes. Having enablers for safe, secure,
and efficient multitenancy in slices. Methods to enable diverse requirements for NS,
including guarantees for the end-to-end QoS of a service within a slice.
Slicing Service Mapping: Creating an efficient service mapping model binding across
network cloud slicing, specifying policies and methods to realize diverse service require-
ments without re-engineering the infrastructure.
Slicing Resource Mapping: Creating an efficient resource to slice mapping model bind-
ing across network cloud slicing.
Recursion: Namely methods for slicing segmentation allowing a slicing hierarchy with
parent–child relationships.
Customized Security Mechanisms Per Slice: In any shared infrastructure, security is
a key element to guarantee proper operation, and especially a fair share of resources
to each user including resource isolation and allocation policy at different levels and
isolation of network service management for multiple tenants.
NS Reliability: Maintaining the reliability of a network cloud slice instance, which is
being terminated, or after resource changes.
Optimization: Namely methods for automatic selection of network resources for slic-
ing; global resource views; global energy views; network cloud slice deployment based
on global resource and energy efficiency.
Capability Exposure: For network cloud slicing (allowing openness); with APIs for
slice specification and interaction; guarantees for KPIs and/or SLAs characteristics.
Programmability and Monitoring Control of network cloud slices.
Per-tenant Policy Management: In a multitenant, multislice end-to-end hosting and
networking scenario, closed-loop automation requires both per-tenant policies, as
well as the network operator’s own. Per-tenant policies would be set to limit compute,
storage, and network resource usage, block the execution of unauthorized operations,
trigger actions including scaling, healing, and topology reconfiguration to meet the
SLA with a tenant.
Efficient and Lightweight Slice Life Cycle Management: Including creation, activa-
tion/deactivation, protection, elasticity, extensibility, safety, and sizing of the slicing
model per network and per network cloud for slices in access, core, and transport
networks; for slices in DCs; and for slices in edge clouds.
Dedicated Network: Each slice must behave as a dedicated network while sharing
underlying resources, physical and virtual. Monitoring the status and behavior of net-
work cloud slice in a single and/or multidomain environment, and maintenance mech-
anisms have to be defined to show and abstract the proper information for each slice
customer.
Full Scalability: To partition network resources in a scalable manner, it is required to
clearly define to what extent slice customers can be accommodated or not on a given
slice. The application of different SLAs on the offered capabilities of management, con-
trol, and customization of slices will directly impact the scalability issue.
Slice Dimensioning: Overdimensioning has been the normal way in the past for avoid-
ing any kind of congestion. With slicing, the traffic sources and destinations become
much less predictable, if at all. Appropriate planning, dimensioning, and enforcement
are needed to make sustainable the transition to this new form of service.
Autonomic Slice Management and Operation: Namely self-configuration, self-

composition, self-monitoring, self-optimization, self-elasticity for slices that will be
supported as part of the slice protocols.
Automated Life Cycle: Instantiation, scaling, and topology reconfiguration of slices.
Scale: Very large-scale slicing with efficient elasticity.
Composability: Efficient and large-scale slice stitching/composition by having
enablers and methods for efficient stitching/composition/decomposition of slices:
vertically (through service + management + control planes); horizontally (between
different domains as part of access, core, edge segments); or a combination of
vertically + horizontally.
Orchestration: Efficient end-to-end network cloud orchestration of slices.
Concluding Remarks
A 5G network is a set of infrastructures (network, cloud, DC), components/network
functions, infrastructure resources (i.e. managed connectivity, compute, storage
resources), and service functions that have attributes specifically designed to meet the
needs of an industry vertical or a service. As such, a network slice is a managed group of
subsets of resources, network functions/network virtual functions at the data, control,
management/orchestration, and service planes at any given time. The behavior of the
network slice is realized via NSIs (i.e. activated slices, dynamically and nondisruptively
reprovisioned).
The 5G architecture is designed to provide slices as a service. Each of these slices is a
set of computational and networking resources created with the purpose that customer
users (tenants) can run one or several application services on top.
To ensure that the supported services can be deployed appropriately, these slices are
orchestrated to fulfill on-demand end-to-end quality requirements, independently each
one from the others, and spanning across a shared infrastructure of several administra-
tive domains.
The slicing can be performed either at the resource level or the virtual infrastruc-
ture management level of each of the administrative domains contributing to a slice.
The high-level 5G architecture can be described in terms of its constituting functions,
and from that point of view, four functional domains can be distinguished, namely the
tenant’s domain, the resource domain, the resource marketplace, and the slice provider.
5G networks will require a novel approach on how orchestrate, deploy, and manage
services and slices. Figure 21 presents an indicative list of key issues that are under
research in the context of the 5G slice networking.
Acknowledgment
This work was partially done by the H2020 4th EU-BR Collaborative Call, under the
grant agreement no. 777067 (NECOS – Novel Enablers for Cloud Slicing), funded by the
European Commission and the Brazilian Ministry of Science, Technology, Innovation,
and Communication (MCTIC) through RNP and CTIC. The authors thank all NECOS
project participants, whose contributions have been fundamental to the realization of
this work.
• Transition from network devices to network functions and virtual network functions
• Transition from network service to precision network services in scalable slices
• Dynamically adapting the network to meet future demands
• Creating the dynamic, configurable, programmable, resilient, safe and cost effective E2E network
• A programmable network operating system with simple interface to the network (smart network fabric)
E2N multi-domain orchestration
E2E coordination, conflict resolution, multi-domain information exchange
Management and control

Mobility Network Service Slice
Service adapted
network slices
Enabled by
Dedicated ICT Network
network functions Service Slice
including NFV High-precision vertical
network service slice
Light weight smart E2E network fabric facilities:

Network abstraction, network Softwarisation, allocate (virtual) network resources/slices, maintain
network state, ensure network reliability in a multi domain environment
EDGE EDGE
Smart cloud and
network fabric FIXED
CORE
RADIO EDGE
Enabled by aCCESS aCCESS METRO
EDGE
programmability EDGE EDGE
including SDN
Figure 21 5G networking.
List of Abbreviations
API Application Programming Interface
CDN Content Distribution Network
DC Data Center
eMBB enhanced Mobile BroadBand
IMA Infrastructure and Monitoring Abstraction
KPI Key Performance Indicator
LSDC Lightweight Software Defined Cloud
mMTC massive Machine Type Communication
NFV Network Functions Virtualization
OTT Over-The-Top
QoS Quality of Service
SDN Software Defined Networking
SDO Standards Developing Organization
SLA Service Level Agreement
SRO Slice Resource Orchestrator
URLLC Ultra Reliable and Low Latency Communication
VDU Visual Display Unit
VIM Virtual Infrastructure Manager
VM Virtual Machine
VNF Virtual Network Function
VNFM Virtual Network Function Manager
WAN Wide-Area Network

WIM Wide-area network Infrastructure Manager
Related Articles
Network Slicing/Virtualization Security
Slicing Across Multiple Operator Domains
Core and Transport Network Slicing
References
3GPP (2019). 5G end to end Key Performance Indicators (KPI), Release 15, 3GPP TS
28.554, ver. 15.3.0.
3GPP SA2 (2016). Study on Architecture for Next Generation System/Network slice related
functionality (3GPP TR 23.799).
3GPP SA2 (2017a). System Architecture for the 5G System/Network slice related
functionality (3GPP TS 23.501).
3GPP SA2 (2017b). Procedures for the 5G System: procedures and flows of the
architectural elements/Network slice related procedures (3GPP TS 23.502).
3GPP SA3 (2017). Study on the security aspects of the next generation system/network
slice related security (3GPP TR 33.899).
3GPP SA5 (2017). Study on management and orchestration of network slicing for
next-generation network (3GPP TR 28.801).
3GPP SA5 (2018a). Provisioning of network slicing for 5G networks and services: detailed
specification of network slice provisioning/network slice management (3GPP TS 28.531).
3GPP SA5 (2018b). Management of network slicing in mobile networks – concepts, use
cases and requirements (3GPPTS 28.530).
3GPP TR23.799 (2016). Study “Network Slicing” (2016); SA5 TR 28.801 Study Item
“Network Slicing” (2017).
5G Slicing Association (2018). Position white paper: 5G network slicing for cross industry
digitization. http://www-file.huawei.com/-/media/CORPORATE/PDF/white%20paper/
5G-Network-Slicing-for-Cross-Industry-Digitization-Position-Paper.pdf?source=corp_
comm.
ETSI (2017a). Network Operator Perspectives on NFV priorities for 5G. https://portal.etsi
.org/NFV/NFV_White_Paper_5G.pdf.
ETSI (2017b). GS NGP 001: next generation protocol (NGP); Scenario Definitions. http://
www.etsi.org/technologies-clusters/technologies/next-generation-protocols
ETSI (2018a). E2E network slicing reference framework and information model. Kiran,
Makhijani-Huawei Technologies, Kevin Smith-Vodafone John Grant – Ninetiles Alex
Galis- UCL, Xavier Defoy-Interdigital - published in October 2018, https://www.etsi
.org/deliver/etsi_gr/NGP/001_099/011/01.01.01_60/gr_ngp011v010101p.pdf.
ETSI (2018b). E2E network slicing reference framework and information model. Kiran,
Makhijani-Huawei Technologies, Kevin Smith-Vodafone John Grant – Ninetiles Alex
Galis-UCL, Xavier Defoy-Interdigital published in October 2018 by ETSI as a standard
specification document. https://www.etsi.org/deliver/etsi_gr/NGP/001_099/011/01.01

.01_60/gr_ngp011v010101p.pdf.
de Foy, X., Rahman, A., Galis, A. et al. (2018). IETF Draft NetSlices interconnections.
https://tools.ietf.org/html/draft-defoy-coms-subnet-interconnection-03.
Galis, A. (2018a). Network slicing tutorial. IEEE CNSM, Rome, 5–9 November 2018, http://
cnsm-conf.org/2018/files/CNSM18_SlicingTutorial_AlexGalis_5-10-2018.pdf.
Galis, A. (2018b). Perspectives on Network Slicing – Towards the New ‘Bread and Butter’ of
Networking and Servicing. IEEE. https://sdn.ieee.org/newsletter/january-2018/
perspectives-on-network-slicing-towards-the-new-bread-and-butter-of-networking-
and-servicing.
Galis, A., Makhijani, K., Yu, D., and Liu, B. (2018c). IETF Draft Autonomic NetSlicing.
draft-galis-anima-autonomic-slice-networking-04.
Galis, A., Denazis, S., Brou, C., and Klein, C. (2004). Programmable Networks for IP Service
Deployment, 450. Artech House Books. ISBN 1-58053-745-6. http://www.artechhouse
.com/International/Books/Programmable-Networks-for-IP-Service-Deployment-1017
.aspx.
Galis, A., Abramowicz, H., Brunner, M. et al. (2009). Management and service-aware
networking architectures (MANA) for future internet. Invited paper IEEE 2009 Fourth
International Conference on Communications and Networking in China (ChinaCom09),
Xi’an, China, 26–28 August 2009, http://www.chinacom.org/2009/index.html.
Galis, A., Dong, J., Makhijani, K. et al. (2017a). IETF Draft Network slicing. https://tools
.ietf.org/html/draft-gdmb-netslices-intro-and-ps-01.
Galis, A., Dong, J., Makhijani, K., et al. (2017b). IETF Draft Network slicing. https://tools
.ietf.org/html/draft-gdmb-netslices-intro-and-ps-01.
Galis, A., Kuklinski, S., Dong, J. et al. (2017c). IETF Draft Network slicing – revised
problem statement. draft-galis-netslices-revised-problem-statement-03.
Geng, L., Dong, J., Makhijani, K. et al. (2018a). IETF Draft NetSlices architecture.
draft-geng-netslices-architecture-02.
Geng, L., Qiang, L., Lopez, D., and Contreras, L. (2018b). IETF Draft NetSlices
management architecture. draft-geng-coms-architecture-01.
GENI (2019). Key GENI concepts. http://groups.geni.net/geni/wiki/GENIConcepts
(accessed July 2019).
H2020 (2018). 5GPPP White Paper on 5G Architecture (Open Access), https://5g-ppp.eu/
wp-content/uploads/2018/01/5G-PPP-5G-Architecture-White-Paper-Jan-2018-v2.0
.pdf.
Heilig, L. and Voss, S. (2014, ISSN: 2168-7161). A scientometric analysis of cloud
computing literature. IEEE Transactions on Cloud Computing 2 (3): 266–278. doi:
10.1109/TCC.2014.2321168.
Homma, S., Nishihara, H., Miyasake, T. et al. (2019). IETF Draft Network Slice Provision
Models, provision-models-00. https://www.ietf.org/id/draft-homma-slice-provision-
models-00.txt’ (accessed 1 February 2019).
ITU-T (2017a). Recommendation: application of network softwarization to IMT-2020
(O-041). http://www.itu.int/en/ITU-T/focusgroups/imt-2020/Pages/default.aspx.
ITU-T (2017b). Framework for IMT-2020 overall network architecture (O-043) http://
www.itu.int/en/ITU-T/focusgroups/imt-2020/Pages/default.aspx.
ITU-T (2017c). Network management framework for IMT-2020 (O-047). http://www.itu
.int/en/ITU-T/focusgroups/imt-2020/Pages/default.aspx.
ITU-T IMT2010/SG13 (2019). Future networks, with focus on IMT-2020, cloud computing
and trusted network infrastructures. http://www.itu.int/en/ITU-T/focusgroups/imt-
2020/Pages/default.aspx (accessed on July 2019).
ITU-T IMT-2020 (2019a). Network slice life-cycle management level architecture. https://
www.itu.int/en/publications/Documents/tsb/2017-IMT2020-deliverables/mobile/index
.html#p=49 (accessed July 2019).
ITU-T IMT-2020 (2019b). Network management requirements (O-046). http://www.itu
.int/en/ITU-T/focusgroups/imt- 2020/Pages/default.aspx.
ITU-T Y.3011 (2011). Future networks: objectives and design goals. http://www.itu.int/rec/
T-REC-Y.3001-201105-I (accessed on July 2019).
Kuklinski, S. and Tomaszewski, L. (2019). Key performance indicators for 5G network
slicing. 2nd Workshop on Advances in Slicing for Softwarized Infrastructures, Paris,
France, 28th June 2019.
Makhijani, K., Qin, J., Ravindran, R. et al. (2017). IETF Draft NetSlices use cases
draft-netslices-usecases-01.
Market Places (2019). Business Dictionary, Market Definition. http://businessdictionary
.com/definition/market.html (accessed on July 2019).
NECOS (2018). D6.1: report on design of federated cloud environment. Released in
October 2018.
NGMN Alliance (2016). Description of network slicing concept. https://www.ngmn.org/
fileadmin/user_upload/160113_Network_Slicing_v1_0.pdf.
NGNM: White Paper on 5G (2016). https://www.ngmn.org/5g-white-paper/5g-white-
paper.html (accessed on July 2019).
ONF Recommendation TR-526 (2017). Applying SDN architecture to Network Slicing.
TR-526 Applying_SDN_Architecture_to_5G_Slicing_TR-526.pdf.
Qiang, L., Geng, L., Makhijani, K. et al. (2018). IETF Draft NetSlices management use
cases. draft-qiang-coms-use-cases-00.
Qiang, L., Galis, A., Geng, L. et al. (2019). IETF Draft NetSlices information model.
draft-qiang-coms-netslicing-information-model-02.
Report on Net Slicing Support with ETSI NFV Architecture Framework (2017). http://
www.etsi.org/deliver/etsi_gr/NFV-EVE/001_099/012/03.01.01_60/gr_NFV-
EVE012v030101p.pdf.
Rochwerger, B., Caceres, J., Montero, R. et al. (2009). The reservoir model and architecture
for open federated cloud computing. IBM Journal of Research and Development 53 (4):
http://www.haifa.ibm.com/dept/stt/sas_public.html.
Further Reading
Galis, A. (2000). Multi-Domain Communication Management, pp. 1–419 and Appendices,

pp. 422–1160 in CD-ROM. Boca Raton, FL: CRC Press LLC, ISBN 0-8493-0587-X.
Galis, A., Denazis, S., Brou, C., and Klein, C. (2004). Programmable Networks for IP Service
Deployment, 450. Artech House Books, ISBN 1-58053-745-6. http://www.artechhouse
.com/International/Books/Programmable-Networks-for-IP-Service-Deployment-1017
.aspx.
View publication stats

Slicing 5G Networks - An Architectural Survey - in - Wiley 5G Ref Online

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

Slicing 5G Networks - An Architectural Survey - in - Wiley 5G Ref Online

Uploaded by

Copyright:

Available Formats

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

Slicing 5G Networks: An Architectural Survey

Chapter · May 2020

Alex Galis Stuart Clayman

SEE PROFILE SEE PROFILE

Christian Esteve Rothenberg

PORVIR-5G - programabilidade, orquestração e virtualização de redes em 5G View project

The user has requested enhancement of the downloaded file.

Slicing 5G Networks: An Architectural Survey

Network Slicing: A Primer

1) The concurrent deployment of multiple logical, self-contained, and independent

3) The separation of functions, simplifying the provisioning of services, the manageabil-

Surveying the Network Slicing Landscape

Early Deﬁnitions of Slicing

resources; (iii) Dynamic mapping and deployment of a service on a virtual infras-

Service application 1 Service application 2 Service application 3

Virtualizer Virtualizer Virtualizer

Computational resource Computational resource Computational resource

VEE host VEE host VEE host

Figure 1 Partitioning clouds by a virtualization layer into virtual execution environments.

forms a composite cloud. To optimize resource utilization, the computational resources

Figure 2 Conceptual architecture of network virtualization.

Figure 2 represents the conceptual architecture of network virtualization, which con-

Network slice Network slice Network slice Network slice

Network slice management and orchestration

Template NS Life cycle management

E2E Domain NS Resource

NE1 NE3 NE5 NE6

Created network slice instance

NS–subnet 1 NS–subnet 3 NS–subnet 6 SBC

Figure 4 IETF network slicing.

Communication service customer (CSC) CSC

Communication service provider (CSP) CSP

Data centre service provider (DCSP) Provider

VISP Consumer NFVI

Service instance layer

Describe network aspects of service

Network slice instance layer

Describe resource mapping and attachment

Figure 6 Three-layer network slice and service concept.

service instance layer): A sketch of services instantiated, independent of any technology

Governs the Governs its slice

Administrator Application/SDN controller

Server context Server context Server context Client

Resource Resource Resource Resource Resource

Client context = Slice

Figure 7 ONF slicing. Source: ONF TR-526 (2017).

I1-S, I1-F, I1-RC l1-RT l1-C l1-RC

OSS/BSS Order Service l2-Cbilateral Service

Service agnostic Topology l2-S, l2-F (Os-Ma-nfvo’) Inter provider

Element VNF Resource l2-Mon Resource

Figure 8 Functional model of 5GEx multidomain orchestration.

Service manifest mgmt.

decision execution decision

Infrastructure abstraction Infrastructure adaptor VNF adaptor

la-Vi la-Wi la-Vi Ve-Vnfm

Figure 9 SONATA high-level architecture.

BSS & policies decision

Control applications & policies

Common control layer functions Dedicated controI layer functions

VNF VNF VNF

PNF PNF PNF VNF

Figure 10 5G NORMA functional architecture.