Dynamic Slicing of RAN Resources For Heterogeneous Coexisting 5G Services
Dynamic Slicing of RAN Resources For Heterogeneous Coexisting 5G Services
Dynamic Slicing of RAN Resources For Heterogeneous Coexisting 5G Services
Abstract—Network slicing is one of the key components allow- However, in the above works it is not detailed how these
ing to support the envisioned 5G services, which are organized values (NpRB ) are derived for each slice, knowing that each
in three different classes: Enhanced Mobile Broadband (eMBB), slice type has its own characteristics and requirements. For
massive Machine Type Communication (mMTC), and Ultra-
Reliable and Low-Latency Communication (URLLC). Network instance, eMBB (enhanced Mobile Broadband) requests high
Slicing relies on the concept of Network Softwarization (Software bandwidth, while URLLC (Ultra-Reliable and Low-Latency
Defined Networking - SDN and Network Functions Virtualization Communication) aims to minimize latency and maximize
- NFV) to share a common infrastructure and build virtual reliability. Rather, the ratio of radio resources to allocate to
instances (slices) of the network tailored to the needs of dif- each slice is considered static and is decided in a manner
ferent 5G services. Although it is straightforward to slice and
isolate computing and network resources for Core Network (CN) agnostic to the actual application requirements of each slice
elements, isolating and slicing Radio Access Network (RAN) in terms of latency and/or throughput. This work fills this
resources is still challenging. In this paper, we leverage a two-level gap by completing the work of [1] and [2] with a dynamic
MAC scheduling architecture and provide a resource sharing RAN resource slicing mechanism to derive the value of
algorithm to compute and dynamically adjust the necessary radio NpRB to dedicate to each running slice, according to its
resources to be used by each deployed network slice, covering
eMBB and URLLC slices. Simulation results clearly indicate the specific requirements and the varying conditions of the radio
ability of our solution to slice the RAN resources and satisfy the environment. The proposed mechanism runs at the SO level,
heterogeneous requirements of both types of network slices. and relies on monitoring information obtained from the RAN.
Index Terms—5G, Network slicing, Scheduling, Radio re- Our contributions are the following: In § III, using tools
sources sharing. from queuing theory, we propose an algorithm that derives the
service rate necessary to sustain the latency requirements of a
I. I NTRODUCTION URLLC slice, which it translates to an initial pRB allocation.
The network slicing paradigm has been adopted in the de- This mechanism relies solely on information obtained from a
sign of current 5G systems as a key technological component. slice template provided by the slice owner, and is agnostic to
It aims at sharing the same physical infrastructure (Mobile the channel conditions of each user. Similarly, our mechanism
Network infrastructure, RAN and Core Network), by creating provides an initial pRB allocation for eMBB slices aiming to
virtual instances of the network tailored to application needs. satisfy their throughput requirements. Then, in § IV, we design
To build these virtual instances on top of the underlying a RAN-aware dynamic slicing algorithm that exploits per-user
physical substrate, Network Slicing uses Network Softwariza- RAN-level information to more accurately translate the derived
tion techniques, i.e., Software Defined Networking (SDN), service rate to an appropriate pRB assignment. Simulation
Network Functions Virtualization (NFV) and Cloud Com- results on the performance of the proposed algorithms follow
puting. Network slicing requires sophisticated mechanisms in § V.
to share and isolate resources among the coexisting slices.
While the core and transport network resources can be more II. R ELATED WORK
easily dimensioned and isolated for each slice, RAN resource
sharing across slices remains a challenge hard to tackle. In [1] Several works in the literature address the allocation of
and [2], the concept of a two-level scheduler was introduced, resources to Network Slices. In [4], the authors discuss the
which aims to share physical radio resources (i.e., physical dynamic allocation of RAN resources to different tenants (e.g.,
Resource Blocks - pRBs) among slices by abstracting pRBs virtual mobile network operators and service providers). They
and using two scheduler levels: The first level is slice-specific, propose a weighed proportionally fair allocation mechanism,
allowing each slice to use its own internal scheduler, and which aims to ensure the desirable fairness and protection
schedules each User Equipment (UE) with virtual Resource among the network slices of the different tenants and their
Blocks (vRBs). The second level, on the other hand, considers associated users.
the slice-specific (virtual) resource assignment and maps it to The authors of [5] design optimization algorithms for com-
actual pRBs. However, since the number of pRBs (NpRB ) mon scheduling between eMBB and URLLC slice traffic, con-
is limited, the second-level scheduler controls the number of sidering the dual objectives of maximizing utility for eMBB
pRBs assigned to each slice according to the recommendation traffic while satisfying instantaneous URLLC requests. This
of a Slice Orchestrator (SO). The latter indicates the maximum is achieved by dynamically multiplexing the URLLC traffic
number of pRBs to dedicate to each slice, after executing an through puncturing/superposition of the eMBB Traffic. The
intra-slice physical resource sharing algorithm. results show that this joint problem has structural properties
that enable clean decomposition, and corresponding algorithms eNodeBs (i.e., different physical locations). The SO receives
with theoretical guarantees. from a tenant (owner) a request to instantiate a slice in the
In [6] the authors analyze dynamic resource sharing in form of a slice template, which indicates the slice type (e.g.,
network slicing when tenants (such as mobile operators and/or eMBB, uRLLC, mMTC), its duration, the list of involved UEs,
services) support inelastic users with minimum rate require- the (application) data rate (denoted by λ) of the service used in
ments. They propose a network slicing framework combining this slice, and application requirements such as the maximum
(i) admission control, (ii) resource allocation, and (iii) user tolerated latency. According to this information, the SO derives
dropping, which they study using tools from game theory. the appropriate number of pRBs that fits the needs of the slice,
The authors of [7] present algorithms that study the prob- which will be communicated later to the involved eNodeBs via
lem of resource allocation in the context of a slicing-ready the southbound protocol.
5G network. These algorithms are composed by: i) traffic In this work, we consider that a network slice is either
analysis and prediction per network slice using the Holt- eMBB or URLLC; hence, we propose two corresponding
Winters forecasting procedure to analyze and predict future mechanisms to estimate the NpRB needed by each slice. Note
traffic requests associated with a particular network slice, that although the 5G system considers three types of slices, in
ii) admission control decisions for network slice requests this paper we considered only two of them; resource allocation
using a heuristic algorithm, and iii) adaptive correction of the for eMBB and mMTC may follow the same mechanisms
forecasting solution based on the measured deviations, using and algorithms. The main difference lies between eMBB and
a proposed network slice scheduler. uRLLC, as the first one seeks high data rate, while the second
The authors of [8] focus on the computational outages that requires low latency. The proposed algorithm first derives an
can occur between RAN functions, aiming to improve the initial estimation of the number of pRBs necessary using the
performance of scheduling and modulation and coding scheme information obtained from the slice template. Then, a dynamic
(MCS) selection functions. The problem, which was shown to algorithm is used to tune NpRB periodically according to the
be NP-hard, was formulated as a joint optimization one and feedback obtained from the eNBs via the southbound protocol.
some algorithms to solve it were proposed. In this section, we will detail the first step for each network
Finally, [9] adopts revenue management models, which have slice type considered (eMBB and URLLC).
been introduced in other contexts (airlines, hotels, etc.), in
order to propose a resource allocation model. The authors A. eMBB slice
propose the concept of slice overbooking to maximize mobile
An eMBB slice requires high data rate, which will represent
operators’ revenues, by introducing a hierarchical control
the main objective when estimating NpRB . In the first step, we
plane to manage the orchestration of slices.
start by estimating the maximum number of required pRBs for
To summarize, despite the fact that all the methods already
each eNodeB i (NpRBmax (i)), using the information provided
proposed have shown relatively good results in the challenge
by the slice owner, i.e., the data rate per user required by the
of dynamic resource allocation, all these methods propose
application running on top of the slice (dApp/user ), and the
algorithms for dynamic resource sharing individually or in
number of users (Nusers (i)) of the network slice connected
combination, which are based on several constraints on users,
to eNodeB i, which can be retrieved from the eNodeB via the
operators, etc., which require several information from them,
southbound control protocol. The main constraint to satisfy is
and which can not always be feasible, optimal and/or accu-
that the number of pRBs NpRBmax (i) to dedicate periodically
rate. On the other hand, our contribution proposes a simpler
for an eMBB slice at each eNodeB should be (greater than or)
algorithm which is based only on the estimation of the quality
equal to the aggregate data rate needed by the slice application
of the channel, as well as it allows to estimate the number of
for all users connected to it; this is captured in (1).
resources to allocate to each slice, which adds more precision
to the system. NpRBmax (i) ∗ dpRB = Nusers (i) ∗ dApp/user . (1)
III. A RCHITECTURE AND ASSUMPTIONS Indeed, the equation indicates that the NpRBmax (i) allowed
In this work, we envision the same network architecture to a slice on a given eNodeB i should cover the needed
model adopted in [1] and [2]. We assume a 5G network which slice’s applications (i.e., the number of active users Nusers (i)
includes a SO and a set of eNodeBs deployed covering an multiplied by the data rate required by the application). Here
area. The role of the SO is to deploy and manage the life we consider that dApp/user is the same for all users. We further
cycle of network slices in the mobile network (RAN and assume that dpRB is the maximum data rate provided by one
Core Network). We assume that a SO is responsible for a pRB, and that it is the same for all users. In this first step,
region covered by a certain number of eNodeBs. The SO we consider that this rate is the maximum achievable by the
communicates with the eNodeBs using a southbound protocol, radio system for ideal channel conditions, i.e., the maximum
such as FlexRAN [3], that allows to interact and manage possible Channel Quality Indicator (CQI) value of 15, and the
remotely the eNodeBs. The eNB management process consists corresponding MCS and transport block size as specified in
in getting status information on the RAN and appropriately the standard [10].
configuring eNodeBs, e.g., by setting the number of pRBs Once each NpRBmax (i) is computed using (1), it is com-
to dedicate to each slice. We assume that a set of UEs are municated via the southbound protocol to the corresponding
served by/associated with a network slice, spanning a set of eNodeBs.
B. URLLC slice According to (2), we can extract the number of pRBs (noted
Knowing that a URLLC slice includes all services requiring NpRBopt ) to dedicate to a URLLC slice as follows:
ultra-low latency, the aim when deriving NpRBmax is to keep µopt ∗ avg packet size
latency below a maximum threshold (Latmax ) indicated in NpRBopt = (8)
dpRB
the slice template provided by the slice owner. To do that, we
At this step, we go by the assumption that the value of
need to derive a model that estimates the latency experienced
dpRB is the same for all UEs, as in the case of eMBB, and
by URLLC packets at the eNodeB queue.
that avg packet size is constant, and aim to solve (7) for µ.
Given that each slice has its own downlink queue at the
We denote the solution to (7) as µopt .
eNodeB [1], all packets belonging to the slice share the same
Deriving µopt analytically is not straightforward. Therefore,
queue. Therefore, to estimate the latency of the packets, we
we estimate it numerically using the following simple algo-
propose to model the slice queue at the eNB as an M/M/1/K
rithm.1
one. The traffic arrival rate follows a Poisson distribution with
intensity λ, the service rate µ is exponential and the queue has Result: µopt
a size of K. Here, the value of λ corresponds to the traffic initialization: M u = [µ1 , µ2 , ..µL ], Mopt = []
rate of the application running on top of the slice, while the for l ← 1:L do
service rate µ depends on the scheduling process at the MAC λ
ρ(l) = M u(l)
layer. To derive λ and µ we can use the following formulas: 1−ρ(l) PK k
Npacket (l) = 1−ρ(l)K+1 k=0 kρ(l)
NpRB ∗ dpRB Tw (l) =
Npacket (l)
µ= (2) λ
avg packet size
if latmax − Tw (l) ≥ then
Nusers ∗ dApp/user Mopt .append(M u(l))
λ= , (3)
avg packet size else
with avg packet size denoting the average packet size of the reject M u(l)
URLLC application, and dApp/u ser having the same value for end if
all slice users. To estimate the latency of URLLC packets, end
we apply Little’s law. The latter assumes that whatever the µopt = min Mopt
distribution of the arrival rate, the average time a user spends in Algorithm 1: Calculation of µopt that allows to respect the
a queue depends on the number of active users Nusers and the latency requirement of a URLLC slice.
traffic intensity (i.e., λ). As the number of users corresponds
in our case to the number of packets (Npacket ) of the URLLC The steps of this procedure are as follows: First, we generate
service waiting in the queue, Little’s law is used as follows to L candidate values for µ and keep them in a vector M u. The
derive the time a packet spends in the queue: number of values to generate is limited: For example, since
Npacket dpRB is assumed for now fixed, we can generate one µ value
Tw = (4) for each possible number of pRBs, which is defined by the
λ
available bandwidth for the given radio technology (e.g, for
As we assumed that the URLLC queue is modeled as
a bandwidth of 5Mhz, a maximum of 25 pRBs can be used)
M/M/1/K, Npacket can be derived as follows:
using (2). Then, we calculate Npacket corresponding to each
K value of µ and the resulting Tw value, which we compare with
1−ρ X k
Npacket = kρ (5) Latmax to check if condition (6) is respected.
1 − ρK+1 Note that we use a latency margin when we compare Tw
k=0
with Latmax to accept or reject a µ value. By appropriately
where ρ = µλ . Since µ corresponds to the service rate of controlling , we can ensure that Tw is adequately lower than
the URLLC queue, and depends on the number of resources the latency threshold Latmax , but also close enough to it
dedicated to the URLLC slice, it can be derived using (2). By in order not to waste a lot of resources, while respecting
assuming that Latmax is the maximum tolerated latency by a condition (6).
URLLC slice, Tw should be less than or equal to this value: Out of all the µ values that lead to an acceptable latency
Tw ≤ Latmax . (6) (in case there are multiple), we select as the optimal the
one which minimizes the difference between Tw and Latmax ,
We substitute Tw by its value given by (4), obtaining the i.e., the smallest value of Mopt . These steps are illustrated in
following expression: Algorithm 1.
Once µopt is obtained, we use (8) to derive the correspond-
λ
1− µPK λ k ing NpRB to be assigned to a URLLC slice. As for the case of
Npacket λ K+1
1−( µ ) k=0 k( µ )
= ≤ Latmax (7) eMBB, the proposed method needs to be run for each eNodeB
λ λ where UEs of the slice are connected to.
Therefore, we need to find a value of µ, noted µopt , that 1 Adaptations of standard numerical techniques such as the Newton-Raphson
ensures at least a latency equal to Latmax for URLLC. and the bisection algorithms are also applicable.
IV. A CHANNEL QUALITY- DRIVEN ALGORITHM FOR V. P ERFORMANCE E VALUATION
DYNAMIC NpRB ESTIMATION A. Scenarios and parameters
The initial number of resource blocks calculated per slice To evaluate the performance of the proposed solution, we
in the previous step is based on the assumption that dpRB is extended the Matlab implementation of the two-level scheduler
fixed for all users. However, users experience different channel used in [1]. We mainly modified the SO part to include our
conditions, and hence different data rates. algorithms. In this simulation, we considered two types of
slices, i.e., eMBB and URLLC. Each slice is defined by
Therefore, we propose to correct the estimation of the
the required application data rate, the number of users, the
dpRB by using per-UE channel quality reports obtained from
maximum latency for URLLC, etc.
eNodeBs. These reports include the CQI and MCS values
We simulated different scenarios, where we varied the
of each UE belonging to a cell. Note that these values are
number of users of the URLLC slice (NuRLLCusers ) while
transmitted to eNodeBs by the UEs in order to be used in the
keeping it fixed for the eMBB slice (NeM BBusers ) to 5 users,
scheduling process. We organize these CQI values in a matrix
and for different channel qualities: (i) medium quality where
v(j, k), where j is the id of the slice and k is the id of the
the CQI varies from 7 to 9; (ii) good quality where the CQI
UE. Based on the CQI, we can estimate dpRB per UE and
varies from 13 to 15. The different channel qualities will
per cell (eNodeB). Indeed, dpRB can be obtained by using the
directly affect dpRB, which allows us to see its impact on
same tables used by the eNodeB to translate a CQI to a data
the proposed solutions. Note that we simulated the case of
rate [10]. Matrix v is then transformed to a matrix of data
only one eNodeB and one SO. Table I presents the simulation
rates noted dpRB (j, k), where j and k have the same meaning
parameter set in all scenarios:
as for matrix v.
Algorithm 2 presents the different steps of the dynamic slice TABLE I: Simulation parameters
resource allocation procedure. We note that Slice(j) gives
the type of the deployed slice, NpRBopt (i, j) is a matrix that Parameter Values
gives for each cell i the necessary number of pRBs for slice Slices [uRLLC, eMBB]
Average Packet Size [20, 125] bytes
j, Nusers (i, j) a vector indicating the number of users of a Data rate [160, 1000] kbit/s
slice j in cell i, and dApp user (j) the data rate required by TTI [1, 1] ms
an application (per user) running on top of a slice j. This SO interval 1s
algorithm allows to estimate the NpRB allocated to each slice
and for each network cell more accurately: For an eMBB slice, We compared our solution with the one adopted in [1],
it sums the necessary resources per UE considering each user’s which shares the pRBs among the different slices using a
individual radio capacity reflected in dpRB (j, k). For URLLC, statically selected percentage; in our tests we considered a 50%
it applies (8), using the optimal service rate as computed slice-dedicated bandwidth (SDB) per slice. It is worth noting
by Algorithm 1 to attain latency requirements, and the mean that the number of available pRBs is bounded by the channel
achievable dpRB across all slice users per eNodeB considering bandwidth. For our simulation, we used a channel bandwidth
each user’s channel quality, instead of a fixed optimistic value of 5Mhz, where 25 pRBs are available. We selected this
for all. number to saturate quickly the channel and show the efficiency
Note that this algorithm is run periodically by the SO. It of our solution. For higher bandwidths, the only difference
relies on the eNodeBs’ reports obtained also periodically. The concerns the threshold from where our solution does not per-
periodicity of running these algorithms is independent from the form well. It may happen that the combined number of pRBs
scheduling period TTI used at the MAC layer of the eNodeBs. to be allocated to both eMBB and uRLLC exceeds the channel
capacity; hence, we adopted in this implementation a fair share
Result: NpRBopt (i, j) of the resources, which has been computed as follows. First
for each cell i do we compute ∆ = NpRBmax − (NpRBuRLLC + NpRBeM BB )
for each slice j do that represents the difference between the available number
if Slice (j) == eMBB then of pRBs and the requested number of pRBs for both slices.
Pk=N (i,j) dApp/user (j,k) Then, we reduce the same amount of pRB ( |∆| 2 ) from each
NpRBopt (i, j) = k=1 users dpRB (j,k) slice, in order to fit the capacity of the channel. Other policies
else
could be used, such as giving high priority to one slice, by
if Slice (j) == uRLLC then
µopt ∗avg packet size first satisfying this slice and giving the remaining pRBs to the
NpRBopt (i, j) =
1
k=Nusers
P (i,j) other slice. In this paper we use only the fair share of the
Nusers (i,j)
dpRB (j,k)
k=1 channel, leaving other policies for future work.
end if Finally, we computed three main metrics: the eMBB slice
end if throughput, the URLLC latency and the variation of NpRB
end for each slice. We varied the number of URLLC slice users
end from 1 to 20 in the case of the medium-quality channel, and
Algorithm 2: Calculation of NpRB for eMBB and uRLLC
from 1 to 30 in the case of the good-quality channel, while
slices for multiple cells
fixing the number of eMBB users to 5. The presented results
are averaged after several runs of the simulation.
80 60
Latency using our method lat= 1
Latency using our method lat= 10
70 Latency using our method lat= 50
Latency using static method for 50% 50
Latency Threshold= 1
60 Latency Threshold= 10
Latency Threshold= 50 Latency using our method lat= 1
Latency[ ms]
Latency[ ms]
40
50 Latency using our method lat= 10
Latency using our method lat= 50
40 30 Latency using static method for 50%
Latency Threshold= 1
30 Latency Threshold= 10
20 Latency Threshold= 50
20
10
10
0 0
0 5 10 15 20 0 5 10 15 20 25 30
uRLLC Nusers uRLLC Nusers
(a) Medium channel quality. (b) Good channel quality.
Fig. 1: Latency vs. the number of URLLC users.
5000 5000
Throughput using our method lat= 1
4500 Throughput using our method lat= 10 4800
Throughput using our method lat= 50
Throughput [ kbps]
Throughput [ kbps]
4000 4600
Throughput using static method 50%
3500 Throughput Threshold 4400
3000 4200
2500 4000
Throughput using our method lat= 1
2000 3800 Throughput using our method lat= 10
Throughput using our method lat= 50
1500 3600 Throughput using static method 50%
Throughput Threshold
1000 3400
0 5 10 15 20 0 5 10 15 20 25 30
uRLLC Nusers uRLLC Nusers
(a) Medium channel quality. (b) Good channel quality.
Fig. 2: Throughput vs. the number of URLLC users.
It is worth noting that our main objective is to evaluate the Namely, there is a threshold beyond which the performance
accuracy of our proposed methods to well estimate the needed of the slice degrades, particularly in the case of a good
radio resources for each type of slice. channel quality. Indeed, for the medium channel quality, our
solution cannot guarantee the requested bandwidth (5 users ×
B. Results 1 Mbps). However, for the good channel quality our solution
Fig. 1a and 1b illustrate the latency experienced by the guarantees the needed bandwidth until 10 and 25 users when
uRLLC users for different numbers of Nusersu RLLC , and for Latmax =1 ms and 50 ms, respectively. This is expected, as
two channel qualities, good and medium. in the case of Latmax =1 ms the URLLC users need more
Here we considered different values for Latmax : 1 ms, pRBs, which strongly affects the eMBB users (see Figures 3b
10 ms and 50 ms, which reflect different service-level require- and 4b). Regarding the static assignment of pRBs, it ensures
ments. We remark that our algorithm allows to keep the latency always the same throughput (lower than 5mbps), which is not
around Latmax , whatever the value of the latter and for both optimal.
channel qualities. However, we see that there is a threshold To better understand the obtained results, we have drawn
(i.e., number of URLLC users) beyond which latency exceeds in Fig. 3 and 4 the number of pRBs (N pRB) estimated and
Latmax ; 2, 5 and 14 for the medium channel quality for used by the eNodeBs for each type of slice, and for both
Latmax =1 ms, 5 ms and 50 ms respectively, and 15, 22 and channel qualities. From Fig. 3a and 4a we clearly see that the
29 for the good channel quality for Latmax =1 ms, 5 ms and estimated value of NpRB is similar to the one communicated to
50 ms respectively. The difference between these values is the eNodeB, until reaching the identified thresholds in Fig. 1a
explained by the fact that good channel quality permits to have and 1b. When exceeding these thresholds, the communicated
higher NpRB compared with the medium channel quality, thus NpRB to eNodeB are lower than the estimated value. This
accommodating more URLLC users. In addition, we observe is mainly because the channel capacity is exceeded, and the
that using a fixed number of pRBs cannot guarantee the very proposed solution starts using the fair share of pRBs among the
low latency requirement, as the used value (i.e., 50%) is not two slices. Hence, it is possible to accommodate the URLLC
optimal (see Fig. 1a and 1b). requirement for both channel qualities.
Fig. 2a and 2b show the throughput obtained for the eMBB Regarding the eMBB slice, where the results are displayed
slice as a function of the number of the URLLC slice’s users. in Fig. 3b and 4b for both channel qualities, the estimated
We remark the same behaviour as in the precedent figures. NpRB cannot be satisfied in case of medium channel quality,
80 50
uRLLC NpRB for threshold= 1 after FS eMBB NpRB for threshold= 1 after FS
70 uRLLC NpRB for threshold= 10 after FS 45 eMBB NpRB for threshold= 10 after FS
uRLLC NpRB for threshold= 50 after FS eMBB NpRB for threshold= 50 after FS
60 uRLLC NpRB for threshold= 1 estimate 40
eMBB NpRB real estimate
uRLLC NpRB for threshold= 10 estimate
50 uRLLC NpRB for threshold= 50 estimate 35
NpRB
NpRB
40 30
30 25
20 20
10 15
0 10
0 2 4 6 8 10 12 14 16 18 20 0 2 4 6 8 10 12 14 16 18 20
uRLLC Nusers uRLLC Nusers
(a) NpRB of uRLLC slice. (b) NpRB of eMBB slice.
Fig. 3: Number of pRBs vs. the number of URLLC users for a medium channel quality.
30 15
uRLLC NpRB for threshold= 1 after FS
uRLLC NpRB for threshold= 10 after FS
25 14
uRLLC NpRB for threshold= 50 after FS
uRLLC NpRB for threshold= 1 estimate
20 uRLLC NpRB for threshold= 10 estimate 13
uRLLC NpRB for threshold= 50 estimate
NpRB
NpRB
15 12
10 11
eMBB NpRB for threshold= 1 after FS
5 10 eMBB NpRB for threshold= 10 after FS
eMBB NpRB for threshold= 50 after FS
eMBB NpRB real estimate
0 9
0 5 10 15 20 25 30 0 5 10 15 20 25 30
uRLLC Nusers uRLLC Nusers
(a) NpRB of uRLLC slice. (b) NpRB of eMBB slice.
Fig. 4: Number of pRBs vs. the number of URLLC users for a good channel quality.
and after exceeding the identified threshold in Fig. 2a and 2b VII. ACKNOWLEDGEMENT
for good channel quality. Furthermore, we remark that the This work was partially supported by the European Union’s
number of needed NpRB is higher in case of medium channel Horizon 2020 Research and Innovation Program under the
quality, which is expected as dpRB in this case is lower than 5G!Drones (Grant No. 857031) and 5G-TRANSFORMER
when channel quality is better; hence more pRBs are needed (Grant No. 761536) projects.
to satisfy the throughput of eMBB users.
Overall, these results confirm that the proposed model to R EFERENCES
estimate the needed NpRB for eMBB and URLLC employed [1] A. Ksentini et al., “Providing low latency guarantees for slicing-ready
by our proposed solution is accurate and permits to solve the 5G systems via two-level MAC scheduling,” in IEEE Network, Nov.
2018.
problem of sharing the RAN resources among slices. [2] A. Ksentini and N. Nikaein, “Towards enforcing Network Slicing on
RAN: Flexibility and Resources abstraction,” in IEEE Communications
Magazine, Jun. 2017.
VI. C ONCLUSION [3] X. Foukas et al., “FlexRAN: A Flexible and Programmable Platform
for Software-Defined Radio Access Networks,” in Proc. ACM CoNEXT,
In this paper, we addressed the problem of slicing and 2016.
[4] P. Caballero, “Multi-Tenant Radio Access Network Slicing: Statistical
isolating RAN resources in slicing-ready 5G networks using Multiplexing of Spatial Loads,” in IEEE/ACM Transactions on Network-
the concept of two-level scheduling introduced in [1]. We ing, vol. 25(5), Oct. 2017.
proposed two algorithms that estimate the needed RAN re- [5] A. Anand et al., “Joint Scheduling of uRLLC and eMBB Traffic in 5G
Wireless Networks,” in Proc. IEEE INFOCOM, 2018.
sources for two types of 5G slices: eMBB and uRLLC. We [6] P. Caballero et al., “Network Slicing for Guaranteed Rate Services: Ad-
used simulation to evaluate the performance of the proposed mission Control and Resource Allocation Games,” in IEEE Transactions
algorithms under different channel conditions. The obtained on Wireless Communications, vol. 17(10), Oct. 2018.
[7] V. Sciancalepore et al., “Mobile Traffic Forecasting for Maximizing 5G
results allowed us to verify the accuracy of our algorithms Network Slicing Resource Utilization,” in Proc. IEEE INFOCOM, 2017.
when estimating the needed pRBs for each type of slice. [8] D. Bega et al., “CARES: Computation-aware Scheduling in Virtualized
The proposed algorithms are used at the slice orchestrator Radio Access Networks,” in IEEE Transactions on Wireless Communi-
cations, vol. 17(12), 2018.
level and could be easily implemented in a real platform. Our [9] J. Salvat et al., “Overbooking Network Slices through Yield-driven End-
future work will focus on improving the estimation of the to-End Orchestration,” in Proc. ACM CoNEXT, 2018.
URLLC algorithm by relaxing the assumptions on the traffic [10] LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer procedures, 3GPP TS 36.213, v. 15.2.0, Release 15, Oct. 2018.
characteristics, using more general models.