Dynamic Network Slicing for 5G IoT and eMBB services: A New Design with Prototype and Implementation Results

Full text

Dynamic Network Slicing for 5G IoT and eMBB
services: A New Design with Prototype and
Implementation Results
Salvatore Costanzo∗, Ilhem Fajjari†, Nadjib Aitsaadi‡and Rami Langar§
∗Sorbonne University, CNRS, LIP6 UMR 7606, F-75005 Paris, France
†Orange-Labs, F-92320 Chˆ
atillon, France
‡University Paris-Est, LIGM-CNRS UMR 8049, ESIEE Paris: F-93162, Noisy-le-Grand, France
§University Paris-Est, LIGM-CNRS UMR 8049, UPEM, F-77420, Marne-la-Vall´
ee, France
Emails: Salvatore.Costanzo@lip6.fr, ilhem.fajjari@orange.com, nadjib.aitsaadi@esiee.fr, rami.langar@u-pem.fr
Abstract—Recent progress in sensor and communications have
opened the road for the ever-growing development of Internet of
Things (IoT) services, where a massive number of devices require
access to the transport network, using widely deployed fixed or
wireless access technologies and/or mobile Radio Access Network
(RAN). Supporting IoT in the RAN is challenging, as IoT services
may generate a multitude of short and bursty sessions, thus
impacting the performances of mobile users sharing the same
RAN. To this end, network slicing is envisioned as a promising
design approach to enable optimal support for heterogeneous
service segments sharing the same RAN, i.e., the key requirement
of the upcoming fifth generation (5G) mobile network.
In this paper, we propose a network slicing solution for
enabling efficient coexistence of enhanced mobile broadband
(eMBB) and IoT services, sharing the same RAN. Our solution
aims at efficiently sharing the bandwidth resources among
different slice segments, while considering their requirements.
We validate the proposed solution in a 5G prototype based on
the Cloud Radio Access Network (C-RAN) architecture, which
makes use of the Open Air Interface (OAI) platform and the
FlexRAN SDN controller. The main goal of our work is to validate
the feasibility of the prototype of supporting the creation and
configuration of network slices on-demand, taking into account
diverse requirements that are elaborated by a northbound SDN-
based slicing application. By means of emulations, we show
that the prototype is capable to dynamically manage the slicing
process in real-time, providing isolation among eMBB and IoT
services.
Keywords:5G, Network Slicing, Open Air Interface, IoT,
eMBB.
I. INTRODUCTION
The fifth generation (5G) network is expected to accommo-
date a multitude of services, with heterogeneous requirements.
To this end, the International Telecommunication Union (ITU)
and Fifth Generation Public Private Partnership (5G-PPP)
have identified three categories of services to be handled
by 5G [1]: Enhanced Mobile Broadband (eMBB), massive
Machine-Type communications (MMTC), and Ultra-Reliable
and Low Latency communications (URLLC). Among these
categories, several use-cases can be defined, varying from
general broadband cellular systems to Internet of Things (IoT)
networks [2]. All these services require a set of heterogeneous
requirements that cannot be satisfied by the traditional one-
sizefits-all architecture. To this end, alternative architectural
choices are required to handle all these heterogeneous services
in an efficient manner.
With this in mind, 5G is being designed with a pro-
grammable and a flexible infrastructure, allowing different
services (e.g., IoT, cellular, vehicular, etc.) to share the same
radio access network (RAN), while guaranteeing Quality of
Service (QoS) and Service Level Agreement (SLA). Besides,
the concept of Network Slicing is employed for enabling
efficient coexistence of heterogeneous services in the same
shared network. According to the Next Generation Mobile
Networks (NGMN) Alliance’s vision for 5G [3], slices are
defined as end-to-end self-contained logical networks, which
can be controlled and managed in an independent way by the
slices’ owners, such as Over-The-Top (OTT) service providers
and Mobile Virtual Network Operators (MVNOs).
The new emerging network virtualization technologies, like
as Software Defined Networking (SDN) [4] and Network
Function Virtualization (NFV) [5], are envisioned as the key
enabling approaches of network slicing, by providing the
required tools to virtualize the physical resources and allocate
them to the logical slices in an efficient way. Moreover, SDN
and NFV provide the appropriate tools to orchestrate the un-
derlying resources and enables the coexistence of independent
slices within the same physical infrastructure.
In this paper, we put forward a Software Defined Radio
(SDR) prototype for testing network slicing in the Cloud
Radio Access Network (C-RAN) [6], which make use of
both OpenAirInterface (OAI) [7] platform and FlexRAN SDN
Controller [8]. Our prototype enables efficient sharing of the
RAN resources among diverse services, i.e., IoT and eMBB
slices respectively. Supporting IoT is challenging, as IoT traffic
is characterized by bursty sessions that may impact the regular
operation of mobile services. To this end, we propose to
dynamically scale in/scale out the size of each slice, i.e., the
amount of radio resource blocks (RBs), in accordance to the
traffic profile of the IoT services.

