Why 5G needs network slicing and how to implement it

Why 5G needs network slicing and how to implement it

[[189050]]

When 5G is widely mentioned, network slicing is the most discussed technology. Network operators such as KT, SK Telecom, China Mobile, DT, KDDI, NTT, and equipment manufacturers such as Ericsson, Nokia, and Huawei all believe that network slicing is the ideal network architecture in the 5G era.

This new technology allows operators to divide a hardware infrastructure into multiple virtual end-to-end networks. Each network slice is logically isolated from the device to the access network to the transmission network and then to the core network, adapting to the different characteristic requirements of various types of services.

For each network slice, dedicated resources such as virtual servers, network bandwidth, and quality of service are fully guaranteed. Since the slices are isolated from each other, errors or failures in one slice will not affect the communication of other slices.

Why 5G needs network slicing

From the past to the current 4G network, mobile networks mainly serve mobile phones, and generally only some optimizations are made for mobile phones. However, in the 5G era, mobile networks need to serve devices of various types and requirements. The application scenarios that people mention more often include mobile broadband, large-scale Internet of Things, and mission-critical Internet of Things. They all require different types of networks and have different requirements in terms of mobility, billing, security, policy control, latency, reliability, etc.

For example, a large-scale IoT service connects fixed sensors to measure temperature, humidity, rainfall, etc. It does not require the switching and location updates of mobile phones that are the main services in the mobile network. In addition, mission-critical IoT services such as autonomous driving and remote control of robots require end-to-end latency of several milliseconds, which is very different from mobile broadband services.

Main application scenarios of 5G

Does this mean that we need to build a dedicated network for each service? For example, one for 5G mobile phones, one for 5G large-scale IoT, and one for 5G mission-critical IoT. In fact, it is not necessary, because we can use network slicing technology to slice multiple logical networks on an independent physical network, which is a very cost-saving approach!

Application requirements for network slicing

The 5G network slice described in the 5G white paper released by NGMN is shown in the following figure:

NGMN 5G network slicing diagram

How do we achieve end-to-end network slicing?

(1) 5G radio access network and core network: NFV

In today's mobile networks, the main device is the mobile phone. RAN (DU and RU) and core functions are built with dedicated network equipment provided by RAN vendors. In order to implement network slicing, network function virtualization (NFV) is a prerequisite. Basically, the main idea of ​​NFV is to deploy the network function software (i.e. MME, S/P-GW and PCRF in packet core and DU in RAN) all in virtual machines on commercial servers instead of separately deployed in their dedicated network equipment. In this way, RAN is treated as edge cloud and core functions as core cloud. The connection between VMs located in edge and core cloud is configured using SDN. Then, slices are created for each service (i.e. telephony slice, massive IoT slice, mission-critical IoT slice, etc.).

How to implement network slicing

The following diagram shows how applications specific to each service can be virtualized and installed in each slice. For example, a slice can be configured as follows:

(1) UHD slicing: virtualizing DU, 5G core (UP), and cache servers in the edge cloud, and virtualizing 5G core (CP) and MVO servers in the core cloud

(2) Phone slicing: Virtualizing the 5G core (UP and CP) and IMS servers with full mobile capabilities in the core cloud

(3) Large-scale IoT slicing (e.g. sensor networks): Virtualizing a simple and lightweight 5G core in the core cloud without mobility management functions

(4) Mission-critical IoT slicing: Virtualizing the 5G core (UP) and related servers (e.g., V2X servers) in the edge cloud to minimize transmission latency

Until now, we need to create dedicated slices for services with different requirements. And virtual network functions are placed in different locations in each slice (i.e. edge cloud or core cloud) according to different service characteristics. In addition, some network functions such as billing, policy control, etc. may be necessary in some slices but not in other network slices. Operators can customize network slices the way they want, and it may be the most cost-effective way.

How to implement network slicing 2

(2) Network slicing between edge and core cloud: IP/MPLS-SDN

Software Defined Networking, although a simple concept when it was first introduced, has become increasingly complex. Taking Overlay as an example, SDN technology can provide network connections between virtual machines on the existing network infrastructure.

End-to-end network slicing

First, let's look at how to ensure that the network connection between the edge cloud and the core cloud virtual machines is secure. The network between virtual machines needs to be implemented based on IP/MPLS-SDN and Transport SDN. In this article, we mainly discuss the IP/MPLS-SDN provided by router manufacturers. Ericsson and Juniper both provide IP/MPLS SDN network architecture products. The operations are slightly different, but the connection between virtual machines based on SDN is extremely similar.

In the core cloud are virtualized servers. In the server's hypervisor, a built-in vRouter/vSwitch runs. The SDN controller provides tunnel configuration between the virtualized server and the DC G/W router (PE router that creates MPLS L3 VPN in the cloud data center), and creates an SDN tunnel (i.e. MPLS GRE or VXLAN) between each virtual machine in the core cloud (such as the 5G IoT core) and the DC G/W router.

The SDN controller then manages the mapping between these tunnels and MPLS L3 VPNs (such as IoT VPNs). The process is the same in the edge cloud, creating an IoT slice that connects from the edge cloud to the IP/MPLS backbone and all the way to the core cloud. This process can be implemented based on the mature and available technologies and standards so far.

(3) Network slicing between edge and core cloud: IP/MPLS-SDN

Now what is left is the mobile fronthaul network. How do we cut this mobile fronthaul network between the edge cloud and the 5G RU? First, the 5G fronthaul network must be defined first. There are some options in the discussion (such as introducing a new packet-based fronthaul network by redefining the functions of DU and RU), but no standard definition has been made yet. The figure below is an illustration given in the ITU IMT 2020 working group and gives an example of a virtualized fronthaul network.

ITU organizes 5G C-RAN network slicing example

Network slicing technology in the 5G era is still evolving, and some concerns and issues remain unresolved. Therefore, we will track technology updates from operators, vendors, and standardization organizations in Korea and around the world to keep you up to date with the latest information about the technology.

<<:  3 ways to do next generation network migration correctly

>>:  How does Beijing’s government cloud build the city’s “strongest brain”?

Recommend

We cannot allow "free-network tools" to threaten network information security

Recently, the official website of the Ministry of...

Is the network model seven layers, five layers, or four layers?

When we are doing network development, we often h...

Linkerd 2.10 (Step by Step) (I) Adding your service to Linkerd

[[405467]] In order for your services to take adv...

Comparing WiFi 6 and WiFi 5, there are three differences

[[430598]] The shopping festival is here. If you ...

Quick Start with Linkerd v2 Service Mesh

In this guide, we'll walk you through how to ...

TCP

[[381851]] This article is reprinted from the WeC...