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, health check, life cycle management) 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).
D release highlights (12-08-20):
Expanded set of xApps from expanded community: Cherry release includes xApps from AT&T (TS, QP-D, QP, HW, MC), Samsung (KPIMON), and HCL (AD).
Jira: Count of Epics, User Stories, Tasks, and Issues: 165 issues
Status (5-25-21):
D Release status
New xApps:
Bouncer xApp (HCL, C++): RIC performance measurement xApp - in conjunction with the appropriate E2 Sim, can test E2 control loop latency (INSERT-CONTROL) as well as the scalability of the RIC with regard to the number of E2 Nodes supported.
LP (Load Prediction, ChinaMobile, python): Initial version of a cell load predictor.
HW-P (Hello World - Python, Samsung): A python based demo xApp that demonstrates how an xApp can use the RIC platform features in python.
HW-G (Hello World - go, Samsung): A go-based demo xApp that demonstrates how an xApp can use the RIC platform features in go.
Improved xApps:
AD (Anomaly Detection, HCL, python): A ML-based real-time anomaly detection using KPI data populated in inFlux DB.
KPIMON (Samsung, go): Improved version implements E2 SM KPM 2.0.3 version and stored collected data in time series DB (inFlux)
QP (QuE Predictor, HCL, python): A ML-based predictor of UE's throughput if it was handed over to a neighboring cell. The D release version finally uses a ML-trained prediction model and includes the functionality previously provided as a separate QP-driver xApp.
TS (TRaffic Steering, U. Parana, C++): Extended version of the TS xApp that now receives anomaly detection messages, requests QoE prediction, and issue control operation to request a UE handover.
Together, AD, QP, and TS xApps and Viavi E2 Tester, implement a use case where anomaly detection is combined with QoE prediction and traffic steering action to move the affected UEs to a different cell.
Near-Real-time RAN Intelligent Controller Platform (E2 Interface) (RICPLT)
Mission: Update to newer O-RAN specs (E2,A1,O2,O1) and related features.
Original primary goals: Update to E2APv1.1 (E2 Node configuration transfer in E2 Setup and E2 Configuration Update (even if likely changing again in E2APv2.0) and E2SM OID support in internal E2SM function query interfaces) // support for A1-EI (as per A1APv3.0) // support for O2 as per WG6 use cases // support for RIC-708 O1-CM to xApps // RIC-734 Include time series database into RIC platform (InfluxDB) for usage by xApps // RIC-421 O1 mediator graceful restart with O1 data being persisted over restarts // Concrete alarms from RIC platform (related to message overload): RIC-204, RIC-203 // SDK package, well documented interfaces to be used by xApps via xApp frameworks // Portability SDK (in xApp project) // REST interface for subscription management. 35 Epics planned: link and 11 items as stretch goals: link
Achieved D release highlights (2021-06-10):
REST interface for xApps towards E2 subscription manager. No need to encode E2AP subscription messages in the xApps anymore. The Xapp framework for Go already supports/uses this.
Support for A1-EI (Enhancement information) to xApps
A lot of extra load/scalability testing (using a new bouncer xApp) and functionality testing (E2, ...) was done under RIC-150 using a "bouncer xApp".
Wider scope of the xapp framework for python (RIC-778, RIC-773).
We added InfluxDB as optional platform service time series database (RIC-734)
Support for O2 as per WG6 use case "Deploy xAPP in Near-RT RIC" in O-RAN Orchestration Use Cases v2.0. This also includes a change in how xApps register as part of their startup.
libe2ap (asn1c-based) can be re-used by components to encode/decode E2AP ASN.1 PDUs (Protocol Data Unit)
E2 statistics are now visible as VES metrics events
RMR raises alarms using the RIC alarm system in temporary overload situations
The Near-RT RIC can be deployed on Kubernetes 1.18 and helm 3. For the first time, this and all robot framework based "end-to-end" tests have also been verified in the O-RAN SC lab.
The Near-RT RIC project now achieved the CII (Core Infrastructure Initiative) badge "passing": (link).
Status 2021-06-11: Work is about to complete for the following 25 (19 epics and 6 "others") items link. 14 of these are already "done". The following 22 items (16 epics and 6 "others") we had to move out from Dawn content link. None of the stretch goals (link) has been worked on. See release highlights (above) for what has been achieved. Most notable items that were dropped are support for the E2APv1.1 capabilities "config transfer" and "OID support (i.e., we continue with E2APv1.0), RIC-708 O1-CM to xApps. Discussion on the portability SDK is still work in progress. We continue to support all the existing SDKs via the xapp Frameworks for C++, python and go.
Status 2021-03-03: Work started on many items. 31 Epics planned: link and 15 items as stretch goals: link. Start of release snapshot (MS Excel): link For CII compliance (link)we now do some checks every two weeks in the status meeting and have started a Release criteria checklist template that we go through before releasing, Note that we update to E2APv1.1
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/SMO applications) to perform Non-RT-RIC tasks.
Non-RT-RIC will also host the new R1 interface (between rApps and SMO/NONRTRIC services)
D Feature Scope:
NONRTRIC Functions:
Integrated A1 Adapter from ONAP (controller – mediation)
Integrated A1 Policy Management Service from ONAP (controller – A1 policies)
OSC A1 Enrichment Information Coordinator (controller – 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)
As an O-DU L2 developer, I want to develop O-DU High Layers to support Closed Loop Automation Use-case
Yang modules to be supported by O-DU to ensure the end-to-end functionality of the use case "Closed loop" is in progress. Basic configuration is agreed to support CLA use case.
Internal call flow/message sequence between O-CU and O-DU for cell activation and deactivation is clarified. Call flow updated at
As an O-DU L2 developer, I want to develop O-DU High Layers to support Closed Loop Automation Use-case
Edit-config implementation for o-ran-sc-du-hello-world YANG (admin state changes), Done.
Integration with O-DU code for cell down and up scenario in progress
Integration testing with OAM in progress
Dependency/Blockers:
O1 configuration for day-1 shall need to be completed to start with CLA. However basic configuration e.g. cell state/operational state/admin state shall be supported initially. Use admin state as unlocked to validate the RU link failure.
Server(VM) configuration (H/W and S/W) to mount Radisys CU as a test fixture.
Unable to use valgrind with Intel libraries. Debugging must be carried out with Alternate methods.
SIB1 PDSCH reached L1 but cannot be observed in logs. Awaiting response from Intel.
Viavi to confirm successful decoding of SSB at UE sim (TM500).
O-DU Low
Primary Goals:
—Continue O-DU low and O-DU high pairwise test.
—FAPI P7 massage integration -> Ongoing
—Continue O-DU Low and O-RU emulator test.
—Further CU plane testing -> Ongoing
—Continue E2E test with UE simulator.
—Support the UE attachment test
—Development activity for Closed Loop Automation use-case
—Support and test for cell stop and restart within O-DU High layers
D Release Feature Scope:
PTL: @Zhimin Yuan
Status
Simulators (SIM)
Primary Goals:
Support rapid prototyping by providing simulated interfaces
D Feature Scope:
Enable "Closed Loop Use Case" demonstration by providing O1 interface Simulators for:
O-DU (containing o-du-hello-world YANG model)
O-RU (containing O-RAN-RU-FH November 2020 train YANG models)
O1 Simulator improvements:
"Blank" simulator, which allows dynamically loading any YANG models of interest, for simulating a NETCONF/YANG interface
Jira: Count of Epics, User Stories, Tasks, and Issues:
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).
D Feature Scope:
Support for O1 interface
Implementation of NETCONF client in SMO
Reference implementation of a NETCONF server that O-RAN Network Functions, e.g. Near-RT RIC, CU, DU and RU can use. The code can be found at https://github.com/CESNET/netopeer2
A minimal set of YANG models that demonstrate the capability of the O1 interface while satisfying the closed-loop automation use-case.
Support for O1/VES interface
Demonstrate the capability to receive VES events, collect them in a dB, and display them in a dashboard.
An implementation of the O1 interface has been checked into Gerrit. Check out this repo. It has been tested on Ubuntu Linux version 20.04. Feedback is appreciated on other versions and operating systems. Note, this commit is not feature compatible with the O1 interface in other implementations. Some of those features have been identified and marked as enhancements in either this or the next release.
An implementation of the VES interface based on schema version 7.2.1, with backward compatibility to 7.0, has been submitted for Gerrit review, and review comments have been provided. Author has updated the commit based on the comments. Waiting on more reviews. Again, the commit is not feature compatible with VES interface in other implementations. Some of those features have been identified and will be added in this or the next release.
Jira: Count of Epics (0 issues), User Stories, Tasks, and Issues: 6 issues