Our contribution is the design and implementation of a
northbound SDN application, which enables the creation and
configuration of IoT slices on demand, while considering
the requirements of the eMBB services. To do so, we put
forward a first algorithm to evaluate the effective capability
of the prototype to configure slices on-demand according to
predefined set of inputs. By means of emulations, we show that
the prototype is capable of handling IoT and eMBB slices in
real-time while providing isolation among them.
The reminder of this paper proceeds as follows. In Sec-
tion II, we provide an overview of the state of the art
network slicing solutions for 5G networks. In Section III,
we present the proposed network slicing solution, followed
by a description of our prototype architecture in Section IV.
In Section V, we evaluate the performances of the proposed
network slicing solution and we provide some insights for
future work in Section VI, which concludes the paper.
II. RE LATE D WO RK
The current literature presents several architectures for
network slicing. Some works focus on evaluating the impact
of network programmability and network slicing on certain
5G services, while others analyze the slicing as a RAN
sharing issue. To this end, 3GPP has highlighted the service
and business requirements for realizing the so-called network
sharing paradigm [9] and defined two main models for RAN
sharing, referred to as Multi-Operator Core Network (MOCN)
and Gateway Core Network (GWCN), respectively. In the
MOCN scenario, the RAN spectrum is shared among multiple
operators, while in the GWCN scenario, both the RAN and
the core network are shared among multiple operators. In this
paper, we refer to the MOCN use case, wherein the RAN is
assumed to be shared among diverse slices.
In the context of RAN sharing, authors in [10] propose
the concept of on-demand capacity broker to enhance the
RAN sharing flexibility. The on-demand capacity broker aims
at enabling more flexibility in the resource allocation by
allowing a host RAN provider to allocate a portion of net-
work capacity for a specific time period to MVNO or OTT
service provider via signaling mean. Similar to [10], in this
paper we propose a resource allocation approach for enabling
flexible sharing of resources among multiple slices. However,
differently from [10], we propose a dynamic slicing solution
that makes use of an SDN approach and we evaluate the the
proposed solution by prototyping a C-RAN testbed using SDR
platforms.
In [11], authors propose an enhanced architecture for the
scheduler of a shared Long Term Evolution (LTE) eNodeB
(eNB), wherein an entity called Hypervisor, virtualizes the
physical resources into a number of slices and allocate each
slice to a different virtual operator according to predefined
SLA. In [12], authors propose a solution for virtualizing the
LTE eNB hardware by creating logically independent virtual
base stations, that enables resource isolation and coexistence of
independent policies among different virtual eNBs instances.
Although the results in [11] [12] are promising, these models
Fig. 1: Reference Scenario
have not been tested in real 5G testbeds and do not take into
account the constraints of future 5G architectures.
In [13], authors propose an architecture for enabling slicing
in a RAN shared by multiple MVNOs, which makes use
of logically centralized controller for managing the creation
and configuration of slices in a dynamic fashion. However,
the proposed architecture makes use of a theoretical model,
which hasn’t been validated in a 5G scenario. In [14], authors
put forward a framework to evaluate the potential benefits
offered by an application-oriented network slicing approach
and evaluate the performances of high priority and low priority
traffic in a 5G slicing scenario by means of a simulation
campaign. Different from [13] and [14], in this paper, we
investigate the impact of slicing in a C-RAN architecture using
a real SDN controller and we perform diverse emulations to
validate the proposed slicing solution in a real 5G prototype.
In [15], the authors propose a framework to enforce network
slices in an OAI-based testbed and provide an initial perfor-
mance evaluation of a scenario with multiple slices sharing
a single RAN and with multiple core networks. Differently
from [15], in this paper, we mainly focus on the resource
allocation issue and we propose a dynamic slicing approach
with the aim to validate the isolation property, which is a key
enabler for an efficient slicing.
III. PROP OS ED NE TW OR K SLICING SOLUTION
In this section, we detail our SDN-based network slicing
solution, which enables flexible spectrum sharing between
multiple slices, while ensuring isolation between them. In
particular, we consider the reference scenario depicted in
Fig. 1. We assume the presence of two type of devices:
IoT nodes and mobile smart-phones. The IoT devices are
connected to the RAN via a 5G gateway. The IoT gateway
collects the IoT data periodically and establishes a connection
with the C-RAN network when it needs to deliver the collected
data to the cloud. The C-RAN network consists of an SDN
architecture, where a logical centralized controller handles the

