SliceNet Control Plane for 5G Network Slicing in Evolving Future Networks

Full text

1
SliceNet Control Plane for 5G Network Slicing in
Evolving Future Networks
Luca Baldini4 , Qi Wang1, Jose Alcaraz Calero1, Maria Barros Weiss2, Anastasius Gavras2, Giacomo Bernini3, Pietro G. Giardina3 , Ciriaco
Angelo4, Xenofon Vasilakos5, Chia-Yu Chang5, Navid Nikaein5, Salvatore Spadaro6, Albert Pagès6, Fernando Agraz6, George Agapiou7,
Thuy Truong8, Konstantinos Koutsopoulos9, José Cabaça10,Ricardo Figueiredo11
1University of the West of Scotland, UK; 2Eurescom GmbH, Germany; 3Nextworks, Italy; 4Ericsson Telecomunicazioni, Italy; 5EURECOM,
France; 6Universitat Politècnica de Catalunya, Spain; 7OTE, Greece; 8Dell EMC, Ireland; 9Creative Systems Engineering, Greece; 10Altice
Labs, Portugal; 11RedZinc, Ireland
Abstract

— Future networks including the Fifth Generation (5G)
and beyond mobile networks shall manage, control and
orchestrate the new services for users especially vertical sectors,
thereby they shall maximize the potential of 5G infrastructures
and their services. Network slicing has emerged as a major new
networking paradigm for meeting the diverse requirements of
various vertical businesses in virtualized and softwarised 5G
networks. SliceNet is a project of the EU 5G Infrastructure
Public Private Partnership (5G PPP) and focuses on network
slicing as a cornerstone technology in 5G networks. This article
describes how the SliceNet Control Plane shall evolve to meet the
end-to-end needs of many different vertical businesses. SliceNet
Control Plane shall span across multiple administrative domains,
by integrating different technologies in each involved segments
(RAN, MEC, CN, inter-connectivity). Moreover, SliceNet Control
Plane is able to allow verticals to plug their own control logic on
top of provisioned slices and specialize their services
characteristics while optimizing the use of shared resources,
providing dynamic configuration, dynamic management,
resource isolation and scalability.
Index Terms

—network slicing; slice management; cognitive
network management; verticals; control plane; softwarization;
virtualization

.
I. INTRODUCTION
The Fifth Generation (5G) and beyond mobile networks are
expected to meet the diverse service quality requirements from
different use cases of various vertical businesses. Typical use
cases of different classes of Quality of Service (QoS)
requirements can include enhanced Mobile Broadband
(eMBB), Ultra-Reliable and Low-Latency Communications
(uRLLC), and massive Machine Type Communications
(mMTC), as defined by ITU [1]. Towards achieving a
cost-efficient solution for supporting the different classes of
use cases in the same physical infrastructure, network slicing
has emerged as a most promising game changer in the
remarkable paradigm shift from the Fourth Generation (4G) to
the 5G era, being a crucial enabler for provisioning flexible
and tailored services in software-networking based 5G
networks. Network Function Virtualization (NFV) and
Software-Defined Networking (SDN) are two key enabling
technologies and principles for softwarisation in 5G networks,
especially 5G network slicing.
Despite the importance of network slicing in 5G networks
and beyond, there is no standardised solution yet for achieving
end-to-end (E2E) network slicing, especially across multiple
administrative domains. Moreover, QoS support for truly
QoS-aware network slicing is still largely missing in existing
work, and Quality of Experience (QoE) support for slice-based
services has not been considered sufficiently either. In
addition, the evolving nature of mobile networks calls for a
novel network slicing framework that is compatible with both
existing and emerging networks including 4G, 5G and beyond
networks.
In light of the above gaps and challenges, SliceNet, a
project of the EU 5G Infrastructure Public Private Partnership
(5G PPP), has recently defined an innovative architecture for
network slicing of 5G and beyond networks. One of the main
project objectives is to achieve multi-domain E2E network
slicing with controllable QoS/QoE optimisation capabilities.
This paper focuses on the SliceNet Control Plane (CP)
framework as a fundamental enabler of the SliceNet
architecture. This novel SliceNet CP framework has
advantageous architectural features and components to enable
a set of essential or value-added capabilities for network
slicing control including Plug and Play (P&P) control for
vertical users, QoS support, QoE optimisation, SDN-style
network segment controllers, adapters and so on, and ensures
high extensibility, compatibility, adaptability, and scalability
to meet the requirements of evolving future networks in
network slicing.
The reminder of the paper is structured as follows. Section
II describes the SliceNet CP requirements to achieve the
desired characteristics for the future sliced 5G network.
Section III presents the SliceNet CP architecture addressing
how the architecture can fulfill the identified requirements.
Subsections III.A, B and C provide an insight on the SliceNet
CP main architectural principles, namely, P&P Control, Slice
QoE optimization and Network Segment Controllers. Section
IV reviews the project’s technical approaches to achieve
advances beyond the state of the art. The paper is concluded in
Section V, which also provides a perspective of ongoing and

