In the previous two posts of these series, we first 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 different types of application traffic. We then saw there are two mechanisms in 5G to implement network slicing: soft network slicing and hard network slicing. We covered soft network slicing in the second post of the series, describing how it uses QoS techniques across all components of the 5G cellular network (Radio Access Network (RAN), Mobile Core (MC), and Backhaul Network), to provide differentiated treatment for different traffic classes. We also saw that these low-level mechanisms are sometimes not enough to fulfill the heterogeneous requirements of different applications over the same physical network infrastructure.
In this post, we are going to describe how hard network slicing uses virtualization and replication of 5G components to address the shortcomings of soft network slicing, by effectively enabling separate virtual network instances for different application needs.
Hard Network Slicing relies on component virtualization and replication, thanks to the software-based, cloud-based nature of the 5G architecture, along with its support for component disaggregation. I.e. each of the RAN, backhaul network, and MC components of the cellular network is split into virtual components that can be replicated and then run in different geographical locations. Then, virtual components can be logically grouped into what are effectively separate cellular network instances (or hard network slices) than can then each be configured to meet the requirements of different types of applications. E.g., URLLC applications that require application backends to run as close to end-users as possible, or mMTC applications that instead depend on backends located in remote data centers.
For MC, the cloud-based service mesh that forms a 5G MC can be replicated, effectively allowing the creation of multiple MC slices of different Standardized Slice Type (SST. For example, SST1 applies to eMBB, SST2 applies to URLLC, and SST3 to mMTC. Furthermore, each MC slice may run at a different location, so MC slices for URLLC applications could run an edge data center, and MC slices for other types of applications could run in more centralized locations, e.g., in a centralized Mobile Core location that acts as a gateway to the greater Internet.
RAN can be split into multiple components: the Radio Unit (RU) running in the base station, the Distributed Unit (DU) running in a central office in charge of scheduling user traffic among one or more RUs, and the Centralized Unit (CU) aggregating multiple DUs and communicating with the MC. RAN also supports virtual schedulers over the same air interface, effectively enabling virtual base stations which different RU, DU, and CU each, and potentially running in different locations for each of the different virtual base stations.
Backhaul networks rely on the disaggregation of data plane and control plane in order to create network slices. The data plane runs on specialized hardware in white label switches, and the control plane runs in the cloud where it can be virtualized and replicated. This enables the creation of multiple virtual routers in the same physical device, and the grouping of multiple virtual routers into separate, administratively separated virtual backhaul network slices.
Note that the backhaul network itself becomes more complex, because the separate components of a RAN now need to be connected too: the RU-DU interconnection network is denoted as the fronthaul network, the DU-CU interconnection network as the midhaul network, and the CU-MC interconnection network as the actual backhaul network.
Putting everything together, we could see a certain virtual scheduler in a RAN being applied to traffic pertaining to a given URLLC application, and that traffic could then be transported by a backhaul network slice towards an MC user plane slice running in the local edge data center, whereas traffic pertaining to an mMTC and eMBB application could be transported through a different virtual base station and by another backhaul network slice towards a centralized MC on its way to a remote data center in the greater Internet. Figure 1 shows an example of how the 5G virtual components that form these two examples of hard network slices would be distributed across the same physical cellular network
Figure 1 shows two virtual cellular networks (or hard network slices). One is formed by the combination of the RAN 1 virtual base station, the BN1 virtual backhaul network, and the MC “edge” user plane slice. The second one is formed by the combination of RAN 2, BN2, and MC “central” user plane slice.
RAN 1 components are distributed between the base station (RU, and DU) and the edge cloud in the central office (CU), and its distribution is actually different from the same components in RAN 2 (DU and CU running in the edge cloud, and only RU in the base station).
Both the control plane of the virtual routers and the user plane of MC slice “edge” run at the Edge location in the central office, whereas the user plane of MC slice “central” runs at the Mobile Core location.
In addition, the “Edge App” application backend also runs at the Edge location in the central office. It is associated with the virtual cellular network (RAN 1, BN1, MC “edge”), which means that the GTP tunnel carrying user traffic destined to the application backend actually ends at the edge location (where the MC “edge” user plane slice is). This is denoted as early breakout, and enables the application to achieve end to end delays as low as 5ms or less.
This can only be achieved if both the “Edge App” application backend and the MC “edge” user plane slice are in the same location. Without hard network slicing, there would have been a single MC user plane at the Mobile Core central location. User traffic would have exited the GTP tunnel there and would have had to “come back” to the central office where the “Edge App” application backend would be, incurring in unnecessary extra delay and potentially jeopardizing the latency requirements of the applications. In fact, the latter situation is what would have been accomplished with soft network slicing. Note that the edge data center hosts both external applications such as the “Edge App” as well as internal applications to the operator, such as the MC user plane slice, the cloud control plane of virtual routers, or the DU and CU of virtual base stations. In addition, the edge cloud in Figure 1 is located at the central office of an operator. That means that the Multi-Access Edge Computing (MEC) infrastructure that operators are building at these locations can be used to provide compute and storage services to both internal and external applications.
Furthermore, the combination of hard network slicing and MEC enables operators to create and manage multiple virtual cellular networks and to have the flexibility to assign them to different types of applications and/or to different customers. In addition, the administrative separation between these virtual cellular networks also opens the door for customers being able to manage them by themselves.
To summarize, hard network slicing enables the creation of virtual cellular networks that support the heterogeneous requirements of different types of applications over the same physical infrastructure. 5G specifies soft and hard network slicing for both the RAN and the MC, but not for the backhaul network. Without any support for virtualization and replication in the backhaul network, 5G network slicing would be limited to soft network slicing, because even though RAN and MC could be virtualized and replicated, the communication between them would happen over a network that would only have support for traditional, low-level QoS mechanisms. In order to realize the full potential of 5G and implement hard network slicing end to end, the backhaul network must have support for virtualization and replication as well.