aarnanetworks

[aarnanetworks]

O-RAN Architecture & the SMO

Bhanu Chandra K.

In this three part blog series, I am going to talk about O-RAN architecture with a little extra emphasis on the Service Management & Orchestration component, the NONRTRIC, and finally some NONRTRIC use cases. Today we'll cover the first topic.

The O-RAN specification allows service providers to speed up 5G network development through its standardized architecture. It minimizes proprietary hardware dependency and makes the network more accessible to a broader range of designers.

The O-RAN alliance architecture principles are:

● Radio area network (RAN) virtualization, open interfaces, and AI-capable RAN

● Disaggregation of RAN element deployment and leveraging multi vendor solutions

● Minimization of proprietary hardware and a push toward merchant silicon and off-the-shelf hardware

● Interfaces and APIs to drive "standards to adopt them as appropriate" and explore "open source where appropriate"

O-RAN Architecture

O-RAN Components

·       Service Management & Orchestrator (SMO): The component that oversees all the orchestration aspects, management and automation of RAN elements. It supports O1, A1 and O2 interfaces.

·       Non-RT RIC (non-real-time RAN Intelligent Controller): A logical function that enables non-real-time control and optimization of RAN elements and resources, AI/ML workflow including model training and updates, and policy-based guidance of applications/features in near-RT RIC.

·       Near-RT RIC (near-real-time RAN Intelligent Controller): A logical function that enables near-real-time control and optimization of O-RAN elements and resources via fine-grained data collection and actions over the E2 interface. It includes interpretation and enforcement of policies from Non-RT RIC. and supports enrichment information to optimize control function.

·       O-CU (O-RAN Central Unit): A logical node hosting RRC, SDAP and PDCP protocols. O-CU includes two sub-components O-CU-CP (O-RAN Central Unit – Control Plane) and O-CU-UP (O-RAN Central Unit – User Plane).

·       O-DU (O-RAN Distributed Unit): A logical node hosting RLC/MAC/High-PHY layers based on a lower layer functional split.

·       O-RU (O-RAN Radio Unit): A logical node hosting Low-PHY layer and RF processing based on a lower layer functional split.

O-RAN SMO Interfaces

The key O-RAN SMO interfaces are:

·       O1: Interface between management entities in Service Management and Orchestration Framework and O-RAN managed elements, for operation and management, by which FCAPS management, software management, and file management shall be achieved.

·       O2 (previously O1*): Interface between Service Management and Orchestration Framework and Infrastructure Management Framework supporting O-RAN virtual network functions.

·       A1: Interface between non-RT RIC and near-RT RIC. Over this interface non-RT RIC performs policy management, enrichment information and AI/ML model updates on the near-RT RIC.

In the next post we will see the various requirements and current limitations, and how the O-RAN architecture — especially the non-RT RIC — optimizes the 5G network.

[aarnanetworks]

Non-Real-Time Radio Intelligent Controller (non-RT RIC) : Data driven RAN optimizer

Bhanu Chandra K.

In this part 2 of a 3 part series (part 1 here), I am going to introduce the non-RT RIC. Before jumping into the non-RT RIC capabilities, let's evaluate the limitations of current RAN infrastructures and future needs.

Rapid traffic growth and multiple frequency bands utilized in a commercial network make it challenging to steer the traffic in a balanced distribution.

Current controls are limited to:

Adjusting the cell re-selection     and handover parameters

Modifying load calculations and     cell priorities

RRM (Radio Resource Management)     features in the existing cellular network that are all cell-centric

Base stations based on     traditional control strategies treat all UEs in a similar way and are     usually focused on average cell-centric performance, rather than being     UE-centric

The current semi-static QoS framework does not efficiently satisfy diversified quality of experience (QoE) requirements such as cloud VR or video applications. The framework is limited to looking at previous movement patterns to reduce the number of handovers.

The non-RT RIC, which is part of O-RAN Service Management & Orchestration (SMO) layer, addresses these current limitations and supports various use cases. It allows operators to flexibly configure the desired optimization policies, utilize the right performance criteria, and leverage machine learning to enable intelligent and proactive traffic control.

