Full Text

1 Introduction

Network slicing is a key next-generation networking technology that allows multiple virtual subnetworks to be built over a shared physical infrastructure. The virtual subnetworks are then configured to meet the specific needs of applications, services, devices, customers, or virtual network operators. This approach makes it possible to implement in practice flexible configuration and infrastructure management, which make part of the requirements for new generation networks . This concept allows the infrastructure provider to lease network slices to tenants. These relationships are governed by the Service Level Agreements (SLA). Efficient use of network bandwidth and adherence to the terms of these agreements provides economic benefits to all parties. Guaranteeing slice isolation when allocating RAN radio resources makes the problem of efficient resource allocation even more challenging.

The emerging fifth generation (5G) telecommunication networks are envisioned to offer a large number of end-to-end network services for various applications. These stem not only from traditional mobile services, but also from vertical market segments such as automatic driving, unmanned aerial vehicles, telemedicine, massive Internet of Things (mIoT), etc. To provide services with so different requirements for the quality of service (QoS), it is crucial to be able to implement specific virtual subnetworks by using network slicing, since fourth generation (4G) networks with their one-fits-all paradigm are no longer fitted for the task .

In this paper, we propose a simulation model as a reusable, versatile tool for evaluating slicing policies for next-generation network resource sharing. The rest of the article is structured as follows. Section 2 presents the system model. In Section 3 we briefly present the slicing policy under study, which was initially proposed by the authors in . Further, it is considered in terms of queuing theory in Section 4. Section 5 explains the architecture of the simulator. The experimental results are discussed in Section 6. Finally, in Section 7, conclusions are drawn and future work is outlined.

2 System model and notation

Following , we consider the downlink transmission of a 5G base station (BS) with a virtualized RAN and network slicing. We assume that there are \(S\) instantiated slices at the BS and denote their set by \(\mathscr{S}\), \(|\mathscr{S}|=S\). Let \(C_{s [Gbps]}\geqslant 0\) denote the capacity of slice \(s\in\mathscr{S}\), so that \[\label{eq:CsSum}
\sum_{s \in \mathscr{S}} C_s \leqslant C,\] where \(C_{[Gbps]}\) is the total BS capacity. Let \(N_s\) denote the number of users in slice \(s\in \mathscr{S}\), and let \(\mathbf{N}=(N_{s})_{s \in
\mathscr{S}}\). We assume that each slice is intended for one type of services (e.g., for video streaming, video conferencing, gaming, file transfer, web browsing), and hence the traffic in each slice is homogeneous in terms of characteristics and QoS requirements. Let \(R_{s [Gbps]}\) denote the average user data rate in slice \(s\), i.e., \[\label{eq:RsDef}
R_s = \frac{C_s}{N_{s}}, \ s\in\mathscr{S}.\] The column vector of data rates is denoted by \(\mathbf{R}_{[S
\times 1]} = (R_s)_{s \in \mathscr{S}}\).

It is assumed that the infrastructure provider (InP) leases parts of its infrastructure in the form of slices to tenants. A Service Level Agreement (SLA) between the InP and the tenant includes the following slice characteristics:

• a minimum average user data rate \(0<R^{\min}_s \leqslant R_s\),

• a maximum average user data rate \(R_s\leqslant R^{\max}_s \leqslant
  C\),

• a guaranteed capacity share \(\gamma_s\) or contracted number of users \(N_s^{\mathrm{cont}}\).

We assume that performance isolation of slice \(s\) is provided as long as \[\label{eq:gamma}
N_s\leqslant N_s^{\mathrm{cont}},\
\text{or equivalently,}\ \frac{N_s R^{\min}_{s }}{C}\leqslant
\gamma_s,
\quad 0\leqslant \gamma_s\leqslant 1.\]

By performance isolation we understand that traffic fluctuation in one slice does not negatively affect performance in other slices.

3 Slicing scheme

The calculation of slice capacities is performed according to the slicing scheme with SLA-based isolation .

Let us partition \(\Omega=\mathbb{N}^S\) as \[\label{eq:om} \Omega = \Omega^{\max} \cup
\Omega^{\mathrm{opt}} \cup \Omega^{\mathrm{cong}}.\]

