1. Introduction
The evolution of mobile wireless systems towards heterogeneous networks with the introduction of fifth-generation systems has significantly increased the complexity of radio resource management [
1]. Researchers [
2] have investigated plausible options for implementation of the slicing concept at the RAN level by a mobile network operator to respond to the needs of vertical applications. In addition, they discuss the main challenges of RAN slicing, paying particular attention to the resource allocation problem between slices sharing the same spectrum.
When it comes to distributing network slices across physical resources, one of the biggest challenges is RAN network slicing. Researchers in [
3] aimed to improve network performance and flexible use of network resources by dynamically using network resources to meet the different requirements of activated network slices. As a method, researchers [
3] proposed a data-driven RAN slicing mechanism based on a resource-sharing algorithm operating at the Slice Orchestrator (SO) level.
In order to ensure uninterrupted transmission in new 5G systems based on mobility management network slicing, management schemes are widely required due to the diversity of 5G application scenarios. Network slicing is used in the Cloud Radio Access Network (C-RAN), Software Defined Network (SDN) and Network Function Virtualization (NFV) to provide point-to-point connectivity between physical radio equipment and the radio equipment controller. A suitable approach for integration is not yet available. Network slicing needs to work with other 5G technologies to enable more network slices to be used in future 5G networks [
4].
In 5G, the level of flexibility on the radio access network side can be achieved by implementing multiplexing of numerology types in the frequency domain. For example, Ultra Reliable Low Latency Communication (URLLC) traffic requires a short slot length to meet stringent latency requirements, while the Enhanced Mobile Broadband (eMBB) use case typically requires a medium slot length. A long slot length is used for Massive Machine Type Communication (mMTC). Therefore, among the set of supported numerology types for a given operating band and distribution configuration, URLLC may be represented by the number associated with the shortest slot length, eMBB may be represented by the number associated with the medium slot length and mMTC may be represented by the number associated with the largest slot length. In order to meet the latency and data rate requirements of the UE for different network slices such as URLLC, eMBB and mMTC, the physical resources in the gNB need to be dynamically managed according to the incoming packet types.
The overall system includes end-to-end User Equipment (UE), Distributed Unit (DU), Control Unit (CU), User Plane Function (UPF) and Data Network (DN). The network slicing architecture is shown in
Figure 1. In order to manage different network slices on the core network side, a dedicated UPF is positioned for each network slice when going to the data network. On the RAN side, however, there appears to be a single physical resource block for these three different network slices. Having a single resource block creates the need to dynamically manage it to meet the needs of three different networks. Bandwidth and slot width requirements vary depending on the needs of the applications that will be using the network slices. Sometimes applications can be closed and the resources they use reassigned to other network slices to increase efficiency.
As mobile data usage continues to grow and advanced applications are deployed, it has been observed that inflexible mobile network architectures cannot meet evolving service requirements. It is stated that 5G mobile networks will have to overcome challenges such as higher capacity, higher data speed, lower end-to-end latency, multiple device connections, reduced cost and continuous quality of service that cannot be effectively addressed in 4G. In [
5], technologies and design principles that will make it easier to overcome these difficulties are explained, and it is stated that traffic management should be performed with an intelligent mechanism to ensure continuous quality of service for users. Using SDN technology in 5G, programmable, flexible, and modular logical networks can be created on the same network infrastructure. These logical networks are defined as network slices. Each network slice represents an isolated, end-to-end network designed to meet the different requirements of a specific application, as opposed to the current ‘one size fits all’ architectural approach [
6].
SDN technology aims to centralise network control by separating the data and control planes that are combined in traditional network architectures. The separation of the control and data planes is achieved through a well-defined programming interface between the network switches and the SDN controller. This Application Programming Interface (API) allows the controller to directly control the data transmission activities of data plane devices. The most popular API is the OpenFlow [
7] protocol. An OpenFlow switch contains one or more packet processing rule tables. Each rule that matches traffic performs specific actions (drop, forward, replace, etc.) on the traffic. Depending on the rules loaded by the controller application, the OpenFlow switch can be instructed by the controller to act as a router, firewall or load balancer [
8].
While SDN architecture is the technology that enables network slicing, it lacks key capabilities to efficiently manage the lifecycle of network slices and their constituent resources [
6]. In this regard, an NFV architecture [
9], which manages infrastructure resources and regulates the allocation of resources required to deliver Virtualised Network Functions (VNF) and network services, appears to be the ideal solution [
6]. NFV activities are led by the European Telecommunications Standards Institute (ETSI). The ETSI NFV Management and Orchestration (NFV-MANO) architectural framework defines the following functional blocks:
The VIM is responsible for controlling and managing the computing, storage and network resources of the Network Function Virtualization Infrastructure (NFVI). The NFV orchestrator has two main roles. The first is to ensure the correct allocation and use of virtual resources in the network, and the second is to manage the lifecycle of network services. VNFM is responsible for the lifecycle management of VNF servers [
10].
In the 5G network, the user needs to select the appropriate network slice and receive service from that network slice. This is where the Network Slice Selection Function (NSSF), one of the core network functions, comes in. NSSF receives network slice information from MANO via the north interface. By looking at the network slice information received from MANO, the network slice information to be accessed and the network slice information in the subscription information, the user can access the default network slice or the authorised network slice [
11]. To express this functionality in
Figure 2, the UE (User Equipment); DU (Distributed Unit); CU (Control Unit); core network components (NSSF-Network Slice Selection Function, NRF-Network Repository Function); UDM-Unified Data Management; PCF-Policy Control Function; NEF-Network Exposure Function; AUSF-Authentication Server Function; AMF-Access and Mobility Management Function; SMF-Session Management Function; UDR-Unified Data Repository; UPF-User Plane Function; and transmission network; the end-to-end SDN and NFV-based 5G network architecture is shown.
In 5G networks, hardware-dependent devices in the transport network can be virtualised and managed via SDN controllers and MANO on general-purpose servers. In this way, network resources are expected to scale more easily according to changing needs and infrastructure costs are expected to decrease.
In this study, we evaluated cloud-based dynamic network scaling and network slicing approaches for next-generation wireless networks. SDN–NFV-based network scaling methods and RAN network slicing performance regarding physical resource utilisation are investigated. An SDN application has been developed that allows network resources to be dynamically scaled according to changing user needs to ensure continuous quality of service. This application detects congestion on the network slice via the OpenDaylight SDN Controller [
12] and enables dynamic scaling of network resources via NFV-MANO.
Section 4 describes the SDN–NFV-based QoS management. This study also discusses the applicability of RAN network slicing in the case of shared physical resource blocks for different network slices. The ability of network slices created to meet different application needs to dynamically share the physical resource block is investigated. Simulation tools are used to show the effect of the number of users, traffic type and numerology changes on physical resource utilisation.
Section 2 describes end-to-end network slicing and the physical resource usage of 5G RAN network slicing.
Section 3 analyses the physical resource block usage according to different network slices of QoS type, bandwidth and numerology in the simulation environment.
2. 5G RAN Network Slicing
Network slicing aims to provide customised communication services for different usage scenarios. For example, one slice can be reserved for high-speed data transfer, while another slice can be reserved for applications that require low latency. With network slicing, service providers can flexibly and quickly deploy their applications and services to meet the specific requirements of different services [
13]. Partitioning a single physical network into different logical networks, customised according to different unique requirements, has emerged as a promising approach to meet such diverse requirements in a sustainable manner [
14].
Figure 1 shows the 5G architecture by end-to-end network slices, including the physical layer.
It is expected that as the number of devices connected to the network increases, different types of traffic will require different bandwidth and delay. For example, video games require more bandwidth while audio data requires less bandwidth. According to Viavi [
15], 40% of the devices in a 5G network will require URLLC, 50% will require mMTC and 10% will require eMBB network slices.
Figure 3 shows the shared use of the physical resource block by network slice using these rates as a reference.
Table 1 shows the frame structure subcarrier spacing (SC) and slot duration defined in the 3GPP standards [
16] according to a numerology system. The numerology (µ) is represented by numbers from 0 to 4, indicating different subcarrier spacings from 15 KHz to 240 KHz.
The slot duration, which is initially 1 ms (µ = 0), decreases as the number increases. This shows that lower latency and faster packet processing per unit time can be achieved at higher numbers. The URLLC network slice must be designed to meet the requirements of low latency and high packet throughput. Accordingly, a high number should be used when allocating physical resources to applications belonging to the URLLC network slice. According to the test scenarios in this study, numerology values were used for the URLLC network slice (µ = 3), for the mMTC (µ = 2) and for the eMBB (µ = 1).
4. SDN-NFV Based QoS Management
In 5G and beyond, SDN–NFV-based transport networks can instantly change the behaviour of the network on a software basis using the SDN controller. This flexibility enables faster adaptation to different QoS requirements in the transport network. In order for the network to be able to quickly adapt to changing requirements and be configured via software, the core network, the radio access network and the NFV-MANO units need to work in an integrated manner.
In this study, an SDN algorithm is proposed that enables dynamic scaling of network resources to ensure continuity of quality of service to users as traffic density increases in a network that is NFV-MANO-integrated. Open-source tools have been used to test the proposed algorithm.
4.1. Open-Source SDN Application Development Environment
In this study, OpenDaylight was used as the SDN controller. OpenDaylight is an open-source SDN controller maintained by the Linux Foundation. It has a microservice architecture. The Mininet [
17] tool was used to create the data plane. Mininet is a network emulator. Network keys, links and hosts can be created on it. While simple network topologies can be created with a single command, customised network topologies can also be created using the Python programming language. The iPerf tool [
18] was used to generate traffic. The SFlow-RT tool [
19] was used to control which virtual switches on the topology the traffic flowed through.
Figure 8 shows the SDN network topology created using virtual switches (Open vSwitch, OVS) [
20] on the Mininet. The inter-switch bandwidth in the topology is 100 Mbps. Flows 1, 2 and 3, which are assumed to be initiated by the UE, represent the data flows sent to the data network through the transmission network in the 5G architecture, as shown in
Figure 2. Virtual switches in the transmission network are connected to the SDN controller via the flow control interface. The traffic characteristics in the test scenario created for verification are shown in
Table 5. The expected data throughput is 50 Mbps for game traffic in Flow 1, 10 Mbps for video traffic in Flow 2 and 50 Mbps for HD video traffic in Flow 3 on the test servers located on the data network side.
4.2. SDN–NFV-Based Dynamic Network Scaling Algorithm
In an SDN–NFV network, virtual switches are considered as VNF in NFV architecture [
21]. In this study, a dynamic network resource scaling method based on SDN–NFV is proposed in case of congestion in the 5G transport network, as shown in
Figure 2. The activity diagram of the developed SDN–NFV algorithm is shown in
Figure 9.
In the developed algorithm, the detection of congestion in the network is performed by the SDN controller. First, network topology information is obtained by sending an HTTP GET request to the northbound interface of the SDN controller. The Dijkstra algorithm is used to find the shortest path between the source and destination using the topology information obtained. Then, by sending HTTP POST requests to the SDN controller, flow rules are created on the virtual switches. This ensures that traffic follows the shortest path. The SDN controller then measures the current bandwidth value on the ports of the virtual switches at 2 s intervals. If the measured bandwidth value reaches the specified threshold, the congested virtual switch is detected. If there is no congestion, traffic continues to flow along the existing path.
After the network congestion problem is detected, a request is sent to the VNF manager to create a new virtual switch to reduce the load on the congested switch. If there are sufficient resources in the system, the VNF manager will create a new virtual switch. If there are not enough resources, an alert is sent to the alert manager. When a new virtual switch is added to the topology, the flow rules required to create a new traffic path are created on the virtual switches.
Figure 10 shows the network topology after scaling.
5. Simulation Results
This section compares the two methods used to prevent the quality of service to users from deteriorating in the event of network congestion. In the first method, traffic is routed through different shortest paths in case of congestion. Secondly, the SDN–NFV based dynamic network scaling method proposed in this study was applied. Both methods were implemented in a simulation environment and their performance was compared. The average data rate, one of the QoS parameters, was considered as a performance indicator.
In the simulation environment, flows were started simultaneously according to the traffic characteristics in
Table 5. After a while, it was observed that the data transfer rates decreased and network congestion occurred. Initially, in the event of network congestion, routing was performed through different shortest paths using the Dijkstra algorithm through the SDN controller without scaling. Using this method, the average data rates at the receiver were measured to be 46.9 Mbps for Flow 1, 9.95 Mbps for Flow 2 and 43.9 Mbps for Flow 3 per stream. When this method is evaluated in terms of performance rate, it can be seen that the expected throughput values at the receiving end are achieved by 93.8% for Flow 1, 99.5% for Flow 2 and 87.8% for Flow 3.
When the SDN–NFV based dynamic network scaling method proposed in this study is applied, the average data rates at the receiver are measured to be 49.8 Mbps for Flow 1, 9.96 Mbps for Flow 2, and 49.8 Mbps for Flow 3 per stream, respectively. When evaluated as a performance rate, it was found that the expected data rates for all flows were achieved at a rate of 99.6%.
Table 6 shows the average throughputs achieved per stream for both methods.
In
Figure 11, traffic routing over different shortest paths and simulation results of the proposed SDN–NFV-based dynamic network scaling method are shown graphically.