2
future work for SliceNet CP.
II. FUTURE (5G) NETWORKS REQUIREMENTS
One of the main challenges with 5G network requirements
is that there are many different vertical businesses, each one
requiring their own E2E needs to be met by future/5G
networks, e.g., video streaming sector requires very high data
rates with low latency while Internet of Things (IoT) sector
requires low data rate and long battery life times, etc.. These
conflicting functional requirements lead to the fact that not all
of them can be satisfied by one technology/domain and thus
anticipate the future system to enable a number of different
technologies to operate together, each meeting a set of needs.
Coordination across multiple domains is required to render an
E2E slice to the verticals, with guaranteed ubiquitous
experience for end-users. In this respect, the future system is
anticipated to provide a set of capabilities that can offer
tailored and optimized services with guaranteed measures for
different vertical businesses. Also, as the number of service
types grows, the system should be able to support scalability
and, possibly, automation at scale to ease the complexity and
operability for the operators. Therefore, 5G networks have to
be designed to support the traditional operator model, but at
the same time be flexible and scalable to support a shared
infrastructure model and a CP on top of existing CP to support
abstractions that need to be exposed to upper layers.
In 5G network slicing, a service model might involve the
participation of multiple domains, in which two or more
Network Service Providers (NSPs) or Service Providers (SPs)
are associated in the delivery of E2E slices to meet different
vertical sectors. To this end, SliceNet CP has been designed to
operate on top of an infrastructure spanning across multiple
administrative domains, integrating different technologies in
each involved segments (Radio Access Network (RAN),
Mobile Edge Computing (MEC), Core Network (CN) and
Wide Area Network (WAN) for inter-connectivity between
domains). Also, softwarisation and virtualization with
resource isolation overlay on top of shared physical resources
is the key to create many different logic networks (network
slices), each with a set of different network characteristics,
designed for different vertical sectors. In this respect, SliceNet
CP must be able to support optimization in the use of shared
resources with guaranteed measures for all verticals. As
SliceNet also aims to provide a truly customized environment
for offering vertical runtime control and operation of their E2E
slice instances, dynamic configuration and dynamic
management are required in SliceNet CP to offer
vertical-tailored services and enable a high degree of slice
customization, allowing verticals to plug their own control
logics on top of provisioned slices and specialize their
services.
The adoption of technologies such as NFV and SDN are
driving the wider utilisation of practices such as control and
data plane separation as well as workflow and process
automation. Consequently, future network architectures
necessitate the introduction of novel practices able to support
forward compatibility with respect to easier and faster
integration of new features and functionalities. In this respect,
the required agility depends among others on the ability of the
infrastructures to support the dynamic inclusion of functional
elements that are made available after the initial platform
setup. This seamless integration scheme requires that high
level control and management procedures remain agnostic of
the particular technology implementations available in each
domain of the managed infrastructure and the related
workflows are defined on the basis of abstract, mission
specific intents that are enforced in a common way towards
each domain, leaving the fine grained processing and actual
enforcement to be adapted and utilised accordingly by the
currently active functional resources. E2E network slicing is
one of the key capabilities of SliceNet as it enables multiple
logical networks to be created on top of a common physical
infrastructure.
III. SliceNet Control Plane Architecture
In this section, the overall SliceNet CP is presented first
with the design principles, building blocks and architecture
introduced, and subsequently selected key components are
described in more details.
A. High-level control plane architecture
Aiming at adequately and effectively coping with the
challenges posed by slicing practices tailored to the diversity
of vertical needs such as resilience, security, service continuity
as well as fast provisioning, SliceNet CP is based on the
realisation of a Service Based Architecture (SBA) that is quite
aligned with the concepts being exercised by Next Generation
Mobile Networks (NGMN) and 3rd Generation Partnership
Project (3GPP). With continuous evolution as a driving aspect,
the SBA allows for dynamic expansion of the managed
architecture since pillar adaptors can be onboarded and
registered to automate utilization of newly added pillar
implementations. Equally, SBA allows several instances of the
same implementation to be deployed in different slices as
dictated by management practices. The inclusion of new
function or resource instances via SBA registration and
discovery scheme is enabling scalability both in terms of the
number of resources allocated but also in terms of topology
rearrangements aiming at effectiveness and optimisation.
SliceNet CP is challenged by the diversity of technologies
that can be potentially utilised for the provision of E2E slicing.
This diversity is occurring along two main axes. On the one
hand, it is the roadmap with respect to the development of the
emerging and future mobile networks specifications and
implementation availability, i.e. evolution of 5G systems,
enhancements of 4G systems, coexistence of new and old

