Received December 28, 2020, accepted January 4, 2021, date of publication January 8, 2021, date of current version January

20, 2021.
Digital Object Identifier 10.1109/ACCESS.2021.3050155

Cloud-Native Network Slicing Using Software

Defined Networking Based Multi-Access Edge
Computing: A Survey
SYED DANIAL ALI SHAH , MARK A. GREGORY , (Senior Member, IEEE),
AND SHUO LI , (Member, IEEE)
School of Engineering, RMIT University, Melbourne, VIC 3000, Australia
Corresponding author: Mark A. Gregory ([email protected])
This work was supported by Royal Melbourne Institute of Technology (RMIT) University Research Stipend Scholarship (RRSS).

ABSTRACT Fifth-Generation (5G) mobile cellular networks provide a promising platform for new,
innovative and diverse IoT applications, such as ultra-reliable and low latency communication, real-time
and dynamic data processing, intensive computation, and massive device connectivity. End-to-End (E2E)
network slicing candidates present a promising approach to resource allocation and distribution that permit
operators to flexibly provide scalable virtualized and dedicated logical networks over common physical
infrastructure. Though network slicing promises the provision of services on demand, many of its use
cases, such as self-driving cars and Google’s Stadia, would require the integration of a Multi-Access Edge
Computing (MEC) platform in 5G networks. Edge Computing is envisioned as one of the key drivers
for 5G and Sixth-Generation (6G) mobile cellular networks, but its role in network slicing remains to
be fully explored. We investigate MEC and network slicing for the provision of 5G service focused use
cases. Recently, changes to the cloud-native 5G core are a focus with MEC use cases providing network
scalability, elasticity, flexibility, and automation. A cloud-native microservices architecture, along with its
potential use cases for 5G network slicing, is envisioned. This paper also elaborates on the recent advances
made in enabling E2E network slicing, its enabling technologies, solutions, and current standardization
efforts. Finally, this paper identifies open research issues and challenges and provides possible solutions
and recommendations.

INDEX TERMS Network slicing, software defined networking, multi-access edge computing, cloud native,
ultra-reliable, and low latency communication.

I. INTRODUCTION require a massive number of connections, and therefore,

AS envisioned by the network operators, Fifth Generation high transit bandwidth will be needed for the aggregated
(5G) mobile cellular networking takes communications traffic. Mission-critical services such as autonomous vehi-
closer to the vision of the Internet of Everything (IoE) [1], [2]. cles, Vehicle-to-Vehicle (V2V) cooperative driving, remote
5G networks are envisioned to support not only the Internet of health monitoring, and industrial control will require
Things (IoT) but also the emerging vertical industries [2]. IoT Ultra-Reliable and Low Latency Communication (URLLC).
demands support for a diverse set of services such as smart The heterogeneous and diverse requirements for future smart
cities, eHealth, smart buildings, Internet of Vehicles (IoV), cities indicate that current network designs based on the
and so on. The rapid growth of IoT alone means that billions conventional approach of ‘‘one-size-fits-all’’ will no longer
of devices will be connected to the network over the next be appropriate and 5G network design should reflect the
decade. need for scalable and flexible network designs. 5G network
The requirements for IoT-enabled smart cities are diverse. architectures need to evolve to provide service diversity, guar-
Services, such as smart grids, intelligent traffic light anteed performance, and a short time to market to ensure
management, smart households, and smart agriculture, will that there is support for the deployment of new services,
resource allocation, reduced Capital Expenditure (CAPEX),
The associate editor coordinating the review of this manuscript and services automation, and convergence of fixed and mobile
approving it for publication was Noor Zaman . access.

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
VOLUME 9, 2021 10903
 S. D. A. Shah et al.: Cloud-Native Network Slicing Using SDN Based MEC: A Survey

TABLE 1. A list of commonly used acronyms in this paper.

The diversity and flexibility expectations for 5G networks Functions (VNFs). The VNFs are interconnected through
raises an important challenge to provide service flexibility well defined logical or virtual links to form fully-fledged NSI.
whilst enabling network technology diversity. To overcome Software Defined Networking (SDN) is also a key enabler
the challenges, End-To-End (E2E) network slicing is a poten- for E2E network slicing. It is a networking paradigm that sep-
tial key enabler technology that supports customized network arates the control and data planes. SDN controllers provide
services through provisioning of on demand Network Slice centralized management and a global network topology view
Instances (NSIs). that increases the efficiency of network traffic flow related
The network slicing concept emerged as a result of recent decision making. SDN supports flexible programmatic oper-
advancements in cloud computing and Network Function ation of the control plane, including rapid deployment of new
Virtualization (NFV). Network slicing is the slicing of phys- and updated network applications, traffic steering, mobility
ical network infrastructure resources into dedicated logical management for wireless mobile stations, and traffic rerout-
networks, thus facilitating vertical segmentation of networks, ing for congestion avoidance. It allows efficient connec-
services and applications [3]. The logical or dedicated net- tivity and traffic steering among different VNFs forming
works can be used to provision tailored solutions for distinct an NSI by providing dynamic service chaining [4]. SDN
service types and application scenarios. controllers maintain knowledge of the network topology by
NFV is a key enabling technology for 5G network slicing exchanging information with adjacent controllers and domain
as it permits the creation and instantiation of isolated or gateways.
partially shared NSIs by abstracting the virtual and phys- Network slicing, through its enabling technologies, e.g.,
ical infrastructure resources, and offering customized con- SDN/NFV, aims to satisfy new vertical use cases. It is envi-
figurations and policy to dedicated logical resources. The sioned that to provide new customized services on demand,
logical resources or networks are then assigned to a vertical the service providers need to automate the operations and
application, that may include providing Virtualized Network deployment of the 5G mobile core. The disaggregation of

10904 VOLUME 9, 2021

S. D. A. Shah et al.: Cloud-Native Network Slicing Using SDN Based MEC: A Survey

the 5G mobile core, i.e., Control and User Plane Separation • A preliminary evaluation was carried out of an
(CUPS), facilitates 5G use cases including Multi-Access envisioned cloud-native 5G architecture that supports
Edge Computing (MEC) and network slicing. The 5G network slice mobility and services migration across
use cases require that the 5G mobile core Network Func- cloud-native edge clouds deployed at different zonal
tions (NFs) be deployable in the core and at the Mobile Edge locations in southeast Australia.
(ME) utilizing private and public clouds. Service providers
will be able to realize new vertical solutions that achieve A. EXISTING WORKS
URLLC, Massive Machine Type Communication (mMTC), Network slicing has recently been the focus of different
and Enhanced Mobile Broadband (eMBB). The cloud-native standardization bodies, including 3GPP, ETSI, and ITU-T
5G core and its enabling technologies such as containers, [12]–[14]. This paper provides a detailed review of E2E net-
microservices, container orchestration engine, and Contin- work slicing considering both the single and multiple admin-
uous Integration and Deployment (CI/CD), will allow the 5G istrative and technology domains. This review covers the
mobile core to be fully automated, flexible and scalable. The recent progress made and provides the emerging technology
role of the cloud-native architecture in realizing MEC enabled vision for E2E network slicing, including the recently pro-
network slicing remains an area of current research. This posed 5G transport slice connectivity interface [15], the role
paper provides insights and use cases on how the cloud-native of MEC and the vision for the cloud-native 5G mobile core.
architecture and modern software development paradigms, There are a few related surveys available on the topic such
such as a microservice architecture can facilitate the 5G use as [5]–[7]. The authors in [7] present a detailed review
cases. and analysis on the topic of network slicing. However, they
Unlike the traditional client-server application develop- do not consider, in detail, enabling slice federation among
ment model, the emergence of MEC, which introduces an multiple administrative domains, new transport-layer mech-
intermediate entity at the network edge, results in a new anisms, MEC integration, and the cloud-native solutions for
three-layer application development model, e.g., client, near the automation of the 5G mobile core. In [9], authors present a
server and far server. This raises challenges for application detailed survey on 5G network slicing, including the architec-
developers, to identify the application features that require tures, recent advancements, and future challenges. However,
low-latency and real-time responses, so that those applica- unlike [9], our work focuses on the new challenges intro-
tion features can be deployed in the near server, i.e., edge, duced by the cloud-native transformation of 5G networks and
whereas the application features that do not demand real-time mobility management of MEC-enabled 5G networks. A brief
response and require high compute power can be deployed overview of the state of the art network architecture for 5G
at the far server, i.e., cloud. To deal with the challenges and network slicing is provided in [6], [16]. The work in [5] deals
adapt to this new application development paradigm, devel- with the resource allocation problem in network slices that
opers are adopting virtualization based application design, only takes into account network slicing across a single tech-
e.g., microservices and container based architectures. The nology domain, i.e., Radio Access Network (RAN) slicing.
recent white paper released by the ETSI MEC group [11] In [17], the authors proposed an on-demand RAN-slicing
emphasizes the importance of a microservices based cloud- approach that jointly considers both the network slicing and
native architecture for MEC. In this paper, a cloud-native 5G spectrum sharing to realize the spectrum-aware slicing across
microservices architecture for MEC enabled network slicing all the RAN resources. A cloud-native approach for net-
is envisioned. Its potential use cases in the context of MEC work slicing is introduced in [18], but the paper does not
enabled network slicing are also introduced. The main con- include a discussion of the latest key enabling technolo-
tribution of this article is summarized as follows: gies for the 5G cloud-native microservices architecture, e.g.,
• An in-depth and comprehensive review of recent dockers, containers, Kubernetes, and also the integration of
advances made in enabling E2E network slicing edge computing, one of the fundamental motivations for a
across multiple technologies and administrative 5G cloud-native architecture. The authors in [19] consider
domains. the transport network architecture based on SDN/NFV. Other
• The role of MEC, as one of the key drivers of 5G and relevant articles related to network slicing and its enablers,
6G, is explored. Potential use cases considering network i.e., SDN/NFV, [20]–[24] also, do not consider the latest
slicing are discussed. trends and progress made in this field. Table 2 indicates a
• The cloud-native 5G core and its design principles are summary and comparison of the recent related survey papers
investigated. on 5G network slicing.
• We described the limitations of the traditional network
virtualization techniques used to create network slices. B. RELATED APPROACHES TO NETWORK SLICING
A cloud-native 5G microservices architecture is envi- Techniques and solutions similar to the virtualized 5G core
sioned along with its potential use cases in supporting were proposed for 4G, including Dedicated Core (DECOR),
MEC enabled network slicing. Enhanced Dedicated Core (eDECOR), and RAN sharing.
• Open issues and research challenges are identified DECOR allows operators to deploy multiple Dedicated Core
related to E2E network slicing and MEC integration. Networks (DCN), with each DCN dedicated to a specific

VOLUME 9, 2021 10905

 S. D. A. Shah et al.: Cloud-Native Network Slicing Using SDN Based MEC: A Survey

TABLE 2. Summary of recent surveys and tutorials with their primary focus.

customer or application. DECOR enables the customization C. PAPER ORGANIZATION

of the control and user plane functions for the DCNs. The The rest of the paper is organized as follows. We briefly
solution introduces a new subscription information parameter introduce the MEC integration into 5G Service Based Archi-
called a ‘‘UE usage type’’ that is stored in the Home Sub- tectures (SBAs) in Section II. In Section III, a detailed review
scriber Server (HSS). This parameter is used by the operators of recent progress related to E2E network slicing across mul-
to configure the required type of service; in other words, this tiple technologies and administrative domains is provided.
value enables the selection of the DCN. The parameter values In Section IV, we explore mobility management solutions for
can reflect different types of services such as general Machine network slicing. In Section V, the key enabling technologies
Type Communications (MTC) or low latency services for for network slicing are provided, and new features for these
autonomous cars. In comparison to E2E network slicing that technologies, such as the SDN meter table, are discussed.
spans across multiple technological domains such as radio, In Section VI and VII, we discuss cloud-native 5G core
edge, transport, and core, this scheme only deals with core for network slicing, along with its enabling technologies
network slicing. and potential use cases. In Section VIII, research issues and
eDECOR was also designed to achieve the same function- challenges are identified, and future research directions are
alities as DECOR, but with slight enhancements specified by provided. The conclusion is provided in Section IX. To bet-
the 3GPP [25]. In contrast to DECOR, where the DCN selec- ter understand the structure and organization of this survey,
tion is made by enodeB (enB), in Edecor the UE assists in we refer the reader to Fig. 1. Table 1 provides a list of
the selection of DCN by providing two parameters, i.e., DCN commonly used acronyms in the survey.
selection assistance parameter and Network-Attached Stor-
age (NAS) type. This approach also only takes into account II. 5G SBA AND MEC DEPLOYMENT
core network slicing. 5G SBAs include the separation of the control and user planes
Another similar slicing approach, RAN sharing, consid- to provide scalability and flexibility [27]. The control plane
ers network slicing in the RAN. RAN sharing involves functions are connected to each other via service-based inter-
sharing network infrastructure, e.g., antenna and backhaul faces. The Access Management Function (AMF) and Session
equipment [26]. However, this approach doesn’t include the Management Function (SMF) are connected to the user plane
softwarization and virtualization needed to provide flexibil- nodes via N1, N2, and N4 interfaces as shown in Fig. 2. AMF
ity and scalability. Also, it doesn’t consider E2E network and SMF are used to manage subscriber attachment, mobility,
slicing. and sessions. A brief summary of the 5G SBA NFs includes:

