A reference architecture for network slicing

Sławomir Kukliński∗ Adlen Ksentini Eleonora Cau

Lechosław Tomaszewski∗ and Pantelis A. Frangoudis and Marius Corici
and Tomasz Osiński∗ Eurecom Fraunhofer FOKUS
∗
Orange Polska,  Warsaw University of Technology Sophia Antipolis, France Berlin, Germany
Warsaw, Poland
Abstract—Network slicing is an important technology that are similar to NSI, but do not have to form a complete logical
influences the way in which new networking solutions will be network. Multiple NSIs may share the SNIs. In this concept,
designed and operated. Currently, there are several approaches to the service instances are separate to network slice instances.
network slicing, but so far there is no a systematic approach that
includes all aspects of the technology. In this paper, we present NFV has no special support for network slicing, but this is
a generic network slicing framework that includes embedded in the key technology commonly used in most network slicing
each slice some management and operations related mechanisms solutions. In [5] it has been proposed to add to the NFV
in order to cope with slice management scalability and to address architecture a slice specific entity (Slice Controller), as a
the multi-tenancy issue. The presented solution uses NFV MANO
part of the OSS/BSS domain. It communicates with MANO
for slice orchestration and supports multi-domain slicing.
via the Os-Ma-nfvo reference point, beyond which everything
I. I NTRODUCTION relies on standard NFV concepts and procedures. ETSI NFV
Network slicing enables creation of many, fully fledged group in Release 3 plans to address some network slicing
virtual networks over a common infrastructure while main- requirements like scalability and multi-tenancy.
taining isolation between the slices. A network slice can be The IETF has initiated works on network slicing [6], but
glued with applications. The key enabler of network slicing is so far no Working Group on the topic has been formed. The
ETSI Network Functions Virtualization (NFV) technology [1]. IETF works concern the requirements, architecture and the
Network slicing was introduced by PlanetLab in 2002 [2] and adaptation of IETF protocols to network slicing needs.
more recently reinvented by NGMN [3]. It brings three main The 3GPP concepts DÉCOR [7] and eDÉCOR [8], appli-
benefits: (i) dynamic deployment of networking solutions with cable to 4G networks, allow for the deployment of several
short time to market and low CAPEX; (ii) ability to create Evolved Packet Cores (EPC) sharing the same RAN, but
networks that are tightly coupled with their service(s); (iii) only one network slice can be used by the end-user. The 5G
delegation of almost complete network slice management to a network slicing by 3GPP splits slices into planes (user/control)
slice tenant (a vertical). and divides the control plane functions into common and
In this paper we propose a reference framework for network slice-specific [9]. Common control plane functions include
slicing, addressing such issues as slice related operations, slice selection, authentication and mobility management. A
management and orchestration in a single and multi-domain benefit of the common functions is the terminal’s ability to
environment. Our work is based on an exhaustive analysis of be attached to several slices simultaneously. The 5G Sys-
different network slicing approaches and relevant standardis- tem [10], [11] incorporates the New Radio (NR), which
ation efforts (§ II). We have tried to identify key commona- enables RAN slicing [12]. The 3GPP has started working
lities of different approaches as well as gaps. The features, on several standards documents which deal with 5G network
requirements and design assumptions that drive our vision are slice management [13], provisioning [14], selection [15] and
described in § III. § IV presents the overall architecture, § V security [16]. Recently finalized 3GPP studies, [17], [18]
focuses on operations, management and orchestration issues and [19], address network slice management and orchestration.
in single domain sliced networks and § VI depicts extensions In the 5G PPP research program, several projects focus on
related to multi-domain slicing. § VII concludes the paper. network slicing. They commonly use NFV and SDN tech-
nologies. The 5G PPP project 5G NORMA II [20] proposes a
II. R ELATED WORK mobile network architecture for the multi-tenant environment.
In the NGMN approach [4], a Network Slice Instance (NSI) NORMA assumes that some control plane functions should be
is built over physical or logical resources (computation, storage common for multiple slices. The 5GEx project [21] focuses
and transport) that are fully or partially isolated from other on transport networks only. It targets multi-domain slicing by
resources. The NSI is built using Network Functions and is extending the ETSI NFV MANO framework towards cross-
a complete, instantiated logical network that meets certain domain orchestration and management.
characteristics as required by a Service Instance(s). The NSI
can be composed of many Sub-network Instances (SNIs) that III. R EQUIREMENTS AND DESIGN ASSUMPTIONS
This work has been realized in the framework of the EU-Japan project To make the network slicing framework generic as well
5G!Pagoda under grant agreement 723172. as compatible with other approaches we have selected the
978-1-5386-3416-5/18/$31.00 c 2018 IEEE following requirements that it has to fulfill:
• Slice isolation. Slice isolation may be full or partial, logi- Customers portal

