Network Slicing in O-RAN

Introduction

In 5G, there are cases with such diverging requirements, in which there is a need to use the same network functions (NFs), but with different placements to fulfill e.g. latency requirements. There are also cases, where there are some NFs needed for one use case and not for the other. Thus, with network slicing, this could be done utilizing a single physical infrastructure allowing to put the functionality where and when needed depending on the use case and application. Therefore, this concept allows flexibility and tailoring of a dedicated virtual network to a specific need.

In this post, we’ll discuss the overall concept of network slicing with the focus on 5G RAN aspects (NG-RAN, Next Generation Radio Access Network). This will be followed up by placing the network slicing in the O-RAN context. Thus, we’ll touch on the architectural aspects related to Open RAN as defined by O-RAN ALLIANCE.

Note: If you are interested in the Open RAN concept, check this post. If you are interested in the details of O-RAN, here is the relevant post.

5G Network Slicing

Network slicing is a 5G concept of using a single physical infrastructure that allows to virtualize and provide multiple logical networks which can fulfill different requirements or that are defined for different tenants (e.g. MNOs) who want to provide their own service.

A network slice is a logical network comprising a set of network functions (NFs) supporting the communication services for a particular use case deployed on a common physical infrastructure. Those use cases may refer to different applications with different requirements, like V2X (Vehicular-to-Anything), IoT (Internet-of-Things), or MBB (Mobile Broadband). This, however, could also refer to different services of the same user type, but for different operators, or the same use case for the same operator, but for different purposes, e.g. private network vs public access.

Fig 1. shows an example, where there is a single infrastructure with cloud computing platforms at various locations along with the cell site. A core cloud is a central location, typically a regional data center for an operator with a large computing capacity. Edge cloud is located close to the network edge, to assure cloud computing resources at a distant place to decrease latency for data processing. Three different slices are provided as virtual network instances composed of different functional components to support different requirements:

• eMBB (enhanced Mobile Broadband) slice – the requirement is to provide users with high throughput, e.g. 15 Gbps for video – thus there is a local caching function at the edge node/cloud, while mobility management, charging, session, and access management are put at the core cloud;
• IoT/mMTC (massive Machine Type Communications) slice – requires the ability to serve a large number of static devices, rarely sending small reports, e.g. 150k IoT devices per km2. – thus there is a lightweight core deployed without mobility management. In addition to this, everything except RAN functions is deployed centrally. It is because we do not need a cache, and latency requirements are not strict. Instead, the service user rather wants to have analytics collectively gathered to process the data centrally from a large group of sensors;
• V2X (Vehicular-to-Anything) slice – here, there is yet a different aspect to cover, i.e. very low latency – thus more functionality is deployed close to the edge, to assure low round trip time including e.g. mobility or session management. At the same time, some non-latency-sensitive functions are deployed centrally, e.g. charging.

Network Slicing impact on NG-RAN

It’s not only the core network, which relates to slicing. RAN also needs to be aware of slices. There is a need to assure resource isolation, availability, and proper selection of the resources through radio resource management (RRM). This is where the RAN is linked to the network slicing.

NG-RAN needs to support different slices with differentiated handling. For instance, mobility management or handover procedures are needed for one slice, while another may not need handover at all, like in the IoT/mMTC case.

Each slice is typically accompanied by its Service Level Agreement (SLA). Thus, one aspect is the resource management between slices, as there is a need to support policy enforcement between slices per SLA to assure it for each individual slice. As an example, RAN needs to decide, what happens, if we need more resources – i.e. how to reschedule those that we have. gNB can support multiple slices, and assuring dynamic resource adaptation is of crucial importance to apply optimal resource management policy. SLA protection between slices is part of this to assure resource isolation so that when there is congestion in one slice, it should not compromise the SLA of another slice.

Yet another aspect, is the location of the services to be provided. There may be a full 5G network with a set of the base stations, while only in one location we may need to support a specific slice/service. One example of such slice-specific service can be Traffic Steering (TS). The TS is required to be used within the network slices dedicated for mobile users, e.g., V2X, eMBB. However, for network slices that serve static devices, such functionality is redundant, e.g., while considering IoT/mMTC-dedicated network slice.

UE may also be connected to multiple slices, e.g. a “car UE” may be connected to a regular MBB slice for video streaming for passengers, while at the same time being connected to a V2X slice for assisted driving application. Such a use case requires management at the RAN level to support e.g. proper handover in a high-speed scenario for both slices.

The above-mentioned examples are providing general insight into the idea of network slicing within the context of NG-RAN.  The table below [38.300], treats more detailed aspects of network slicing’s impact on the RAN.