3
RAN and CN. On the other hand, it is the availability of the
enabling technologies that are utilised for building the network
infrastructures. In order to efficiently cope with these
challenges, SliceNet has designed a CP architecture around the
following principles:
●Infrastructures can span across different Points of
Presence (PoPs).
●Infrastructure segments based on their roles in the
overall operation are identified as pillars providing
RAN, MEC, Backhaul, CN and WAN functions.
●Each pillar functions may be implemented by
different technologies (or vendors).
●All implementations for a pillar are providing
functionalities from a common set with a minimum
subset being mandatory to allow basic integration.
●The same pillar may consist of several instances of
the same or different implementations in parallel.
●Each implementation requires an adapter that at its
southbound interface (SBI) supports the interaction with
specific technology/implementation details whereas provides a
northbound interface (NBI) according to the model of the
common set of functionalities.
The set of adapters provides the first level of abstraction
over the pillar functionalities. The functionalities exposed by
the different pillars are integrated and exploited in the context
of SliceNet CP Services exposing technology agnostic Slice
APIs as shown in Figure 1.
Figure 1 SliceNet Control Plane Architecture
Each CP Service offers a different and specific configuration
as well as different control capabilities.
1) CPSR

: The Control Plane Service Register (CPSR) is the
software component which allows other CP services to
register themselves as a service instance in the SBA
framework as well as providing authorization and discovery
services capabilities. Other service consumers such as
Plug&Play or any other authorized SliceNet component can
use any specific CP Service by querying to the CPRS for its
reachability.
2) NF Config

: The NF Config is in charge of the dynamic
configuration of the slice Network Functions playing thus, a
key role in the initial and run time configuration of the slices.
3) QoS Control

: The QoS Control is responsible of deploying
Quality of Service constraints to the different network
segments depending on the input parameters gathered from
the exposed interfaces.
4) IPC Control

: The InterPoP Connections (IPC) is the
responsible, for each slice instance, to deliver a proper
inter-connection of the slice Network Functions (i.e
mostly VNF and MEC applications) deployed in different
segments and domains, namely edge (e.g MEC) and Core
ones.
The arrangement of functionalities into blocks formulates a
Slice Technology/Implementation Agnostic Application
Programmable Interface (API) which is the set of SliceNet
configuration endpoints.

