Welcome to the E release page for the O-RAN Software community.
The E release is currently under development and its source code is maintained within the master branch of each repo. Once released further instructions related to separate maintenance branches and release image lists will be available here,
Near-Real-time RIC X-APPs (RICAPP)
Primary Goals:Expand the community working on open source xApps for O-RAN SC.Enhance the set of open source xApps in support of the R-SAC use cases (traffic steering, network slicing) as well new use cases. Update and enhance existing xApps to take advantage of the new features in xApp SDK (implemented by the xApp frameworks in C++, go, and python).
E release plan (12-01-21):
New xApps: RC (RAN Control) by Mavenir - implements subset of E2 SM RC
Improved xApps:
LP (Load Prediction) by ChinaMobile: Include trained ML model, will populate predictions in inFlux DB
AD (Anomaly Detection) by HCL: Will identify a new anomaly type (area anomaly), use geo-location as a feature.
QP (QoE Predictor) by HCL: Include prediction for current serving cell, incorporate predicted load as a feature, provide sequence of predictions.
TS (Traffic Steering) by UTFPR (University, Parana, Brazil): Call RC xApp to trigger UE handover, improvements in traffic steering logic.
Bouncer by HCL: Increase performance and functional testing capabilities; continue identifying RIC platform bottlenecks.
HW (HelloWorld) demo xApps in C++, go and python by AT&T and Samsung: Add usage of more platform features, update usage of platform features that are evolving.
Integration of AD, QP, TS, LP, RC, and KPIMON with Viavi simulator.
Extensive performance benchmarking of the RIC platform using Bouncer and E2 Simulator (HCL)
Design for xApps to support network slicing use case.
Jira: Count of Epics, User Stories, Tasks, and Issues: 165 issues
Status (12-01-21):
RC: Committers identified, design agreed, repo created
LP: Trained ML-model added to the xApp
AD: Work on new anomaly type - testing in progress
HW: New functionality added to HW-go and HW-python.
Bouncer: Bottleneck with E2 Subscriptions identified in RIC platform. - RIC benchmarking testing - In progress
Discussions on network slicing use case with HCL, Viavi, UTFPR. - Will come up with the proposal
E release source code, container images and deployment instructions
Will be provided when E Release is ready.
Near-Real-time RAN Intelligent Controller Platform (E2 Interface) (RICPLT)
Mission: E2 updates with first E2APv1.1 support and improvements in E2 subscription handling.
Original primary goals: Update to E2APv1.1 (E2 Node configuration transfer in E2 Setup and E2 Configuration Update (RIC-638, even if likely changing again in E2APv2.0) and E2SM OID support in internal E2SM function query interfaces (RIC-640)) // RIC-809 Subscription manager to delete subscriptions in case of E2 disconnect (incl. Xapp changes) // RIC-796 sub mgr and xapp-frame error cases // RIC-793 Prevent A1 Job ID conflicts from multiple RICs using the same A1 producer (SMO) // Partial only: RIC-647 (first step of reimplementation A1 mediator in golang to avoid A1 being the only python container in RIC platform // RIC-709 E2 stats exposing individual counters instead of groups // RIC-714 support for DMS REST interface in addition to DMS CLI // RIC-113 DB: SDL CLI for debugging and testing // RIC-110 FindKeys/GetAllKeys SDL API to support glob-style patterns // RIC-676 Update to Ubuntu 20.04 as base image for all containers // improvements in xApp testing // 29 Epics planned: link and 30 items as stretch goals: link
Achieved E release highlights = high-level release notes (2021-12-03) below (note that the release image list is here (once releases): link)
we updated from E2APv1.0 to E2APv1.1. The platform now stores OIDs (introduced in E2APv1.1) for the E2SM of E2 function definitions in RNIB. Since E2APv1.1 is backwards compatible with 1.0, you can still connect E2 nodes that support E2APv1.0. Note that for the next release we plan to switch to E2APv2.0 only.
The E2 subscription manager now automatically deletes its stored subscriptions if it gets notified (by the E2 manager) of E2 nodes having disconnected. xApps are expected to do the same and need to re-issue their subscriptions once the E2 node is reconnected. This behavior is different to earlier behavior where the subscription manager kept the subscriptions in such situations. Note that the standard requires the E2 node to delete its subscriptions if there's the E2 interface is disconnected.
The E2 subscription manager now handles various error scenarios that previously were not handled.
We will continue the re-implementation of the A1 mediator in golang in release F. The first parts are already implemented, but in the E release we stay with the "old" python-implementation of the A1 mediator.
On SDL side we now have a SDL CLI that can be used in testing (instead of direct usage of the Redis CLI). The SDL API for findkeys/getkeys now supports glob-style patterns.
The golang SDL API/library now handles namespaces as part of its function signatures instead of this being a global parameter. This eases usage of multiple namespaces from the same application.
For the E release of the near-RT RIC we did only limited integration testing: only the use cases: deploy RIC, deploy xApp and make E2 connection were tested.
Status 2021-12-03: we are working on implementing the last planned development items below. From the 29 epics planned (link) we implemented so far 11 (link). 12 items have been moved out of the E release, e.g, because of implementation delays (link). We expect 6 items to still complete and one item (RIC-375) is still under discussion what to do with it (link).
RIC-113 (DB) - expected to complete by Dec-3 → thjoralf to check with Timo
RIC-779 to complete by Dec-7, RIC-790, RIC-816 asked from Sunil.
RIC-816 → expected to be done tomorrow
RIC-790 → done and for extra work create new item
RIC-779 → expected to be done tomorrow
RIC-375 discussion with Anssi+Juha on whether we move this to F
RIC-640 Subhash commented: "(likely done by Dec-6) " → DONE
E release source code, container images and deployment instructions
Each repository has a branch named "e-release" that can be accessed using git: "git clone --branch e-release "https://gerrit.o-ran-sc.org/r/ric-plt/e2". Make sure to replace the URL with correct repositories. Note that this branch is in maintenance and all new development is done in branch "master". The complete list of repositories belonging to the RIC platform is defined here: Scope of the near-RT RIC platform and its components (summary).
In order to deploy the E release of the near-RT RIC platform you can re-use the pre-created container images as defined here. The same instructions as always apply, i.e., follow the general latest instructions: https://docs.o-ran-sc.org/projects/o-ran-sc-ric-plt-ric-dep/en/latest/ → Installing Near Realtime RIC in RIC Cluster, but make sure to use "git clone --branch e-release ..." instead of "git clone ..." when cloning it/dep and ric-plt/ric-dep.
Non-Real-time RIC (A1 Interface) (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 also host the new R1 interface (between rApps and SMO/NONRTRIC services)
E Feature Scope:
E Release Priorities:
ONAP Control Loop -> O-RAN rApp : “The rApp-ification of ONAP Control Loops”
Adopt ONAP CL work as a starting point, continue to identify gaps, then extend
Identify & motivate where an rApp is different from a CL
Types of rApps:
Microservice-based rApps
Non-Microservice-based rApps
NONRTRIC Service Exposure/Gateway -> O-RAN R1 : “The R1-ification of Service Exposure”
Service-independent aspects
Types of exposure support in R1:
Microservice-based rApps & Service
Non-Microservice-based rApps & Service
Use cases of rApps & Exposing specific Services via R1
Requirements drivers & demonstrators
O-RU FH recovery (multiple), Slice Assurance, Existing Function Tests, various other use cases in ONAP
Continued Evolution & Support for A1 functions
NONRTRIC Functions:
Integrated A1 Adapter from ONAP (controller – mediation)
Integrated A1 Policy Management Service from ONAP (controller – A1 policies)
rApp/Control Loop Manager (ONAP & OSC)
OSC Enrichment Information Coordinator (controller – Data exposure & A1 EI Job management)
OSC Non-RT-RIC Control Panel (GUI – for A1-P & A1-EI Job management)
OSC A1 Simulator (a stateful test stub to simulate near-RT-RIC end of A1 interface – A1-P & A1-EI)
OSC APP catalog (for registering/querying APPs)
K8S Helm Chart LCM Manager - for APP µServices etc. (ONAP & OSC)
E release source code, container images and deployment instructions
TODO
Simulators (SIM)
Primary Goals:
Support rapid prototyping by providing simulated interfaces
E Feature Scope:
Support of O-RAN-SC E-Release Network Slicing use case by Radisys - support of O-DU projects for end-to-end closed loop use cases for RAN network slicing (implement any message flows in the O-DU Simulator, if needed)
Align O1 Simulator with the latest specifications released by O-RAN Alliance.
Support of NETCONF CallHome via TLS, for the O1 simulator
Jira: Count of Epics, User Stories, Tasks, and Issues:
D release source code, container images and deployment instructions
not applicable
Service Management and Orchestration (SMO)
Primary Goals: The primary goal of the SMO project is to integrate different software artifacts of existing open-source projects creating a fully functional open-source Service Management and Orchestration (SMO).
E Feature Scope: In E-release, SMO will be extended to support network slicing. In particular, RSAC has come up with closed loop automation use case for network slicing which involves the SMO collecting PM counters related to network slicing, and based on them breaching some thresholds will cause a change in the configuration of the network slice. That means the SMO has to have support for PM counters related to network slicing, and an ability to reconfigure the O-DU for the network slice. Separately, AT&T has asked for a disaggregated VES solution that separates the collection of VES events from how it is presented to any application that wants to view them.