10906 VOLUME 9, 2021

S. D. A. Shah et al.: Cloud-Native Network Slicing Using SDN Based MEC: A Survey

FIGURE 1. Structure and organization of the paper.

FIGURE 2. MEC integration into 5G [28].

• Access and Mobility Management Function (AMF) • Policy Control Function (PCF) is used to provide the
is used to manage access control and mobility. It also policy framework incorporating mobility management,
provides reachability and communication services for network slicing, and roaming.
other NFs. • Unified Data Management (UDM) is used to store the
• Session Management Function (SMF) is required to subscribers’ data and profiles. It is similar to HSS in 4G.
manage and create sessions according to the defined • Authentication Server Function (AUSF) is used to
network policy. Some of its functionalities include IP perform the authentication function of 4G HSS, e.g.,
address allocation and selection, traffic rules configura- it implements Extensible Authentication Protocol (EAP)
tion of user plane function, and roaming support. and stores keys for UE authentication.
• User Plane Function (UPF) is a centralized entity that • Network Resource Function (NRF) is a new and most
plays a key role in traffic routing towards required net- important function that is incorporated in the 5G SBA.
work functions and applications. This function can be It allows network functions discovery functionality so
deployed in various locations or configurations, depend- that the network functions can discover and communi-
ing upon the type of service required. cate with each other via APIs. NRF maintains the profile

VOLUME 9, 2021 10907

 S. D. A. Shah et al.: Cloud-Native Network Slicing Using SDN Based MEC: A Survey

of all the NF instances and their supported services such advertise and offer MEC services via platforms in the same
as capacity information, IP addresses. In other words, or different MEC system. The MEP receives traffic rules
NRF is responsible for discovering all the available from the MEC platform manager, applications, or services
services. and configures the data plane accordingly.
• Network Exposure Function (NEF) is a centralized By flexibly locating the UPF, the MEC can be deployed in a
point that is responsible for exposing the capability data network that is external to the 5G system. The distributed
information and services offered by the 5G core network MEH deployed in a data network can accommodate MEC
functions to external entities. This function authorizes applications, e.g., computational offloading applications or
external users such as partner operators, to monitor and MEC services, e.g., message broker. The applications running
enforce application policy. in the MEC system, can produce a wide range of services such
• Network Slice Selection Function (NSSF) assists as Vehicle to Everything (V2X), and mobile virtual reality.
the selection of suitable NSIs, and allocation of More details on the MEC integration with the 5G network
required AMFs to the users depending upon the service can be found in [28].
requirements.
III. E2E NETWORK SLICING
NFs may incorporate other NFs that are reusable, indepen-
Network slicing is the integration of a set of technologies to
dent of each other, and often referred to as microservices.
create customizable and specialized dedicated logical Net-
An NF can act as either producer or consumer of these
works as a Service (NaaS) in order to meet diverse and het-
services; for example, a consumer NF can request subscriber
erogeneous requirements from vertical industries. It involves
policy information from a producer NF [29].
efficient virtualization and isolation mechanisms, customized
CUPS is one of the most important 5G core design princi-
and flexible functions design, and Operation and Mainte-
ples. It facilitates flexible service deployment at centralized
nance (O&M) tools to provide dedicated logical networks
or distributed locations, i.e., edge [27]. The modular func-
upon a shared infrastructure [2]. The components of E2E
tion design of the 5G core enables E2E network slices for
network slicing are briefly described below, followed by a
different service requirements and concurrent access to both
detailed description in later sections:
local and centralized services, e.g., to support low-latency
• Network Slice Instance (NSI) is the most important
mission-critical communication. In this case, low-latency
concept in E2E network slicing. It is described as an
applications or services can be deployed in the local data
E2E logical network that consists of various virtual
center or the ME by using the MEC Platform (MEP). In most
NFs, resources, and connectivity relationships. NSI dif-
cases, the user plane functions such as UPF are deployed in
ferentiates the E2E 5G network slicing concept from
the edge or local data center, whereas, the control plane is
the existing approaches as it covers multiple techni-
centralized. In some cases, control plane network functions
cal domains, such as terminal, Radio Access Network
e.g. NEF, can also be hosted in a distributed manner such
(RAN), Edge Network (EN), Transport Network (TN),
as in the edge to support mission-critical communication
and Core Network (CN). Additionally, it also involves
services [27].
the Data Center (DC) domains to host third party appli-
cations from different vertical industries. Different NSIs
A. MEC INTEGRATION INTO 5G SBA may consist of different VNFs and allocated resources.
The deployment of an MEC system in 5G SBA is shown However, NSI can also share VNFs and resources to
in Fig. 2, as defined by the European Telecommunications reduce CAPEX.
Standards Institute (ETSI) [28]. The MEC system consists • Network Slice Type: Three broad usage scenarios and
of an MEC Orchestrator (MEO) at the system level that acts service categories of 5G, as defined by ITU-R, are
as an Application Function (AF) and interacts with the 5G eMBB, mMTC, and URLLC. Each of these categories
core NEF. The MEO maintains an overall view of the MEC has its own demands and requirements that are highly
system, i.e., available resources, offered services, deployed distinct to each other. Network slice types are used to
MEC hosts (MEH). It is also responsible for the selection represent high-level categories in order to define the
of appropriate MEH for the application instantiation and NSIs.
application relocation if needed [30]. The key components • Network Slice Template (NST): NST design is differ-
that facilitate the integration of MEC with the 5G core are the ent from the operation of NSI and is used in the slice
ability of MEC to act as an AF and influence the routing of designing phase. NST is generated based on the net-
edge application traffic by interacting with the 5G core NEF; work capabilities of each technical domain and specific
and its ability to receive event notifications such as a mobility requirements of tenants. NSI instantiation depends upon
event that initiates application relocation. the NST output, which also includes VNF configura-
The MEC host-level consists of the MEP and the virtual- tion and deployment and resources in multiple technical
ization infrastructure that provides resources, i.e., compute, domains.
storage, and networking, to the MEC applications. The MEP • Network Slice Subnet Instances (NSSIs): An NSI typ-
offers an environment where MEC applications can discover, ically consists of multiple NSSI that integrate to form

10908 VOLUME 9, 2021

S. D. A. Shah et al.: Cloud-Native Network Slicing Using SDN Based MEC: A Survey

FIGURE 3. E2E network slicing architecture.

a fully-fledged NSI. NSSIs represent a group of VNF consists of an E2E network slice controller that interacts
instances. with and manages the individual controller of each technical
• RAN Slice, also known as RAN Sub-Slice, consists of domain, e.g., RAN, Transport, and core Slices controller [15].
customized and independent RAN network functions An E2E network slice controller is also required to enable the
such as eNB and Next-Generation node B (gNB) for control and coordination of network slices.
each E2E network slice. In accordance with the 3GPP definition of E2E network
• Edge Slice, also known as Edge Sub-Slice is used to slice, Fig. 3a represents the E2E network slice architecture
host various RAN and mobile core components, user in a single administrative domain. Considering the use case
service-based functions, and applications to provide study of MEC for the provision of low-latency 5G services
URLLC services. in [31], a MEC layer is proposed for the E2E network slice
• Transport Slice, also known as transport sub-slice, is a architecture. The MEC approach can be utilized to place the
set of connections between various VNFs or PNFs with VNFs, and user functions closer to the end-users by distribut-
deterministic Service Level Agreements (SLAs). This ing network data centers closer to the network edge. This
type of slice can be realized by various technologies and approach will help to improve the overall service experience
transport such as IP, optics, microwave, and Resource of end-users, such as the provision of URLLC services. The
Reservation Protocol (RSVP), segment routing, SDN addition of an MEC layer would also result in a reduced
meter tables, respectively. load on the transport infrastructure by providing the cloud
• Core Slice, also known as Core Sub-Slice, consists of computing facilities within or close to the transport network
customized and independent core, virtual NFs, such as as shown in Fig. 3a.
UPF, AMF, and SMF. The MEC data centers host both the virtualized RAN
• E2E Network Slice is defined as a virtual network capa- components such as the Centralized Unit (CU) and also
ble of supporting a specific vertical or service, functional the mobile core components such as the UPF, depending
and performance requirements. It is provided by the slice upon the network design requirements, as shown in Fig. 3a.
provided after certain agreements with the slice buyer, Additionally, user service-based functions and applications
such as slice lasting time. related to the provision of URLLC services can also be placed
in the MEC.
A. E2E NETWORK SLICING IN A SINGLE ADMINISTRATIVE Similar architectures are proposed for the provision of
DOMAIN a V2X URLLC slice in our previous work [32] and in
As defined by 3GPP [15], each E2E network slice comprises another work [33]. The authors proposed to host the SDN
a multitude of RAN, core, and transport slices, each having mobility management application in the MEH, to provide
its own controller. Considering the dynamic nature of the up-to-date topology information, the position and trajectory
E2E network slice, the life cycle of each network slice of each vehicle, thus ensuring low-latency operation and
might be a few hours, days or months. Therefore, various triggering seamless UP/CP functions migration, handovers,
controllers, i.e., a controller in each respective domain, are and reconfiguration of network resources in active slices. The
needed to perform the life cycle management of network recent state-of-the-art approaches for network slicing across
slices in their domain. Additionally, to achieve automation single administrative and technical domains are summarized
and optimization of network slices, an E2E network also in Table 3.

VOLUME 9, 2021 10909

 S. D. A. Shah et al.: Cloud-Native Network Slicing Using SDN Based MEC: A Survey

TABLE 3. Summary of state-of-the-art network slicing approaches.

10910 VOLUME 9, 2021

S. D. A. Shah et al.: Cloud-Native Network Slicing Using SDN Based MEC: A Survey

B. LOGICAL FLOW OF CREATION AND AUTOMATION OF

E2E NETWORK SLICE
The logical flow process to achieve E2E network slice
automation for different smart city services such as URLLC,
eMBB, mMTC is discussed in this section.
The customer requests the slice provider or operator to
create an E2E network slice for a service. Based on an SLA
agreement, this request is forwarded to an E2E network slice
controller, which uses its predefined NST and creates an NSI.
The NSI contains information about the NFs in RAN, core,
and edge that will be part of this E2E network slice. It then
requests the RAN and edge slice controller to create a RAN
and edge slice, respectively. Both of the domain controllers
trigger the creation of virtual NFs in their respective domains
by using the NFV interface, known as the ETSI interface FIGURE 4. Logical flow of automation and creation of E2E network slice.

os-Ma-nfvo. The details of NFV and this interface are pro-

