Welcome to the G release page for the O-RAN Software community.
The G release is currently in incubation; initiating the definition of the requirements
Non-Real-time RIC (NONRTRIC)
Primary Goals:
The primary goal of Non-RT RIC is to support intelligent RAN optimization by providing policy-based guidance, ML model management and enrichment information to the near-RT RIC function so that the RAN can optimize, e.g., RRM under certain conditions.
It can also perform intelligent radio resource management function in non-real-time interval (i.e., greater than 1 second).
Non-RT RIC can use data analytics and AI/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.
Non-RT-RIC will define and coordinate rApps (Non-RT-RIC applications) to perform Non-RT-RIC tasks.
Non-RT-RIC will host the A1 interface (between NONRTRIC & near-RT RICs )
Non-RT-RIC will also host the new R1 interface (between rApps and SMO/NONRTRIC services)
Continue work of Service execution platform extensions (K8s, Istio, Keycloak, OPA, Gateway) to enable service isolation & exposure
Extend Release F prototyping of 3GPP CAPIF-aligned Service Exposure Manager function (& API)
R1 Data Management & Exposure
Align with emerging proposals for R1-DME where possible
R1 DME Data Catalog support in NONRTRIC ICS
R1 Data delivery & filtering (kafka & REST)
rApp Manager
Build on ONAP “Automation Composition” model & platform to implement rApp use cases
Demonstrate controlled on-boarding & LCM rApps with & without µService
Overlap with Service Exposure work to examine role of an rApp Manager to support controlled exposure & LCM of µService and non-µService parts of an rApp
Investigate where parts of rApp executes in KNative environment (e.g. ML model part of an rApp)
Near-Real-time RAN Intelligent Controller Platform (E2 Interface) (RICPLT)
Mission: TODO
Original primary goals:
E2T improvements: Support for E2 Reset procedure (from E2 node to RIC (RIC-386); Correct handling of E2 node reconnects and multiple E2 Setups (RIC-932), Support split architecture (CU/DU) in E2T/E2M.
A1: finalize re-implementation of A1 in golang (from python)
Remove support for RMR in E2 subscription interface and only continue with E2 REST subscription interface towards xApps
can be done because last missing xapp-framwork supports REST (xapp-frame-cpp). Go and python already support E2 REST subscriptions
Subscription delete callback to xApps and subscription cleanup after xApp removal.
Support for DMS via REST in addition to command line tool DMSCLI
First version of the xApp framework for Rust
First version of a RIC CLI
Achieved G release highlights = high-level release notes (2022-05-18) below (note that the release image list is here: TODO)
TODO
For the G release of the near-RT RIC we do only limited integration testing: only the use cases: deploy RIC, deploy xApp and make E2 connection are to be tested.
Filled in end-of-release checklist : Release criteria checklist - TODO
G release source code, container images and deployment instructions
TODO
Operation and Maintenance (OAM)
Primary Goals:
According to the O-RAN-SC-OAM-Architecture document, all ManagedElements (near-real-time-RIC, O-CU-CP, O-CU-UP, O-DU and O-RU) implement the O1-interface.
G release Feature Scope:
support of O-RAN WG10 VES message bodies
update of OAM-Controller to ODL version Sulfur
Note: team decided to go with Java11 - Java 17 would be possible but is pushed out to next release.
update to keycloak version 18
even more secure keycloak configuration
there is a request for a "bare-metal" deployment which is not in scope of O-RAN, but still useful - also for development and module test
support of AI/ML based on RSAC and other input.
support of Tacker team
Please see also project wiki for further details: G-Release
Jira: Count of Epics, User Stories, Tasks, and Issues: 5 issues
G release source code, container images and deployment instructions
Source code: TODO
Container images are described here: TODO
Instructions:TODO
Code coverage: in progress (sonar for C/C++ code in LF repos)
Service Management and Orchestration Layer (SMO)
Primary Goals:
The SMO acts as an uber identity that overlooks the different aspects of the O-RAN deployment. Starting with how solutions are deployed, to how they interact with each other, to how they are managed.
G release Feature Scope:
The focus for the G release in SMO is interoperability. Every sub-project within SMO has at least one item that focuses on interoperating with one other entity outside of SMO. For example,
On the O1 interface, the focus is on trying to bring-up O-DU using NETCONF and YANG models defined for O-DU.
On the O1/VES interface, it is ability to generate network slicing PM events in the O-DU, and the ability to receive them in SMO dashboard, and store them in InfluxdB.
On the O2 interface, it will be the ability to instantiate an instance of a Network Function (NF) like the O-DU in the O-Cloud.
Separate from this, each sub-project within SMO has other features/capabilities it will address as part of the G-release. For details please refer to the minutes of the SMO meeting here.
PTL: Mahesh Jethanandani
G release source code, container images and deployment instructions (and status)
G release source code for SMO can be found in the following repositories
O1 repository
O1/VES repository
O2 repository
The container images for SMO when G-release is finally available will be found here (for now the images might point to the F-release).
The installation instructions for SMO can be found in the documentation page here.
Status
The status of the SMO project is tracked using Jira items. For the latest status refer to the items below.
INF is a downstream project of StarlingX and Yocto Project, the above coverage report may not reflect the real code coverage so we also need to refer to the status from upstream projects.