4
This API provides the control context of a slice.
Finally, the SliceNet CP API abstractions and the SBA
approach are enablers with respect to slice isolation, as
realised via the control and data plane virtualized functions,
due to the fact that they allow high level management
decisions to be uniformly enforced over an heterogeneous set
of function implementations and the dynamic life cycle of
their instances.
In the following subsections, selected key architectural
components are elaborated in more details.
B. Plug & Play Control
With 5G, verticals will require more and more tailored and
specialized services, therefore providing them truly
customized runtime control, management and operation of
E2E slice instances will be key. In this context, the P&P
control is one of the key enablers of slice customization, as it
aims to offer a novel combination of tailored control
functions, APIs and tools to enable to specialize their slice
instances according to their unique needs and allow them to
even plug their own control logics when required. The
ultimate goal is to provide an innovative control environment,
dedicated per slice, which offers to the verticals, and in
general to slice consumers, significantly enhanced degree of
flexibility for deploying services to the end users.
The P&P control functions are conceived to be activated for
the runtime operation of slice instances, as a way to expose
per-slice instance dedicated and vertical customized control
features and capabilities. The P&P control, at least in its
concept, has to be considered as agnostic of the specific
provider-to-consumer interaction. This way it can be applied
to any “slice provider-to-vertical” or “slice provider-to-slice
provider” case in support of either single-domain or
multi-domain E2E slices. This way, P&P control functions can
be exposed to verticals for their customized slices operation,
and to other customers in general (like other slice providers) in
the context of E2E slices spanning across multiple
administrative domains.
The P&P control logically lays on top of the heterogeneous
infrastructure composed by the integration of 5G RAN, MEC
and CN network segments, including where applicable the
vertical enterprise segments, providing those per-slice
customization functions needed to accommodate vertical´s
requirements. The main goal of the P&P control is therefore to
offer verticals with an isolated control environment, specific
per slice instance that can be activated on-demand when new
E2E slice instances are provisioned. The idea is that each P&P
control instance can have access to a limited set of slice
control and management primitives, strictly depending on the
P&P requirements specified by the vertical and included in the
slice templates and descriptors, offering a specific
vertical-tailored level of slice control exposure. Moreover, to
guarantee isolation, each P&P instance has controlled access
(either direct or indirect) to those physical and virtual network
functions (e.g. for configuration purposes) owned and used by
the given slice instance for which it is activated, as a way to
restrict and limit the allowed operations exposed to verticals.
Following the CP principles defined above, the P&P
implements the second level of abstraction oriented to expose
to the verticals a simplified view of E2E slice instances. On
the one hand it can be aligned and compliant with each
vertical logic and needs, and on the other it hides and further
abstracts the slice technology agnostic APIs according to the
agreements with the slice provider in terms of control
exposure. Moreover, the P&P follows the described SBA
approach, and therefore each P&P control instance can be
considered as a dedicated per-slice CP service exploiting the
slice technology agnostic APIs. It provides specialized
per-slice control exposure capabilities, which are loosely
coupled to other CP services (i.e. either other P&P control
instances dedicated to other slices or other control plane
services) and deployed on-demand through independent
management workflows.
Each P&P instance is an independent logical run-time
component which has access to multiple control and
management logics and APIs by means of dedicated drivers
and plugins, each with specific hooks to monitoring, runtime
control and orchestration platform primitives. The restriction
and selection of the tailored subset of these primitives is
performed by P&P management features during the activation
phase. Dedicated P&P management functions in the
management plane are responsible for each P&P control
instance lifecycle management (activation, plug of specific
tailored drivers, configuration of proper abstraction features,
deactivation).
Figure 2 P&P control instance high-level decomposition
Figure 2 presents the functional decomposition of a P&P
control instance, which follows a layered approach built by
three main high level components and targeting an high degree
of flexibility and customization in creating customized views
of slice instances for the verticals. In particular, the P&P is
built around a generic, common and technology agnostic slice
information model to be specialized in the context of each

