Network Slice Selection Function for Data Plane Slicing in a Mobile Network.

Javier Jose Diaz Rivera Computer Engineering

Jeju National University Jeju, Republic of Korea shaifvier@gmail.com

Talha Ahmed Khan Computer Engineering

Jeju National University Jeju, Republic of Korea talhajadun@gmail.com

Abstract—Network Function Virtualization (VNF) is one of the main drivers for the next generation of mobile networks. It allows the creation of multiple and diverse functionalities over a single physical infrastructure thus fulfilling the main requirements for 5G mobile networks that focus on serving heterogeneous ecosystems. The research presented in this literature focuses on a Network Slice Selection Function (NSSF) for the selection of Data Plane network slices, which are created and configured with specific QoS that cater to the need of network users. As the complexity of managing multiple Virtual Network Functions (VNF) grows with the number of Data Plane Network Slices, a system that abstracts the configuration of the mobile network is needed. This paper positions the NSSF as part of a three-layer Virtual Mobile Network System that contains an Application Layer for Policy creation, a Management Layer for Orchestration of VNFs and a Physical Layer for the deployment of network functions.

Keywords—5G, NSSF, M-CORD, TOSCA, Network Slice, Data Plane QoS

I. INTRODUCTION

5G is characterized by an ample diversity of use cases and multiple requirements in terms of bandwidth, power and services, [1]. Network Slicing is the key ingredient that is needed to efficiently meet these technical requirements. It allows operators to deploy only the necessary network functions in order to support particularly market needs. This cater directly to devices that require specific functionality from network functions without having to deploy complex and expensive hardware resources that are not used in full capacity, thus resulting directly in savings and efficiency.

Network Slicing relies heavily on the use of network virtualization technologies such as Network Function Virtualization (NFV) and Software-Defined Networking (SDN) which aim to move modern networking to a software-based automation paradigm [2, 3]. Taking this into account multiple efforts have been done to achieve efficient management in mobile Network Slicing systems. H. Flinck et al. From Nokia Labs have proposed a system for Network Slicing Management and Orchestration that aligns with work done by 3GPP and ETSI by considering a Network Slice Management Function (NSMF) [4] coupled with an NFV Orchestrator based on the MANO reference architecture [5]. Interestingly, their proposal includes a three-layer architecture made up of a Service Instance Layer managed by a service level orchestrator, a Network Slice Instance Layer where the NSMF and NFV orchestration reside and a Resource Layer where the “subnets” of network slices exist with particular network functions that are instantiated for each slice. Although the proposal includes a feasible design oriented to Network Slice Management, no further development exists for

*Corresponding Author

this research. Furthermore, in the Wireless World Research Forum white paper for E2E-Network Slicing [6] a compilation of 3GPP technical specification functionality for network slicing along proposals from multiple authors is presented. The literature shows procedures of slicing for the Control Plane, Data Plane and Radio Access Network, and includes description and functionality of a Network Slice Selection Function and its interaction with 5G Network Functions. As extensive as this white paper content is, there is no further implementation or proof of concept related to the functionality proposed in the document.

The focus of our research is the provisioning and deployment of Data Plane Network Slices and the selection of a proper slice by taking identification parameters from the user equipment (UE). In order to effectively operate a sliced network, it is evident that a management system is required. This literature presents enhancements of a previously proposed Network Slice Selection Function (NSSF) [7] to allow the selection of data plane slices. To achieve this, the NSSF has been situated as part of a three-layer System. The top layer includes an Intent-Based Networking Tool in charge of the QoS policy definition for the Data Plane Slices. The middle layer focuses on Management of the Virtual Network Functions (VNF) and Policy implementation which is handled by the M-CORD Platform [8]. The lower level is the Physical Layer where the VNFs that represent the EPC and eNodeB reside, it is in this layer where the NSSF is deployed and the slice selection is done.

The paper is divided into the following sections. Section II presents the three-layer system architecture and its details, section III focuses on the description of the NSSF and its functionality, section IV presents the implementation and results and finally section V concludes the document.

II. SYSTEM OVERVIEW