Fig. 2: Proposed SDN-based Scheduler
slicing process in real time, taking into account the global
view of the network state offered by the SDN paradigm. More
specifically, the slicing process is performed at the northbound
“Slicing APP”, which consists of two different modules, one
for each traffic’s category. The first module, referred to as “IoT
APP”, stores the IoT related traffic information, e.g., the traffic
profile of the IoT devices including the estimated time of the
peak sessions. The information about the traffic profile can be
obtained by the RAN Information Base (RIB), i.e., a database
containing various users’ performance metrics. Accordingly,
the “4G/5GAPP” analyzes the mobile traffic, identifying the
amount of resources that are needed to satisfy the mobile
users’ QoS requirements. Finally, the “Slicing APP” identifies
the amount of resources to be allocated to each slice, taking
into account each slice’s traffic profile, while guarantying the
QoS of the whole system.
The slicing process is then implemented in an SDN-based
fashion, according to the policy employed at the “Slicing
APP”. The building blocks of the proposed slicing process
are described in more details in the following Section III-A.
While, in Section III-B, we describe the northbound “Slicing
APP” application, which we have developed to enable dynamic
slicing of the radio resources among IoT and eMBB services.
A. Network Slicing Scheduler
We put forward a network slicing approach for sharing
the bandwidth resources among IoT and eMBB slices, which
make use of a slicing scheduling algorithm, that is driven
by a centralized SDN controller. We propose to transform
the conventional LTE scheduler operation into an SDN-based
solution, where the control plane of the MAC layer is separated
by the data plane and executed as a northbound application in
a centralized SDN Controller, hosted at the cloud site.
We recall, that in the conventional architectures, the control
part of the MAC, dealing with scheduling decisions, and
the action part, which is responsible for the execution of
the scheduling decision, are merged together. Accordingly,
the radio resources are scheduled among multiple services
according to a specific scheduling policy, that is implemented
by the network operator at the RAN access points, i.e., eNBs.
It is worth to note that the proprietary nature of the RAN
equipment prevents the implementation of novel policies for
adapting the RAN to new services, e.g., IoT, in a flexible and
efficient manner. By using SDN, we aim at opening the road
for a more flexible scheduling approach, i.e., the key enabling
action for efficient network slicing.
The building blocks of the proposed approach are depicted
in Fig. 2. In our approach, the eNB is freed from the control
responsibilities and only handles the RB allocation based on
the scheduling decision made by the SDN controller. The
eNB is equipped with an “Agent” software, that interfaces
the “Slicing Scheduler” module with the SDN controller via
an appropriate SouthBound Interface (SBI). The scheduling
decision is remotely taken at the “Slicing APP”, taking into
account the requirements of the IoT and eMBB services
respectively. The details of such a northbound application are
provided in Section III-B.
More specifically, the slices’ owners, i.e., IoT and 4G/5G
APPs, can communicate a service request to the SDN “Slicing
APP” via a NorthBound Interface (NBI). For instance, the
slice’s owner may request an amount of resources for a
number of users which are located in a specific area, while
guaranteeing a specific QoS target. Accordingly, the SDN
Controller, in cooperation with the northbound “Slicing APP”,
firstly performs an admission control. To do so, it verifies that
the service request is in line with pre-established SLAs and
that the required QoS target can be matched according to the
real-time network state. Secondly, it takes the so-called slicing
decision. Hence, it allocates a slice to the slice’s owner, by
setting the following parameters:
•Size: corresponds to the total number of RBs to be used
from that slice.
•Duration of the slice: is expressed in number of trans-
mission time interval (TTI).
•QoS target: refers to the required network performances
(e.g., the throughput target) for aggregate traffic within
the slice.
Once the slicing decision is taken, the SDN Slicing Controller
communicates with the eNB agent, through the SBI interface.
Finally, the “Slicing Scheduler” module instantiates the slices
by reserving an appropriate portion of the bandwidth (i.e., an
amount of RBs) to each slice’s owner in accordance to the
slicing decision carried out by the SDN “Slicing Controller”.
The proposed slicing scheduler architecture offers the ca-
pability to acquire the total control over the RB allocation
process within its reserved slice. In fact, the slice’s owner may
define its own policies independently of other slices’ owners. It
is straightforward to see that such a hierarchical design offers
a high flexibility and guarantees a fair cohabitation between
different slices. More specifically, the slice’s owner communi-
cates its scheduling decision to the SDN “Slicing APP” that, in
turns, configures the “Slicing Scheduler” function accordingly.
Finally, the “Slicing Scheduler” will allocate the RBs within