The following figure shows a functional view of non-RT RIC platform.

                        As described in O-RAN architecture, the non-RT RIC will communicate with near-RealTime RIC element via the A1 interface. Using the A1 interface the non-RT RIC will perform actions such as:

Policy Management: facilitate the provisioning of     policies for individual UEs or groups of UEs

Monitoring: monitor and provide basic     feedback on the policy state from near-RT RICs

Enrichment Information: provide enrichment     information as required by near-RT RICs

AI/Ml updates: facilitate ML model training,     distribution and inference in cooperation with the near-RT RICs

Data Collection

The Non-RT RIC platform within the SMO collects FCAPS (fault, configuration, accounting, performance, security, management) data related to RAN elements over the O1 interface. Examples of collected items:

Events

Performance data.

Cell load statistics

UE level radio information,     connection and mobility/handover statistics.

Various KPI metrics from     CU/DU/RU nodes

Derived Analytics Data

The collected data is used to derive analytics data. Derived analytics data includes measurement counters and KPIs that appropriately get aggregated by cell, QOS type, slice, etc. Examples of derived data analytics:

Measurement reports with     RSRP/RSRQ/CQI information for serving and neighboring cells

UE connection and     mobility/handover statistics with indication of successful and failed     handovers

Cell load statistics such as     information in the form of number of active users or connections, number     of scheduled active users, utilization of PRB and CCE

Per user performance statistics     such as PDCP throughput, RLC or MAC layer latency

The non-RT RIC can provide data driven operations to various RAN optimizations. AI-enabled policies and ML-based models generate messages in non-RT RIC that are conveyed to the near-RT RIC. The core algorithm of non-RT RIC is owned and deployed by network operators.

These algorithms provides the capability to modify the RAN behavior based by deployment of different models optimized for individual operator policies and optimization objectives.

Following are few such examples and applicable scenarios:

Adapt RRM control for     diversified scenarios and optimization objectives.

Capabilities to predict network     and UE performance.

Optimal traffic management with     improved response times by selecting the right set of UEs for control     action. This results in an optimal system and UE performance with increased     throughput and reduced handover failures.

The O1/EI data collection is     used for offline training of models, as well as for generating A1 policies     for V2X handover optimization like handover prediction and detection.

The non-RT RIC can influence     how RAN resources are allocated to different users through a QoS target     statement in an A1 policy.

In this next post we will see the use cases where the non-RT RIC can play a pivotal role to optimize the RAN resources.

[aarnanetworks]

End-to-End 5G Network Slicing Using ONAP

R. P. Mishra

Yogendra Pal

5G network slicing holds tremendous promise in terms of allowing services with completely different characteristics to share a particular 5G network. Even in a private 5G network, enterprises will be able to use the network for multiple applications. When we talk about a 5G network, there are typically three components that come into play:

Radio Access Network

Transport Network

Core Network

When we say we are creating a slice, the slice needs to be created end-to-end across these three domains: RAN slice, Transport slice, and Core slice.

                        Figure 1: Different Components of a Network Slice

The Linux Foundation Open Network Automation Platform (ONAP) provides comprehensive support for end-to-end network slicing. It can be used to create a slice and configure the above three domains and/or spin up new instances of network functions. The slice can be activated once we have set the different configuration parameters.

The diagram below shows a high-level 3rd Generation Private Partnership (3GPP) view of how a network slice should look the different constituent components:

Figure 2: A Variety of Communication service instances provided by multiple NSIs

ONAP can be used to design network slice template and then an operator can order a slice using APIs or a graphical user interface via the communication service management function (CSMF). Next, the network slice management function (NSMF) chooses the network slice instance and hands off the actual domain specific tasks to specific RAN, Core, or Transport network slice subnet management function (NSSMF). External NSSMFs are also supported.

To see a thorough explanation of these concepts and to see a recording of a hands-on demo using ONAP's upcoming Honolulu release, view a recording of our End-to-End Network Slicing technical meetup from two weeks ago (1 hour at 1x speed). If you don't have the time, you can watch just the demo portion of the meetup (10 minutes at 1x speed).

A surprisingly large number of companies want to try ONAP network slicing in their labs. If you are one of these companies, and need some help, feel free to contact us.