Outline:
The ORAN SC (OSC) is a software community that focuses on developing and defining specifications for ORAN implementations. It is a collaborative platform for network equipment vendors, operators, and software developers to drive innovation and interoperability in the telecommunications industry [1].
Why Do We Need O-RAN?
SMO used for increasing effecienct for operational and make network maitenance cost lower. It is an effective solution for boosting operational efficiency and reducing network maintenance costs. SMO enables remote monitoring and control of functions and devices within the ORAN network, providing real-time diagnostics and troubleshooting.
The O1 Interface is a logical connection between all “O-RAN Managed Elements (MEs)” and the “management entities” within the SMO framework [2]. The purpose of the O1 interface is to ensure the operation and management e.g. FCAPS, Software Management, and file management of the O-RAN components.
In other words, we can elaborate, the O1 interface enables the management of all O-RAN components that need to be orchestrated and the associated O-RAN network functions. The components managed via O1 include the near-RT RIC, the O-CU, and the O-DU in 5G NR. The O-CU corresponds to a predefined combination of O-CU-CP and O-CU-UP.
The figure above shows an extracted logical O-RAN architecture to illustrate the O1 interface and its influence on O-RAN Manage Elements, including the O-eNodeB. The O-RU termination of the O1 interface towards the SMO is currently under investigation so this interface is shown dashed.
You can read the paper here [2]
Also the white paper here
The diagram below shows key interfaces in O-RAN architecture.
The SMO performs its functions/services through four key interfaces to the O-RAN Elements:
The key capabilities of the SMO that provide RAN support in O-RAN are:
FCAPS: Fault, Configuration, Accounting, Performance, Security. They are all the information needed for functions management. Supporting FCAPS for O1 interface:
• Performance Management (PM)
• Configuration Management (CM)
• Fault Management (FM)
• File Management
• Communications Surveillance (Heartbeat)
• Trace
• Physical Network Function (PNF) Discovery
• PNF Software Management.
SMO supports Non-RT RIC for RAN optimization.
The Non-RT RIC is comprised of two sub-functions:
The SMO utilizes the O2 interface to the O-Cloud to provide:
The example functionalities should be supported in SMO:
SMO Functions | Descriptions | Example |
---|---|---|
Inherent Non-RT RIC Framework Functionality | This functionality is definitively associated with the Non-RT RIC itself | The two interfaces “owned” by the Non-RT RIC: The A1 and R1 interfaces |
Inherent O-RAN SMO Framework Functionality | This functionality is definitively not associated with the Non-RT RIC | The O1 and O2 interfaces |
Implementation Variable Functionality | This functionality may or may not be associated with the Non-RT RIC. | An SMO provider is free to include this functionality in or exclude this functionality from a Non-RT RIC implementation |
Here's the SMO Repository on gerrit. On the way to explore. [3]
NONE
NONE
This is the example of HPE Deployment [Image 1]
16 or more CPU cores
24+ GB of RAM
80 GB of Disk (mostly used to store container image)
Ubuntu 22.04 server
Containerd v1.7.16
Kubernetes v1.28.0 (multi node)
Calico cni v3.27.3
Release H
Download the IT/dep repository from gerrit
mkdir workspace && cd workspace
git clone --recurse-submodules https://gerrit.o-ran-sc.org/r/it/dep.git
Setup Helm Charts
##Setup ChartMuseum
./dep/smo-install/scripts/layer-0/0-setup-charts-museum.sh
##Setup HELM3
./dep/smo-install/scripts/layer-0/0-setup-helm3.sh
## Build ONAP/ORAN charts
./dep/smo-install/scripts/layer-1/1-build-all-charts.sh
Deploy components
./dep/smo-install/scripts/layer-2/2-install-oran.sh
Modify the yaml file.
smo-install/helm-override/default/network-simulators-override.yaml
.
ru-simulator:
image:
tag: 1.5.2
ntsimNg:
<<: *ntsimConfig
ipV6Enabled: false
sshConnections: 0
tlsConnections: 1
du-simulator:
image:
tag: 1.5.2
ntsimNg:
<<: *ntsimConfig
ipV6Enabled: false
sshConnections: 1
tlsConnections: 0
topology-server:
image:
tag: 1.8.1
ntsimNg:
<<: *ntsimConfig
ipV6Enabled: false
sshConnections: 0
tlsConnections: 1
Install Network simulator (RU / DU / Topology Server)
./dep/smo-install/scripts/layer-2/2-install-simulators.sh
Check all pods are running
sudo kubectl get pods -n network
Login to web console:
URL: https://<your host ip/>:30205/odlux/index.html
user: admin
password: Kp8bJ4SXszM0WXlhak3eHlcse2gAw84vaoGGmJvUy2U
Result
This step is executed after the SMO installation is complete.
Helm repo add and install
Research Gap: Look for the others SMO Feature, that SMO in OSC lack of.
You can easily replicate or analize the code and deployment of ONAP as the SMO here [4]
Juniper has their own SMO Product for slicing (check it)
They have their own solution on RIC
Here's the blog that talked about it (take a look)
Find their solutions here
See their view on how to face vRAN here
One of the key benefits of the Open RAN model lies in its commitment to vendor neutrality. This interoperability is maintained regardless of the specific equipment or software suppliers involved, breaking down proprietary barriers and fostering a more open, competitive ecosystem.
This is extended and enhanced by the E2 interface defined in O-RAN Alliance which together with O1 and O2 enable a standardised approach to the management, orchestration and support for real time telemetry exposure and control of the CU and DU nodes to bring AI/ML network intelligence in the RAN. [5]
This vendor neutrality gives network operators the flexibility to integrate best-in-class solutions without being tethered to one provider.
Here's the shallow definition for each components (check it out)
But for the detail explanation, you can check it here
Then for the simple yet eye catching slides here
The Central Unit (CU) oversees the higher layers of the protocol stack, particularly the SDAP, PDCP, and RRC layers. Its primary roles encompass:
To draw a parallel, the CU is akin to a symphony conductor, ensuring each section comes together harmoniously for a flawless performance.
Acronym explainers:
The Distributed Unit (DU) handles the lower layers of the protocol stack, which includes the Upper Physical, MAC, and RLC layers. Its chief responsibilities are:
Metaphorically, think of the DU as the skilled technician of a symphony, tuning the instruments to perfection before the performance.
Acronym explainers:
Near-RT RIC is a logical function that enables near-real-time control and optimization of RAN elements and resources via fine-grained data collection and actions over an E2 interface.xApp, an application designed to run on the Near-RT RIC, is central to the operation of Near-RT RIC. A question that often comes up is, what does ‘x’ mean? ‘X’ stands for any, so any app designed to run on the Near-RT RIC.
Each xApp is likely to consist of one or more microservices. At the point of on-boarding, microservices will identify which data it consumes and which data it provides. The important point that has excited many within our industry is that these applications are independent of the Near-RT RIC and may be provided by any third party. The E2 interface enables a direct association between the xApp and the RAN functionality.
It is important to point out that sometimes there can be overlapping or conflicting requests from multiple xApps. This can lead to a tricky situation as each application will typically change one or more parameters with the objective of optimizing a specific metric. This is where Conflict Mitigation steps in to resolve any conflicting actions.
Introduction
The goal of Non-Real Time RAN Intelligent Controller (O-RAN Non-RT RIC) is to support intelligent RAN optimization by providing policy-based guidance, model management, and enrichment information to the Near-RT RIC function so that the RAN can be optimized. In contrary to Near-RT RIC, which sits in the RAN domain and works on a timescale of tens to hundreds of milliseconds, Non-RT RIC works within the management plane (and more particularly in Service Management and Orchestration, SMO) and operates on a timescale of seconds and minutes [4].
The functionality of the Non-RT RIC includes configuration management, device management, fault management, performance management, and lifecycle management for all network (NW) elements within O-RAN architecture. It is similar to Element Management System (EMS) and Analytics and Reporting functionalities in the traditional NWs. All RAN elements are self-configured by the Non-RT RIC, reducing the need for manual intervention. By providing timely insights into NW operations, Mobile Network Operators (MNOs) may use Non-RT RIC to better understand and optimize NW by applying pre-determined service and policy parameters. Its functionality is internal to the SMO in the O-RAN architecture and provides an A1 interface to the Near-RT RIC.
Non-RT RIC can use data analytics and Artificial Intelligence (AI)/Machine Learning (ML) training/inference to determine the RAN optimization actions for which it can leverage SMO services such as data collection and provisioning services of the O-RAN nodes. Trained models produced in the Non-RT RIC are distributed to the Near-RT RIC for runtime execution. Network slicing, security, role-based access control, and RAN sharing are example aspects that are enabled by the combined controller functions namely, Near-RT and non-RT. Standardized in O-RAN.WG2.Non-RT-RIC-ARCH-TR-v01.00.
Architecure Non-NT RIC
Figure above shows the internals of the SMO framework including the Non-RT RIC. Functionality inherent to the Non-RT RIC itself is colored in blue. Those functions are used basically for managing the rApps which are external to the Non-RT RIC framework accessible through an open Application Programming Interface (API), using R1 interface. Also, another set of "blue elements” include those that create the data to be transmitted over the A1 interface, namely: A1 policy functions, A1 enrichment information functions, A1 ML functions.
There are also parts in the SMO framework that are out of Non-RT RIC scope, marked with a "pink-ish” color. They are basically related to the O1/O2 termination as well as other SMO framework functions, e.g. for network slicing lifecycle management. Those are inherent to the SMO framework.
Finally, the green part refers to the functionality which implementation is flexible. Those functions could be part of Non-RT RIC and they could be also external to Non-RT RIC and sit in the SMO. They are not inherent to any of those. The example here is AI/ML workflow functions. In such light, AI/ML could be either part of Non-RT RIC, or it could be external, providing the information to the SMO service exposure functions.
rApps are applications designed to run on Non-RT RIC providing additional value-added services to help creation of policies that the Non-RT RIC framework delivers down to Near-RT RIC through the A1 interface. Fig. 2, shows Non-RT RIC with three example rApps, namely rApp R, rApp U, and rApp Q connected via R1 interface to the Non-RT RIC framework. Their inputs and outputs are as follows:
rApp R
rApp R is an rApp which consumes the O1 measurements. It takes the information from the O1 interface for RF signal experienced by a UE on serving and neighboring cells, and UE location. Based on this input, it estimates/predicts the future UE location and RF signal level when the UE moves towards a certain direction. For example, based on the past information of UEs at a given location with particular values for received signal levels from serving and neighbor base stations, and on the current measurements, it predicts the most likely UE signal levels after it moves towards predicted location.
rApp R (RF signal predictor):
rApp U
rApp U is a cell utilization predictor, which consumes the cell load utilization and amount of resources of a cell over time and outputs a future prediction of the cell load utilization, based on the trend. Doing so, it could deduct, e.g., that at the beginning of the day there is a lot of traffic in particular area, and then the traffic volume drops because all the people are moving to work so the traffic moves to the city center and thus predict the future cell load utilization.
rApp U (Cell utilization predictor):
rApp Q
rApp Q takes outputs from rApp R and rApp U, i.e. the predicted locations, signal levels, and cell utilization at a particular area and time, as well as the actual measurements and the actual cell utilization. Based on those it calculates the potential quality of experience (QoE). So, e.g., it could predict the future QoE if the user stays at a particular location or in different future location, for a scenario, where UE stays at the same cell or is handed over to another one.
rApp Q (UE QoE predictor):
You can review it here
You can review the paper here
You can see more HLD here