Evaluation of 5G Core Slicing on User Plane Function

Network slicing is one of the most important features in 5G which enables a large variety of services with diverse performance requirements by network virtualization. Traditionally, the network can be viewed as a one-size-fits-all slice and its services are bundled with proprietary hardware supported by tel-ecom equipment providers. Now with the network virtualization technology in 5G, open networking software can be deployed flexibly on commodity hardware to offer a multi-slice network where each slice can offer a different set of network services. In this research, we propose a multi-slice 5G core architecture by provisioning its User Plane Functions (UPFs) with different QoS requirements. We compare the performance of such a multi-slice system with that of one-size-fits-all single slice architecture under the same resource assignment. Our research objective is to compare the performance of a network slicing architecture with that of a “one-size-fits-all” architecture and validate that the former can achieve better performance with the same underlying infrastructure. The results validate that our proposed system can achieve better performance by slicing one UPF into three with proper resource allocation.

The 5G core (5GC) is designed to be "cloud native" where NFV is leveraged to create network slices. A 5G core slice is composed of a collection of 5G core VNFs that are chained together to support a specific use case [1]. Though an end-to-end 5G network slice may consist of different network slice subnets including 5G core, access, or transport networks [6], in this research we will focus on 5G core slicing. Also, we will follow one of the major characteristics of 5G, Control and User Plane Separation (CUPS), to decouple a 5G system into two parts and deploy Control Plane (CP) as a commons slice and configure User Plane (UP) into multiple customized slices, each with different bandwidth requirements.
Several related works on the design of 5G core slicing are surveyed below. In [7], potential challenges in 5G core slicing such as slice creation, slice management, and security in network slicing were elaborated. Our system tackles these challenges by leveraging APIs provided by OpenStack and Tacker for slices creation and management. Also, to protect the VNFs in slices our system relies on the security group provided by OpenStack and Tacker.
In [8], the modularization of 5G Core is identified as an important feature since this would allow independent evolution of its modules in the future. Our system thus adopts NCTU free5GC which follows a modularized functional design.
Another important issue related to network slicing is how to guarantee hard isolation between slices [9]. Our system resolves this issue by utilizing the VM-based system architecture where the policy of strict no-resource-sharing between VMs is enforced.
The KPIs for network slicing based on ETSI NFV MANO architectural framework were defined in [10]. On the other hand, the main concepts and principles of network slicing such as the NFV, SDN and cloud technologies are well elaborated in [11]. The above two papers provide a comprehensive overview of network slicing.
Our research objective is to compare the performance of a network slicing architecture with that of a "one-size-fits-all" architecture and validate that the On the compared system, only one UPF will be used to serve different services.
Also, both systems will be given the same amount of computing/communication resources.
The rest of the paper is organized as follows: Section II introduces the background of the technologies used in our system and discusses the related work on network slicing. Section III introduces our proposed multi-slices 5G system based on the NFV MANO (MANagement and Orchestration) architecture. Section IV describes the implementation and evaluation of our system and compares our system with the one-size-fits-all single slice system under the same resource allocation. Finally, Section V presents our conclusion and future work.

Background
We construct our proposed 5GC slicing system by leveraging several technologies such as 5GC platform, ETSI NFV-MANO architectural framework and MANO-based 5GC slicing. In this section, we explain the background of these techniques and related work.

5GC Platform
The 5G system is proposed to support a diverse set of vertical services with different QoS requirements. It is designed as a set of network functions (NFs) and follows CUPS to separate its CP from UP. These NFs are modularized to enable flexible Network Service (NS) development. The 5G CP follows the Service-Based Architecture (SBA) that provides a common interface for inter-communications among NFs. The 5G core architecture consists of eleven NFs with ten in CP while one in UP. Figure 1 shows 5G non-roaming reference architecture as Figure 1. 3GPP 5G non-roaming system reference architecture.
C 5G CUPS makes the deployment of modularized network functions of 5GC more flexible and agile. In our experiment, we aim to leverage the CUPS characteristic in 5G to create event slices [12], defined as network slices created specifically to handle the sudden rise of traffic in special events such as New Year's Eve party. As a result, we would structure our 5GC slicing experimental system with UP as customized event slices and CP as a common slice shared by those event slices.