vided later. The Network Function Virtualization Orches-
trator (NFVO) performs the life cycle management of the there is a need for an additional control layer to be added
virtual NFs. The NFs are then programmed by their respective to the single administrative domain architecture. This layer
domain controllers. should be able to map the service requirements to the capa-
The same process as mentioned above applies to the cre- bility of the infrastructure domain by identifying the domains
ation of a core slice. To provide connectivity between various with the required resources, i.e., computing, storage, and
NFs, multiple transport slices, i.e. various connections, will networking resources, thus ensuring efficient E2E network
be needed, e.g., transport slices between RAN, edge and slicing federation.
core slices. A transport slice also triggers the creation of After identifying the infrastructure domains, the layer,
VNFs in its domain, such as a firewall and security gateway, i.e., cross-domain slice coordinator, should request the E2E
if required. After all the respective domain slices are created, network slice controller of the administrative domains to
the E2E network slice controller will associate all of them instantiate an NSI instance within their respective domains.
together to form a single E2E network slice instance for the This NSI instantiation within a single administrative domain
specific service type. A unique network slice id, i.e., Network follows the same steps as mentioned in the logical flow pro-
Slice Selection Assistance Information (NSSAI) is also allo- cess above. This cross-domain slice coordinator should then
cated to the new network slice. The UEs will then be able be able to join the NSIs within the administrative domains to
to request access to this network slice by using signalling form a federated NSI.
procedures [15]. The logical flow for the provisioning of an The cross-domain slice coordinator is responsible for the
E2E network slice is shown in Fig. 4. The number mark management, control, and monitoring of the resources related
represents the order of actions in which the network slice is to a federated NSI. It should also ensure secure and reliable
provisioned. connectivity between administrative domains.
The interface connecting the E2E network slice controller The authors in [3] recommended using a cross-domain
with the RAN and core slice controller has been defined in slice coordinator to perform federated resource allocation,
technical specifications released by the 3GPP [15]. However, i.e., compute storage and network resources. To perform this
the literature available on the transport slice interface is lim- federated resource allocation, two architectural entities are
ited [15]. The transport slice and its connectivity interface are required to assist the cross-domain slice coordinator with fed-
summarized later. erated resource allocation: unified cloud mediator and unified
connectivity resource manager. The unified cloud mediator
contains the performance capability description of the infras-
C. E2E NETWORK SLICING IN MULTIPLE ADMINISTRATIVE tructure resources, and the connectivity resource manager
DOMAINS negotiates cross-domain connectivity. Fig. 3b depicts the E2E
An E2E network slice can belong to one or more adminis- network slice federation among administrative domains inte-
trative domains that may be distributed between DCs. Thus, grating the two additional entities as proposed by the authors
to deal with this deployment challenge, the E2E network in [3]. The recent state-of-the-art approaches for network
slicing architecture needs to be overhauled for the multiple slicing across multiple administrative and technical domains
administrative domain scenarios. are summarized in Table 3.
A multi administrative domain federated NSI combines
two or more NSIs that belong to different administrative D. SLICING AT THE MEC
domains, to form a slicing federation. In order to facilitate Several 5G use cases are expected to rely on the
E2E network slicing across multiple administrative domains, MEC paradigm to support a new generation of services,

VOLUME 9, 2021 10911

 S. D. A. Shah et al.: Cloud-Native Network Slicing Using SDN Based MEC: A Survey

e.g., mMTC, URLLC, and eMBB [34]–[36]. Though network Sanguanpuak et al. in [43] proposed an infrastructure cost
slicing and MEC are two key 5G enablers, they are evolving minimization algorithm where a network operator could
in parallel as defined by two different standardization bodies, deploy MEC slices by efficiently using the edge infrastructure
i.e., 3GPP and ETSI. Therefore integration of network slicing resources to meet latency requirements. Xiang et al. in [44]
and MEC is a research challenge that should be addressed to proposed a model that jointly considers the computational
provide enhanced slicing capabilities at the network edge. resources available at the MEC servers, slicing of the RAN
This section reviews selected recent proposals for orches- and edge computing resources, and routing diverse traffic
tration and management platforms that integrate MEC and requests towards the optimal MEC slices. The authors aim
network slicing. to achieve a flexible balance between the network operator
costs and the user-perceived latency by making effective use
1) ARCHITECTURE of the available computing resources.
The authors in [34] proposed a novel architecture compliant
with ETSI and 3GPP that integrates MEC as a sub-slice. E. 5G TRANSPORT SLICE
The work proposed a multi-tenancy and in-slice deployment Transport slice is a distinct set of connections between mul-
model to support MEC network slicing. In this proposal tiple virtual or physical NFs, each with its own specific SLA.
MEP is deployed as a VNF at the edge NFV Infrastructure It is implemented in the network by using IP and tunnels, e.g.,
(NFVI) and is shared among the slices or deployed inside IP, and Segment Routing (SR).
the slice, respectively. The MEO is responsible for instanti-
ating the applications at the edge NFVI and communicating 1) TRANSPORT SLICES IN CLOUD RADIO ACCESS
the MEP application IP address to enforce traffic steering. NETWORKS (C-RAN)
Cominardi et al. in [37] proposed solutions to evolve the The RAN consists of two functional units known as the
MEC framework towards integration with 5G network slic- Baseband Unit (BBU) and the Radio Unit (RU), which is also
ing, enabling multi-tenancy support. The authors emphasize known as the Remote Radio Head (RRH) [45]. The RU is
the need for interaction between MEC, NFV, and 3GPP sys- responsible for the transmission and reception of radio waves
tems to facilitate the slice-aware MEC app allocation on MEC over the air interface to the User Equipment (UE) and is
facilities. The authors also propose a communication channel connected to the BBU through the Fronthaul Network (FN).
to support MEC inter-slice communication. The BBU has signal processing capabilities and is connected
to the core network through the transport network. The MEC
2) RESOURCE ALLOCATION system, equipped with MEO, acts as an AF, that interacts with
D’Oro et al. in [38] proposed a unified MEC slicing the NEF of 5G SBA. The MEC system also consists of a dis-
framework that optimizes the resource allocation in the tributed cloud, that can be used to host different applications
strictly-constrained MEC computing and storage resources belonging to one or more network slice instances.
and supports instantiating MEC slices without suffering In this architecture, a single E2E network slice involves
resource over-provisioning. Xiang et al. in [39] proposed a four Transport Slices (TS): TS1, TS2, TS3 and TS4. TS1 con-
mathematical model that integrates MEC and network slicing nects the RAN to the core, TS2 connects the RRHs to the
focusing on addressing the stringent latency requirements of centralized BBU, TS3 that connects the MEC to Core and
critical services. The optimization problem deals with joint TS4 that connects the RAN to the MEC as shown in Fig. 5.
allocation of RAN and edge computing resources to the MEC
sub-slice. Liu et al. in [40] proposed a decentralized resource
orchestration system that supports dynamic network slicing
in edge computing networks. The proposed work leverages
deep reinforcement learning techniques to learn optimal poli-
cies, e.g., the resource demands of E2E slices, and dynam-
ically allocates the resources accordingly. Jošilo et al. in FIGURE 5. Transport slices connecting multiple domains.
[41] proposed an optimization algorithm that aims to meet
the latency-sensitive computational task requests by jointly
assigning the tasks to the most suitable MEC sub-slice, and 2) TRANSPORT SLICE CONNECTIVITY INTERFACE
dynamically managing the radio resources within the slices. The Transport Slice Connectivity Interface (TSCI) is an
interface between the E2E network slice controller and the
3) OPERATOR COSTS transport slice controller. It provides association and binding
Feng et al. in [42] proposed a novel framework that jointly between RAN to transport and core to transport slices. The
optimizes the slice-admission request and resource-allocation transport slice controller receives the request for the required
in MEC to maximize the operators average revenue. The connections between various NFs in the RAN and core by
proposed optimization algorithm achieves a balance between using a TSCI. The connections are then implemented by the
the average delay and the average operator revenue by mak- transport slice controller by using various IETF models. It is
ing dynamic and effective slice request admission decisions. important to note that this new TSCI provides information

10912 VOLUME 9, 2021

S. D. A. Shah et al.: Cloud-Native Network Slicing Using SDN Based MEC: A Survey

about the required connections and not the services. For SDN overlay application performs network slice selection
example, an E2E network slice controller requests a transport functionalities in the case of inter-slice V2X handover. The
slice controller to create a transport slice with multiple con- authors proposed a utility function that considers the slice
nections between the RAN and core NFs. The E2E network resource availability to determine the optimal target slice.
slice controller can make use of the TSCI interface to inform
the transport slice controller of the required connections A. IMPACT OF 5G SBA ON NETWORK SLICING MOBILITY
between the RAN and core NFs, e.g., between RAN1 and MANAGEMENT
UPF1, to serve a particular customer, tenant, service type or The 5G SBA plays an important role in realizing the network
SLA. slicing concept by providing NF or service reuse and enables
To implement the required connections, the transport slice customization across slices. Various NFs combine to form
controller finds the endpoints and best path to create a ser- an E2E slice to support different service requirements. For
vice between these endpoints, e.g., to provide the connection example, consider the deployment of an AMF NF in two dif-
between the RAN1 and UPF1, the controller first finds the ferent types of slice with different service requirements, i.e.
best available Border Routers (BR) for each NF, then finds the URLLC and IoT. The URLLC slice is often required to sup-
best path available between them. Finally, it creates a service port mission-critical communications such as autonomous
between these endpoints. driving and demands high mobility. The IoT slice, on the
other hand, enables massive device connectivity with rela-
IV. MOBILITY MANAGEMENT FOR NETWORK SLICING tively low mobility requirements. The AMF in the URLLC
User mobility from one domain to another may cause a slice will require more instances of AMF services because of
degradation in QoS or disconnection of the ongoing mobile its high mobility requirements as compared to the IoT slice.
communication and service session. This may happen when a Additionally, the UPF can also be deployed in the edge using
new network slice with the same characteristics, e.g., comput- the MEC paradigm to support low-latency communications
ing, storage, and networking resources, is to be instantiated in a URLLC slice as shown in Fig. 6.
at the destination network. Therefore, network slicing should
support mobility of the slice computing, storage, and network
resources [46]. In addition to mobility support, the network
slice should also be capable of dynamically adjusting and
adapting the resource allocation, e.g., freeing the unused
resources or adding more resources depending upon the ser-
vice requirements and resource availability. Recent research
proposals deal with the various aspects of mobility manage-
ment in network slicing.
Addad et al. in [46] proposed slice mobility patterns, e.g., FIGURE 6. 5G SBA scalability and mobility support.
full slice and partial slice mobility patterns, to efficiently
manage and migrate resources. The authors also introduced
the concept of slice breathing and scaling to dynamically 1) V2X SlICE USE CASE SUPPORTED BY 5G-MEC
adapt to the varying slice resources demand, i.e., sudden INTEGRATION
increase or decrease in the service demands causing Mobility support is an essential feature in V2X commu-
over-consumed or under-consumed slice resources, respec- nications [51]. V2X applications have diverse Quality of
tively. Shah et al. in [32] leveraged SDN to track the user Service (QoS) requirements; for example, the autonomous
mobility patterns across different mobile networks and trigger driving application requires ultra-low-latency and reliability
network slice mobility action towards the most optimal des- and very high availability. Infotainment applications have
tination network. In addition the SDN contoller, dynamically very high throughput requirements. As the vehicle exhibits
allocates the required resources to the relocated network slice. very high mobility characteristics and travels across multiple
De Vita et al. in [47] proposed a deep reinforcement learning cells, it is essential for V2X applications to guarantee the QoS
algorithm that learns optimal policies to relocate the net- requirements and maintain service continuity.
work slice across different MEC servers without any explicit As V2X applications have very demanding QoS require-
knowledge of the underlying processes. Yousaf et al. in [48] ments, the applications are often offloaded to the MEH
proposed the inclusion of specialized mobility management closer to the network edge. As the vehicle moves from the
NFs within a network slice capable of selecting the mobility service area of one cell to another, the source MEH may
management scheme depending upon the service mobility no longer be appropriate to provide V2X services to the
requirements. Meneses et al. in [49] proposed SDN based vehicle. The MEO should identify a target MEH by acting
mechanisms to increase the acceptance rate of incoming as an AF and subscribing to the 5G AMF and SMF for
slice handover requests by conserving the slice resources vehicle mobility-related events and user plane management
after the user handover. Mouawad et al. in [50] proposed events, respectively. Based on location updates, the MEO
an SDN based network slice management solution where an can identify a new target MEH, and the application instance

VOLUME 9, 2021 10913

 S. D. A. Shah et al.: Cloud-Native Network Slicing Using SDN Based MEC: A Survey

FIGURE 7. V2X slice mobility use case.