each slice according to the scheduling decision of each slice’s
owner.
B. SDN Northbound APP for IoT Slicing Management
In this paper, we target both a qualitative and quantitative
evaluation of our SDN-based slicing solution. To do so, we
need to evaluate the capacity of our approach to accommodate,
in real-time, the outputs received by a centralized resource
slicing allocation algorithm, hosted in an SDN controller. To
this end, we have developed a northbound “Slicing APP”,
which enables any user of our prototype to configure the
slicing process in real-time via a web GUI, as illustrated in
Fig. 3. By means of the “Slicing APP”, the users of our
prototype can experiment our slicing solution and manually set
the size of each slice for testing purposes. It is worth noting
that, the configuration of the slicing process can be also done
automatically making use of a dynamic slicing algorithm.
To put forward the interest of our SDN-based slicing
solution, we have developed a dynamic allocation algorithm
for the “Slicing APP”. The latter configures the size of both
IoT and eMBB slices in real-time, taking into account the
amount of RBs which are effectively required by each slice
and the number of RBs currently used by each slice. To this
end, the traffic profile is taken into account for predicting the
peak sessions of the IoT traffic. Note that in this paper we
assume a scenario where the IoT traffic is characterized by
periodical peak sessions, while a regular traffic profile for the
eMBB services is assumed, e.g., the mobile users are assumed
to stream videos during the whole emulation period.
The main idea of our solution is to proactively allocate
additional RBs to the IoT slice before the peaks, in order to
mitigate the impact of IoT peak sessions on the performance
of the eMBB services. Each slice is then scaled-in/scaled-out
Algorithm 1 Dynamic Slicing for IoT
SETsI oT =IoT slice
SETsMob=Mobile Traffic slice
for tti ∈Tdo
RB R(T T I , sIoT )=#RB s alloc(T T I,sI oT )
#RBs req uired(T T I,sI oT )
RB R∆(sI oT ) = AV G(RB R(T T I, sI oT )),∆T)
if RB R∆(sI oT )≤T hrIoT (sI oT )then
/*Triggering of IoT peak session */
setSize(sI oT )[TTI+1]=Size(sI oT )[TTI]+
+%Size(sMob)[TTI]
setSize(sMob)[TTI+1 ]=Size(sM ob)[TTI]+
-%Size(sI oT )
else
setSize(sMob)[TTI+1 ]=Size(sM ob)[TTI]+
+%Size(sI oT )
/*End of IoT peak session: the IoT resources are
redistruibited to the mobile users*/
end if
end for
Fig. 3: C-RAN Prototype
according to the its resource allocation satisfaction. The latter,
denoted by RB R(T T I , s), is defined as the ratio between the
number of RBs allocated and the number of RBs which are
actually required by a specific slice at that TTI. The average
value of RB R(T T I, s), calculated in a temporal window
∆T, is taken into account to dynamically adapt the size of
each slice as follows. If that value, denoted by RB R∆(s)is
less than a specific threshold, then the “Slicing App” exploits
the RB R∆of the other slices in order to identify a slice
whose performance is higher than a slice-specific threshold.
If that slice is identified, the “Slicing APP” will transfer a
percentage of the bandwidth from that slice to the other one
that is experiencing worse performances. By doing so, we
exploit the unused RBs of a specific slice and distribute them
to a slice having worst performance.
It is worth to note that at the beginning of the IoT peak
sessions, the value of RB R∆(s)will be very low, as the
amount of RB required from IoT traffic in that TTI is much
higher that in previous time intervals. Indeed, a low value
of RB R∆(s)can be used to identify the starting of an
IoT peak session and trigger an appropriate scale-in/scale-
out action. More specifically, in order to satisfy both slices’
requirements, we assume to allocated more RBs to the IoT
slice once the peak session is triggered, while redistributing the
unused RBs to the mobile users in the other time intervals. The
performances of the mobile users, e.g., the ones who stream
videos continuously, are guaranteed because they will get
allocated more RBs than required during the quite IoT periods.
The additional allocated RBs will be used to save additional
video frames in the buffer, thus preserving the quality of the
video streaming operation during the IoT peaks. In this way,
the IoT performances are guaranteed during the peak sessions
from one hand, while maintaining the QoS requirements of
mobile users on the other hand. More formally, the pseudo-
code of the proposed dynamic slicing algorithm is detailed in
Algorithm 1.