A virtualized mobile network system architecture is represented in Fig. 1. The three layers that comprise the system are defined as Application, Management and Physical layer, organized in a Top-to-Bottom structure. High-level policies are defined in the Application Layer and pushed to the Physical Layer where the VNFs of the mobile network are deployed. The abstracted policies need to be tailored and applied to each VNF by the means of the Management layer through an Orchestrator that leverages the complex tasks of managing the different VNFs that reside in the Physical layer.

Wang-Cheol Song* Computer Engineering

Jeju National University Jeju, Republic of Korea

philo@jejunu.ac.kr

Asif Mehmood Computer Engineering

Jeju National University Jeju, Republic of Korea

asif@jejunu.ac.kr

© Copyright IEICE – The 20th Asia-Pacific Network Operations and Management Symposium (APNOMS) 2019

Fig. 1. Mobile Network Slicing System.

A. Application Layer The upper layer main functionality is the creation of

network contracts and the definition of QoS for each of them [9]. This is achieved by applying the concept of Intent-Based Networking (IBN) which focuses on defining “what to do” without specifying “how to”. This concept aims to deliver the business goals in the most abstracted form as possible independently of the complexity of the network system that sits in the bottom layer. The contracts that are defined in this layer, are translated to Topology and Orchestration Specification for Cloud Application (TOSCA) files that the management layer can understand and use for configuration of the network slices

B. Management Layer This layer takes the TOSCA configuration files defined by

the Application Layer and uses it to configure each VNF that is defined as a data plane network slice. The heart of this layer is the M-CORD Platform which contains an extensible service control plane known as XOS that serves as the orchestrator, a network controller (ONOS) and a cloud manager (OpenStack). XOS contains service synchronizers that monitor the operation of the VNFs. Their role is to keep the management layer up to date with the status of the physical layer. The synchronizer capability of monitoring the VNF status (number of instances, deployment errors, network interface, and IP-Address assignment) is essential for the NSSF. Through the synchronizer, the Management Layer can get bidirectional communication with all the running VNFs.

C. Physical Layer The multiple VNFs that represent a mobile network sit on

this layer. LTE-A based open source components from Open Air Interface were used for both the EPC and the eNodeB Emulation [10]. The configuration of the mobile network is handled automatically by the management layer. This is achieved by feeding proper TOSCA configuration files that include Service Graph definitions, network, and service instance creation. The physical layer is in constant change due to the policies that are pushed from the upper layer and the NSSF always contain the up-to-date status of the system, thanks to the synchronizer that is running on the management layer.

III. NETWORK SLICE SELECTION FUNCTION DESCRIPTION

Fig. 2. NSSF Service and VNF.

The NSSF is based on 3GPP implementation for the 5G Mobile Network Architecture [11]. Fig. 2. Shows how the XOS Service for the Network Slice Selection Function plays a key role in collecting the information of current deployed VNFs and keep it on record in a Database that the NSSF VNF accesses for selection of slices.

A. Network Slice Selection Function synchronizer

Fig. 3. NSSF Synchronizer Algorithm

The synchronizer running inside the XOS service for the NSSF has two purposes. Fig. 3 shows the logic behind the synchronizer. Firstly, it watches over the status of the mobile network by monitoring all available SPGW-C and SPGW-U VNFs that get instantiated. For both cases, it gets a list of Tenants that are successfully provisioned. These tenants are represented as objects with specific attributes that were defined in the data model of their respective XOS service. Secondly, The NSSF synchronizer extracts two attributes from both SPGW-C and SPGW-U tenant lists, the first attribute is the network.port and the second attribute is the name of the network service. As the synchronizer works on the Management Layer it can obtain all the tenant information directly from XOS. The network.port is represented by the IP-Address of the tenants, and the service is defined by the type of contract that was created in the Application Layer e.g. HD-Video, WEB, IoT. This attribute is the most important for association of network slices, as the SPGW-C and SPGW-U are linked together based on the service that was assigned to them when the contracts were defined. The information pertaining to the total SPGW-C and SPGW-U tenants that currently exist in the network is inserted in a Slice-Table which is located inside the vHSS database.

© Copyright IEICE – The 20th Asia-Pacific Network Operations and Management Symposium (APNOMS) 2019

There is only one SPGW-C per service and multiple SPGW-U that can be linked to it. The reasoning behind this is to easily differentiate the multiple Data Plane Network Slices that are created in the Physical Layer, as the SPGW-C works as a stitching point for the SPGW-U which gets the QoS configuration from the network contracts.