can be relocated to the target MEH. The MEP of the target through a virtualization layer enabling each VNF to work
MEH then acts as an AF and interacts with the NEF of 5G independently from hardware resources. This virtualization
SBA, specifying a new target MEH and traffic routing profile. layer can be a server such as Xen and VMware and network
This new request is passed to the PCF, which triggers the such as OpenFlow or Virtual Extensible LAN (VXLAN).
updated rules and passes this to the SMF. The SMF will
reconfigure the traffic rules and insert a new Uplink (UL) 3) NFV MANAGEMENT AND ORCHESTRATION
classifier in the UPF to steer the traffic/packets coming from NFV Management and Orchestration (NFV MANO) consists
the vehicle towards the target MEH. Various transport slices of three main components including the Virtualized Infras-
facilitate the interaction between these NFs instantiated in the tructure Manager (VIM), VNF Manager (VNFM), and NFV
V2X slice by providing connectivity from the edge enabled Orchestrator (NFVO). VIM is responsible for managing and
access layer to the cloud. This process can be seen in Fig. 7. controlling VNF interactions with physical resources such as
resource allocation and deallocation. VNFM performs VNF
V. KEY ENABLING TECHNOLOGIES life-cycle management, i.e., initialization and termination of
A. NETWORK FUNCTION VIRTUALIZATION VNFs and NFVO are responsible for implementation of dif-
Network Function Virtualization (NFV) is a key enabling ferent network services on the NFVI.
technology for 5G network slicing. It allows flexible creation Another component of the NFV framework is Operation
of network slices on shared physical resources and removes Systems and Business Support (OSS/BSS) that assists NFV
the dependencies on dedicated hardware by providing an MANO in executing networking policies.
efficient resource abstraction layer. NFV allows the network
services to run in virtual machines (VMs) or containers on the B. SDN AND SERVICE CHAINING
edge on cloud infrastructure. This allows each VM to perform SDN is another key enabler of network slicing. The SDN
independent network operations, e.g., load balancing or fire- controller can be used to provide effective network slice
wall. The main NFV components are summarized below: management by applying independent rules for each network
slice as defined by the corresponding network policy or slice
1) VIRTUAL NETWORK FUNCTION provider. It introduces programmability in the network by
VNF is the virtualization of NFs to enable their inde- decoupling the control plane from the data plane. SDN pro-
pendent operation. Each VNF can be further divided into vides centralized network intelligence that can be leveraged
sub-functions called VNF components. to instantiate new services by dynamically chaining NFs,
i.e., PNFs or VNFs, depending upon the network conditions
2) NFV INFRASTRUCTURE and user requirements.
NFVI defines the software and hardware required to deploy, Service chaining is a network capability that allows
monitor, and operate VNFs. It provides abstraction of hard- application-driven networking through the ordered con-
ware resources such as computing, storage, and networking nection of NFs [16], [52]. It allows flexible chaining of

10914 VOLUME 9, 2021

S. D. A. Shah et al.: Cloud-Native Network Slicing Using SDN Based MEC: A Survey

both control and data plane functions. It also enables processed, rate limitations, and Differentiated Services Code
application-driven traffic steering, i.e., traffic of certain appli- Point (DSCP) numbers, respectively. DSCP is a 6-bit field
cation, service, or users traverses a particular set of NFs as included in the IP header that is used to identify the service
defined by the service chaining policies [53]. This dynamic level of the packet, e.g., DSCP value 0 and 46 are used to
service chaining process enables the network operators to define the best effort and high priority class, respectively.
flexibly create, scale and remove NFs of a specific net- This feature provided by SDN OpenFlow 1.3 [62] can
work slice depending upon the varying demands or service be used for efficient traffic splitting to provide DiffServ to
requirements. the customers. SDN and OpenFlow meter table features as
Several research papers have focused on providing net- described can be adapted to realize the vision of network
work slicing through NFV and SDN integration [54]–[56]. slicing, i.e., to provide diverse service requirements.
In summary, network slicing allows the mobile operators to
add virtual networks and services to create mobile virtual
networks on the same physical network. In this scenario, VI. CLOUD-NATIVE 5G CORE FOR NETWORK SLICING
NFV provides the ability to create mobile network services
5G network slicing presents network operators with opportu-
through VNFs, and, in turn, the SDN framework is used for
nities to achieve a significant revenue boost by providing new
NF connectivity.
enterprise use cases beyond the enhanced mobile broadband
services. To provide the new use cases, evolved 5G core
1) SDN ENABLED TRAFFIC STEERING
technologies are required. Cloud-native 5G core software
VNFs or virtual function instances may reside at different
design can facilitate network slicing by providing services on
locations, e.g., different technical domains or administrative
demand.
domains, and the VNFs are chained to form a service. Traffic
A key motivation for 5G, compared to the previous
steering through the VNFs that span multiple technical and
mobile generations, is that it is service-focused, e.g., URLLC,
administrative domains is a very challenging task. In tradi-
mMTC, and eMBB, to support a wide range of vertical
tional networks, traffic is directed to the desired NFs using
sectors. To provide the diverse services with a different set
manual device configuration. However, in the case of network
of requirements, operators should be able to deploy 5G core
slicing that requires the dynamic and real-time deployment of
components across public, local, or private DCs and in
VNFs to create services on demand, this traditional approach
any geographical location dynamically, depending upon the
can not be imported. Because network slicing consists of
application demands. Thus, the 5G core design needs to be
dynamic allocation of resources to VNFs, there is a need
flexible and portable, which can be achieved by adapting
for autonomous traffic steering capabilities. SDN, because
the cloud-native software design of the 5G core and transi-
of its centralized architecture, offers intelligence and flexible
tioning VNFs to Cloud-Native Network Functions (CNFs),
control and enables efficient traffic steering towards VNFs.
i.e., allowing 5G core components (NFs) to run on con-
Several studies show that by extending SDN capabilities,
tainers enabling automation across any cloud environment.
i.e., Layer 2 (L2) and Layer 3 (L3) forwarding functions,
Cloud-native principles can be applied to control and user
it can allow efficient and dynamic traffic steering through
plane functions of the 5G core, AMF, SMF, and UPF respec-
VNFs [57]–[59]. The authors in [59] propose an algorithm
tively, to achieve flexibility, scalability and performance effi-
that finds the best path through a set of VNFs.
ciency. Operators can make full use of the cloud-native
approach in the UPF, thus eliminating the need for dedicated
2) SDN METER TABLES
hardware for core network routing and switching.
SDN, through its central management platform and intelli-
Design principles and some of the major components that
gent control, improves network programmability and allows
will enable the cloud-native approach in the context of 5G
dynamic control of the routing elements. OpenFlow is the
network slicing are described in the following sections.
protocol used to pass flow messages between controllers and
the data forwarding devices, to make network flow decisions
and carry out other network control related and monitoring
functions. The control plane interacts with the data plane to A. CLOUD-NATIVE DESIGN PRINCIPLES FOR NETWORK
specify forwarding instructions based on flow entries. SLICING
SDN network can also be used for efficient traffic splitting 1) AGNOSTICITY
for Differentiated Services (DiffServ) by using the recently Cloud-native is essential for the 5G NFs. For customized
released OpenFlow 1.3 [60], [61], i.e., OpenFlow 1.3 enables services on demand, e.g., URLLC, the 5G network appli-
the use of a new feature called a meter table. It consists of cations should not be built for specific infrastructure. The
meter entries that are used to define per-flow meters, where cloud-native network applications should be able to run on
a meter performs QoS operations such as rate-limiting and any Kubernetes enabled infrastructure, as these cloud-native
DiffServ. The most important element of meter entry is the applications can be deployed in a distributed manner in
meter band that specifies band type, rate, and type-specific the edge, core, or public cloud depending on the service
arguments to define the way the packet should be requirements.

VOLUME 9, 2021 10915

 S. D. A. Shah et al.: Cloud-Native Network Slicing Using SDN Based MEC: A Survey

2) DECOMPOSED SOFTWARE solutions, e.g., Open Source Mano (OSM) [85], that delivers
The 5G network applications should be designed so that the a MANO stack fully aligned with ETSI NFV information
applications can be decomposed into microservices. This will models.
enable independent life cycle management and scalability.
2) KUBERNETES
3) ORCHESTRATION AND AUTOMATION Docker deals with the packaging and distribution of applica-
To manage the complexity of 5G applications and the tions or functions, whereas the Kubernetes platform is used
service-based use cases, it is necessary to utilize and build out to scale, run and monitor the applications or functions [86].
the orchestration needed to manage cloud-native applications Kubernetes is also referred to as a container orchestrator that
and infrastructure. provides deployment automation, scheduling, scaling, and
coordination of containerized applications [87]. Kubernetes
B. CLOUD-NATIVE ENABLING TECHNOLOGIES FOR does not run the containers directly, instead, one or more
NETWORK SLICING containers are wrapped into a high-level architecture called
1) CONTAINERS pods. The containers in the same pod share the resources
Containers are a lightweight virtualization alternative to and network, and communicate with each other. The general
VMs [80] that leverage two Linux kernel features: namespace architecture of the Kubernetes cluster consists of a master and
and cgroups. The namespace is used to enable application nodes, as can be seen in Fig. 9. The master is responsible
isolation by providing it with a limited view of the underlying for exposing the Application Program Interface (API) to the
operating system environment, i.e., network resources (IP developers, scheduling the cluster deployments, e.g. pods,
addresses, routing tables and interfaces). The cgroups pro- nodes. The nodes contain the container runtime, e.g., one or
vides the capability to enforce limitations and prioritization more Docker containers running inside pods, and an element
of system resources (CPU and memory) [32]. called kubelet that is responsible for communication between
The 5G SBA and its use cases, such as MEC and network the node and the master.
slicing, rely heavily on virtualization techniques; VM based
virtualization adds complexity and overhead to the system
as the VMs require packaging of the entire Operating
System (OS) along with the hosted applications or func-
tions. When compared to VMs, containers can reduce over-
head by packaging only the application or function and the
application-specific OS dependencies [32], [81]. One of the
most widely used containerization technologies is Docker
because of its ability to provide portability and scalabil-
ity [82]. The advantage of using containers rather than VMs
for network slicing can be seen in Fig. 8.

FIGURE 9. Kubernetes edge/cloud cluster.

3) OPENSTACK
OpenStack because of its flexible and modular nature, is also
considered as one of the ideal candidates for enabling 5G
edge computing use cases [88]. It is open-source software
used to build private and public clouds and provides robust
FIGURE 8. Containers vs VMs.
support to virtualization and container technologies. Open-
Stack is also referred to as a cloud OS that manages and con-
Containers allow the efficient deployment of microser- trols large pools of resources, e.g., computing, networking,
vices, where each service part can be decoupled into separate and storage in the DCs [89]. OpenStack provides a highly
containers and wrapped into pods where they can commu- distributed infrastructure software platform, and it is used in
nicate with each other. This permits modular development, thousands of DCs around the world today. Recently, it has
efficient scaling, and deployment models. been adopted by the telecommunications industry to advance
Docker containers are considered to be an integral part of the edge computing use cases.
the NFV framework [83] that is the key enabling technology
for network slicing. Software developed by the SONATA C. DEPLOYMENT SCENARIOS
project called ‘‘vim-emu: A NFV multi-pop emulation plat- There are multiple deployment scenarios in which the
form’’ [84] allows VNFs to be provisioned using Docker con- cloud-native approach, e.g., Docker, Kubernetes, and Open-
tainers. This emulation platform fully integrates the MANO Stack, can be used to provision the service-focused use cases

10916 VOLUME 9, 2021

S. D. A. Shah et al.: Cloud-Native Network Slicing Using SDN Based MEC: A Survey

of MEC enabled network slicing. For example, the whole

Kubernetes cluster can be wrapped in a lightweight package
and deployed at the edge, where it can host different vertical
applications and cloud-native 5G core NFs as containers run-
ning inside pods. Another approach proposed is Huawei’s IoT
edge platform [90]. Instead of deploying the whole Kuber-
netes cluster at the edge, the control plane residing in the
cloud manages the containers and pods running at the edge
nodes. This approach is also proposed by the open source
system called KubeEdge [90].

D. CLOUD-NATIVE ARCHITECTURE AND ITS ADVANTAGES