5
E2E slice (thus for each P&P instance) according to vertical
needs and control exposure level. This generic slice model has
to be considered as a kind of topology-like abstract view of a
slice. Its specialization provides the customized view of the
slice instance for a given vertical, based on the provisioning of
a specific slice-context to each element in the slice view,
together with allowed control operations for each of them. In
particular, the technology independent information model
proposed in an IETF Common Operations and Management
on network Slices Internet-Draft (COMS I-D) [2] is
considered as reference to model properties, attributes and
operations on each slice entity. The three main components of
the P&P control instance can be briefly described as follows:
●Pluggable plugins and drivers

: it includes the set of
plugins and drivers that provide the required adaptation
between the P&P generic slice model and the monitoring,
control plane and orchestration framework primitives.
These are pluggable modules providing access to specific
control and management logics, and P&P driver exposes
its capabilities to the abstraction layer to enable its
dynamic pluggability and usage by the P&P logics.
●Abstraction and slice-specific model

: it provides the
specialization of the generic slice information model into
the customized vertical view of a given E2E slice instance.
The slice-specific model produced implements an
abstracted and vertical friendly view enabling the second
level of abstraction.
●Vertical oriented APIs

: they implement the set of control
and management APIs that are exposed to the vertical,
offering tailored control operations over the slice-specific
model and view, following the slice control exposure level
agreed by slice consumer and slice provider and described
as part of the slice template or descriptor.
C. Slice Quality of Experience Optimization
QoE guarantees when provisioning services is one of the
focal aspects of future 5G networks. To properly address such
requirement, a key feature of SliceNet CP is the
QoE/QoS-driven slice provisioning tailored to the specific
needs of the slice customers and applications/services running
on top. The Slice QoE Optimizer module is the responsible of
such task. The scope of such module is to maintain the
required slice QoE levels over the time and under dynamic
conditions, triggering necessary (re-)configuration actions at
the infrastructure level, both virtual and physical.
In this regard, the Slice QoE Optimizer provides a per-slice
optimization framework in which performance metrics at
multiple layers are collected to derive QoS metrics of the slice.
Then, such metrics are employed to determine current QoE
levels. A decision-making engine analyses if the monitored
levels are satisfactory or not and, if needed, the most optimal
actions to be taken to re-establish desired quality levels.
Actions are carried out through an actuation system which
interacts with core CP functionalities through the Technology
Agnostic APIs layer to request actions at specific
infrastructure segments onto which the slice is realized or the
modification/re-configuration of PNF and/or VNF instances.
These specific actions to re-configure the underlying
infrastructure level (physical and/or virtual) are enforced by
core CP functionalities through the specific segment
controllers.
From a design perspective, the Slice QoE Optimizer is based
on two main principles. First, Machine Learning (ML)
techniques are employed for QoE analysis and derivation.
Particularly, ML models specially adapted to the type of
services that current instance is materializing (e.g. uRLLC,
mMTC) are employed to learn the relationship between
monitored QoS metrics and QoE ones. These ML models are
constructed thanks to the analysis of past experience and data.
Then, during slice runtime, the slice model is employed to
determine QoE levels from the monitored information. The
executed model may be adapted given current insights to
reflect in the most reliable way how QoE is determined.
Second, actuation to optimise QoE leverages on a
policy-based system for resource configuration. Policies that
dictate resource configuration for both system-wide and
slice-specific items are generated and then distributed across
policy decision points (PDP) and policy execution points
(PEP), being the Slice QoE Optimizer a PDP and PEP at the
same time. Once QoE metrics are determined, and given
monitored QoS metrics at the different segments composing
the slice, the Slice QoE Optimizer analyses current active
policies and determines which ones should be applied. The
selected policies will mandate the imperative actions to be
carried out, which will be executed through the actuation
system abovementioned.
Figure 3 Slice QoE Optimizer instance high-level
decomposition
Given these design principles, Figure 3 exemplifies the
structure of a Slice QoE Optimizer instance, providing a
high-level functional decomposition. As said before, QoE
optimization is conceived in the form of a per-slice
optimization framework, meaning that, for each provisioned
slice, an instance of the Slice QoE Optimizer is also being
provisioned to deal with the QoE maintenance/optimization
within the slice. Functionally, all Slice QoE Optimizer