ETSI NFV-MANO Architectural Framework
ETSI NFV-MANO [14] is an architectural framework for enabling Network Services (NSs) (and thus network slices) under virtualized infrastructure. Each NS is composed of one or multiple VNFs. These VNFs are connected by Virtual Links (VLs) and their interactions are regulated by VNF Forwarding Graphs (VNFFGs).
To deal with different QoS requirements of various vertical services, operators need to provide NSs of different characteristics.
As depicted in Figure 2, the ETSI NFV-MANO architecture consists of the following three major function components [14]: • VNF Manager (VNFM): This is responsible for the lifecycle management of VNFs on the VNF platform, such as creation, modification and termination.
Note that each VNF is a network function thus should be coupled with an Element Management (EM) system which is responsible for FCAPS 1 management

MANO-Based 5GC Slicing
According to 3GPP, a network slice is an end-to-end network architecture consisting of multiple network slice subnets. Each network slice subnet represents a different segment in an end-to-end network such as access network, core network, transport network. Each network function can be deployed as VNF or  Figure 3 shows the mapping between a 3GPP network slice and an ETSI NFV NS [17]. The left side of Figure 3 shows 3GPP-defined communication service, network slice, network slice subnet, network function and their relations. On the other hand, the right side of Figure 3 shows NFV-defined network service, VNF, PNF and their relations.
The MANO-based 5GC slicing system can be divided into three parts: user plane, control plane and management plane. The ETSI NFV-MANO architecture is the management plane while the 5GC platform serves as the control and user planes. The management plane is responsible for the life cycle management of NSs, VNFs and other virtual resources. On the other hand, the 5GC supports all network functions required by the control plane and the user plane to provide 5G services.
In this research, we assume a 5G core with multiple slices pre-provisioned and instantiated. As 5G service traffic arrives at the core network, its control signaling will be directed to a common network slice that consists of all CP VNFs. On the other hand, its user data traffic will be routed to multiple customized UP slices preconfigured with different QoS characteristics, then forwarded to different data networks

Design of Multi-Slice Architecture
As depicted in Figure 4, we propose to deploy four slices: a common network slice consisting of all CP VNFs and three customized network slices, each with a single UP UPF configured with different bandwidth limits. These slices will be pre-provisioned before the system starts its operations. Our purpose is to verify that under the slicing system, there will be more flexibility to allocate limited resources. Figure 3. Mapping from network slice (subnet) to network service [12].

Design of 5G Network Slices
Our slicing design is focused on customized slices. In three customized slices, only one UPF is deployed but each with a different bandwidth setting. These customized slices are designed to optimize resource allocation. Table 1 shows the bandwidth allocation and expected traffic of each customized slice. These three slices are to handle three different kinds of 5G eMBB traffic with low, medium and high bandwidth requirements.
In the compared one-size-fits-all single slice system, we set its user plane bandwidth as the summation of those in three customized slices of our proposed system. In the proposed system, we specify 3 vCPU, 16G RAM and 40 GB disk for each customized slice. In the compared system, we specify 9 vCPU, 48G RAM and 120 GB disk. All the UPFs in UP are equipped with the Debian 7 operating system. Consequently, the total virtualized resources of the compared and the proposed systems are exactly the same except that the proposed system would set the bandwidth limitation on each customized slice.
On the other hand, the common slice consists of 9 CP VNFs including AMF,