The self-management and scalability capability of cloud-
native VNFs differentiates them from the conventional VNFs.
Following are some of the key benefits of the cloud-native FIGURE 10. Cloud-native microservices architecture for network slicing.
VNFs that overcomes the limitations of conventional VNFs.
• Automated installation and configuration of VNFs.
• Automated and dynamic scaling of network resources
and VNFs depending upon the workload.
• Self-healing and fault-tolerant where the cloud-native
orchestration platform automatically restarts the failing
VNFs.
• Automated performance monitoring of VNFs for analy-
sis of bottlenecks, for improved overall performance.
• Simplified and softwarized management enabling
reduced energy consumption.
• High reusability and portability enabled by light-weight
containerization platform.
Previous works on network slicing, identified in a litera-
ture search, were found to not fully consider a cloud-native FIGURE 11. Service chaining in cloud-native environment.
5G core and microservices architecture. Also, most of the
existing research does not present the benefits of using
container-based virtualization of VNFs; VM and Hypervisor VII. CLOUD-NATIVE NETWORK SLICING: USE CASES
are often used for virtualization as shown in the Table 3. A. 5G E-hEalth (MISSION-CRITICAL Communication)
Based on the design principles identified in this paper,
The 5G e-health connected ambulance is one of the most
an architecture for MEC enabled cloud-native network slicing
important use cases of network slicing as envisioned by the
is envisioned that exploits the benefits of enabling new fea-
SliceNet project [64]. The use case intends to improve ambu-
tures for NFV with cloud-native technologies, e.g., Docker
lance services and provide real-time health care and first-aid
containers and Kubernetes, as shown in Fig. 10. The logical
to patients. The vision of this use case is to enable a connected
flow of the provisioning of E2E network slices follows the
ambulance to serve as a mobile edge (connection hub) for
same process as shown in Fig. 4, but the cloud-native tech-
the emergency medical equipment or wearables, enabling
nologies are leveraged to envision a cloud-native NFV stack
real-time and dynamic streaming and storing of patient health
instead of the traditional virtualization orchestrator(s).
data to the emergency team awaiting at the destination hospi-
tal. Through real-time video feeds and provision of patient
E. SERVICE CHAINING IN CLOUD-NATIVE ENVIRONMENT insights, the emergency team will be able to support the
In a cloud-native environment, services are offered by instan- paramedics attending the patients with intelligent decision
tiating service containers or pods to dynamically apply single support.
or multiple services to traffic from one endpoint to another. This use case demands the deployment of URLLC slices
To create a service chain, SDN can facilitate the creation of on-demand to enable intensive and real-time patient data
tunnels across the underlay network spanning through all ser- (video feeds) communication between the paramedics and the
vices in the chain. Fig. 11 shows two compute nodes deployed emergency team waiting at the destination hospital. This use
in a Kubernetes cluster, each with one service instance and case can be supported by different scenarios of the envisioned
traffic going through all the services to and from one endpoint cloud-native 5G microservices architecture for network slic-
to the other. ing. For example, consider the case where the ambulance has

VOLUME 9, 2021 10917

 S. D. A. Shah et al.: Cloud-Native Network Slicing Using SDN Based MEC: A Survey

its own mini DC, with the capability to host VNFs. As the applications for pattern detection, classification, and coop-
connected ambulance case requires the provision of URLLC, erative driving for V2V communication, require low latency
the control plane VNFs can be located in the central DC communication. The European METIS project envisions the
whereas the user plane VNFs as well as Virtual RAN (vRAN) E2E latency to less than five milliseconds and reliability
and connected ambulance applications can be located in the of 99.99 percent [92].
ambulance mini DC as shown in Fig. 12. MEC holds significant promise here by offering the cloud
computing resources closer to the end-users at the edge of the
network. MEH provides the compute, storage and networking
resources to host different V2X applications and ME services.
In response to the high mobility requirements of the V2X
use case, applications and services should seamlessly migrate
from one MEH to the adjacent MEH, while ensuring reduced
latency and service interruptions.
This use case can be supported by the containerized based
approach for network slicing. The lightweight Docker con-
tainers support portability and real-time deployment of dis-
tributed applications. The features provided by the Docker
container-based solutions make it a key enabler for the
FIGURE 12. 5G e-health use case. MEC [93], [94].
For the high mobility scenario, as the vehicle moves from
As the URLLC slice is requested, the E2E slicing orches- the service area of one MEH to another, the MEO by the use
trator or E2E network slice controller designs and instantiates of the Radio Network Information Service (RNIS), tracks the
NST based on the network capabilities and specific require- trajectory of the vehicle and finds out the appropriate target
ments of tenants. NSI is instantiated as an output of NST, MEH. By taking full advantage of the modularity offered by
i.e., 5G core CNFs are instantiated and deployed in a flexible the Docker containerized solution, applications and services
and distributed way across the cloud and edge. These CNFs can be migrated to the target MEH in real-time, i.e. service
register with the NRF of the 5G SBA. The cloud-native 5G and application instances are replicated in the target MEH.
microservices architecture, as described above, facilitates the The SDN controller reconfigures the traffic rules and installs
real-time and distributed deployment of the 5G core CNFs new flows to reroute the traffic from the vehicle towards the
across the cloud and edge. By using a containers based target MEH. This use case can be seen in Fig. 13.
solution, the 5G core CNFs and RAN components can be
deployed as containers, whereas the SDN transport network
solution can facilitate the service chaining and connectivity
among different 5G core CNFs. The Layer 3 Virtual Private
Network (L3VPN) is configured over the transport network to
create an E2E slice. In this use case, two Kubernetes clusters
can be deployed with one at the core cloud and the other at
the edge cloud to host control and user plane 5G core CNFs
as containers, respectively. The RAN components can also be
deployed as containers on the edge cluster. Before or during
this operation, the service providers will be able to deploy
and scale different functions on demand. The cloud-native
microservices solution based on containerization technology
enables the real-time deployment of the service components.
Similar use cases of cloud-native design, e.g., Kubernetes
for 5G network slicing and vertical services, are provided by
the 5G-PPP in [91]. The 5G-PPP software network working
group emphasizes on the importance of cloud-native design to FIGURE 13. Docker containerization solution for V2X slice.
meet emerging customers’ demands for new services in [91].
The 5G-PPP group also recommends the network operators A similar approach for real-time service migration is pro-
adopt the cloud-native microservices architecture. posed in [95] and our previous work [32]. In [32], an SDN
enhanced edge computing architecture is proposed that inte-
B. V2X USE CASE FOR URLLC SERVICES grates the containerization engine for the provision of V2X
V2X communication requires the provision of high band- URLLC slice in a high mobility scenario. Results provided
width and URLLC services. Certain V2X applications such show that by using the Docker containerized approach for
as advanced safety applications, e.g., machine learning service migration, the service downtime values are reduced.

10918 VOLUME 9, 2021

S. D. A. Shah et al.: Cloud-Native Network Slicing Using SDN Based MEC: A Survey

FIGURE 14. Virtual cluster based network slice migration in cloud-native edge clouds.

C. NETWORK SLICE MOBILITY AND SERVICE MIGRATION are isolated by forming virtual clusters by defining different
IN CLOUD-NATIVE EDGE CLOUDS namespaces within the Kubernetes cluster. The virtual clus-
5G supports new vertical use cases that require new ters allow seamless and parallel migration of all the services
mobility approaches beyond the conventional device-centric defined within the namespace.
approaches. For example, the mobility of low-latency com- Conventionally, Kubernetes doesn’t support service migra-
munication services deployed at the edge and shared by a tion between clusters. We made use of the open-source
group of mobile users, e.g., a group of connected cars or project ‘Velero’ [96] that permits the backup of cluster
Unmanned Aerial vehicles (UAVs). To ensure service conti- resources and persistent volumes and migration of the backup
nuity, as the users move from the service area of one edge to another cluster. We considered the different sizes of net-
cloud to another, the service configuration files and slice work slices by defining pods having 2, 3, and 4 service
resources should also move in real-time to the destination instances running as containers. The size of these service
edge cloud. The cloud-native approach can be used to support containers is taken as 114MB, 127MB, 107MB, and 197 MB.
service portability as it provides the capacity to move the We fixed random sizes of service instances to represent
edge services from one edge cloud to another in real-time by the services with varying data demands. We assumed that
making use of container advanced features. the group of connected UAVs and cars, being served by
We conducted a preliminary evaluation of the cloud-native slice 1 and 2, moves out of the service area of the source edge
approach for supporting real-time migration of communi- cloud towards the destination edge cloud, and the service con-
cation services shared by a group of mobile users across figuration files as well as the cluster resources are migrated
different edge clouds. Fig. 14 portrays the real experimental to the new destination edge cloud. It takes approximately
testbed set up to emulate the slice mobility across different 20 seconds to migrate the service configuration files and 23,
edge clouds deployed as multi-node Kubernetes clusters in 30, and 39 seconds to restore the pods having 2, 3 and 4 ser-
different regions in the Google Cloud Platform. The Kuber- vice instances, respectively, as seen in Fig. 15. It was noted
netes clusters are allocated 3 CPUs and 11.25 GB of memory. that the size of the service containers does not impact the
We assume that a group of mobile users, e.g., a group of UAV latency induced by the migration of service configurations;
and a group of connected cars, are being served by slice 1 and however, the pods having service instances of larger container
slice 2, respectively. The slices consist of multiple services sizes take longer service restoration time as seen in Fig. 15.
running as containers in their respective pods. The slices This is because the pods containing more service instances

VOLUME 9, 2021 10919

 S. D. A. Shah et al.: Cloud-Native Network Slicing Using SDN Based MEC: A Survey

orchestrated by OpenStack and pods orchestrated by Kuber-

netes. It’s an area with limited research carried out so far.

C. NETWORK SLICE ISOLATION FOR THIRD-PARTY

SERVICES IN A CLOUD-NATIVE ENVIRONMENT
Future 5G mobile networks are expected to support the
creation of network slices that might be made available
to third-party organizations, e.g., enterprises. Traditional
cloud-native orchestration platform(s), e.g., Kubernetes, pro-
vide a flat networking model wherein resources created, e.g.,
pods, can talk to each other. Therefore, a prerequisite for
supporting highly sensitive services in a network slice is
to develop an effective policy to provide isolation between
different pods and services.
FIGURE 15. Network slice migration in cloud-native edge clouds.
D. DYNAMIC SERVICE CHAINING IN MODULAR
SOFTWARE ARCHITECTURE OF 5G
The 5G SBA enables decoupled network functionalities, e.g.,
of higher data sizes induce high computing and processing CUPS. When compared to the traditional network entities that
demands. are closely-coupled to each other, the 5G SBA is envisioned
The preliminary results show that because of the to contain loosely-coupled, and modular NFs and services.
OS-independent virtualization and portability offered by the This improves the network programmability, and each service
cloud-native environment, it takes less than 60 seconds to can be realized by a set of specific functionalities depend-
migrate and restore multiple services in the destination edge ing upon the service type and requirements. Therefore, each
cloud. The results highlight that with an accurate predic- service can be updated or scaled independently of others,
tion of the time instant at which the service pre-relocation thus enabling a highly flexible and scalable architecture.
should start, service continuity can be maintained for the The self-contained smaller and modular NFs are connected
group of mobile users. The results also indicate that the time and flexibly chained to realize an E2E network slice for a
taken is substantial, being seconds rather than the preferred dedicated service [16]. However, because of the dynamic and
micro-seconds for real-time service or application continuity. modular 5G software architecture, chaining and connection
of the dynamic NFs components is a very challenging task
VIII. CHALLENGES AND FUTURE RESEARCH DIRECTIONS due to the number of connectivity interfaces involved in the
A. CLOUD-NATIVE 5G CORE ADAPTABILITY process that remain need to be designed.
Cloud-native 5G core adaptability is necessary to take
full advantage of cloud-native functionalities, e.g., service E. TRUST MANAGEMENT AMONG MULTIPLE
automation, dynamic application and NF scaling, and effi- ADMINISTRATIVE DOMAINS
cient use of storage and computing capabilities. To fully Slicing federation among multiple administrative domains
adopt the cloud-native architecture, the core NFs should is an important network slicing challenge [64]. In a high
be designed in a way that they are fully compatible with mobility scenario when URLLC slicing is requested, e.g.,
the cloud-native microservices architecture. For example, V2X communications there is a need for slicing federa-
the role of UPF is to handle the traffic coming from the tion. The security and trust management between different
end-user devices and to perform several operations such as vendors across different administrative domains that share
managing sessions and routing traffic to the edge. To make physical resources to realize slicing federation needs to be
UPF cloud-native, the challenge is to design a packet pro- investigated.
cessing solution that is fully compatible with containers
and can be scaled elastically. In addition, it should also be F. MOVING INTELLIGENCE AND USER-SPECIFIC
cost-effective i.e., reduced CPU requirement. COMPUTATION TO EDGE
6G envisions taking the intelligence and user-specific com-
B. HYBRIDIZATION OF CONTAINERS AND VMs putation to the edge [97]. Edge computing will permit the
It might not be possible to make NFs cloud-native and to computation-intensive and low-latency applications to run at
adapt to the stateless microservices approach because not all the edge. The increasing number of smart devices and smart
applications might benefit from the cloud-native approach, city applications generate a massive amount of local data that
e.g., LANs and WANs. Coexistence of both technologies is transmitted to the centralized cloud for processing, result-
might be the way forward. Therefore, more research efforts ing in latency and computational complexity at the cloud.
are needed to develop an orchestration platform that would To deal with these challenges, the 6G vision is to facilitate
interconnect two different types of workloads, e.g., VMs artificial intelligence (AI) use cases such as self-learning