cal or physical [4]. Limited isolation capabilities of some Global OSS/BSS operator
Global OSS/BSS
solutions cause the relaxed isolation requirements. Isolation NFVO

concerns both slice resources and slice oriented operations Slice #1

(including management and orchestration). Slice Sliced
Slice
Operations
• Slice creation rights. The orchestrator operator, 3rd parties Slice #1 Manager Network
Support
tenant
or end-users should be able to create a slice.
VNFM
• Support for per-plane slicing. Per plane slicing should be Slice #n
Slice #n
Slice
supported. In some cases, it is an implementation con- tenant Slice Sliced
Operations
Manager Network
straint, whereas keeping some functions as common (e.g. Support

authentication, handover) is reasonable and can make slices

lightweight and faster to provision. NFVI VIM

• Mapping of services to slices. Slices should support single

or multiple services. In the latter case, the service instance Fig. 1. System architecture in a single orchestration domain
lifetime management should be separated from slice lifetime
(SM) performs slice management. The SM allows for slice
management.
management by its tenant.
• Sub-slices. A slice can be created as a combination of
existing or on-demand created sub-slices. A. The Sliced Network
• Multi-domain slicing. Slices should cross technological or Each Sliced Network is composed of data, control and
administrative domain borders. For that purpose, the slice application planes (see Fig. 2) that realise the same functions
should be composed of sub-slices. as in the non-sliced case (e.g. EPC). Such split provides high
• Slice provisioning time. Some on-demand created slices may flexibility of slicing by enabling independent slicing at each
require short provisioning time. plane level. Moreover, it provides compatibility with existing
• 3GPP compatibility. Compliance with 3GPP slicing app- approaches, like (e)DÉCOR.
roaches (dedicated slices selection mechanisms, not sliced
RAN of (e)DÉCOR, common control plane functions of the Slice (or Sub-slice)
5G Core) is required. Sliced Network

Slice Operations
Slice Manager
• Legacy solutions inclusion. Legacy mobile networks will Application Plane

Support
coexist with 5G networks. Incorporation of migrated legacy
Control Plane
systems in the overall picture is highly desirable.
• Grouping of slices. A group of service-oriented slices can Data Plane
be, e.g., used by the MVNO. The grouping should impact
the access rights to slices (no additional authentication, etc.).
• Slice management rights. The slice operator/owner (3rd Fig. 2. Slice or sub-slice generic structure
party) should have management capabilities that include: The approach allows for sharing of functions of a specific
policy-based management, configuration, security opera- plane by several or all slices of the domain, whereas other
tions, accounting and performance monitoring. planes can be fully based on slice-dedicated functions. We
• Management scalability. As the number of possible slices have decided to group the shared/common functions into
can be high, management operations should be automated as a single domain sub-slice called Common Sub-Slice (CSS)
much as possible, and slice management should be scalable. and group the functions that are dedicated for a specific
goal into the Dedicated Sub-Slice(s) (DSS). The DSSes can
IV. T HE OVERALL ARCHITECTURE access CSSes services through the CSS APIs. Both sub-
The proposed approach for a single orchestration domain is slices “stitched vertically” form a single Dedicated Slice. It
presented in Fig. 1. The overall management and orchestration is expected that in a single domain there will be a single CSS
of slices are distributed into several functional blocks. The and multiple DSSes. An example of a slice composed of CSS
Global OSS/BSS is a logically centralised entity that drives the and a single DSS is presented in Fig. 3.
behaviour of the entire system. The NFV MANO compliant The CSS is generally optional, but in some cases its
orchestration is used in the concept without modifications, existence may be enforced by system limitations, whereas in
following the arguments presented in [5]. other cases it is a solution of choice. For example, there is
A slice (or a sub-slice) in our concept is composed of no way to avoid CSS in legacy solutions, and the use of the
three groups of functions. The first group, Sliced Network CSS to handle mobility and authentication of users attached
(SN), is the same set of functions of the non-sliced network. to several DSSes is reasonable. The life-cycles of CSS and
The second group, Slice Operations Support (SOS), supports DSSes are separated – from the DSS point of view, the CSS is
operations related to slice selection, subscription, user authen- a permanent slice. As CSS functions are used, the DSSes may
tication, and stitching of sub-slices of different domains to have a smaller footprint and can be provisioned faster, what
obtain the end-to-end slice. The third group, Slice Manager is of premium importance for on-demand created slices. The
 Single