Now, for \(\mathbf{N}\in\Omega^{\max}\stackrel{\text{def}}{=}\{
\mathbf{N} \in \Omega:
\mathbf{N} \mathbf{R}^{\max} \leqslant C\}\) we set \[\label{eq:omega0r}
R_{s}(\mathbf{N})=R_{s}^{\max}, \ s\in \mathscr{S}\quad
\implies \quad C_{s}(\mathbf{N})=N_s R_{s}^{\max}, \ s\in \mathscr{S},
\mathbf{N}\in\Omega^{\max}.\]

For \(\mathbf{N}\in\Omega^{\mathrm{opt}}\stackrel{\text{def}}{=}\{\mathbf{N}\in\Omega
:
\mathbf{N}\mathbf{R}^{\min}\leqslant C <
\mathbf{N}\mathbf{R}^{\max}\}\) we determine the data rates as the solution to the convex programming problem \[\begin{aligned}
{2}
\label{eq:target}
&\text{maximize } U(\mathbf{R}) = \sum_{s\in \mathscr{S}}
W_s(N_{s}) N_{s} \ln(R_s),\\
& \text{subject to } \mathbf{N}\mathbf{R} = C, \label{eq:fo}\\
& \text{over } \mathbf{R}\in \mathbb{R}_+^S: R_{s}^{\min}
\leqslant R_s
\leqslant R_{s}^{\max},
\label{eq:pro}\end{aligned}\] where \(W_s(N_{s})\) is given by \[\label{eq:weights}
W_s(N_s) = \left\{
\begin{aligned}
& 1, \quad N_s\leqslant N^{\mathrm{cont}}_s
\\
& N^{\mathrm{cont}}_s/N_s, \quad N_s >
N^{\mathrm{cont}}_s
\end{aligned}
\right.\]

The objective function [eq:target] is differentiable and strictly concave by assumption and the feasible region [eq:fo], [eq:pro] is compact and convex, there exists hence a unique maximum for the data rate vector \(R_{s}\), which can be found by Lagrangian methods.

Now consider \(\mathbf{N}\in\Omega^{\mathrm{cong}}
\stackrel{\text{def}}{=}\{\mathbf{N}\in\Omega :
\mathbf{N}\mathbf{R}^{\min} > C\}\). Denote \(N_s^{\min}(\mathbf{N})\stackrel{\text{def}}{=}\min\{N_s,N^{
\mathrm{cont}}_s\}_{s\in\mathscr{S}}\). Thus \(\mathbf{N}^{\min}\mathbf{R}^{\min}\) is a due capacity. If \(\mathbf{N}^{\min}\mathbf{R}^{\min}\geqslant
C\), we set \[C_s(\mathbf{N})=\frac{N^{\min}_s
R^{\min}_s}{\mathbf{N}^{\min}\mathbf{R}^{\min}}C.
\label{cs}\]

If, conversely, \(\mathbf{N}^{\min}\mathbf{R}^{\min} <
C\), then \[\label{eq:cs2}
C_s(\mathbf{N})=N^{\min}_s
R^{\min}_s+\frac{(N_s-N^{\min}_s)R^{\min}_s}{(\mathbf{N}-\mathbf{N}^{\min})\mathbf{R}^{\min}}(C-\mathbf{N}^{\min}\mathbf{R}^{\min}).\]

To solve the problem [eq:target]–[eq:pro] numerically, we use the gradient projection method (Algorithm [alg:1]).

The gradient projection method is a well-known algorithm for solving optimization problems with linear constraints. It is specified by a standard iterative procedure : \(\mathbf{X^{k+1}}=\mathbf{X^k}+\tau\mathbf{d^k}\), where \(\mathbf{X^k}\) is the point at which the algorithm arrived at the \(k\)-th iteration, \(\tau\) — the stepsize, \(\mathbf{d^k}\) — the increment vector, which is found as the projection of the target function gradient on the constraints: \(\mathbf{d^k} = P \nabla
U(\mathbf{X^k}),\) where the projection matrix is initially given by \(P = \mathbf{I} -
\mathbf{N}^{T}{(\mathbf{N}\mathbf{N}^{T})}^{-1}\mathbf{N}\).

4 Queuing system model

We use queuing theory to model the system described in the Section 2. Each slice is modeled as a separate queuing systems (QS). The types of QS must be selected in such a way as to adequately reflect the nature of the service provided. Jobs in QSs correspond to user sessions in slices. Since in the system model the slices are part of a single network of a total capacity \(C\), the \(S\) queuing systems share a total resource (capacity) \(C\), which is partitioned so that the resource share available to QS \(s\) equals \(C_s\).

At the moment, we have implemented a slice of a Best Effort (BE) type without admission control and with maximum user data rate, which we denote by \(BE^{\max}\). It is represented by a QS with the EPS (egalitarian processor sharing) service discipline. The job service rate \(R_s\) of all jobs is equal and inversely proportional to their number \(N_s\), but cannot exceed \(R^{\max}_s\). Serving jobs in such a QS can be interpreted as downloading files.

Network slicing from this perspective corresponds to a repeated redistribution (re-slicing) of the capacity \(C\) among otherwise independent QSs. The considered model is shown in figure 1, where \(A_s(x)\) is the distribution law of the interarrival times, \(B_s(x)\) is the distribution law of the job lengths (service time on one resource unit) for \(s \in \mathscr{S}\).

It should be noted that in our model admission control and resource allocation within a slice are individual characteristics for each type of slice. For the \(BE^{\max}\) considered in this work, we assume the same service rate for all users (jobs) and unlimited admission (any number of jobs in service). Since this type of slice lacks admission control and queue, it makes sense to introduce a service level degradation threshold (\(0 \leqslant R^d_s \leqslant C\)) to assess the efficiency of the slicing scheme. This parameter sets the threshold for job service rate in the slice, below which degradation of service occurs, the service is provided poorly. Slice degradation can occur as a result of user arrival and/or redistribution of capacity.

For simplicity, in what follows, the terms slice and queuing system will be used interchangeably.

5 Simulator architecture

5.1 Modules

The discrete event simulator is written on the OMNeT++ platform using the queuinglib standard library. The implementation of the algorithm for solving the optimization problem for the slicing scheme required the inclusion of Boost library for operations with matrices. The construction of a simulation model in OMNeT++ assumes a modular structure, and also allows the use of both standard and modified modules (figure 2).

To achieve the required level of abstraction, we have developed two modules:

• is a container consisting of simple modules inside that form a QS. For different types of slices, the way of servicing jobs (users), and as a consequence, the internal structure is not strictly defined and can vary greatly. However, all types of slices are inherited from a common ancestor, which defines the required external parameters that are used to receive the initial data of the model (table 1), and the characteristics that are passed to the slicer as re-slicing parameters, which collected to vectors: \(\mathbf{N}, \mathbf{R}^{\min},
  \mathbf{R}^{\max}\).

• is a simple module that handles requests for capacity re-slicing from slices. The slicer also performs initial re-slicing of the capacity by formula [eq:inres]. Slices and slicers communicate via channels — standard OMNeT++ technology.

Let us take a closer look at the table 1. First, the structural characteristics of the model are determined, such as the number of slices and the type of each one. Further, the distribution laws for the arrival of requests and their service time are established, the parameters of the slices are selected, etc.

One of the parameters of the initial data is the way of invoking the re-slicing — this is an event or message that occurs periodically during the simulation, which is a condition for invoking the capacity re-allocation algorithm. We consider re-slicing triggered by

• events:

  • all events, i.e., job arrivals and departures (in our case this corresponds to optimal real-time slicing),

  • arrivals only,

  • degradation in any slice;

• timer (every \(t_{timer}\) s);

• static slicing (no re-slicing, corresponds to complete partitioning), where the capacity of slice \(i\) equals

\[\label{eq:inres}
C_i = \frac{\gamma_i}{\sum_{j = 1}^{S} {\gamma_j}} C, i \in
\mathscr{S}.\]

Consider the implementation of \(BE^{\max}\) slice type. Figure 3 shows a diagram of the correspondence of the QS elements with software modules in a slice, which include the Delay modification — \(\mathbf{ElasticTrafficDelay}\), and the \(\mathbf{Source}\) and \(\mathbf{Sink}\) modules from the standard set provided by the OMNeT++ and queuinglib bundle.

Consider them:

• \(\mathbf{Source}\) is a basic generator of requests that correspond to users’ requests for the provision of a service, according to specified distributions.

• \(\mathbf{Sink}\) is a module that receives serviced jobs and destroys them. The Sink collects all the primitive statistics on jobs, such as average, maximum, minimum time spent in the system, average time in queue, etc.

• \(\mathbf{ElasticTrafficDelay}\) extension was written for the standard Delay module. This modification is intended to simulate the service of “elastic” traffic, as the name of the module implies. With the help of standard Delay, you can simulate the service of traffic on discrete devices: after the arrival, the job is in the system for a certain time, and then goes to the drain. ElasticTrafficDelay takes into account the presence of all jobs on the device and equally distributes the available resource between them. Therefore, the standard module was extended with mechanisms for recalculating the service rate [eq:rec] and departure time (Algorithm [alg:2]):

\[\label{eq:rec}
R_i =
\begin{cases}
\min(\frac{C_i}{N_i}, R^{\max}_i), & N_i > 0, \\
0, & N_i = 0,
\end{cases}\quad
i \in \mathscr{S}.\]

5.2 Simulation algorithm

Slices, in their essence, function independently of each other, however, as mentioned earlier, the simulator is built on a discrete-event basis, so there is a common queue of events. It contains all the events generated by the model and is executed in the occurrence.

Depending on their type, slices, can generate many different events, but all will be characterized by the following:

• arrival of a job in a slice;

• departure of a job from a slice;

• slice degradation;

• arrival of a job in a slice \(s\) with zero resource \(C_s, s \in\mathscr{S}\).

Only the events of the model cause a change in the state of the system, which we designated as \(\textbf{N}\). Therefore, re-slicing for all events is reduced to tracking the events of arrival and departure of jobs. In our system, the slices themselves notify the slicer of these events (figure 4). After capacity \(C\) allocation, the slicer notifies the slices that their available resource \(C_s, s
\in\mathscr{S}\) has changed. On these notifications, the slices adjust the end time of servicing their jobs in the event queue (Algorithm [alg:2]). If there are no jobs \(N_s = 0\) in the slice \(s\), then after re-slicing it can be assigned a zero resource value \(C_s =
0\), which means that when the first request arrives, it will be necessary to activate the slice, in other words, call re-slicing again.

In the case when re-slicing is triggered by timer (figure 5), the slicer sends messages to itself with the required delay \(t_{\text{timer}}\) s. Since there is a chance that the slice can receive zero resource, it became necessary to enter the activation of the slice upon the arrival of the request in this case.

With static slicing, the slices receive resource proportionally, in accordance with the values of \(\gamma\) by equation [eq:inres].

5.3 Metrics

The built simulator allows you to take indicators in various forms using the built-in OMNeT++ tools, and more specifically using signals and statistics. The signal (@signal) transmits information at the right moments in the form of values ​of primitive types: bool, int, float, etc., or more complex data objects . Statistics (@statistic) is a signal processing mechanism that allows you to accumulate vectors of original data transmitted by signals and scalars calculated by these vectors: sum, quantity, average, time average, maximum, minimum, etc. Preset simulator settings allow you to take such indicators like:

• average time spent in each module of the constructed QS inside slices and in the network as a whole;

• average number of jobs in each module of the constructed QS within slices and in the network as a whole;

• average service rate in slice;

• average number of jobs in slice, etc.

As part of assessing the effectiveness of slicing, the following additional indicators were taken:

• Slice degradation probability, \[P^{\text{deg}}_s = P\{R_s < R_s^{d}\} =
  \lim_{T\rightarrow\infty} \frac{1}{T} \sum_{i = 1}^{D_s(T)}
  (d_{s,i}-d_{s,i-1})\mathcal{H}\{R_{s,i} < R_s^{d}\},\] where \(s\in \mathscr{S}\), \(T\) is model time, \(D_s(T)\) — counter of slice \(s\) degradation threshold \(R_s^{d}\) crossing (in any direction), \(R_{s,i}\) — time of the \(i\)-th rate change, \(d_{s,i}\) — time of the \(i\)-th degradation threshold \(R_s^{d}\) crossing, and \(\mathcal{H}\) is Heaviside step function.

• Average slice resource, \[\overline{C_s} = \lim_{T\rightarrow\infty}
  \frac{1}{T}
  \sum_{i=1}^{L_s(T)} (c_{s,i}-c_{s,i-1}) C_{s,i}, \quad s\in
  \mathscr{S} ,\] where \(L_s(T)\) — counter of slice \(s\) resource changes, \(c_{s,i}\) — moment \(i\) of changing resource \(C_s\).

• Average duration of slice degradation period, \[\overline{t^{\text{deg}}_s} =
  \lim_{T\rightarrow\infty}
  \frac{1}{D_s(T) + 1} \sum_{i = 1}^{D_s(T)}
  (d_{s,i}-d_{s,i-1})\mathcal{H}\{R_{s,i} < R_s^{d}\}, \quad s\in
  \mathscr{S}.\]

• Capacity utilization, \[\text{UTIL} =
  \frac{1}{C} \sum_{s \in \mathscr{S}}
  \lim_{T\rightarrow\infty} \frac{1}{T} \sum_{i = 1}^{Y_s(T)}
  (y_{s,i}-y_{s,i-1})N_{s,i}R_{s,i}, \quad s\in \mathscr{S},\] where \(Y_s(T)\) — counter of slice \(s\) service rate \(R_s\) and number of jobs \(N_s\) changes, \(y_{s,i}\) — moment \(i\) of changing \(R_s\) or \(N_s\).

• Re-slicing frequency.

• Average duration of the re-slicing operation.

6 Numerical results

To illustrate the performance of the simulator, we consider five slices with the parameters given in the table 2.

Scenario is intended to demonstrate a system with an increased workload in slices 1 and 2. The guarantees are selected in such a way, that slices 3 and 4 are the main donors of capacity.

Figure 6 illustrates how the degradation probability \(P^{\text{deg}}_s\) varies depending on the re-slicing triggers for the cases under study. Static re-slicing gives a high degradation probability in slice 1. For event triggers, we observe low degradation probability (\(\sim1\%\)) for slices 1, 2, 4 and insignificant degradation probability in 5. When re-slicing is triggered by timer, the slicer reacts to the state of the system with a long delay, so there is an unacceptably high probability of degradation in donor slices 3 and 4.

The capacity utilization metric in figure 7 indicates that re-slicing upon all events and arrivals provide the highest resource utilization and the lowest waste of resources. This would be good if it were not for the fact that at a much lower system utilization, re-slicing upon degradation yields the same efficiency in terms of degradation probability.

Let us take a look at such an important indicator as the frequency of re-slicing calls. Figure 8 additionally confirms the efficiency of re-slicing upon degradation compared to re-slicing upon all events and arrivals, and even by timer. For all triggers, as expected, slicing takes roughly the same amount of time, averaging 0.04 ms.

Let us consider the average share of capacity \(\overline{C_s}\) allocated to each slice depending on the re-slicing trigger (figure 9). As we see, slices 1 and 2 receive significantly more capacity with frequent re-slicing than indicated in the SLA — the scheme allows this.

7 Conclusion

A simulation model of network slicing with SLA-based isolation has been developed. By using the Object-Oriented Programming paradigm , as well as the built-in functionality of OMNeT++ and queuinglib, the following principles have been achieved:

• Modularity of the system: model elements (slicer, slice, queue, source of requests, delay, etc.) implemented as objects are logically separated, and the interaction among them occurs by transmitting global signals or messages through special channels.

• Polymorphism, inheritance and encapsulation of slices: all types of slices have a common ancestor which specifies all the mechanisms necessary for communicating with the slicer, so each descendant class describing a new slice type can replace their implementation with their own without breaking the interaction structure. In connection with the same principle, the QS describing the way of processing users (jobs) within a slice can take any form and be designed at the discretion of the developer. Thus, any slice is characterized only by its type and unified set of parameters.

• Homogeneity of the structure of the input data: an important characteristic for any simulator is the ease of use, in particular, the way of specifying the input data. In our implementation, based on the previous principle, the initial conditions for any slice are set in the same way using a configuration file.

Compliance with the indicated principles leads to scalability and extensibility of the simulation model.

Further research objectives:

• taking into account the state of the radio channel;

• adding and analyzing other re-slicing triggers;

• adding other types of slices;

• extensive numerical analysis.

About the authors

Nikita A. Polyakov

Peoples’ Friendship University of Russia (RUDN University)

Author for correspondence.
Email: goto97@mail.ru

Bachelor of Science, Master student

6, Miklukho-Maklaya St., Moscow, 117198, Russian Federation

Natalia V. Yarkina

Peoples’ Friendship University of Russia (RUDN University)

Email: ksam@sci.pfu.edu.ru

Candidate of Sciences

6, Miklukho-Maklaya St., Moscow, 117198, Russian Federation

Konstantin E. Samouylov

Peoples’ Friendship University of Russia (RUDN University); Federal Research Center “Computer Science and Control” of the Russian Academy of Sciences (FRC CSC RAS)

Email: ksam@sci.pfu.edu.ru

Doctor of Technical Sciences, Professor, applied Mathematics & Communications Technology Institute

6, Miklukho-Maklaya St., Moscow, 117198, Russian Federation; 44-2, Vavilov St., Moscow, 119333, Russian Federation

References