10920 VOLUME 9, 2021

S. D. A. Shah et al.: Cloud-Native Network Slicing Using SDN Based MEC: A Survey

networks, e.g., Deep Reinforcement Learning (DRL) over I. INTEGRATION OF MACHINE LEARNING FOR EFFICIENT
wireless links, at the edge cloud. Shifting the AI and com- RESOURCE UTILIZATION
putation capability to the edge will enable new use cases and The role of machine learning algorithms, e.g., Support Vector
services such as self-driving cars, mobile virtual reality, and Machine (SVM) and DRL, in network slicing is yet to be fully
mixed reality applications. The challenge is to design efficient exploited. For example, SVM can be used as an efficient tool
and new neural network architectures over the wireless link for service requirements classification assisting in network
at the network edge to realize the new services. slice selection and DRL can be used in dynamic workload
dependant resource allocation problems such as efficient and
dynamic allocation of resources to each logical network (slice
G. CONVERGENCE OF JOINT COMMUNICATION, resource allocation) over a common shared physical network.
COMPUTATION, CACHING, AND CONTROL
RESOURCES J. CONTROLLER PLACEMENT SOLUTIONS
One of the 6G initiatives is the convergence of joint commu- Network slicing supports the realization of E2E services
nication, computation, caching, and control (4C) resources on demand, each with its own specific requirements, e.g.,
[98], [99] at the edge. MEC has been standardized to aug- latency, bandwidth, and availability. Depending upon the
ment cloud computing by reducing the network delay and service requirements, 5G core NFs can be deployed across
computational load on the cloud servers. However, an edge public, local, or private DCs in any geographical location.
server has minimal network resources, and when operated Thus, the challenge is to find the optimal placement strategy
independently, it can’t handle the computational load and big for the E2E network slice controller that will enable slice
data demands generated by IoT applications. Therefore, new management considering the specific service requirements.
mechanisms and algorithms need to be developed to facili- Also, determining the optimal number of controllers required
tate the cross-domain federation of MEC resources enabling per slice is an open issue to be investigated.
4C at the edge. The existing works on 4C in MEC do not
consider the challenges introduced by a mobile environment, K. CONTROL PLANE ISOLATION AND INTERACTIVITY
e.g., vehicular communications, where federation of MEC Business verticals may have different service requirements,
servers becomes essential for maximum bandwidth savings such as the automotive industry may require a control appli-
and reduced service migration costs. cation, i.e., mobility management application to fulfill the
high mobility service requirements. The challenges are to
provide an isolated and customized control plane for different
H. NETWORK SLICE MOBILITY AND DYNAMIC SERVICE vertical customers instead of a common control plane. This
MIGRATION will permit the vertical business to provide a customized
The provision of network slices on-demand in mobile cel- control application to satisfy service requirements. Also, new
lular networks requires dynamic migration of NFs and ser- interfaces and definitions are required that will facilitate the
vices from one edge cloud to another for service continuity. interaction of the SDN control plane with the network slices.
The preliminary results, as provided in the research shown The SDN control plane interactivity with the network slices
in Fig. 15, exhibits that migration of multiple services used is an open issue to be investigated.
by a group of mobile users takes seconds rather than the
preferred microseconds as E2E latency envisioned for the IX. CONCLUSION
URLLC slice [92]. Therefore, to ensure service continuity, Network slicing based on MEC, SDN, NFV and a cloud-
it is essential to develop self-learning networks, e.g., DRL, native 5G core is emerging as a key enabling technology
for accurate prediction of the user mobility patterns and for 5G network operators and service providers to achieve
early initiation of the service migration process. Research new revenue opportunities and provide new and innovative
on service migration generally considers a single service customized services on demand. However, to fully achieve
and network scenario [100]–[102]. However, a group of the service-focused goals of 5G, there are multiple technical
users demanding multiple-services simultaneously with dif- issues and challenges remaining, such as slicing federation
ferent service requirements is becoming a norm now. Service among multiple administrative domains, cloud-native 5G
migration as users move across the network can be cost- core adaptability to support the MEC use cases, dynamic
inefficient, consume limited bandwidth, and the target edge service chaining, and controller design and placement. This
cloud may not have the resources needed to support service paper investigates the recent efforts and progress made in
continuity. Therefore, services should be migrated depending realizing E2E network slicing, its key enabling technologies
upon the service requirements, e.g., latency and bandwidth. such as NFV for virtualization support, MEC for URLLC
Efficient algorithms should be designed to answer the follow- services, cloud-native 5G core for service automation and
ing challenges: when to migrate, what to migrate, and where SDN for dynamic service chaining and VNF management.
to migrate, in particular for multiple services and multiple As the NFV and 5G use cases have started to shift to a cloud-
mobile network operators scenarios. native platform, and adoption of cloud-native applications

VOLUME 9, 2021 10921

 S. D. A. Shah et al.: Cloud-Native Network Slicing Using SDN Based MEC: A Survey

and NFs is accelerating among network operators for services [19] X. Costa-Perez, A. Garcia-Saavedra, X. Li, T. Deiss,
scalability, agnosticity, portability, and automation. An SDN A. de la Oliva, A. di Giglio, P. Iovanna, and A. Moored, ‘‘5G-
crosshaul: An SDN/NFV integrated fronthaul/backhaul transport
and MEC enabled cloud-native architecture for 5G network network architecture,’’ IEEE Wireless Commun., vol. 24, no. 1,
slicing is envisioned in this article, along with some of its pp. 38–45, Feb. 2017.
potential use cases. The recent progress made by indus- [20] R. Mijumbi, J. Serrat, J.-L. Gorricho, N. Bouten, F. De Turck, and
R. Boutaba, ‘‘Network function virtualization: State-of-the-art and
try standardization and research into 5G network slicing research challenges,’’ IEEE Commun. Surveys Tuts., vol. 18, no. 1,
is discussed, and selected open issues and future research pp. 236–262, 1st Quart., 2016.
directions are identified, to realize the future vision of [21] J. Gil Herrera and J. F. Botero, ‘‘Resource allocation in NFV: A com-
prehensive survey,’’ IEEE Trans. Netw. Service Manage., vol. 13, no. 3,
5G network slicing. pp. 518–532, Sep. 2016.
[22] V.-G. Nguyen, A. Brunstrom, K.-J. Grinnemo, and J. Taheri, ‘‘SDN/NFV-
based mobile packet core network architectures: A survey,’’ IEEE Com-
REFERENCES mun. Surveys Tuts., vol. 19, no. 3, pp. 1567–1602, 3rd Quart., 2017.
[23] A. Blenk, A. Basta, M. Reisslein, and W. Kellerer, ‘‘Survey on network
[1] W. Saad, M. Bennis, and M. Chen, ‘‘A vision of 6G wireless systems: virtualization hypervisors for software defined networking,’’ IEEE Com-
Applications, trends, technologies, and open research problems,’’ IEEE mun. Surveys Tuts., vol. 18, no. 1, pp. 655–685, 1st Quart., 2016.
Netw., vol. 34, no. 3, pp. 134–142, May/Jun. 2020. [24] I. Afolabi, M. Bagaa, T. Taleb, and H. Flinck, ‘‘End-to-end network
[2] Huawei, ‘‘5G service-guaranteed network slicing white paper,’’ China slicing enabled through network function virtualization,’’ in Proc. IEEE
Mobile Commun. Corp., Beijing, China, Tech. Rep., Feb. 2017. Conf. Standards Commun. Netw. (CSCN), Sep. 2017, pp. 30–35.
[3] T. Taleb, I. Afolabi, K. Samdanis, and F. Z. Yousaf, ‘‘On multi- [25] X. De Foy and A. Rahman, ‘‘Network slicing—3GPP use case,’’ Inter-
domain network slicing orchestration architecture and federated Digital Commun., LLC, Wilmington, DE, USA, Tech. Rep., Oct. 2017.
resource control,’’ IEEE Netw., vol. 33, no. 5, pp. 242–252, [26] X. Costa-Perez, J. Swetina, T. Guo, R. Mahindra, and S. Rangarajan,
Sep. 2019. ‘‘Radio access network virtualization for future mobile carrier networks,’’
[4] M. S. Bonfim, K. L. Dias, and S. F. L. Fernandes, ‘‘Integrated NFV/SDN IEEE Commun. Mag., vol. 51, no. 7, pp. 27–35, Jul. 2013.
architectures: A systematic literature review,’’ ACM Comput. Surv., [27] G. Brown, ‘‘Service-based architecture for 5G core networks,’’ Huawei
vol. 51, no. 6, p. 114, Feb. 2019. White Paper 1, Nov. 2017.
[5] M. Richart, J. Baliosian, J. Serrat, and J.-L. Gorricho, ‘‘Resource slic- [28] S. Kekki, W. Featherstone, Y. Fang, P. Kuure, A. Li, A. Ranjan,
ing in virtual wireless networks: A survey,’’ IEEE Trans. Netw. Service D. Purkayastha, F. Jiangping, D. Frydman, G. Verin, and K. W. Wen,
Manage., vol. 13, no. 3, pp. 462–476, Sep. 2016. ‘‘MEC in 5G networks,’’ ETSI White Paper 28, Jun. 2018, pp. 1–28.
[6] X. Foukas, G. Patounas, A. Elmokashfi, and M. K. Marina, ‘‘Network [29] D. Chandramouli and G. Gkellas, ‘‘5G-service-based architecture,’’ in
slicing in 5G: Survey and challenges,’’ IEEE Commun. Mag., vol. 55, Proc. Wiley 5G Ref: The Essential 5G Reference Online, May 2019,
no. 5, pp. 94–100, May 2017. pp. 1–15.
[7] I. Afolabi, T. Taleb, K. Samdanis, A. Ksentini, and H. Flinck, ‘‘Net- [30] MEC ETSI ISG, ‘‘Multi-access edge computing (MEC); frame-
work slicing and softwarization: A survey on principles, enabling tech- work and reference architecture,’’ ETSI, Sophia-Antipolis, France,
nologies, and solutions,’’ IEEE Commun. Surveys Tuts., vol. 20, no. 3, Tech. Rep. GS MEC 003, Jan. 2019.
pp. 2429–2453, 3rd Quart., 2018. [31] Cisco Converged 5G xHaul Transport, White Paper, Cisco Systems Inc,
[8] A. Kaloxylos, ‘‘A survey and an analysis of network slicing in 5G San Francisco, CA, USA, 2018.
networks,’’ IEEE Commun. Standards Mag., vol. 2, no. 1, pp. 60–65, [32] S. D. A. Shah, M. A. Gregory, S. Li, and R. D. R. Fontes, ‘‘SDN
Mar. 2018. enhanced multi-access edge computing (MEC) for E2E mobility and QoS
[9] A. A. Barakabitze, A. Ahmad, R. Mijumbi, and A. Hines, ‘‘5G network management,’’ IEEE Access, vol. 8, pp. 77459–77469, Apr. 2020.
slicing using SDN and NFV: A survey of taxonomy, architectures and [33] C. Campolo, R. Fontes, A. Molinaro, C. E. Rothenberg, and A. Iera, ‘‘Slic-
future challenges,’’ Comput. Netw., vol. 167, Feb. 2020, Art. no. 106984. ing on the road: Enabling the automotive vertical through 5G network
[10] L. U. Khan, I. Yaqoob, N. H. Tran, Z. Han, and C. S. Hong, ‘‘Network softwarization,’’ Sensors, vol. 18, no. 12, p. 4435, Dec. 2018.
slicing: Recent advances, taxonomy, requirements, and open research [34] A. Ksentini and P. A. Frangoudis, ‘‘Toward slicing-enabled multi-
challenges,’’ IEEE Access, vol. 8, pp. 36009–36028, Feb. 2020. access edge computing in 5G,’’ IEEE Netw., vol. 34, no. 2, pp. 99–105,
Mar. 2020.
[11] D. Sabella, V. Sukhomlinov, L. Trang, S. Kekki, P. Paglierani,
R. Rossbach, X. Li, Y. Fang, D. Druta, F. Giust, and L. Cominardi, [35] A. Filali, A. Abouaomar, S. Cherkaoui, A. Kobbane, and M. Guizani,
‘‘Developing software for multi-access edge computing,’’ ETSI White ‘‘Multi-access edge computing: A survey,’’ IEEE Access, vol. 8,
Paper 20, Feb. 2019. pp. 197017–197046, Oct. 2020.
[36] Q.-V. Pham, F. Fang, V. N. Ha, M. J. Piran, M. Le, L. B. Le,
[12] S. Redana, Ö. Bulakci, A. Zafeiropoulos, A. Gavras, A. Tzanakaki,
W.-J. Hwang, and Z. Ding, ‘‘A survey of multi-access edge computing
A. Albanese, A. Kousaridas, A. Weit, B. Sayadi, B. T. Jou, and
in 5G and beyond: Fundamentals, technology integration, and state-of-
C. J. Bernardos, ‘‘5G PPP architecture working group: View on 5G archi-
the-art,’’ IEEE Access, vol. 8, pp. 116974–117017, Jun. 2020.
tecture,’’ Eur. Commission, Brussels, Belgium, Tech. Rep., Jun. 2019.
[37] L. Cominardi, T. Deiss, M. Filippou, V. Sciancalepore, F. Giust, and
[13] MEC ETSI ISG, ‘‘Multi-access edge computing (MEC); support for net- D. Sabella, ‘‘MEC support for network slicing: Status and limitations
work slicing,’’ ETSI, Sophia-Antipolis, France, Tech. Rep. GR MEC 024, from a standardization viewpoint,’’ IEEE Commun. Standards Mag.,
Nov. 2019. vol. 4, no. 2, pp. 22–30, Jun. 2020.
[14] Framework for the Support of Network Slicing in the IMT-2020 Network, [38] S. D’Oro, L. Bonati, F. Restuccia, M. Polese, M. Zorzi, and
document ITU-T Y.3112, Dec. 2018. T. Melodia, ‘‘Sl-EDGE: Network slicing at the edge,’’ 2020,
[15] R. Rokui, S. Homma, D. R. Lopez, X. de Foy, L. M. Contreras-Murillo, arXiv:2005.00886. [Online]. Available: http://arxiv.org/abs/2005.00886
J. J. Ordonez-Lucena, P. Martinez-Julia, M. Boucadair, P. Eardley, [39] B. Xiang, J. Elias, F. Martignon, and E. Di Nitto, ‘‘Joint network slicing
K. Makhijani, and H. Flinck, ‘‘5G transport slice connectivity interface,’’ and mobile edge computing in 5G networks,’’ in Proc. IEEE Int. Conf.
IETF, Fremont, CA, USA, Tech. Rep., Jul. 2019. Commun. (ICC), May 2019, pp. 1–7.
[16] S. Zhang, ‘‘An overview of network slicing for 5G,’’ IEEE Wireless [40] Q. Liu, T. Han, and E. Moges, ‘‘EdgeSlice: Slicing wireless edge com-
Commun., vol. 26, no. 3, pp. 111–117, Jun. 2019. puting network with decentralized deep reinforcement learning,’’ 2020,
[17] X. Li, K. Jiao, F. Jiang, J. Wang, and M. Pan, ‘‘A service-oriented arXiv:2003.12911. [Online]. Available: http://arxiv.org/abs/2003.12911
spectrum-aware RAN-slicing trading scheme under spectrum shar- [41] S. Jošilo and G. Dán, ‘‘Joint wireless and edge computing
ing,’’ IEEE Internet Things J., vol. 7, no. 11, pp. 11303–11317, resource management with dynamic network slice selection,’’ 2020,
Nov. 2020. arXiv:2001.07964. [Online]. Available: http://arxiv.org/abs/2001.07964
[18] S. Sharma, R. Miller, and A. Francini, ‘‘A cloud-native approach to 5G [42] J. Feng, Q. Pei, F. R. Yu, X. Chu, J. Du, and L. Zhu, ‘‘Dynamic network
network slicing,’’ IEEE Commun. Mag., vol. 55, no. 8, pp. 120–127, slicing and resource allocation in mobile edge computing systems,’’ IEEE
Aug. 2017. Trans. Veh. Technol., vol. 69, no. 7, pp. 7863–7878, Jul. 2020.