Dedicated Sub-slice
be found. It should be also possible to create the on demand
Domain Application Plane
Slice slice. In the latter case, the default slice should provide the

Slice Operations
basic communication and services until the requested slice

Slice Manager
Dedicated Control Plane

Support
is created. Existing legacy, non-sliced systems, e.g. the LTE
Data Plane
network, can be nicely used as a default slice. Their use in the
described way allows for graceful migration from non-sliced
to sliced solutions.
Common Sub-slice
API

Dedicated Sub-slice #1

Slice Operations
Slice Manager

Common Control Plane Slice Operations Support

Support
Slice Selection
Function

Sliced Network
Slice Manager
Subscription &
Authentication
Common Sub-slice
Inter-Domain
Operation Slice Operations Support
Local Slice
Support Repository
Fig. 3. Common and Dedicated Sub-slices concatenation (example)

Slice Selection

Subscription &
Authentication
Sliced Network
Slice Manager

Function
CSS can be used for the definition of the common, lightweight Dedicated Sub-slice #2
LSR #1
control plane with functions can be exploited by the dedicated Slice Operations Support
slices. The set of CSS functions should not be fixed and it Slice Selection
Function

Sliced Network
LSR #2 Inter-Domain

Slice Manager
should be possible to add new functions to the running CSS. Operation
Subscription & Global Slice
A combination of CSS and DSS can also be seen as a new Authentication Repository Support

CSS sub-slice. That way the concept of CSS-DSS combination Inter-Domain

