RAN slicing - Why is it needed and how can it be leveraged?

Introduction

End users today are ready for?a wider range of telecommunication based services: e.g: voice, video, data, IOT, autonomous driving, gaming etc.?The true power?of 5G lies in being able to provide?these services wherever needed with great quality and?in a cost effective way. Network slicing?is a key tool that can enable the service providers to deliver on this promise. In 5G, network slicing will allow carriers to create virtual data pipelines for each of its data type services, thereby assuring the QOS for each service.?

How is this accomplished?

At a high level, network slicing technology enables the fulfilment of the contrasting/ competing business needs of each service type?by creating multiple logical networks on top of a common physical infrastructure. Each such logical network is tailored for?a specific type of service. Stated another way, CSPs (Communication Service Providers) can address the problem of contrasting/ competing needs by creating multiple virtual networks on top of a common physical network. Each such virtual network provides certain services with guaranteed quality of service and - equally importantly - each such network is isolated from other virtual networks that use the same physical infrastructure.

?

Figure-1.1: Multiple service-type based virtual networks on top of a common physical network infrastructure.

Use cases and capabilities

The key challenge that can be solved by slicing technology is the optimization of resource allocation to various competing services. At the same time, in the quest to implement and?deploy this optimization,?the capability of "multi-vendor?slicing" enables the solution eco-system?to potentially evolve rapidly, increase in effectiveness, efficiency and become more economical. Finally, "Slice SLA assurance" is an essential capability if these technologies are to be monetized. It can also foster the demand for customized/ specialized slice capabilities for the generation of new revenue streams for the operators. Each of these aspects is elaborated on below.

?Resource Allocation Optimization

5G networks are becoming increasingly complex with the densification of millimeter wave small cells, and various new?service offerings, such as eMBB (enhanced Mobile Broadband), URLLC (Ultra Reliable Low Latency Communications), and mMTC (massive Machine Type Communications). These services?are characterized by high speed high data volume (eMBB), low speed ultra-low latency communications (URLLC), and infrequently transmitting low data volume from a massive?number of emerging smart devices (mMTC)?respectively. It is a challenging task for 5G networks to allocate resources dynamically and efficiently among multiple network nodes to support these contrasting?services.

Some 5G services have varying characteristics, with network traffic that can be sporadic and with varying usage patterns in terms of time, location, UE distribution and specific applications. For example, IoT sensor applications might be configured to run during off-peak hours or weekends, while special events such as sporting events or concerts can cause traffic demand to shoot up at very concentrated locations. Further ahead, connected vehicles will require URLLC-style services in the morning or afternoon rush hours to support automated driving and/or eMBB services for infotainment and other services, while mobile or fixed wireless users will tend to consume eMBB services to watch video streaming at night in residential areas.

In a service provider's network, each of the individual service types will be served through a separate?network slice. (For example,?an eMBB slice, an mMTC slice, a URLLC slice etc.) - in other words, they are realized as separate virtual networks - or, in other words, separate network slice instances (NSIs). Therefore, the resources allocated to each NSSI (Network Slice Subnet Instance) to support the O-RAN?nodes can be optimized according to the service requirements. The NSSI resource allocation optimization function trains the?AI/ML model, based on the huge volume of performance data collected over days, weeks, months from O-RAN nodes. It then uses the AI/ML model to predict the traffic demand patterns of 5G networks in different times and locations for each network slice subnet, and automatically re-allocates the network resources ahead of the network issues surfaced.

Multi-Vendor Slices

CSPs (Communication service providers) are keen to avoid the "Vendor lock-in problem" as they scale up the deployment of 5G and network slices. Avoidance of vendor lock-in can yield the following benefits:

1.????Increased flexibility and earlier time-to-market

• For example, Vendor A might be able to provide a better eMBB scheduler (on the O-DU) compared to vendor B. Or, it might be available sooner compared to vendor B. On the other hand, vendor B might have an advantage in the case of a URLLC scheduler.
• This flexibility may also help to introduce a new vendor into an operator’s network without a complete swap out. (For example, when a new service is to be introduced OR when a new area is to be served).

2.????Sharing of RAN equipment among operators