TABLE I: Emulation Parameters
Parameter Value
#RRU 1
#RCC 1
#Slices 2
Slice Thr() for asking more RBs 0.5
Slice Thr() for donating RBs 0.8
CRAN Splitting Type NGFI RCC IF4p5
Bandwidth 6MHz (25 RBs)
Frame type FDD
PDSCH reference Signal Power −24 dBm
PUSCH p0Nominal power −96 dBm
Scheduler Downlink Proportional Fair
Application Traffic Model Video Stream + IoT
IV. EXP ER IM EN TAL PLATF OR M
In this section, we present the technical details of the
experimental platform, that we implemented to evaluate the
performance of our SDN-based slicing solution.
Our prototype, illustrated in Fig. 3, makes use of OAI soft-
ware [7] and FlexRAN SDN controller [8]. It is in accordance
with the NGFI C-RAN architecture [16], wherein the baseband
processing functions are carried out at the Radio Cloud Center
(RCC) node, which in turns sends I/Q samples to the Radio
Remote Unit (RRU) via a fronthaul interface. Note that the
prototype relies on an Ethernet-based fronthaul to interconnect
RCC and RRU. The C-RAN architecture adopts the IF4p5
splitting [16] provided by OAI. It is worth noting that IF4p5
refers to the split-point at the input (TX) and output (RX)
of the OFDM symbol generator. More details about the C-
RAN splitting solutions, made available by OAI, are provided
in [16].
In our prototype, the RRU consists of an Ettus USRP B210
card [17] which is connected to a server via USB 3.0interface.
The server has a processor power (CPU) Intel Core i7-3770 8-
core (@3GHz), and a Random Access Memory (RAM) of 16
GB performances. It is running with “Ubuntu 14.04” operating
system characterized by “Linux kernel” release 3.19.0-61-
lowlatency SMP PREEMPT and has 1Gigabit Ethernet port.
The RRU is connected to the RCC through Ethernet cable.
The RCC, which implements the remaining levels of the
LTE protocol stack in accordance with IF4p5, consists in
a laptop, characterized by i7−6500U4-core (@2.50GHz)
CPU and RAM of 16 GB. The latter is running with the
same operating system as the RRU. Upon the aforementioned
operating system, we run a VMware Ubuntu 14.04 Virtual
Machine where all the functionalities of the Evolved Packet
Core (EPC) are implemented by the OAI software.
The RCC runs an SDN controller, which is based on
the FlexRAN controller [8]. FlexRAN is a controller that is
capable of communicating with the OAI platform through a
specific southbound Application Programming Interface (API)
which makes use of Google Protobuf [8]. More specifically,
FlexRAN encompasses two main entities: i) Master Controller
Fig. 4: Traffic Profile
and ii) Agent. The Master Controller is connected to the Agent,
which corresponds to the software module built within the
software of the OAI eNB. The FlexRAN Agent corresponds to
the entity that separates the control plane and data plane of the
OAI software and acts as a southbound interface between the
control plane, which is moved to the Master Controller side,
and the data plane which is kept at the eNB side. By means of
the SBI interface, the Master Controller can interact with the
Agent and hence collects information about the network state
of the RAN. Moreover, the Master Controller makes available
a NBI interface which can be used by northbound applications
in order to manage the RAN environment in an abstracted
way. Note that the implementation details of the FlexRAN
Controller are provided in [8].
On the top of SDN Slicing Controller, we have implemented
our northbound “Slicing APP” application, which provides an
elastic network slicing solution in C-RAN by leveraging the
centralized control offered by SDN, as stated in Section III-B.
Finally, our prototype is completed by two smartphones for
emulating the eMBB slice, which act as Commercial Off-the-
Shelf (COTS) user equipment (UEs). Another COTS UE acts
as a 5G IoT gateway, emulating the traffic profile of an IoT
network.
V. PERFORMANCE EVALUATION
To assess the feasibility and gauge the efficiency of our
SDN-based slicing solution, we have performed diverse emu-
lations to assess the feasibility of employing network slicing
solutions in the prototype described in Section IV. The emu-
lation parameters are reported in Table I.
In the emulations, we assume the presence of two slices:
eMBB and IoT. The traffic of the eMBB slice is emulated
by 2COTS UEs, that stream an H.264 encoded test video,
with an overall bit rate of 250 Mbps, a 3840x2160 resolution
and total size of 897 MB. The IoT traffic is generated by
1COTS UE, that emulates an IoT gateway by generating
IoT traffic according to the profile depicted in Fig. 4. More
specifically, Fig. 4 shows the amount of RBs that are required