10922 VOLUME 9, 2021

S. D. A. Shah et al.: Cloud-Native Network Slicing Using SDN Based MEC: A Survey

[43] T. Sanguanpuak, N. Rajatheva, D. Niyato, and M. Latva-aho, ‘‘Network [64] Q. Wang et al., ‘‘SliceNet: End-to-end cognitive network slicing and
slicing with mobile edge computing for micro-operator networks in slice management framework in virtualised multi-domain, multi-tenant
beyond 5G,’’ in Proc. 21st Int. Symp. Wireless Pers. Multimedia Commun. 5G networks,’’ in Proc. IEEE Int. Symp. Broadband Multimedia Syst.
(WPMC), Nov. 2018, pp. 352–357. Broadcast. (BMSB), Jun. 2018, pp. 1–5.
[44] B. Xiang, J. Elias, F. Martignon, and E. Di Nitto, ‘‘Joint planning of [65] H.-T. Chien, Y.-D. Lin, C.-L. Lai, and C.-T. Wang, ‘‘End-to-end slicing
network slicing and mobile edge computing in 5G networks,’’ 2020, as a service with computing and communication resource allocation
arXiv:2005.07301. [Online]. Available: http://arxiv.org/abs/2005.07301 for multi-tenant 5G systems,’’ IEEE Wireless Commun., vol. 26, no. 5,
[45] S. D. A. Shah, D. Kim, P. Khan, H. Kim, and S. Han, ‘‘A two step multi- pp. 104–112, Oct. 2019.
carrier proportional fair scheduling scheme for cloud radio access net- [66] A. Mayoral, R. Vilalta, R. Casellas, R. Martinez, and R. Munoz,
works,’’ Int. J. Interdiscipl. Telecommun. Netw., vol. 10, no. 1, pp. 49–62, ‘‘Multi-tenant 5G network slicing architecture with dynamic deploy-
Jan. 2018. ment of virtualized tenant management and orchestration (MANO)
[46] R. A. Addad, T. Taleb, H. Flinck, M. Bagaa, and D. Dutra, ‘‘Network slice instances,’’ in Proc. 42nd Eur. Conf. Opt. Commun. (ECOC), vol. 2016,
mobility in next generation mobile systems: Challenges and potential pp. 1–3.
solutions,’’ IEEE Netw., vol. 34, no. 1, pp. 84–93, Jan. 2020. [67] I. Afolabi, J. Prados-Garzon, M. Bagaa, T. Taleb, and P. Ameigeiras,
[47] F. De Vita, G. Nardini, A. Virdis, D. Bruneo, A. Puliafito, and G. Stea, ‘‘Dynamic resource provisioning of a scalable E2E network slicing
‘‘Using deep reinforcement learning for application relocation in multi- orchestration system,’’ IEEE Trans. Mobile Comput., vol. 19, no. 11,
access edge computing,’’ IEEE Commun. Standards Mag., vol. 3, no. 3, pp. 2594–2608, Nov. 2020.
pp. 71–78, Sep. 2019. [68] I. Afolabi, A. Ksentini, M. Bagaa, T. Taleb, M. Corici, and A. Nakao,
[48] F. Z. Yousaf, M. Gramaglia, V. Friderikos, B. Gajic, D. von Hugo, ‘‘Towards 5G network slicing over multiple-domains,’’ IEICE Trans.
B. Sayadi, V. Sciancalepore, and M. R. Crippa, ‘‘Network slicing with Commun., vol. E100.B, no. 11, pp. 1992–2006, 2017.
flexible mobility and QoS/QoE support for 5G networks,’’ in Proc. [69] Q. Li, G. Wu, A. Papathanassiou, and U. Mukherjee, ‘‘An end-to-end net-
IEEE Int. Conf. Commun. Workshops (ICC Workshops), May 2017, work slicing framework for 5G wireless communication systems,’’ 2016,
pp. 1195–1201. arXiv:1608.00572. [Online]. Available: http://arxiv.org/abs/1608.00572
[49] F. Meneses, R. Silva, D. Corujo, A. Neto, and R. L. Aguiar, ‘‘Dynamic [70] H. Zhang, N. Liu, X. Chu, K. Long, A.-H. Aghvami, and
network slice resources reconfiguration in heterogeneous mobility envi- V. C. M. Leung, ‘‘Network slicing based 5G and future mobile
ronments,’’ Internet Technol. Lett., vol. 2, no. 4, p. e107, May 2019. networks: Mobility, resource management, and challenges,’’ IEEE
[50] N. Mouawad, R. Naja, and S. Tohme, ‘‘Inter-slice mobility management Commun. Mag., vol. 55, no. 8, pp. 138–145, Aug. 2017.
solution in V2X environment,’’ in Proc. Int. Conf. Wireless Mobile Com- [71] X. Li, M. Samaka, H. A. Chan, D. Bhamare, L. Gupta, C. Guo, and R. Jain,
put., Netw. Commun. (WiMob), Oct. 2019, pp. 1–6. ‘‘Network slicing for 5G: Challenges and opportunities,’’ IEEE Internet
[51] MEC ETSI ISG, ‘‘Multi-access edge computing (MEC); study on MEC Comput., vol. 21, no. 5, pp. 20–27, Sep. 2017.
support for V2X use cases,’’ ETSI, Sophia-Antipolis, France, Tech. Rep. [72] K. Katsalis, N. Nikaein, E. Schiller, A. Ksentini, and T. Braun, ‘‘Network
GR MEC 022, Sep. 2018. slices toward 5G communications: Slicing the LTE network,’’ IEEE
[52] P. Suengyoung, D. Saikia, and K. Seokhwan, ‘‘SDN-based service chain- Commun. Mag., vol. 55, no. 8, pp. 146–154, Aug. 2017.
ing system,’’ U.S. Patent 9 654 395, May 16, 2017. [73] P. Rost, C. Mannweiler, D. S. Michalopoulos, C. Sartori,
[53] J. Matias, J. Garay, N. Toledo, J. Unzilla, and E. Jacob, ‘‘Toward an V. Sciancalepore, N. Sastry, O. Holland, S. Tayade, B. Han, D.
SDN-enabled NFV architecture,’’ IEEE Commun. Mag., vol. 53, no. 4, Bega, D. Aziz, and H. Bakker, ‘‘Network slicing to enable scalability
pp. 187–193, Apr. 2015. and flexibility in 5G mobile networks,’’ IEEE Commun. Mag., vol. 55,
[54] J. Ordonez-Lucena, P. Ameigeiras, D. Lopez, J. J. Ramos-Munoz, no. 5, pp. 72–79, May 2017.
J. Lorca, and J. Folgueira, ‘‘Network slicing for 5G with SDN/NFV: [74] M. Vincenzi, A. Antonopoulos, E. Kartsakli, J. Vardakas, L. Alonso,
Concepts, architectures, and challenges,’’ IEEE Commun. Mag., vol. 55, and C. Verikoukis, ‘‘Multi-tenant slicing for spectrum management on
no. 5, pp. 80–87, May 2017. the road to 5G,’’ IEEE Wireless Commun., vol. 24, no. 5, pp. 118–125,
[55] I. F. Akyildiz, S.-C. Lin, and P. Wang, ‘‘Wireless software-defined net- Oct. 2017.
works (W-SDNs) and network function virtualization (NFV) for 5G cel- [75] A. Rostami, P. Öhlén, M. A. S. Santos, and A. Vidal, ‘‘Multi-domain
lular systems: An overview and qualitative evaluation,’’ Comput. Netw., orchestration across RAN and transport for 5G,’’ in Proc. ACM SIG-
vol. 93, pp. 66–79, Dec. 2015. COMM Conf., Aug. 2016, pp. 613–614.
[56] X. Li, R. Casellas, G. Landi, A. de la Oliva, X. Costa-Perez, [76] G. Tseliou, F. Adelantado, and C. Verikoukis, ‘‘A base station agnostic
A. Garcia-Saavedra, T. Deiss, L. Cominardi, and R. Vilalta, ‘‘5G- network slicing framework for 5G,’’ IEEE Netw., vol. 33, no. 4, pp. 82–88,
crosshaul network slicing: Enabling multi-tenancy in mobile transport Jul. 2019.
networks,’’ IEEE Commun. Mag., vol. 55, no. 8, pp. 128–137, Aug. 2017. [77] A. Boubendir, F. Guillemin, C. Le Toquin, M.-L. Alberi-Morel,
[57] S. K. Fayazbakhsh, V. Sekar, M. Yu, and J. C. Mogul, ‘‘FlowTags: F. Faucheux, S. Kerboeuf, J.-L. Lafragette, and B. Orlandi, ‘‘Federation of
Enforcing network-wide policies in the presence of dynamic middlebox cross-domain edge resources: A brokering architecture for network slic-
actions,’’ in Proc. 2nd ACM SIGCOMM Workshop Hot Topics Softw. ing,’’ in Proc. 4th IEEE Conf. Netw. Softwarization Workshops (NetSoft),
Defined Netw. (HotSDN), 2013, pp. 19–24. Jun. 2018, pp. 415–423.
[58] Z. A. Qazi, C.-C. Tu, L. Chiang, R. Miao, V. Sekar, and M. Yu, ‘‘SIMPLE- [78] R. A. Addad, M. Bagaa, T. Taleb, D. L. C. Dutra, and H. Flinck,
fying middlebox policy enforcement using SDN,’’ ACM SIGCOMM ‘‘Optimization model for cross-domain network slices in 5G net-
Comput. Commun. Rev., vol. 43, no. 4, pp. 27–38, Sep. 2013. works,’’ IEEE Trans. Mobile Comput., vol. 19, no. 5, pp. 1156–1169,
[59] N. Akhtar, I. Matta, A. Raza, L. Goratti, T. Braun, and F. Esposito, ‘‘Vir- May 2020.
tual function placement and traffic steering over 5G multi-technology [79] J. Ordonez-Lucena, C. Tranoris, J. Rodrigues, and L. M. Contreras,
networks,’’ in Proc. 4th IEEE Conf. Netw. Softwarization Workshops ‘‘Cross-domain slice orchestration for advanced vertical trials in a multi-
(NetSoft), Jun. 2018, pp. 114–122. vendor 5G facility,’’ in Proc. Eur. Conf. Netw. Commun. (EuCNC),
[60] J. Wang and M. Luo, ‘‘Packet prioritization in a software-defined network Jun. 2020, pp. 40–45.
implementing OpenFlow,’’ U.S. Patent 9 923 831, Mar. 20, 2018. [80] K. Gillani and J.-H. Lee, ‘‘Comparison of linux virtual machines and
[61] N. Kitsuwan and E. Oki, ‘‘Implementation of traffic splitting using containers for a service migration in 5G multi-access edge computing,’’
meter table in software-defined networking,’’ J. Eng., vol. 2017, no. 12, ICT Exp., vol. 6, no. 1, pp. 1–2, Mar. 2020.
pp. 662–665, Dec. 2017. [81] M. Chae, H. Lee, and K. Lee, ‘‘A performance comparison of Linux con-
[62] M. K. Jaiswal, ‘‘Introduction to OpenFlow,’’ in Innovations in Software- tainers and virtual machines using docker and KVM,’’ Cluster Comput.,
Defined Networking and Network Functions Virtualization. Hershey, PA, vol. 22, no. S1, pp. 1765–1775, Jan. 2019.
USA: IGI Global, 2018, pp. 52–71. [82] S. K. Guru, M. V. T. Patil, and A. Dhus, ‘‘Survey on docker,’’ Nat. J.
[63] P. K. Chartsias, A. Amiras, I. Plevrakis, I. Samaras, K. Katsaros, Comput. Appl. Sci., vol. 2, no. 3, pp. 5–9, Oct. 2019.
D. Kritharidis, E. Trouva, I. Angelopoulos, A. Kourtis, M. S. Siddiqui, [83] G. A. Carella, M. Pauls, T. Magedanz, M. Cilloni, P. Bellavista, and
A. Vines, and E. Escalona, ‘‘SDN/NFV-based end to end network slic- L. Foschini, ‘‘Prototyping NFV-based multi-access edge computing in 5G
ing for 5G multi-tenant networks,’’ in Proc. Eur. Conf. Netw. Commun. ready networks with open baton,’’ in Proc. IEEE Conf. Netw. Softwariza-
(EuCNC), Jun. 2017, pp. 1–5. tion (NetSoft), Jul. 2017, pp. 1–4.