B. Network Slice Selection Function VNF The NSSF also has logic that runs on the Physical Layer.

It follows the UE network registration procedure and session establishment and interacts directly with the Mobility Management Entity (vMME) for Data Plane Network Slice Selection and indirectly with the Home Subscriber Server (vHSS) for accessing the information of available slices from the database. The procedure for slice selection can be appreciated in the sequence diagram presented in Fig. 4. Firstly, the UE initiates network registration by sending the connection message from the eNodeB to the vMME. The message includes the International Mobile Subscriber Identity (IMSI) which is a fifteen-digit combination that includes the Public Land Mobile Network (PLMN) for the first five digits and Mobile Subscription Identification Number (MSIN) for the rest of the enumeration. These numbers are used for UE identification and Data Plane Network Slice allocation. Secondly, once the vMME finish the registration of the UE into the network, it forwards the IMSI to the NSSF which in turn connects to the database inside the vHSS and queries the Slice-Table to get the SPGW-C IP-Address and the SPGW-U IP-Addresses that correspond to the network service requested by the UE, the NSSF keeps the record of each UE assigned to a Data Plane Slice. Thirdly, the IP-Addresses are forwarded to the vMME which proceeds with the Session Establishment for the UE using the IP information for connecting with the SPGW-C. The MME also stores the SPGW-U IP-Address in the bearer-context message that is sent to the SPGW-C with session information. Finally, the SPGW-C uses the bearer-context information to select an SPGW-U (From a list of registered Data Planes) using the IP-Address of the Data Plane Slice that was received from the vMME and proceeds to create a PDU Session by enabling a GTP-Tunnel between the UE and the selected SPGW-U.

Fig. 4. NSSF VNF operation.

In the current implementation of the NSSF, the IMSI plays a crucial part for the slice selection. Our research has labeled the last two digits of the IMSI as Slice Differentiators by allocating the second last digit to identify the stitch point of a Data Plane Slice i.e. SPGW-C and the last digit to identify the SPGW-U that is going to serve the connection of the UE. Fig. 5 shows the case when two UE with specified IMSI try to

access the network and are directed to their correspondent Data Plane Network Slices.

Fig. 5. IMSI based slice selection.

The Slice-Table inside the vHSS is filled by the NSSF synchronizer, a representation of this table is shown in Fig. 6 where four Data Plane Network Slices are configured for two services e.g. VIDEO and WEB. The services are directly proportional to the number of SPGW-C. For a new service to exist, it needs to be defined in the contract policies on the Application Layer, this creates a new SPGW-C instance in the Physical Layer. Following the same logic, any QoS policies defined for a Data Plane Slice are associated with a Service and creates SPGW-U instances that register to their corresponding SPGW-C.

Fig. 6. Slice-Table content example.

IV. IMPLEMENTATION AND RESULTS Two contracts are defined using the GUI, one for VIDEO

slices and another one for WEB. For the VIDEO Contract, three data plane slices are configured, using predefined QoS values, Slice-1 has an up-rate of 10 Mbps and downrate of 20 Mbps, Slice-2 an up-rate of 15 Mbps and downrate of 30 Mbps and Slice-3 has an up-rate of 20 Mbps and downrate of 40 Mbps. Also, the WEB Contract defines a single Data Plane Slice with a Custom QoS for uprate as 2 Mbps and downrate as 4 Mbps for Slice-4. The configuration is translated into TOSCA files for the deployment of respective SPGW-C and SPGW-U on the physical layer.

The QoS policies defined in the Application Layer are automatically pushed to each SPGW-U during deployment. Linux Traffic Control rules are applied on the SPGW-U, this

© Copyright IEICE – The 20th Asia-Pacific Network Operations and Management Symposium (APNOMS) 2019

is native to the way OAI developed the system, but instead of using static QoS for these rules (from a config file) the rules are provisioned by the Management Layer. This limits the throughput of each Data Plane Slice, effectively differentiating the transmission rate for each of the channels.