Area	Requirements
RAN awareness of slices	* NG-RAN supports differentiated handling of traffic for different NW slices. * Set of network functions comprising each slice is implementation-dependent.
Selection of RAN part of the network slice	* NG-RAN supports the selection of the RAN part of the NW slice by assistance information provided by the UE or 5GC. * Assistance information unambiguously identifies one or more of the preconfigured NW slices in PLMN.
Resource management between slices	* RAN supports policy enforcement between slices as per SLA. * Single NG-RAN should be able to support multiple slices * NG-RAN should be free to apply the best RRM policy for the SLA in place for each supported slice.
Support of QoS within a slice	NG-RAN supports QoS differentiation within a slice.
RAN selection of CN entity	* For initial attach, UE may provide assistance info to support the selection of AMF. NG-RAN should use this info to route the NAS signaling to the given AMF. Otherwise, NG-RAN sends NAS signaling to default AMF. * For subsequent accesses, UE provides Temporary ID (assigned by 5GC) to enable NG-RAN to route NAS signaling to selected AMF.
Resource isolation between slices	* NG-RAN supports resource isolation between slices. * NG-RAN resource isolation may be achieved by means of RRM policies or protection mechanisms. * Overload/congestion in one slice should not comprise the SLA of another slice. * It should be possible to fully dedicate NG-RAN resources to a certain slice. * How NG-RAN supports resource isolation is implementation-dependent.
Slice availability	* Some slices may be available only in part of the network * NG-RAN and 5GC are responsible for handling service requests for a given slice. Admission/rejection of access to a slice may depend on: support for the slice, availability of resources, and support of the requested service by NG-RAN.
Support for UE associating with multiple slices simultaneously	In case a UE is associated with multiple slices simultaneously – only one signaling connection is maintained.
Slice awareness	Slice awareness in NG-RAN is introduced at the PDU session-level, by indicating the S-NSSAI corresponding to the PDU Session, in all signaling containing PDU session resource information

Network Slicing in O-RAN

Earlier, we showed various aspects of network and specifically RAN slicing, which could be realized with the use of O-RAN due to its native virtualization and embedded intelligence. At the same time, the realization of network slicing in a legacy way is much more difficult and strongly limiting.

For this reason Network Slicing is one of the key use cases for O-RAN. The resource management within a slice and resource optimization between slices are subject to O-RAN ALLIANCE discussions. One of the key challenges is to ensure the slice resource isolation, i.e.,  to protect resources utilized by one slice from the other slices. Another topic is to appropriately scale in/out resources to assure SLA within a particular slice.

Figure 2 shows an O-RAN ALLIANCE defined slicing reference architecture.

The “Slice Management Functions” block encompasses the typical ETSI MANO-type functions. Those elements are placed within SMO, as this is where slice-lifecycle management (LCM) takes place (e.g. instantiation, operation, modification, and termination of a slice) as well as cloud resource scaling.

Non- and Near-RT RICs are responsible for optimization of the resource usage for the various network slices, and thus need to be aware of them. For that purpose, they shall be equipped with slice-aware and slice-dedicated xApps and rApps, typically along with ML control mechanisms for predictive behavior.

O-CUs and O-DUs are responsible to provide slice-related performance measurements (PM) and execution of slice-aware (e.g. scheduling) and slice-dedicated (e.g. flow control) algorithms to fulfill the requested SLAs.

All the above requires the O-RAN defined interfaces, including E2 – for PM reporting and action executions, A1 – for slice-related policy control and ML models update, O1 – for reconfiguration of the nodes for slicing purposes, and O2 for cloud computing platform up/down-scaling or LCM of the functions instantiated for various slices.

The table below provides a more detailed overview of those entities with respect to network slicing in the O-RAN architecture.

Element	Role in the network slicing
Nodes
Slice management functions	3GPP defined NSMF and NSSMF with extensions for O-RAN network functions.
Non-RT RIC	* Gathers long-term slice-related data through interaction with SMO framework and applies AI/ML-based approaches interworking with Near-RT RIC to provide innovative RAN slicing use cases; * Should be aware of RAN slices and their respective SLAs through SMO; * May retrieve enrichment information (EI) from 3rd party applications enabling advanced RAN slicing technology to be applied in the O-RAN framework.
Near-RT RIC	* Enables RAN-slice optimization through execution of slicing-related xApps and communicating necessary parameters to O-CU and O-DU through E2; * xApps may utilize AI/ML-based models or other control schemes which can be guided by A1 policies that are generated by Non-RT RIC.
O-CU-CP and O-CU-UP	* Should be slice aware and execute slice-specific resource allocation and isolation strategies; * Are initially configured through O1 based on slice-specific requirements and then dynamically updated through E2 via Near-RT RIC for various slicing use cases; * May generate and send specific PMs through O1 and E2, where PMs can be used for slice performance monitoring and slice SLA assurance purposes.
O-DU	* Supports slice-specific resource allocation strategies; * MAC layer needs to allocate and isolate relevant PRBs to specific slices.
Interfaces
O1 Interface	* Configures slice-specific parameters of O-RAN nodes based on service requirements of slice; * Use 3GPP-defined slice-specific information models, including the RRM policy attributes to provide a ratio of PRBs and split of PRBs among slices; * Those models may be extended and additional information models may be defined to capture slice profiles and slice-specific configuration parameters, to be carried over O1; * Used to configure and gather slice-specific performance metrics and slice-specific faults from O-RAN nodes.
O2 Interface	* Life cycle management of virtual O-RAN network functions; * Used to trigger instantiation of necessary O-RAN functions (e.g. Near-RT RIC, O-CU-CP) based on slice requirements; * Can be used to execute slice modification and slice deletion procedures.
A1 Interface	* Supports policy management, ML model management, and enrichment information services; * These services are utilized for various slicing use cases, (e.g. slice SLA assurance); * Used to send slice-specific policies to guide Near-RT RIC with slice resource allocations and slice-specific control activities, and to receive slice-specific policy feedback for policies deployed on Near-RT RIC.
E2 Interface	* Supports E2 primitives (Report, Insert, Control, and Policy) to control services exposed by E2 nodes. Those can be used by slice-specific applications (xApps) to drive E2 nodes’ slice configurations and slice-specific behavior, e.g. slice-based RRM, radio resource allocations, MAC scheduling policies, etc. used by various RAN protocol stacks; * Used to configure and receive slice-specific reports and performance data from E2 nodes. These include 3GPP-defined slice-specific PMs (e.g. PRB utilization, average delay) and new PMs that can be defined by O-RAN to support various slicing use cases.