6
instances have the same internal modules/functions, however,
they are particularized for the slice they are responsible of.
The core of a Slice QoE Optimizer is the Local Decision
Engine (LDE), which is the responsible to receive external
monitoring information with the actual QoE. This derivation is
made thanks to already trained ML models. The LDE also is
the responsible to decide when a (re-)configuration of
resources/functions is needed to meet desired quality levels.
Once such decision is taken (based on the monitored
information), possible actions are analysed from the Slice
Policies module, which acts as a PDP from upper layers, such
as management. It essentially contains a list of available
actuations, which take the form of complex sets of atomic
actions at slice or segment level to be carried when specific
events happen, such as an increase of packet loss or latency,
which may affect the QoE. Thus, the LDE also acts as a PEP,
fetching the available actions and selecting the one that must
be carried out. Both the LDE and Slice Policies may be
updated (e.g. QoE model, actuations list) through a set of
management actions and APIs. In the last step of the process,
the Actuator Coordinator is the responsible to instantiate/call
the different actuators provided the decisions taken at the
LDE. The different actuators are conceived as standalone
micro-services which encapsulate the list of actions and their
parameters to be carried out through core SliceNet CP
functionalities to trigger the desired (re-)configurations.
Finally, a Slice QoE Optimizer instance also provides the
capability to expose its functionalities for exploitation by the
vertical user through the P&P instance of the slice, following
the plugin approach explained in previous section. The P&P
Rule Checker is employed to constrain the actions of the
vertical towards slice QoE optimization procedures, in order to
limit the impact on the resource configuration and the overall
system.
D. Network Segment Controllers
An SDN controller is envisioned to decouple processing
between the CP and the user plane as well as to control the
underlying network in a centralized manner. There are several
open source implementations for that purpose such as
OpenDayLight (ODL) and ONOS, which are designed for
networks of any size and for any network segments.
However, unlike other segments, the RAN segment control
must comply with hard real-time requirements. For instance,
the real-time scheduler in Long-Term Evolution (LTE)
networks has to respect the 8ms Hybrid Automatic Repeat
Request (HARQ) round trip time constraint, which is expected
to be more stringent for uRLLC in the 5G era due to a much
shorter transmission time interval.
In order to enable the SDN concept in the RAN segment for
the software-defined RAN (SD-RAN) vision in SliceNet, we
can apply a hierarchical scheme according to which control
functionalities can be distinguished between centralized and
distributed ones based on time-criticality and a requirement
(or not) for a centralized approach. To this end, FlexRAN [3]
realizes an SD-RAN platform and implements a customized
RAN south-bound API through which programmable control
logics can be enforced with different levels of centralization,
either by the controller or local RAN agent, as depicted in
Figure 4.
Figure 4 Disaggregated controller design for the RAN
segment
Figure 4 portrays three main components: (i) a centralized
controller entity; (ii) an edge entity, and (iii) a local RAN
agent. The local RAN agent is essentially a local controller
with a limited view of the RAN segment that it is delegated
with a control authority by an edge control entity. The latter
entity is responsible for a small network area (i.e., an edge),
being in charge of time-critical and/or small time-scale
operations in the order of milliseconds. Sitting on top of every
edge entity, lies a centralized coordination and control unit
(i.e., the centralized controller component of Figure 4) that is
responsible for a larger network area, taking soft real-time
decisions on a larger time-scale, e.g. in the order of some
hundreds of milliseconds. In addition, we note that FlexRAN
has evolved to support multiple agents among each
disaggregated RAN entity, so as to be controlled by a
centralized controller, following an evolution trend according
to which the RAN segment has departed away from being a
monolithic infrastructure (e.g., eNB of LTE) and moved
towards incorporating disaggregated entities (e.g., gNB-CU,
gNB-DU, RU of 5G) [4]. In a nutshell, such a RAN segment
controller can enable the deployment of versatile control
applications, as introduced in Section III-B, to enable the
(soft/hard) real-time or non-real-time control for QoE purpose
stated in Section III-C.
Finally, unlike the case of RAN segment controller in 5G,
the CN and the MEC segment controllers can follow the
common SDN centralized controller design principle and still
benefit from the real-time RAN information to adjust its
control logic. For instance, a radio-aware video content
optimization control application deployed at the MEC segment
can rely on the real-time per-user Channel Quality Indicator
(CQI) to adjust the video quality to maintain the QoE.
Optionally, there can be an overall controller entity sitting on
the top of a controller hierarchy that coordinates all segment

