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)
Original primary goals:
E2T improvements: Support for E2 Reset procedure (from E2 node to RIC (RIC-386, Dec-4) - only E2 node-side simulator implementation and possibly some part in E2M related to E2 procedure model, but not full E2 reset procedure ; Correct handling of E2 node reconnects and multiple E2 Setups (RIC-932), Support split architecture (CU/DU) in E2T/E2M (RIC-933), test cases of remaining interface types in config update (RIC-911, maybe-Dec-4-subhash), MDC dynamic log level change in E2T and E2M (RIC-814, RIC-813), check existence of SCTP stack during startup (RIC-931)
A1: finalize re-implementation of A1 in golang (from python) (RIC-849, RIC-914, Dec-4)
Remove support for RMR in E2 subscription interface and only continue with E2 REST subscription interface towards xApps (RIC-375)
can be done because last missing xapp-framwork (xapp-frame-cpp) supports REST (RIC-641, RIC-705) . Go and python already support E2 REST subscriptions
Subscription delete callback to xApps and subscription cleanup after xApp removal (RIC-928, RIC-929)
Support for DMS via REST in addition to command line tool DMSCLI (RIC-714, Dec-4)
First version of the xApp framework for Rust (RIC-924)
missing test cases for xapp-frame-py (RIC-917),
xapp-frame (go) support readiness and liveness state with appmgr/rtmgr (RIC-930)
First version of a RIC CLI (RIC-445)
ric-dep cleanup (RIC-918)
E2 check, validate and define how various overload and disconnect case are handled (RIC-704)
Enhancments in A1 mediator testing and in E2 subscription testing via nanobot (RIC-878, RIC-860)
Update of influxDB from 1.8→2.2, incl. adaptations in stslgo module (RIC-919)
Take go version 1.18 into use in base image (RIC-937)
bug fixes: RIC-945 e2term crashes occasionally when gNB is disconnected,RIC-944 PlmnId to mnc conversion wrong, RIC-943 alarm-go rmr routing table init failure, RIC-936 reference to gcr -> ghcr, RIC-935 kube-flannel changed namespace, RIC-934 Upgrade sdlgo Golang version to fix CVE-2022-32189 vulnerability,RIC-920 fix translation of 21/22/23 bit gnb ids to hex in E2T, RIC-939 race condition and out of bounds check in RMR
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
Status 2022-11-22: From the 28 epics planned (link) we implemented 2 (link). 16 items have been moved out of the G release, e.g, because of implementation delays (link). Incomplete items: 10 (link). Additionally we fixed 7 bugs and small implementation tasks (link)
G release source code, container images and deployment instructions
The list of container images for the G release (link).
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.
Primary Goals: To support OSC project CI pipeline. To test and validate the components and use cases
G Feature Scope / Achievements:
To set up test automation with the XTesting framework that can run at release time to verify features and integration (an XTesting work flow demo can be found here)
Work with OSC open labs (US east coast, US west coast, Asia Pacific) to facilitate community testing. Latest status on the 3 labs are available here
Explore the POWDER testbed for OSC integration test needs: a POWDER account was created that serves as an umbrella project for the OSC community. Multiple profiles were added for automated RIC platform deployment and automated testing.