Notes:

• If you are interested in the details of the ETSI-MANO functions, check out this link: ETSI – Standards for NFV – Network Functions Virtualisation | NFV Solutions
• If you are interested in O-RAN architecture, nodes, and interfaces details, check out this post: O-RAN Architecture, Nodes, and Interfaces – RIMEDO Labs

Example deployment of O-RAN slicing

The below figure shows an example mapping of two slices towards the O-RAN architecture within the example deployment option.

The Near-RT RIC is placed at the regional cloud, while the virtual O-CUs and O-DU are at the edge cloud and O-RU as a physical function sits at the cell site. The O-RU and O-DU, as the processing units are common for both network slices.

In this particular example, both slices are controlled using a single O-CU-CP instance, while each slice has a dedicated O-CU-UP instance. In such a case, if the UE is connected to both slices, there is a single RRC connection to manage the handover procedures and cell assignment (through the common O-CU-CP), but each service belonging to a different slice instance, can have its own dedicated QoS handling and separate flow control through individual SDAP/PDCP stack (within a dedicated O-CU-UP).

The Near-RT RIC is responsible for managing the resources within the O-DU to assure the PRB allocation fulfills the SLA for each slice through a common xApp while providing slice-specific xApps to manage the QoS flows within each slice.

Summary

Network slicing is a concept where there is a single physical infrastructure used to provide multiple logical networks to fulfill different requirements for various services, which include RAN, transport network, and core network. Different aspects of network slicing including, e.g., virtualization, orchestration, and management,  are under the discussion within multiple SDOs like 3GPP, ETSI, GSMA, ONAP, and O-RAN ALLIANCE e.V (recently).

O-RAN ALLIANCE touches slicing in the context of RAN with the Non- and Near-RT RICs being responsible for resource isolation, optimization, and scaling. They act on the basis of the actual demand from the traffic and may use slice-dedicated or slice-aware xApps and ML models to e.g., predict and act prior to the expected increase or decrease of the traffic in a temporal and location-based manner.

One example of slice-dedicated xApp may be traffic steering, where e.g. in one slice we may have a very simple scheme (e.g. in a static IoT/mMTC scenario), while a more demanding one requires a complicated TS scheme to be used with DC/MC (e.g. a V2X use case). On the other end, an example of slice-aware xApp, related to cross-slice management, within the O-DU scheduler, can be an xApp to assure SLA for different slices by playing with the PRB allocation.

Finally, in the O-RAN architecture, O-CU-UP can be dedicated per slice, while O-CU-CP and Near-RT RIC are shared and handle cross-slice operation and optimization.

References

[38.300] 3GPP TS, „NR, and NG-RAN Overall description; Stage-2”

[O-RAN.WG1.Slicing-Architecture-v05.00] O-RAN ALLIANCE TS, „Slicing Architecture”

[ETSI – Standards for NFV – Network Functions Virtualisation | NFV Solutions]

Rimedo Resources

• Other O-RAN posts: Introduction to O-RAN: Concept and Entities, O-RAN Architecture, Nodes, and Interfaces, O-RAN Near-Real-Time RIC, O-RAN Use Cases: Traffic Steering
• O-RAN whitepapers: The O-RAN Whitepaper 2022 (RAN Intelligent Controller), The O-RAN Whitepaper 2021
• O-RAN products and services: O-RAN – RIMEDO Labs
• O-RAN slicing webinar Network Slicing in O-RAN (intelefy.com)
• O-RAN course O-RAN System Training (intelefy.com)

Author Bio