Operation Local Slice
can become recursive. It has to be noted that in contrast to Support Repository
3GPP [17] we do not allow for the existence of individual
network functions that are shared between several DSSes. The
reason is an additional complexity of the management of such Fig. 4. Functional entities of the Slice Operations Support and relationships
between Slice Repositories of CSS and DSSes (example)
individual functions. The proposed solution is to merge such
individual, new functions with the existing CSS. Fig. 4 presents an example of slice selection functionality
There is no doubt that the existence of common functions of SOS split between CSS and DSSes. Initial slice selection
(i.e. CSS) also raises some problems. The limitations of is performed by the CSS Slice Selection Function (SSF) that
CSS services can negatively impact the overall functionality is combined with a Global Slice Repository (GSR). Each
and flexibility of a CSS/DSS slice. Moreover, the separation DSS may have a local, optionally modified copy of GSR, the
between DSSes is also reduced due to the use of CSS. Local Slice Repository (LSR). Slice selection scalability and
reliability justify the existence of SSF and LSR as a part of
B. Slice Operations Support
DSS. Moreover, the LSR may have a subset of GSR slices
A multi-slice environment requires a set of operations not only, e.g. only the slices that are operated by the same tenant
present in non-sliced networks. From the user perspective, (cf. MVNO).
these operations should include network slice discovery, selec- The multi-domain slicing requires a set of operations that
tion, subscription and authentication. Slice chaining (creation support the exchange of information between the slices of
of the end-to-end slice from “horizontally” stitched sub-slices) neighbouring domains to provide the end-to-end activity. Such
also requires mechanisms like exposing the abstracted view functionality is placed in the Inter-Domain Operations Support
of a single domain slice to other domains and supporting (IDOS) block of SOS (Fig. 4). It provides exposure of a slice
inter-slice operations. These functionalities are grouped within to the neighbouring domains (e.g. topology abstraction) and
the Slice Operations Support (SOS) block, deployed together supports protocols that enable information exchange between
with the Sliced Network by enhancing its Blueprint by SOS the domains. More details about SOS functionality in the
functions. These enhancements should be tailored to the needs multi-domain environment will be provided in Section VI.
of the horizontally or vertically stitched sub-slices.
The detailed definition of the slice selection mechanism that C. Slice Manager
has to be combined with the slice description scheme (a part The Slice Manager (SM) is an element of a slice or sub-slice
of SOS) is out of the scope of this paper. However, several acting as its management entity (see Fig. 2). It is only a part
options should be supported. For example, slice selection of the overall management system, cooperating with the main
can be hard-coded (e.g. in case of IoT devices), done in a management platform – the Global OSS/BSS, which plays
way completely agnostic to the end-user by the network, or the master role in the overall management and orchestration
based on a negotiation process between the network and the picture (cf. Fig. 1).
end-user. The latter may include end-user preferences (price, Two reasons justify the inclusion of the SM into a slice.
performance, etc.). Moreover, there should exist a “default” The first one is scalability–the management of multiple, func-
slice to be used if a proper match of a dedicated slice cannot tionally isolated slices by a single management system is
not scalable and raises problems related to the separation of A. Single domain slice related operations
management operations between slices. The second is business For the single orchestration domain, the operations provided
oriented. It is commonly assumed that slices will be tailored to by SOS have already been described in § IV. In such case, the
the needs of specific services that can be offered by 3rd parties IDOS entity of SOS does not need to be implemented.
(verticals), being slice tenants. Each tenant should have some
management capabilities to operate its slice(s) efficiently. B. Single domain management and orchestration
The SM plays the role of the management plane of the Single domain slice management and orchestration is shown
Sliced Network, but it is slightly different from the manage- in Fig. 6. The management is split between SMs and the
ment plane of the non-sliced networking solution. The slice Global OSS/BSS. The role of the SM in case of a single
tenant (typically not a professional operator) obtains with the domain has been already described. The Global OSS/BSS acts
SM a simple and comfortable management of the slice via a as a master and also drives the MANO compliant orchestra-
dedicated interface. Moreover, the SM handles slice (or sub- tion. The first group of Global OSS/BSS functions includes
slice) faults and performance. Tenants request creation of a
slice via the Global OSS Tenants Portal (see Fig. 6), but then Global OSS/BSS functional entities (single domain)

they use SM for most slice oriented operations, except those Generic e-TOM Single Domain OSS
functions Slice Domain NFVO NFVO
that are related to slice life-cycle management and accounting. Configurator Manager Support Domain
Global OSS
Operator Portal Dedicated
Slice Manager Dedicated Common Common
Tenant Oriented Functions Slice #1
Support Slice #n Slice Sub-slice
Embedded Management Global OSS
Slice Configuration Support Support Support Manager
Functions Tenants Portal
Global OSS Support
Slice Tenant Portal
Dedicated Dedicated
Legacy Systems Sub-slice #1 ... Sub-slice #n
Slice KPI Monitoring and Reporting Management Support Manager Manager

Accounting Autonomic Management Fig. 6. Management and orchestration architecture in case of single orches-
tration domain

Fig. 5. Functional entities of Slice Manager