7
controllers, including the disaggregated/hierarchical controller
for the RAN segment and the CN segment with the purpose to
provide E2E controller functionalities, i.e., E2E network
slicing.
IV. COMPARISON WITH RELATED WORK
The proposed SliceNet CP provides a set of advanced
control functionalities for network slicing and offers an
architecturally innovative approach by introducing a novel
adaptive overlay layer, beyond the state of the art as explained
in the following aspects.
Firstly, the SliceNet approach leverages the benefits of
decoupling the CP from the data plane, following the generic
SDN principle especially in the Network Segment Controllers.
Numerous work related to SDN are existing especially in the
area of SDN controllers such as ODL [5], ONOS [6], and Ryu
[7]. However, none of them is specifically designed for the
purpose of network slicing control over 5G networks.
Meanwhile, the Open Networking Foundation (ONF) proposes
an SDN-based slice abstraction model [8], where an SDN
Client Context is considered equivalent to a network slice,
comprising a set of resources managed/controlled by an SDN
controller. More specific definition of this model, especially
on top of the 5G control plane, is yet to be proposed though.
Secondly, the proposed SliceNet CP comprises a set of
network slicing specific components that have not been
incorporated in other related 5G projects. In particular, the
QoE Optimiser and the P&P Control modules are novel and
advanced CP elements. For example, the SESAME project [9]
features a Service Level Agreement (SLA) Monitoring
component yet lacks the QoE optimisation control loop as in
SliceNet. The SELFNET [10] and CogNet [11] projects
emphasise autonomic/cognitive network management with
cognition loops although they do not target to deal with
cognitive QoE optimisation for network slicing. In addition,
the 5GNORMA project [12] focuses on intra- and inter-slice
control, the 5GEx project [13] considers multi-domain
network slicing, whilst traffic steering and resource allocation
techniques for network slicing are highlighted in the
COHERENT project [14]. Nevertheless, none of these projects
have integrated P&P control or QoE optimisation.
Thirdly, the proposed overlay layering approach is
decoupled from and thus fully compliant with the 5G standard
control and data planes. This assures higher interoperability
and wider applicability of the proposed architecture, in
contrast to more radical approaches that replace the existing
5G control plane with brand new ones. For instance, a new 5G
CP was proposed in [15], which assumes an all-SDN network
architecture.
Finally, it is noted that the proposed SliceNet CP operates
over the existing CP of 5G networks. This is in contrast to an
alternative approach that adds new components and interfaces
to the 5G CP directly or modifies existing standard 5G/4G CP
components or procedures directly such as the proposals in
[16], [17] and [18], respectively. The SliceNet architectural
design enables the control framework to extend the
functionalities of 5G CP to achieve network slicing without
compromising the modularity and standard compliance of the
existing 5G CP. Moreover, with the introduction of adapters
between the SliceNet CP and the underlying system, the
SliceNet framework enables the mobile networking
technology agnostic capability in terms of supporting the CP
of 5G and that of 4G and potentially additional variants,
thereby achieving backward compatibility.
To sum up, the SliceNet CP advances the state of the art in
enabling adaptive, advanced, standard-compliant and
interoperable network slicing architecture.
V. CONCLUSION
The network slicing paradigm in 5G and beyond networks
is expected to meet the diverging QoS/QoE requirements
imposed by a range of verticals’ use cases. The SliceNet
Control Plane proposed in this paper introduces a novel
overlay control framework for 5G and beyond network slicing.
The proposed framework is built on a Service-Based
Architecture, which allows high extensibility and scalability.
The overlay approach together with a set of adapters enables
its high adaptability and inclusiveness/compatibility regarding
existing and emerging networks in line with the evolving
nature of future networks. A set of control plane components
are proposed to achieve essential or value-added
functionalities for advanced QoS/QoE-optimised network
slicing with plug & play control capabilities exposed to the
vertical users, QoE optimisation capabilities for slice-based
services, and controllers based on the SDN principle to realise
the slicing in different network segments along the end-to-end
path, among others.
Ongoing research and development work are currently
focusing on prototyping the proposed control plane
components and the framework. Future work will then
integrate this control plane with the SliceNet infrastructure
including a programmable data plane to demonstrate the
QoS/QoE-optimised network slicing. Moreover, the
multi-domain network slicing scenario is being prototyped.

