Status 05-12-2020:

• HW (HelloWorld) xApp is ready except for documentation
• MC (Measurement Campaign) xApp is ready except for documentation
• TS (Traffic Steering) xApp is ready for integration testing
• QP-driver (QuE Prediction Driver) xApp is ready for integration testing
• KPIMON is waiting for legal review at Samsung
• QP (QoE Prediction) xApp status pending (5-12-2020)
• Full integration of the traffic steering xApps (TS,QP,QP-driver, KPIMON) likely in Maintenance release.

Status 3-31-2020:

• Repo issues for new xApps have been resolved
• Detailed design of message schemas for traffic steering use case completed and code commits started for use case xApps
• Health check use case features being implemented in xApps (inc. A1 health check)
• Demo xApp (HelloWorld) making steady progress - xApp demonstrates how to implement typical xApp functionality using C++
• Measurement Campaign (MC) xApp making steady progress
• Blockers: CU/DU simulator/emulator uncertainty (affects KPIMON xApp)

Bronze release highlights (2020-06-03): The E2AP protocol implementation of the near-RT RIC platform has been adapted from one based on pre-specification assumptions to the E2AP protocol as defined by the O-RAN alliance. The new near-RT RIC O1 mediator implements the first O1 interfaces based on netconf and Yang models, e.g., to check the health status of xApps. The near-RT RIC internal messaging and message routing solution has been rewritten to significantly improve throughput, latency, and to behave more robustly in failure and high-load conditions. The Redis-based shared data layer now supports HA (high-available) deployments. Various Near-RT RIC platform components use it to store their state and recover that state in failure, restart and upgrade situations. xApps can use the same shared data HA later solution for their state. xApps that use E2AP subscriptions can now use the new E2AP subscription API instead of having to directly generate ASN.1 encoded E2AP subscription messages. In addition to a Go version, the Bronze release of the near-RT RIC platform now also provides a C++ and python framework to simplify the implementation of xApps.

Original Bronze Feature Scope at start of release: Adapting RIC from pre-spec to WG3's first formal E2 protocol specification (for communication with RAN nodes, like CU/DU). Implement netconf-based O1. Enhance RIC's messaging solution (RMR) to achieve higher throughput, various health check capabilities including a capability to ping E2 nodes via E2 and to do a health check of the A1 interface, better failure handling in various components, ...

Status 2020-04-29 and 2020-04-30 and 2020-05-06 and 2020-05-12