Design of 5G Deployment Templates
Before instantiating our proposed 5GC slicing system, both NSD and VNFD need to be designed [18]. The VNFD describes the behavior and deployment in-  Each VDU needs to connect to a VL through a CPt. The communications between VDUs would go through the same VL. In our system, each 5G VNF consists of only one VDU and each VDU connects to a private network we create in advance to simulate the VL bound by CPt.
To enable network services, the NSD describes the behavior and deployment information of an NS [20].   In NSD, we need to import one or multiple required VNFDs which have been on-boarded and specify their topology. In our system, we deploy CP and UP as a network slice subnet respectively. The combination of CP and UP network slice subnets builds up the network slice of 5GC. In our system, we don't have any service function chain. Therefore, there is no need to specify any VNFFG. In our implementation, we only instantiate the VNFs we need in NSD but no virtual links between VNFs (Tacker does not support VLD). Instead, all the 5GC VNFs would be deployed to a private network (Internal Virtual Link) we create in advance to simulate the inter-VNF communications.
Note that Tacker only supports VNFD and VNFFGD in NSD in its current implementation [21]. It doesn't support PNFD (PNF Descriptor) and VLD in the NSD level for inter-VNF communications. Instead, the connection between VNFs is specified in VL and CP at the VDU level in VNFD.

5GC System Operation Workflow
We deploy the proposed 5GC network slicing system using MANO. Below we show the workflow of our system operations including the setup of the 5GC network slice environment, the onboarding of required NSD and VNFDs and the testing of the proposed system.
1) The MANO system is brought up to construct the 5GC network slice environment. Both VNFM and NFVO (Tacker) would be set up first then OpenStack needs to be registered as VIM to Tacker in order to manage the NFVI resources.
2) The VNFDs of all required network functions need be developed, then on-boarded to VNF Catalogue one-by-one through Tacker after verification.
3) The NSD of the network slice/network slice subnet based on the VNFs just on-boarded needs to be designed and on-boarded to NS Catalogue through Tacker after verification.

System Evaluation
To verify our design, we compare our proposed system with a one-size-fits-all single slice system. We define three evaluation metrics: 1) CPU utilization; 2) Throughput; 3) Response time.
Below we introduce the experiment environment we use and the experiment results.

5G Slice Environment
We followed the ETSI MANO NFV framework discussed in Section III to build our slicing environment. We employed two rack servers configured according to

Traffic Simulation
The testing scenarios were sending two types of data: In the data network, we would set up a server to process the packet from the specific traffic generator. Figure 6 shows the data paths for the proposed system and the compared system. The UPF of the proposed system is sliced into three with different bandwidth requirements while the UPF of the compared system remains as one with the aggregated bandwidth of all UPFs in the proposed system.

Performance Evaluation
We evaluate the performance by collecting throughput, response time and CPU utilization under the UDP traffic. Only UDP packets with upLink traffic were     Communications and Network and the compared system. Here the average is calculated from all three types of data traffic. Since the response time of the compared system will increase dramatically when the traffic becomes very large, the proposed system gets a much lower average response time than the compared system. We suspect this was caused by the computational limit of the UPF design in free5GC.
In CPU Utilization, we only measure the user plane slices. The result of CPU Utilization test for the proposed system and the compared system are shown in Figure 9. We allocate the same resource and bandwidth limitation to both systems. Since the overhead of operating system and the heavier usage of computing resources with three UPFs instead of one UPF in the proposed system, the average CPU utilization of the proposed system is approximately three times higher than that of the compared system.

Conclusions and Future Work
In this paper, we propose a 5G multi-slices system that consists of one common CP slice and multiple UP customized slices. To support different types of services, we specify each customized slice subnet in 5G networks with different bandwidths. Our system was constructed by leveraging open source projects including Tacker, OpenStack, free5GC and compliant with the NFV MANO framework.
We provided a framework for deploying network slices on a VM-based virtual environment using the aforementioned open sources. With such a framework, our 5G multi-slices architecture could achieve parallelization on UP to get better performance than the single slice architecture under the same resource allocation.
In our experiment, we design traffic generators to simulate three eMBB ser- In the future, we plan to expand the system to dynamically add user plane functions according to the increasing traffic load. Moreover, we also want to apply docker which leverages lightweight virtualization technologies such as Container to lower the overhead and reduce the cost of resource usage.