Hard vs. Soft Network Slicing: What’s the Difference (Part 2)

Hard vs. Soft Network Slicing: What’s the Difference (Part 2)

In the previous blog post, we introduced network slicing in the context of 5G cellular networks as a way to fulfill the heterogeneous requirements of diverse types of applications by determining how network resources are assigned to application traffic.

We saw that network slicing needs to be available across all components of the 5G cellular network: Radio Access Network (RAN), Mobile Core (MC), and Backhaul Network, and we introduced two mechanisms in 5G to implement network slicing: one based on QoS techniques and denoted as soft network slicing, and another one based on 5G component virtualization and replication and denoted as hard network slicing.

In this post, we describe soft network slicing, which is achieved by assigning a QoS Class Index (QCI) to each traffic class by the user device. Then, every component of the cellular network applies QoS according to its own mechanisms based on the QCI value of the traffic stream. 5G actually specifies a standard set of network slices based on QCI, denoted Standardized Slice Type (SST), in order to determine how resources need to be assigned at the RAN and at the MC level to fulfill the requirements of different types of applications. For example, SST1 applies to eMBB, SST2 applies to URLLC, and SST3 to mMTC [.

For each active user element connected to the RAN, the associated base station exchanges signaling traffic with the MC’s control plane for user’s authentication, registration, and mobility tracking, using the Stream Control Transport Protocol (SCTP) over IP. The base station also establishes one or more tunnels with the MC’s user plane using the General Packet Radio Service Tunneling Protocol (GTP) over UDP/IP, to ensure each different traffic/application type from the user can receive the corresponding differentiated treatment. i.e., each tunnel has a different QCI assigned to it, and the MC´s user plane implements MC slicing for application traffic by providing distinct QoS services based on the QCI of the corresponding GTP tunnel.


Signaling and data tunnels between base station and MC

The backhaul network must also support the differentiated treatment for different classes of traffic that network slicing requires. This is accomplished thanks to the Quality of Service (QoS) primitives provided by IP network nodes (IP routers), including IP packet classification based on TOS/DSCP field in the IP packet header, as well as queue scheduling, policing, and shaping capabilities. Furthermore, backhaul networks need to provide QoS services not only at the traffic class level, but also at the customer level, and when traffic from multiple customers is aggregated on its way towards the MC. This is known as Hierarchical QoS (HQoS) and it is a necessary requirement in the backhaul network to accomplish network slicing in the 5G context.

At the RAN level, RAN slicing assigns resources in the air interface depending on the QCI value of the traffic stream [1]. In addition, 5G also includes RAN-level optimizations for specific applications such as URLLC. For example, RAN Radio Units (RU) in base stations include support for grant-free uplink access, so that users do not need to wait for a channel access grant form the RU in order to use it for communication; as well as downlink eMBB preemption, so that small amounts of data from mMTC or URLLC applications do not need to be queued behind a large data stream from an eMBB application.

Now, even when RAN, backhaul network and MC all have support for soft network slicing to ensure the different treatment to different application types, the latency requirements of applications such as URLLC may not still be met if there is still significant latency across the fixed Internet after traffic leaves the 5G network and before it reaches its final destination, i.e., between the MC and the remote data center (DC) where the application backend actually runs.

End to end delay for 5G applications with soft network slicing

As seen in Figure 2, the cellular network can only guarantee the latency up to the MC, but not on the Internet leg of the end to end path, that needs to be traversed to reach the application backend running in a remote DC. The only way to reduce and manage latency, in that case, is by bringing the DC closer to the MC and the mobile user, i.e., by running the application backend in a DC located closer to the MC, for example, located within a central office or POP of the network operator. These data centers hosting compute and storage resources closer to the edge of the network are known as edge data centers or edge cloud.

However, an edge-located MC may make sense for this URLLC application, but it would be unnecessary for other types of applications that do not have the same latency requirements and for which it makes more sense to send traffic to remote data centers through a centralized MC. That is, a single, centralized MC may not fit all cases. Therefore, it may seem that low-level mechanisms that soft network slicing provides, such as QoS support across all components of the cellular network, are not enough to ensure that network slicing can fulfill all the requirements of heterogeneous 5G applications.

Fortunately, 5G network slicing has the ability to virtualize and replicate its network components, effectively enabling having separate instances for different needs. This is the basis for hard network slicing, that will be covered in the third and last post of these series on 5G Network slicing.

We will post Part 3 next week.