Network Slicing Architecture in ORAN

Network Slicing Overview

Network slicing allows telecom operators to provide tailored services as per the customer’s requirements. Network slice is defined as a logical network over a common physical network infrastructure. A single physical network is logically sliced into multiple virtual/logical networks that can support different types of customized services.

3GPP has defined concepts, procedures & functionality of architectural components of slicing, all this information is listed in multiple 3gPP docs. ORAN has tried to keep consistency as much as possible with 3GPP in terms of architecture and positioning of network functions.

An example of O-RAN slicing deployment (from ORAN alliance) is below:

5G ORAN components which can be shared with multiple slices are Near RT-RIC, O-CU-CP, O-DU & O-RU and 5G RAN components which are meant to be dedicated during multiple slices are O-CU-CP & O-CU-UP.

ORAN Slicing use cases

ORAN has introduced some new functional block in the architecture, these new elements are Non-Real time RIC in the SMO (Service management & orchestration), Near-Real Time RIC and new interface (E2 Interface) to connect to the E2 nodes (O-CU-CP, O-CU-UP and O-DU). These new elements and interfaces plays a vital role for the RAN slice assurance as displayed in the picture below:

ORAN Slicing General Principles

With a consistency to the RAN slicing principles stated by 3GPP, ORAN has further added some more general principles to its ORAN slicing architecture as mentioned below:

-         The architecture shall provide standardized management service interfaces for RAN slicing management services

-         The architecture shall enable/support multi-vendor interoperability (openness to multi-vendor scenario)

-         The architecture shall support multi-operator/multi-carrier deployment scenario

-         The architecture shall support RAN slices management in multi-operator/multi-carrier scenario

ORAN Slicing Reference Architecture

Maintaining consistency with 3GPP and addition of new ORAN specific functional elements and then further positioning the slice specific 3GPP network functions into the ORAN has been explained here in the picture above. The slicing specific 3GPP defined network function like NSMF, NSSMF and NFMF will be residing in the SMO (service management) layer of ORAN i.e. the Slice Management Function block in ORAN slicing architecture.

3GPP+GSMA has already defined the key functionalities as well as attributes/parameters to be configured for E2E slicing i.e. including service specific slicing templates, Core network functions elements (AMF, SMF, NSSF etc.) and RAN functional elements (CU, DU & RU/Cell). But with the ORAN architecture, we have new functional elements and interfaces. Let’s understand the role played by each:

Non-Real Time RIC:

-         Gathering long term slice related data using interaction with SMO

-         Applying AI-ML based approach with interworking with Near-RT RIC to provide new slicing use cases

-         Retrieving enrichment information from 3rd party applications enabling advanced RAN slicing

-         Retrieves slice specific performance 1 metrics, configuration parameters and required attributes of the RAN slices from the SMO framework

-         Non-real-time optimization of the slice specific parameters of Near-RT RIC, O-CU and O-DU over 4 O1 interface through SMO interaction

-         Generating policy guidance and assist Near-RT RIC over A1 to provide closed loop slice optimization

-         Applying such slice optimizations in the Near-RT RIC can be used for SLA assurance and prevent SLA violations

Near-Real Time RIC:

-         Enables near-real-time RAN slice optimization through execution of slicing related xApps

-         Communicates necessary parameters to O-CU and O-DU through E2 interface

-         It will be aware of RAN slices through O-RAN specific information models & provisioning procedures

-         Configuration of slice resources on E2 nodes can be achieved through fast loop with E2 configuration

-         Slice specific near-RT performance data monitoring through E2 interface

O-CU (ORAN Central Unit): O-CU-UP can be shared across slices or a specific instance of O-CU-UP can be instantiated per slice

-         Execution of slice specific resource allocation and isolation strategies

-         Generates and send specific PMs through O1  and E2 interfaces as per the request from SMO or Near Real Time RIC

-         These PMs are useful for performance monitoring and slice SLA assurance purpose

O-DU (ORAN Distributed Unit): O-DU can be shared between multiple slices

-         Supporting slice specific resource allocation & PRBs isolation strategies

-         Generates and send specific PMs through O1 and E2 interfaces as per the request from SMO or Near Real Time RIC

-         These PMs are useful for performance monitoring and slice SLA assurance purpose

A1 Interface: This interface exists between Non-RT RIC and Near RT-RIC

-         Used to support policy based guidance for slicing use cases, such as SLA assurance

-         Receive feedback related to deployed policies over A1 interface between Non-RT RIC & Near-RT RIC

-         Transferring slice specific enrichment data from Non-RT RIC to Near-RT RIC

E2 Interface: This interface exists between Near RT-RIC and E2 Nodes (O-CU-CP, O-CU-UP & O-DU)

-         To drive E2 nodes’ slice configuration and behavior, such as

o   Slice based radio resource allocations

o   Scheduling policies

o   Configuration policies

-         Configuring and receiving slice specific performance data from the E2 nodes over the E2 interface for near real-time optimization. These PM data includes

o   PRB Utilization

o   Average Delay

O1 Interface: This interface exists between O-RAN managed elements and the management entity

-         It enables slice specific configuration of O-RAN nodes based on the service requirements

-         Used to gather slice specific performance 20 metrics and fault information from O-RAN Nodes.

O2 Interface: This interface exists between the SMO and O-Cloud and is used for life cycle management of virtual O-RAN network functions.

-         RAN NSSI creation and provisioning

-         Executing NSSI modification and NSSI deletion procedures.

Deployment Options

The deployment options have been mainly categorized in 2 ways as mentioned below:

-         3GPP and ETSI NFV-MANO based O-RAN Slicing Architecture

-         ONAP based O-RAN Slicing Architecture Implementation Option (Intended to add this architecture)

With the information available now i.e. only for the first option i.e. 3GPP and ETSI NFV-MANI based O-RAN slicing architecture, there are further 4 more sub-options of deployment. In all these options the differences are mainly about the positioning of the internal network functions of the slice management functional block. The Slice Management Function block is comprised of 3 network functions namely:

-         NSMF (Network Slicing Management Function)

-         RAN NSSMF (RAN Network Slicing Subnet Management Function

-         NFMF (Network function management function)

Let see where these network functions are positioned in the ORAN deployment (ETSI NFV MANO based).

Option1 – In this option both NSMF and NSSMF are deployed within the SMO.

Option 2 – In this option, both NSMF and NSSMF are deployed outside the SMO

Option 3 – In this option, NSMF is placed within SMO, with the NSSMF being deployed outside the SMO. This option is also called as external NSSMF deployment.

Option 4 – In this option, NSMF is in the outside of SMO while NSSMF is deployed within SMO.

Information Reference: www.oran.org/specifications

To understand slicing basics please read the previous article – “5G Network Slicing At A Glance” https://www.dhirubhai.net/pulse/5g-network-slicing-glance-dheeraj-kumar/