Before you read this post, we recommend you read the following articles first: 

• Mobile Network Architecture for 5G Era - New C-RAN Architecture and Distributed 5G Core 
• 5G network as envisioned by KT - Analysis of KT's 5G network architecture

 

5G and Network Slicing

 

With 5G being actively discussed everywhere, Network Slicing certainly is one of the most discussed technologies these days. Network operators like KT, SK Telecom, China Mobile, DT, KDDI and NTT, and also vendors like Ericsson, Nokia and Huawei are all recognizing it as an ideal network architecture for the coming 5G era.

 

This new technology lets operators slice one physical network into multiple, virtual, end-to-end (E2E) networks, each logically isolated including device, access, transport and core network (like partitioning a HDD into C and D drives) and dedicated for different types of services with different characteristics and requirements.

 

For each network slice, dedicated resources (like resources within virtualized servers, network BW, QoS, etc.) are guaranteed. As slices are isolated from each other, an error or fault occurred in one slice does not cause any effect on communication in other slices.

 

 

Then, why 5G needs network slicing?

​

So far, mobile networks (of up to 4G), mainly serving mobile phones, have been optimized for phones only, at large. However, in 5G era, they have to serve a variety of devices with different characteristics and needs. Some of the most mentioned use cases for 5G era are Mobile Broadband, Massive IoT, and Mission-critical IoT, and they all require different types of features and networks in terms of mobility, charging, security, policy control, latency, reliability, etc.

 

For instance, an massive IoT service that connects immobile sensors measuring temperature, humidity, precipitation, etc. to mobile networks does not require features like handover or location update, which have been critical in serving mobile phones. Or, a mission-critical IoT service (like autonomous driving or remote controlled robots) requires, unlike mobile broadband service, a substantially low E2E latency - less than a few ms.  

 

Table 1. Most compelling use cases for 5G

	5G Use Case	Example	Requirements
	Mobile Broadband	4K/8K UHD, hologram, AR/VR	High capacity, video cache
	Massive IoT	Sensor network (metering, agriculture,  building, logistics, city, home, etc.)	Massive connection (200,000/km2)  mostly immobile devices
	Mission-critical IoT	Motion control, autonomous driving,  automated factory, smart-grid	Low latency (ITS 5ms, motion control 1 ms)  high reliability

 

Then, does this mean we have to make dedicated networks for each service? So, one for 5G phone, one for 5G massive IoT, another for 5G mission-critical IoT, and so on? No, we do not have to because network slicing can give you multiple logical networks over a single physical network. A much more cost-effective way!

 

 

Figure 1. Network slicing: Why do we need it?

 

Below is an illustration of 5G network slices by presented in its 5G White Paper.

 

Figure 2. 5G network slices illustrated by NGMN

 

 

How do we implement E2E network slices?

 

The concept of network slices presented in Figure 2 above may look too abstract. Let's take a closer look at how network slices are actually implemented.

 

(1) 5G RAN and Core: NFV

 

❶ In the current mobile networks, main devices are phones, and RAN (DU and RU) and Core functions are built with dedicated network equipment provided by RAN vendors. ❷  To implement network slices, Network Function Virtualization (NFV) is a prerequisite. Basically, the main idea of NFV is to install Network Function S/W (i.e., MME, S/P-GW and PCRF in Packet Core, and DU in RAN) all onto Virtual Machines (VMs) deployed on a virtualized commercial server (COTS; commercial off-the-shelf), NOT onto their dedicated network equipment individually. This way, RAN works as edge cloud while Core works as core cloud. Connectivity among VMs located in edge and core clouds are provisioned using SDN.  ❸ Then, slices are created for each service (i.e., phone slice, massive IoT slice, mission-critical IoT slice, and so on). 

 

Figure 3. How to slice network

 

Figure 4 shows how applications dedicated for each service can be virtualized and installed in each slice. For example, slices can be configured as follows:

• UHD slice: All virtualized DU, 5G Core (UP), and Cache server in Edge cloud, and virtualized 5G Core (CP) and MVO server in Core cloud

• Phone slice: 5G Core (UP and CP) with full mobility features, and IMS server, all virtualized in Core cloud 

• Massive IoT slice (e.g., sensor network): Simpler, light duty 5G Core WITHOUT mobility management feature in Core cloud 

• Mission-critical IoT slice: 5G Core (UP) and associated servers (e.g., V2X server) all down in Edge cloud for minimized transmission delay

 

As seen so far, dedicated slices are created for services with different requirements. And virtualized network functions are being placed in different locations in each slice (i.e., Edge or Core cloud) depending on services. Also, some network functions, like charging, policy control, etc., can be essential in one slice, but unnecessary in other slices. Operators can customize network slices the way they want, probably in the most cost-effective way.  

 

Figure 4. How to slice network (cont.)

 

Up to this point, it was NFV's job. Then, what role does SDN play in network slicing?

 

(2) Network slicing between Edge and Core clouds: IP/MPLS-SDN

 

SDN, although once a pretty simple concept when first introduced, has now become more complicated than ever as every vendor claims their SDN authentic. Let's take Overlay type, an SDN approach that offers connectivity between VMs by leveraging the existing network infrastructure, as an example.  

 

Figure 5. E2E network slicing

 

First let's see how network connectivity between VMs in Edge and Core clouds are secured. Inter-VM networking must be made over both IP/MPLS SDN, and its sub SDN, Transport SDN. Here, however, we will discuss router vendor-supplied IP/MPLS SDN only.

 

Both Ericsson and Juniper have presented this type of IP/MPLS SDN networking architecture, both operating slightly differently, but pretty similar in terms of how VMs are connected through SDN. 

 

In Core cloud lies a virtualized server. In the Hypervisor of the server, a built-in vRouter/vSwitch is run. SDN Controller performs provisioning of the virtualized server and DC G/W routers (PE router of MPLS L3 VPN installed in cloud data center) to create SDN tunnels (i.e., MPLS GRE, VXLAN) between each VM in the Core cloud (e.g., 5G IoT Core) and DC G/W router.

 

The SDN Controller then performs mapping between these tunnels and MPLS L3 VPN (e.g., IoT VPN). The process is the same in Edge cloud as well, creating IoT slice connecting from Edge cloud, to IP/MPLS backbone, and all the way to Core cloud. This process can be implemented using technologies and standards that have become available so far. 

 

(3) Network slicing between Edge cloud and RU at cell site

 

Now what's left is fronthaul. How do we slice this fronthaul between Edge cloud and 5G RU? To begin with, 5G fronthaul would have to be defined first. There are some alternatives in discussion (e.g., introducing new packet-based fronthaul by redefining functions of DU and RU), but no standard definition has been made yet. Figure 6 is an illustration presented in ITU Focus Group IMT 2020, and gives an example of virtualized fronthaul.   

 

Figure 6. Example of 5G C-RAN network slicing by ITU

[Source: Report on Standards Gap Analysis, ITU, Focus groups on IMT-2020, Oct. 2015]

 

Network slicing for 5G era is still shaping up, with concerns and issues remaining unsolved. So, we will keep track of technological updates by operators, vendors and standardization organizations in Korea and around the world, to keep you updated about the technology.