Network slice deployment and configuration in Pledger

Standard

Estela Carmona and August Betzler, i2CAT Foundation

Network slicing can provide dedicated and isolated compute, network, and radio resources according to specific quality of service (QoS) requirements of applications. In Pledger, the SOE and RAN Controller components work together to add network slicing capabilities to the core platform. 

 

Two distinct scenarios with different underlying technologies have been explored in Pledger. In the first scenario, cloud-native network slicing capabilities are explored, by leveraging the use of Kubernetes as a virtual infrastructure manager. This scenario is applied to the vehicular domain, where the radio technology of choice is based on IEEE 802.11p to implement a safety application for micro-mobility in cities. In the second scenario, two private mobile network operators (MNOs) are assigned dedicated slices in a common, 5G new-radio enabled infrastructure where, instead, Openstack is used as the virtual infrastructure manager.

 

In the V2X network slicing scenario, Pledger creates an end-to-end network slice that can be used for communication among vehicles’ on-board units and road-side units. Using SOE, Pledger performs a virtual partition of a Kubernetes-based infrastructure, sets-up OSM to orchestrate network functions, and creates virtual networks with dedicated VLANs for the isolation of traffic coming from different road-side units (RSUs). The RAN Controller then performs the necessary radio configurations in the road-side units and, finally, the V2X slice is activated through the instantiation of a Kubernetes-based V2X software stack and the configuration of an Outside the Context of a BSS (OCB) interface for each radio device (i.e., for each road-side unit). The final slice configuration is shown in Fig. 1., whereas traffic associated to the V2X-Com pod from the V2X software stack in operation is shown in Fig. 2.

Fig. 1: V2X slice configuration

Fig. 2: V2X-Com module from the V2X software stack

Fig. 3: 5G network slicing scenario

In the 5G network slicing scenario (Fig 3.), two isolated network slices with 5G NR elements are deployed, and the connectivity of user equipment to the slices is then showcased, along with relevant RAN-related metrics. During the deployment of 5G network slices, Pledger uses SOE to communicate with an Openstack-based infrastructure in order to create a compute chunk with some given amount of resources. Openstack is also used to create two isolated virtual networks per slice, needed for the management and data planes. The RAN Controller is used to select the desired radio cell from the Amarisoft 5G test-box hardware with relevant radio parameters. During the last step of the deployment, the SOE and RAN Controller are used to deploy the 5G cores, one for each MNO, to configure the PLMNIDs and to register users’ IMSIs. The two 5G cells start radiating and users registered to the two MNOs can now connect to their respective cells. Thanks to the isolation and dedicated use of resources introduced via slicing, the MNO 5G networks are completely independent and separated from each other even though they use a shared infrastructure. RAN metrics are gathered by the RAN Controller through a custom exporter running on an Amarisoft 5G test box (Fig. 4); these metrics are then retrieved by the RAN Controller’s Prometheus instance, which can be seamlessly integrated with Pledger’s monitoring engine and used for setting up SLAs.

Fig. 4: RAN metrics

Add new comment

logo_inverse

is loading the page...