For assessing the functionality of the NSSF four UE configurations are defined inside the emulator, the corresponding IMSI for each device is 208930100001111 for UE1, 208930100001112 for UE2, 208930100001113 for UE3 and 208930100001124 for UE4. Each Data Plane slice has been automatically provisioned with its own QoS by the management layer, in order to test the capabilities of each slice, data transmission tests have been performed on each one individually. Fig. 7 and 8 show the condensed results of the transmission tests for the uprate and downrate QoS. From both pictures, the rules are in effect for each slice as the rates are within the threshold that was configured. Traffic control rules can be deployed with minimal resources without affecting the efficiency of the Data Plane slices. It is important to note that the results presented in this literature are taken from a completely virtual environment that is set up in a single physical server. Due to this, repeating the tests have diminishing returns or inconsistent results with previous tests as the performance of the environment degrades over time. Although, E2E slicing is fully presented in this implementation, both the UE and eNodeB are emulated which limits the possible tests that can be done when simulating a real-life scenario. As there is no real Commercial Of-The-Shelf user equipment (COTS) connected to an eNodeB, the emulator creates virtual interfaces for each UE that are tunneled to an SPGW-U. To achieve the test results for this literature, iPerf was used by specifying the virtual interface of the UE that is being tested.

Fig. 7. Uprate iPerf test results.

Fig. 8. Downrate iPerf test results.

V. CONCLUSION The paper presented an implementation of an NSSF for

Data Plane Slice Selection. The literature makes evident that besides the VNF required for slice selection a management system is necessary for provision, update, and control of the physical layer VNFs that comprise the slices. Also, the implementation focuses only on the Data Plane as QoS for each of the SPGW-U can be clearly defined in an Application Layer and implemented in the Physical Layer as traffic control rules. The Data Plane itself is enough for showing a mobile system that serves heterogenous UE with different requirements for isolated network traffic. As the proposed system evolves, a new grade of automation can be added with the inclusion of a monitoring agent that can oversee the status of the SPGW-U traffic in real-time.

ACKNOWLEDGMENT This research was supported by Basic Science Research

Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Education (NRF-2016R1D1A1B01016322)

This research was supported by the MSIT (Ministry of Science and ICT), Korea, under the ITRC (Information Technology Research Center) support program (IITP-2019-2017-0-01633) supervised by the IITP (Institute for Information & communications Technology Planning & Evaluation).

REFERENCES

[1] GSMA, “Report on 5G Network Slicing & Business Opportunities - Future Networks,” November 2017, [Online]. Retrieved May 7, 2019, from https://www.gsma.com/futurenetworks/digest/new-5g-network-slicing-report/

[2] Open Network Foundation, TR-521: SDN Architecture 1.1, 2016.

[3] Peter Hedman and NGMN P1 WS1 E2E Architecture team. Description of Network Slicing Concept, 2015.

[4] H. Flinck, C. Satori, A. Andrianov, C. Mannweiler, N. Sprecher, Nokia, Network Slicing Management and Orchestration, Internet Engineering Task Force, July 2017, [Online]. Retrieved May 7, 2019, from https://tools.ietf.org/id/draft-flinck-slicing-management-00.html

[5] ETSI, ETSI GS. NFV-MAN 001: Network Function Virtualisation (NFV): Management and Orchestration, 2014.

[6] Future Mobile Communication Forum, Wireless Wolrd Research Forum, “End to End Network Slicing,” White Paper 3, Outlook 21, November 2017.

[7] Javier Diaz Rivera, Talha Ahmed Khan, Mehmood Asif, Wang-Cheol Song. “Network Slice Selection Function on M-CORD”, KNOM Review '18-02 Vol.21 No.02, December 2018.

[8] Open Network Foundation. Mobile-Central Office Rearchitected as a Datacenter (M-CORD) v4.1, Retrieved May 7, 2019, from: https://guide.opencord.org/cord-4.1/

[9] Asif Mehmood, Javier Diaz Rivera, Talha Ahmed Khan, Wang-Cheol Song, “An intent-based mechanism to create a network slice using contracts”, Proceedings of Symposium of the Korean Institute of communications and Information Sciences, (pp. 180-181) 2018.

[10] Eurecom, Open Air Interface Alliance. Open-Air Interface Project. Retrieved May 7, 2019, from: https://gitlab.eurecom.fr/oai/

[11] 3GPP, TS 23.501 V15.0.0, Technical Specification Group Services and System Aspects; System Architecture for the 5G System; Release 15, December 2017.

© Copyright IEICE – The 20th Asia-Pacific Network Operations and Management Symposium (APNOMS) 2019