Fig. 5: Average DL Throughput
by each slice for the whole duration of the emulation, i.e.,
300 s. As it can be seen from Fig. 4, the IoT traffic profile
is characterized by two peak sessions, while the eMBB traffic
profile is more regular. Note that the numerical values, shown
in Fig. 4, have been obtained by observing the amount of RBs,
that may be requested by each slice in a scenario where the
whole bandwidth is made available for that slice.
According to the aforementioned traffic profile assumption,
in our emulations we define two scenarios as follows. The first
one, named Baseline (BL), corresponds to the conventional
scenario, where the total bandwidth is shared among the COTS
UEs, and no slices are instantiated. The second scenario,
named Slicing, employs the proposed slicing solution, wherein
the bandwidth resources are split in 2slices and the configu-
ration of the slices is dynamically performed, according to the
algorithm described in section III-B.
Fig. 5 depicts the average throughput, in downlink (DL),
measured in both eMBB and IoT slices, during a period of
300 s. From Fig. 5 it can be observed that the performance
of both eMBB and IoT users are improved compared to the
BL scenario (i.e., conventional scheduler). In fact, it can be
observed that in the BL scenario, the throughput of the eMBB
users tends to decrease during the IoT peak sessions. This
behavior can be explained as follows. In the BL scenario, a
Proportional Fair (PF) scheduler is employed and the eMBB
and IoT traffic is not isolated, as opposed to the Slicing sce-
nario. Consequently, the increasing load of IoT traffic impacts
the scheduling operation, which, in turn, tries to allocate more
RBs to the IoT UEs to achieve a fairness among all the
traffic flows. Conversely, an up to double throughput gain is
observed for the eMBB users in the Slicing scenario, especially
during the IoT peak sessions. This gain comes by the policy
employed by the Algorithm 1, that efficiently redistributes the
RBs among the 2slices, predicting the IoT traffic demands
by monitoring the RB R∆(s)in real-time. Moreover, Fig. 5
provides an important result in terms of validation of our
slicing solution. In fact, as it can be seen, these emulations
have demonstrated and validated the Isolation property of
slicing in the C-RAN testbed, i.e., the performances of eMBB
Fig. 6: cCDF of RB R
users are not strongly impacted by the IoT peak sessions.
Fig. 6 shows the complementary CDF (cCDF) of the
RB R(T T I , s)value, defined in Section III-B, which pro-
vides an estimation of the resource allocation satisfaction
of each slice in the two different aforementioned scenarios.
Interestingly, we can observe that the probability for the IoT
and eMBB slice to get a 50% satisfaction in the resource
allocation process is 10% and 30% higher than in the BL
scenarios, respectively. Moreover, the performance of eMBB
slice is slightly improved, due to the employment of the
aforementioned dynamic slicing allocation policy.
In Fig. 7, we evaluate the delay jitter of the eMBB and
IoT traffic in the BL and slicing scenarios respectively. In
particular, in order to measure the delay jitter, we have
performed a number of tests with the IPERF tool with an
interval period ∆T of 10 seconds. At each ∆T, we have
generated additional traffic within each slice, by sending UDP
datagrams in downlink with IPERF with a forced transmission
rate of 10 MBs, and measured the delay jitter at the eMBB
and IoT UEs side, respectively.
From Fig. 7, we can observe that the delay jitter reaches a
maximum value of 2.4ms and 3.4ms for the eMBB and IoT
traffic respectively. This is expected due to the presence of IoT
peak sessions, in accordance to the traffic profile assumption.
Conversely, by employing the proposed slicing solution, it can
be noted that the delay jitter tends to decrease during the peak
sessions. This finally results in notable performance gains for
both slices.
VI. CONCLUSION
This paper has proposed an SDN-based network slicing
solution for enabling efficient sharing of the RAN resources
among eMBB and IoT services. The proposed solution has
been tested in an SDR prototype that emulates a C-RAN
scenario by using the OAI software and FlexRAN SDN
controller.
The proposed network slicing approach has been validated
through an emulation technique, showing the feasibility of
our prototype of handling the slicing process in real-time