• Cherry-R5 plans: link and epics only link
• Epics that are done: link (36 as of 2020-05-12), spilling over into Cherry-R5: 13 items. Using filter "movedoutofbronzeR4" you can see items fully moved from Bronze to Cherry-R5: 9 items. Items moved from Bronze to more distant future: 8
• Still open items:
  • RIC-56 (framework for handling alarms ready, but actual first alarms under this item  not ready (RIC-202, RIC-203, RIC-204) - specific alarm work continues in Cherry-R5
  • DB related work: RIC-246 (UE NIB reader API documentation will continue in Cherry. Additionally we have RIC-371 for R5 implementation and documentation work) // RIC-105, RIC-110 moved out bronze to R5 // RIC-101 moved out of bronze to remote future // RIC-106 (HA integration DBAAS = leftover from R3) is done
    
  • RIC-291 is done on E2T side. E2M does not use ASN.1 anymore. Subscription manager part of RIC-291 also done. RIC-60 almost complete. Some minor work in Cherry (RIC-306) and in Bronze maintenance (RIC-306), RIC-83 was started in Bronze, but plan is to continue in Cherry-R5 (with US RIC-208). For RIC-124 we had some O1 work, but the E2M side work for RIC-124 is not yet done (so we continue in Cherry)
  • RIC-95: A still working on this cannot be tested due to lack of simulator. Likely to be ready only in beginning of Cherry. I now mark this as spilling into Cherry-R5.
  • O1-related: RIC-59 moved to future (post Cherry-R5 as no netconf models yet,  work not started yet), RIC-139 (not yet implemented. Nune checked that E2T and E2M are only components that do not have health check yet. Added US for them under this item. Full item moved to Cherry)
  • RIC-173, RIC-174 (E2 specification preparation work for Future work): specifications still being worked on, but blocked by 3GPP license issues. We add these items back into actual planned work, once the 3GPP issues are resolved
  • RIC-136 (moved to Cherry-R5 as no permission from O-RAN yet)
  • RIC-internal E2E work : RIC-57 (documentation) will continue in Cherry-R5 and RIC-149 (test cases) we will mark as done at the end of Bronze.
    
  • RIC-217 only documentation left (target: late commit/work in Bronze-R4)
  • RIC-80 actually done, but commit problems. Plan is to merge this still into Bronze-R4, but for now I mark it to Cherry-R5 so we don't forget it. We mark RIC-80 as done once we can commit it. We have created RIC-375 that includes removal of the old ASN.1 based interface support and which might include minor cleanup work in this context.
    
  • RIC-84 implementation ready, but came to late for Bronze-R4. We merge in the beginning of Cherry-R5. Marked as to be completed in Cherry-R5.
    
  • Moved out from Bronze-R4: RIC-177, RIC-139, RIC-136, RIC-123, RIC-107, RIC-118 and RIC-119 as well as user story: RIC-104, RIC-203. Use this filter for label "movedoutofbronzeR4"
  • RIC-120 Antti working on this in his spare time. We continue the work in Cherry-R5
• Healthcheck use case supporting items that are done: A1 healthcheck (RIC-46), xApp health state as O1 (RIC-14). Partially done, but not yet easy to show-case: RIC-124 (E2M not yet publishing SDL notifications), RIC-56 (alarm path available, but no actual alarms) Not done, but either coming late or in early Cherry-R5: RIC-95 (REST interface for checking the E2 connection states (lack of simulator)). RIC-139 (platform health via O1) 

Status 2020-03-31

• Jira: 63 epics: link (requires free LinuxFoundation account). Items that we worked on already before the first formal development are marked as Bronze-R3 in JIRA "fix release" (11 = 2 (in progress) + 9 (done) // 2 moved to R4) and the ones to be worked on during the five three-week sprints in Bronze-R4 Feb-3 to May-17 (52 = 6 (in progress) + 8 (done or done, but pending review by PO) + 38 (not yet started)). For useful near-RT RIC JIRA links check §8 in Jira usage conventions.
• 2 new epics:  one related RIC-291 to (replacing RIC-136 due to legal issue around copying ASN.1 also mentioned in last status update) and RIC-246
• Question to TOC: progress on ASN.1 legal issues.
• Demos of sprint D3 planned for Thursday, Apr-2, 9am ET (see groups.io calendar)
• Deployment time decision between DBAAS SA (standalone) and DBAAS HA (high available) is transparent to RIC components as expectation is that DBAAS "client configmap" is included in RIC component help charts.
• Switch to new E2AP still pending integration (estimate Apr-3). Multiple components are ready for it.

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.

Bronze Feature Scope:
Initial design and start implementation of NONRTRIC Platform.
Continue evolution of A1 interface.
Continue evolution of A1 Policy Management functions.
Modeling and implementation of the Non-RealTime RIC aspects of the "Health Check" and "Traffic Steering" use cases

Bronze Release highlights(Jun.8):

The Bronze Release includes:

• ORAN WG8 Software Specification compliant DU Low implementation including O-RAN FrontHaul compliant Radio<-> L1 interface, FAPI compliant L1<->L2 interfaces, and a shared memory and buffer management library for efficient L1<->L2 communication
• Ability to link in a high-performance L1 stack application with advanced 5GNR features including 3GPP TS 38.211, 212, 213, 214 and 215, running on Intel Xeon processor based O-DU hardware, and packaged with a comprehensive functional and performance evaluation framework.

Primary Goals: The O-RAN-SC-ODU LOW project provides reference implementation of ODU-LOW according to the O-RAN AAD specification (WG8) documents. The reference design will follow the open interface toward ODU HIGH, RRU and Accelerator, provide physical layer signal processing functionality according to ORAN specification and 3GPP .

Bronze Feature Scope:  Based on release Amber, support the ARM based system. Align with requirement of the O-Cloud, add more services such as fault management , configuraiton management , software management , host management and service management. Improve the automation by adopting the ansible, and integrate with INT project.

Bronze Releae Highlights:

• Implement the container based O-Cloud reference design, and with real time features which is critical for the performance sensitive application such as DU.
• Integrate the telco grade features include fault management, software management, service management, host management and configuration management which leverage from StarlingX.
• Support the ARM based real time Kubernetes cluster.