8
VI. ACKNOWLEDGMENT
This work has been funded in part through the European
Union’s H2020 program, under grant agreement No 761913:
project SliceNet. The authors would like to thank all SliceNet
partners for their support in this work.
www.slicenet.eu
VII. REFERENCES
[1] Recommendation ITU-R M.2083-0, IMT Vision – Framework
and overall objectives of the future development of IMT for
2020 and beyond, Sept. 2015.
[2] L. Qiang et al., “Technology Independent Information Model for
Network Slicing”, IETF COMS I-D,
draft-qiang-coms-netslicing-information-model-02, work in
progress.
[3] X. Foukas, N. Nikaein, M. Kassem, K. Kontovasilis, "FlexRAN:
A flexible and programmable platform for software-defined
radio access networks", 12th International on Conference on
emerging Networking EXperiments and Technologies
(CONEXT 2016), December 2016.
[4] 5G-PICTURE Project, [Online]. Available at
https://www.5g-picture-project.eu/
[5] OpenDaylight, [Online]. Available at
https://www.opendaylight.org
[6] ONOS, [Online]. Available at http://onosproject.org/
[7] Ryu, [Online]. Available at https://osrg.github.io/ryu/
[8] ONF TR-526, “Applying SDN Architecture to 5G Slicing,” Apr.
2016.
[9] SESAME Project, [Online]. Available at
http://www.sesame-h2020-5g-ppp.eu/
[10] SELFNET Project, [Online]. Available at https://selfnet-5g.eu/
[11] CogNet Project, [Online]. Available at
http://www.cognet.5g-ppp.eu/
[12] 5GNORMA Project, [Online]. Available at
https://5gnorma.5g-ppp.eu/
[13] 5GEx Project, [Online]. Available at http://www.5gex.eu/
[14] COHERENT Project, [Online]. Available at
http://www.ict-coherent.eu/
[15] V. Yazici, U. Kozat, and O. Sunay, “A New Control Plane for
5G Network Architecture with a Case Study on Unified
Handoff, Mobility, and Routing Management”, IEEE
Communications Magazine, Vol. 52, No. 11, pp. 76-85, Nov.
2014.
[16] A. Mohammadkhan, K. K. Ramakrishnan, A. S. Rajan, and
C. Maciocco, “CleanG: A Clean-Slate EPC Architecture and
Control Plane Protocol for Next Generation Cellular Networks”,
Proc. ACM Workshop on Cloud-Assisted Networking (CAN)
2016, Irvine, CA, USA, Dec. 2016.
[17] A. M. Nayak , P. Jha, and A. Karandikar, “A Centralized SDN
Architecture for the 5G Cellular Network”, Jan. 2018. [Online].
Available at
https://www.ee.iitb.ac.in/~karandi/publications/preprint/akshath
a_pranan_karandikar_ieee5gforum.pdf
[18] Y. Li, Z. Yuan, and C. Peng, “A Control-Plane Perspective on
Reducing Data Access Latency in LTE Networks”, Proc. 23rd
Annual International Conference on Mobile Computing and
Networking (MobiCom’17), Snowbird, UT, USA, Oct. 2017.