Fig. 7: Delay Jitter
according to the input of a northbound SDN application. Em-
ulation results have demonstrated that our prototype is capable
of providing isolation among different slicing segments, thus
reducing the negative effects of traffic variations between IoT
and eMBB services.
Future work is needed to enhance the slicing allocation algo-
rithm, in order to take into account multiple RAN parameters,
such as different fronthaul splitting options for each slice. We
expect our prototype design to provide worthwhile insights
into developing efficient slicing solutions for 5G, with an in-
depth consideration of practical implementation.
ACKNOWLEDGMENT
This work was supported by the FUI ELASTIC project
(Grant no. C16/0287) and FUI SCORPION project (Grant no.
17/00464).
REFERENCES
[1] 5GPPP Architecture Working Group, “View on 5G Architecture”, White
Paper, Dec. 2017.
[2] W. Ejaz et al., “Internet of Things (IoT) in 5G Wireless Communications”,
IEEE Access, vol. 4, pp. 10310-10314, 2016.
[3] N. G. M. N. Alliance, “5G white paper”. Next generation mobile
networks, white paper (V. 1.0, Feb. 2015).
[4] ONF TR-521 Specification, “SDN Architecture”, Issue 1.1, Feb.2016.
[5] ETSI’s Network Functions Virtualisation (NFV) Industry Specification
Group, “Network Operator Perspectives on NFV priorities for 5G”, ETSI
White Paper, Feb. 2017.
[6] China Mobile Research Institute, “C-RAN The Road Towards Green
RAN”, White Paper, Oct. 2011.
[7] N. Nikaien, “OpenAirInterface Simulator/Emulator”, available on line at
http://www.openairinterface.org/, Jul. 2015.
[8] X. Foukas, N. Nikaein, M. M. Kassem, M. K. Marina and K. Kontovasilis.
“FlexRAN: A Flexible and Programmable Platform for Software-Defined
Radio Access Networks”, ACM CoNEXT, California, USA, Dec. 2016.
[9] 3GPP TS 22.951, “Service Aspects and Requirements for Network
Sharing”, Rel.11, Sep. 2012.
[10] K. Samdanis, X. Costa-P ´
erez and V. Sciancalepore, “From network
sharing to multi-tenancy: The 5G network slice broker”, IEEE Com-
munications Magazine, Jul. 2017.
[11] L. Zhao, M. Li, Y. Zaki, A. Timm-Giel and C. Gorg, “LTE mobile
network virtualization, Mobile Networks and Applications”, Mobile Net-
works and Applications, Vol.16, No.4, Aug. 2011.
[12] J.S. Panchal, R.D. Yates, M.M. Buddhikot, “Mobile Network Resource
Sharing Options: Performance Comparisons, IEEE Trans. Wireless
Comm., vol.12, no.9, Sep. 2013.
[13] A. Gudipati, L.E. Li, and S. Katti,“RadioVisor: A slicing plane for radio
access networks”, ACM SIGCOMM workshop on Hot Topics in Software
Defined Networking (HotSDN), Chicago, USA, Aug. 2014.
[14] S. Costanzo, R. Shrivastava, K. Samdanis, D. Xenakis, X. Costa-P´
erez
and D. Grace, “Service-oriented resource virtualization for evolving TDD
networks towards 5G”, IEEE Wireless Communications and Networking
Conference (WCNC), Doha, Apr. 2016.
[15] A. Ksentini and N. Nikaein, “Toward Enforcing Network Slicing on
RAN: Flexibility and Resources Abstraction”, IEEE Communications
Magazine, vol. 55, no. 6, pp. 102-108, Jun. 2017.
[16] “How to connect cots UE toAI eNB via NGFI RRU”, Tutorial avail-
able online at http://gitlab.eurecom.fr/oai/openairinterface5G/wikis/how-
to-connect-cots-ue-to-oai-enb-via-ngfi-rru
[17] “USRP B200/B210 Specification Sheet”, avalaible online at
https://www.ettus.com/product/details/UB200-KIT