• Each operator might have some preferred vendors and preferred placement of network functions. However, these restrictions can potentially be relaxed in light of vendor equipment interoperability and?the possibility of equipment sharing (because it helps the vendors?with CAPEX and OPEX optimization).

3.????Reduction of supply chain risk

• If an existing vendor providing a certain pair of vO-DU and vO-CU functions withdraws from?the market due to business reasons, operators can deploy new vO-DU and vO-CU functions alternatively from other vendors

Below is a sample deployment scenario. Here, slice #1, is composed of DU(s) and?CU(s), provided by vendor B and slice #2, is composed of DU(s) and CU(s), provided by vendor C. Both of them share the O-RUs provided by vendor A.

?Figure-1.2: Multi-vendor slices

RAN Slice SLA Assurance

Thanks to the efforts of members of?the 3GPP group??and the ORAN-alliance, it is remarkable that we now have a set of standards and recommended architecture?for?sliceable 5G infrastructure which allows creation and management of customized virtual networks to meet specific service requirements that may be demanded by future applications, services and business verticals. This flexible architecture can meet the requirements of several different types of services - each of which may vary significantly in the details from one another.?If a vendor is to monetize the slice based resource allocation for multiple services, then the 5G network needs to adhere to some SLAs. The 5G system should support the needs of the business through the specification of several service needs such as data rate, traffic capacity, user density, latency, reliability, and availability. These capabilities are always provided based on a Service Level Agreement (SLA) between the mobile operator and the business customer. This in turn necessitates putting in place mechanisms to ensure slice SLAs and prevent its possible violations.

Defining the SLAs

The 5G standardization efforts have gone into?defining specific slices and their Service Level Agreements (SLAs) based on application/service type. Since network slicing is conceived as?an end-to-end capability?that includes the core network, the transport network and the radio access?network (RAN), these requirements should be met at each of the?slice subnets during the life-time of a network slice, especially?in the?RAN. Exemplary slice performance requirements are defined in terms of throughput, energy efficiency, latency and reliability at a high level in the standards bodies. These requirements are defined as a reference?for SLA/contractual agreements for each slice, which individually need proper handling in NG-RAN.

Meeting the SLAs

The accompanying figure shows the high level idea as to how this can be accomplished. The Ran Intelligent Controller (RIC) - i.e. the combination of Non-RT RIC and near-RT RIC?is responsible for fine-tuning the RAN behavior dynamically. They monitor the performance of the ORAN nodes (w.r.t the SLA parameters) based on the?measurement reports received from the nodes in the network (also known as E2 nodes). Both long term and short term trends and patterns of the slice subnets' performance are monitored. AI/ML methods are used to learn the network's behavior and to take corrective actions if/when the SLA agreements are in danger of being violated.

?

Figure 1.3 : RAN Slice SLA assurance overview

One example of such corrective actions is to increase the PRBs reserved for one of the slices that is experiencing traffic congestion?at the expense of another slice that is currently experiencing low traffic volume.?

Another example is that the SLA could include specification of the DL/ UL throughput of users in a specific slice. In this case, the near-RT RIC could request the E2 node to continually provide the throughput value for UEs in the slice. If the throughput falls below the configured threshold, the RIC could send policy directives to the RAN in order to improve the situation. For instance, this could involve handing off some UEs to adjacent cells and/or?increasing the priority of the slice and/or changing the priority of certain QOS flows etc.

Standardized slice Ids and potential customizations

The high level characteristics of a slice (in terms of intended traffic treatment etc.) is captured within the structure of the S-NSSAI(Single Network Slice Selection Assistance Information).?It is instructive to take a look at the sub-components of the SNSSAI structure.?It is comprised of the SST (Slice/Service Type)?and an optional SD (Slice Differentiator) field:

The following table lists the slice ids that have been standardized?by 3GPP till date.

SST values from 128..255 are in the "operator specific range" and?can be used for customized service types. A few examples are:

• Private network for enterprise.
• Mission critical for public safety
• Multicast/ Broadcast
• etc.

The SD may be further sub-divided into multiple fields to identify the specific services offered (e.g factory service for enterprise), the customer identification, priority etc. (see below)

References

[1] O-RAN WG1 Slicing Architecture (https://www.o-ran.org/specifications )

Articulated by Venkatesh Potdar, AVP Engineering at Truminds.

?