generic eTOM functions and portals for orchestrator operator
and tenants. The tenants use the Global OSS Tenants Portal
The internal architecture of the SM is shown in Fig. 5. The (see Fig. 6) for requesting slice creation and termination, and
SM is composed of the Tenant Oriented Functions and the for accessing current and historical data related to the slice.
Embedded Management Functions (EMF). Tenant operations The second group of Global OSS/BSS functions (Single
are performed via the Slice Tenant Portal with the involvement Domain OSS) drives MANO orchestration of slices and pro-
of the Slice Configuration Support entity and enable modifica- vides a single domain slice management and orchestration.
tion of slice runtime policies, configurations of slice services The Slice Configurator analyses slice requests, blueprints as
and subscriptions of users. The Slice KPI Monitoring and well as users’ and operators’ policies. In cooperation with the
Reporting entity provides the tenant information about its slice NFVO Support entity, which keeps the catalogue of network
health and usage, and with a combination of the Accounting slices, it creates the Network Slice Description that will be
component allows for charging of slice users. Accounting used by the NFVO for slice deployment. At the same time, the
information is additionally stored in the Global OSS/BSS, Slice Support entity is created, which handles the cooperation
because the SM of a slice disappears on slice termination. with this slice’s SM. The Domain Manager keeps information
To make slice management lightweight and comfortable, about all resources available in the domain, their usage, their
most of the tenant’s management operations (i.e. EMF) should allocation to slices, as well as overall information about alerts,
be automated, providing the overall management system scal- etc. It can also do the arbitrage of resource allocation to slices
ability and short response time for events, alerts, etc. For based on their priorities. The Common Slice Support may
that purpose, the use of the cognitive [22] or autonomic [23] include legacy (i.e. hardware-based) management systems if
network management paradigms is expected. If legacy systems they are not implemented as an SM part of the CSS.
with their own management are used, the EMF should include As already stated, we use the ETSI MANO as it is. However,
support for legacy management functions. MANO orchestration scalability can be also a problem. This
can be partly solved by using multiple VNFMs and NFVOs.
V. O PERATIONS , M ANAGEMENT AND O RCHESTRATION OF
The latter case requires the existence of multiple VIMs sharing
S LICES
the same infrastructure and dynamic allocation of resources
We first describe management and orchestration for the between them. This necessitates a modification of ETSI NFV
single orchestration domain case. We exclusively assume recommendations, which is outside the scope of this paper.
NFV MANO compliant orchestration. Thus, orchestration is
slice-agnostic, while slice management is slice (or sub-slice) VI. M ULTI - DOMAIN SLICING
specific. Some details about the scalability of the proposed A single orchestration domain’s slices, treated as sub-slices,
approach can be found in [24]. can be horizontally stitched to form an end-to-end slice. For
example, RAN and EPC in LTE networks can be stitched to VII. C ONCLUSIONS
form a complete mobile network. Additionally, the transport In this paper, a top-down approach to network slicing
domain (able also to serve as a backhaul) could be integrated. has been presented. We have defined our framework in a
The creation of multi-domain slices raises new issues related systematic way, according to the requirements presented in
to slice operations, management and orchestration. § III. As per our design, each slice has functions responsible
A. Multi-domain operations for slice operations and management. The slice management
component provides a dedicated management interface to slice
The horizontal stitching of several slices impacts the imple-
tenants. The slice operations support component supports slice
mentation of SOSes. It specifically concerns the slice selection
selection and multi-domain slicing. The proposed slice struc-
oriented operations and IDOS functional entities (both func-
ture is generic, allows for flexible, per plane slicing as well as
tions are a part of SOS). Slice selection capabilities should be
for horizontal or vertical slice stitching. Multi-domain slices
implemented in the “edge sub-slices” only. The IDOS entities
are defined as a concatenation of single domain slices, thus
act as inter-slice gateways that implement an exchange of the
avoiding multi-domain orchestration issues. However, even in
information between neighbouring domains to provide their
a single domain, the scalability of MANO orchestration can
efficient cooperation. In this context, IDOS should expose
be an issue, and this problem is yet to be solved.
an abstracted view of its domain as well as enable inter-
domain communication via supporting necessary protocols. An R EFERENCES
example of such functionality, however not labelled as slice [1] “Network Functions Virtualisation (NFV); Architectural Framework”,
level operations, can be found in [21]. The SOS configuration ETSI GS NFV 002, V1.2.1, Dec. 2014.
of each sub-slice (or single domain slice) should be done [2] “PlanetLab”, http://www.planet-lab.org/.
[3] “NGMN 5G White Paper”, NGMN Alliance, white paper, Feb. 2015.
during the multi-domain slice provisioning by each domain [4] “Description of Network Slicing Concept”, NGMN Alliance, Sep. 2016.
Slice Configurator (part of the Single Domain OSS). [5] B. Chatras, S. Tsang Kwong U, N. Bihannic, “NFV Enabling Network
Slicing for 5G”, in Proc. ICIN, 2017.
B. Multi-domain management and orchestration [6] A. Galis (ed.), S. Kukliński et al., Network Slicing - Revised Problem
The multi-domain management and orchestration is shown Statement (draft-galis-netslices-revised-problem-statement-03), Internet-
Draft, informational, Mar. 2018.
in Fig. 7. In comparison to the single-domain case, the Global [7] “Architecture enhancements for dedicated core networks; Stage 2”, 3GPP
OSS/BSS has now several Single Domain OSSes and two new TR 23.709, v13.0.0, Dec. 2014.
entities, namely Multi-Domain Slice Configurator (MDSC) and [8] “Enhancement of Dedicated Core Networks selection mechanism”, 3GPP
TR 23.711, v14.0.0, Sep. 2016.
Multi-Domain Manager (MDM). [9] “Study on architecture for next generation systems”, 3GPP TR 23.799,
v14.0.0, Dec. 2016.
Global OSS/BSS functional entities (multi-domain) [10] “System Architecture for the 5G System”, 3GPP TS 23.501, v15.0.0,
Dec. 2017.
Generic e-TOM
functions Single
NFVO [11] “Procedures for the 5G System”, 3GPP TS 23.502, v15.0.0, Dec. 2017.
Domain #1 [12] “NR; Overall description; Stage-2”, 3GPP TS 38.300, v15.0.0, Jan.
Multidomain Domain OSS
Global OSS Slice Domain #1 2018.
Operator Portal Configurator Single [13] “Management of network slicing in mobile networks; Concepts, use
...
Domain OSS cases and requirements”, 3GPP TS 28.530, v0.5.0, Feb. 2018.
NFVO
Global OSS Multidomain Domain #n
Domain #n [14] “Provisioning of network slicing for 5G networks and services”, 3GPP
Tenants Portal Manager
TS 28.531, v0.3.0, Feb. 2018.
[15] “5G System; Network Slice Selection Services; Stage 3”, 3GPP TS
Domain #1 Domain #n 29.531, v1.0.0, Mar. 2018.
Sub-slice Sub-slice
Managers Managers [16] “Study on security aspect of 5G network management slicing”, 3GPP
TR 33.811, v0.4.0, Jan. 2018.
[17] “Study on management and orchestration of network slicing for next
Fig. 7. Multi-domain management and orchestration architecture generation network”, 3GPP TR 28.801, v15.0.0, Jan. 2018.
[18] “Study on management and orchestration architecture of next generation
The MDSC translates the business requirements (described network and service”, 3GPP TR 28.800, v15.0.0, Jan. 2018.
in the sub-slice or slice blueprint) into technology-specific [19] “Study on management aspects of next generation network architecture
and features”, 3GPP TR 28.802, v15.0.0, Jan. 2018.
ones. Then, in cooperation with Slice Configurator of each [20] B. Sayadi et al., “SDN for 5G Mobile Networks: NORMA perspective”,
domain, it configures each domain SOS for proper inter- in Proc. CrownCom, 2016.
domain operations as described in the previous section. [21] R. Guerzoni et al., “Multi-domain Orchestration and Management of
Software Defined Infrastructures: a Bottom-Up Approach”, in Proc.
The MDM interacts with each Domain Manager to solve EuCNC, 2016.
multi-domain management issues. Such information exchange [22] http://www.cognet.5g-ppp.eu/.
could be beneficial for end-to-end optimisation. According to [23] “Generic Autonomic Network Architecture (An Architectural Reference
Model for Autonomic Networking, Cognitive Networking and Self-
the “domain oriented philosophy”, though, exchanging mana- Management)”, ETSI GS AFI 002, v1.1.1, Apr. 2013.
gement information between domains should be minimised. [24] S. Kukliński, L. Tomaszewski, “DASMO: A Scalable Approach to
In our concept, we have avoided a direct orchestration of Network Slices Management and Orchestration”, in Proc. 3rd IEEE/IFIP
5GMan (in conjunction with IEEE/IFIP NOMS), 2018.
multi-domain slices. Instead, we propose to create the end-
to-end slices as a chain of single domain slices that are
orchestrated by a single orchestrator. Therefore there are no
multi-domain orchestration issues.