VOLUME 9, 2021 10923

 S. D. A. Shah et al.: Cloud-Native Network Slicing Using SDN Based MEC: A Survey

[84] M. Peuster, H. Karl, and S. van Rossem, ‘‘MeDICINE: Rapid prototyping [102] F. De Vita, G. Nardini, A. Virdis, D. Bruneo, A. Puliafito, and G. Stea,
of production-ready network services in multi-PoP environments,’’ in ‘‘Using deep reinforcement learning for application relocation in multi-
Proc. IEEE Conf. Netw. Function Virtualization Softw. Defined Netw. access edge computing,’’ IEEE Commun. Standards Mag., vol. 3, no. 3,
(NFV-SDN), Nov. 2016, pp. 148–153. pp. 71–78, Sep. 2019.
[85] A. Israel, A. T. Sepulveda, A. Reid, F. Vicens, F. J. R. Salguero,
G. G. de Blas, G. Lavado, M. Shuttleworth, M. Harper, and M. Marchetti
‘‘OSM release FIVE technical overview,’’ ETSI White Paper, Jan. 2019.
[86] J. Shah and D. Dubaria, ‘‘Building modern clouds: Using docker, kuber-
netes & Google cloud platform,’’ in Proc. IEEE 9th Annu. Comput.
Commun. Workshop Conf. (CCWC), Jan. 2019, pp. 0184–0189. SYED DANIAL ALI SHAH received the B.S.
[87] E. Casalicchio, ‘‘Container orchestration: A survey,’’ in Proc. Syst. Mod- degree from the University of Engineering
eling, Methodol. Tools, 2019, pp. 221–235. and Technology, Taxila, Pakistan, in 2016, and
[88] G. Merlino, R. Dautov, S. Distefano, and D. Bruneo, ‘‘Enabling workload the master’s degrees in research from Incheon
engineering in edge, fog, and cloud computing through openstack-based National University (INU), South Korea, in 2018.
middleware,’’ ACM Trans. Internet Tech., vol. 19, no. 2, pp. 1–22, 2019. He is currently pursuing the Ph.D. degree with
[89] J. Hao, K. Ye, and C.-Z. Xu, ‘‘Live migration of virtual machines in the School of Engineering, RMIT University,
OpenStack: A perspective from reliability evaluation,’’ in Proc. Int. Conf.
Melbourne, Australia. He worked as a Research
Cloud Comput., 2019, pp. 99–113.
Assistant with INU for two years. He is currently
[90] Y. Xiong, Y. Sun, L. Xing, and Y. Huang, ‘‘Extend cloud to edge with
KubeEdge,’’ in Proc. IEEE/ACM Symp. Edge Comput. (SEC), Oct. 2018, an Academic Staff with the School of Engineering,
pp. 373–377. RMIT University. His research interests include 5G/6G, cloud/edge comput-
[91] Cloud-Native and Verticals’ Services, 5G-PPP, 5G-PPP Software Net- ing, software-defined wireless networks, vehicular networks, and network
work Working Group, Aug. 2019. design.
[92] I. Parvez, A. Rahmati, I. Guvenc, A. I. Sarwat, and H. Dai, ‘‘A sur-
vey on low latency towards 5G: RAN, core network and caching solu-
tions,’’ IEEE Commun. Surveys Tuts., vol. 20, no. 4, pp. 3098–3130,
4th Quart., 2018.
[93] R. Morabito, V. Cozzolino, A. Y. Ding, N. Beijar, and J. Ott, ‘‘Consolidate MARK A. GREGORY (Senior Member, IEEE)
IoT edge computing with lightweight virtualization,’’ IEEE Netw., vol. 32, received the Ph.D. degree from RMIT University,
no. 1, pp. 102–111, Jan. 2018. Melbourne, Australia, in 2008. He is currently an
[94] G. Avino, M. Malinverno, F. Malandrino, C. Casetti, and Associate Professor with the School of Engineer-
C. F. Chiasserini, ‘‘Characterizing docker overhead in mobile edge ing, RMIT University. In 2009, he received an
computing scenarios,’’ in Proc. Workshop Hot Topics Container Netw.
Australian Learning and Teaching Council Cita-
Networked Syst., Aug. 2017, pp. 30–35.
tion for an outstanding contribution to teach-
[95] C. Campolo, A. Iera, A. Molinaro, and G. Ruggeri, ‘‘MEC support for
5G-V2X use cases through docker containers,’’ in Proc. IEEE Wireless ing and learning. His research interests include
Commun. Netw. Conf. (WCNC), Apr. 2019, pp. 1–6. telecommunications, network design, 5G/6G, and
[96] S. Kriss, A. Amarnath, C. Campos, N. Brubaker, T. Hinderliter, and technical risk management. He is a fellow of the
S. Bauman. (2019). Backup and Migrate Kubernetes Appli- Institute of Engineers Australia. He is also the Managing Editor of two
cations and Their Persistent Volumes. [Online]. Available: international journals, such as the Australian Journal of Telecommunications
https://github.com/vmware-tanzu/velero and the Digital Economy (AJTDE) and International Journal of Information,
[97] M. Katz, M. Matinmikko-Blue, and M. Latva-Aho, ‘‘6Genesis flagship Communication Technology and Applications (IJICTA) and the General
program: Building the bridges towards 6G-enabled wireless smart society Co-Chair of ITNAC.
and ecosystem,’’ in Proc. IEEE 10th Latin-Amer. Conf. Commun. (LAT-
INCOM), Nov. 2018, pp. 1–9.
[98] A. Ndikumana, N. H. Tran, T. M. Ho, Z. Han, W. Saad, D. Niyato, and
C. S. Hong, ‘‘Joint communication, computation, caching, and control
in big data multi-access edge computing,’’ IEEE Trans. Mobile Comput., SHUO LI (Member, IEEE) received the B.S.
vol. 19, no. 6, pp. 1359–1374, Jun. 2020.
and Ph.D. degrees from the City University of
[99] Y. Zhou, L. Liu, L. Wang, N. Hui, X. Cui, J. Wu, Y. Peng, Y. Qi, and
Hong Kong, in 2009 and 2014, respectively. She
C. Xing, ‘‘Service-aware 6G: An intelligent and open network based
on the convergence of communication, computing and caching,’’ Digit. worked as a Lecturer with Tianjin University,
Commun. Netw., vol. 6, no. 3, pp. 253–260, Aug. 2020. China, from 2014 to 2017. She is currently a Lec-
[100] P. Bellavista, A. Corradi, L. Foschini, and D. Scotece, ‘‘Differentiated turer with the School of Engineering, RMIT Uni-
service/data migration for edge services leveraging container characteris- versity, Australia. Her research interests include
tics,’’ IEEE Access, vol. 7, pp. 139746–139758, Sep. 2019. telecommunications, analysis and design of opti-
[101] A. Machen, S. Wang, K. K. Leung, B. J. Ko, and T. Salonidis, ‘‘Live cal networks, 5G/6G core networks, and underwa-
service migration in mobile edge clouds,’’ IEEE Wireless Commun., ter sensor networks.
vol. 25, no. 1, pp. 140–147, Feb. 2018.

10924 VOLUME 9, 2021