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)
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 integrate O-DU High with O-DU Low in Radio Mode
SSB transmission successful
Debugging issue with Sib1 transmission , PDCCH is received but no PDSCH seen at O-DU low.
PDSCH for SIB1 is detected at L1 but L1 does not process it. Pointer is to check the PDSCH PDU parameters
Further debug sessions needed to close the ongoing issues.
There is no breakthrough even after several debug sessions with O-DU Low
SIB1 detection at L1 is successful. PHY.XML is updated with removing the hardware accelerator (<dpdkBasebandFecMode> from 1 to 0 to force the SW encoder)
For the CLA usecase, Cell stop request is received from O-DU high to low but O-DU low sends stop indication multiple times. This issue is fixed in L1 later binary 20.08. This binary update will happen in D-maintenance phase.
implement single UE DL data path and bench-marking
As an O-DU L2 developer, I want to support End to End testing scenarios
Testing of broadcast messages at O-RU emulator set to begin
Viavi confirmed receiving at O-RU. Needs verification from UE sim.
Debug session is planned on 23rd June to achieve SSB and SIB1 transmission till UE simulator and then follow with RACH procedure.
Latest issue: the eCPRI packets differentiation between control plane and user plane through vlan id is supported by Intel, however O-RU support the packet differentiation based on eCPRI packet type. hence the fronthaul transmission validation is blocked.
Intel shall update the L1 package supporting C/U plane differentiation using eCPRI packet type in the D-release maintenance phase.
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 integrate O-DU High Layers to support Closed Loop Automation Use-case
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.
Intel/Viavi to confirm successful decoding of SSB/SIB1 at UE sim (TM500).
D release source code, container images and deployment instructions
TODO
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
D release source code, container images and deployment instructions
TODO
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: 5 issues
with O-DU Low in Radio Mode
SSB transmission successful
Debugging issue with Sib1 transmission , PDCCH is received but no PDSCH seen at O-DU low.
PDSCH for SIB1 is detected at L1 but L1 does not process it. Pointer is to check the PDSCH PDU parameters
Further debug sessions needed to close the ongoing issues.
There is no breakthrough even after several debug sessions with O-DU Low
SIB1 detection at L1 is successful. PHY.XML is updated with removing the hardware accelerator (<dpdkBasebandFecMode> from 1 to 0 to force the SW encoder)
For the CLA usecase, Cell stop request is received from O-DU high to low but O-DU low sends stop indication multiple times. This issue is fixed in L1 later binary 20.08. This binary update will happen in D-maintenance phase.
As an O-DU L2 developer, I want to support End to End testing scenarios
Testing of broadcast messages at O-RU emulator set to begin
Viavi confirmed receiving at O-RU. Needs verification from UE sim.
Debug session is planned on 23rd June to achieve SSB and SIB1 transmission till UE simulator and then follow with RACH procedure.
Latest issue: the eCPRI packets differentiation between control plane and user plane through vlan id is supported by Intel, however O-RU support the packet differentiation based on eCPRI packet type. hence the fronthaul transmission validation is blocked.
Intel shall update the L1 package supporting C/U plane differentiation using eCPRI packet type in the D-release maintenance phase.
r/sim/o1-interface". 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 SIM project is here.
As an O-DU L2 developer, I want to develop O-DU High Layers to support Closed Loop Automation Use-case
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.
Intel/Viavi to confirm successful decoding of SSB/SIB1 at UE sim (TM500).
Infrastructure (INF)
Primary Goals:
Implement the O-Cloud reference design, provide the real time performance to allow the O-DU and other components running on top of it.
Provide interaction capabilities with other components.
D Feature Scope:
Enabe the 2 AIO severs with additional worker nodes deployment scenario
Major components upgrade
Implement the O2 interface as the MVP (will defer to next release)
Each repository has a branch named "dawn" that can be accessed using git: "git clone --branch dawn "https://gerrit.o-ran-sc.org/r/sim/o1-interface". 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 SIM project is here.
D release source code, container images and deployment instructions
The repository has a branch named "dawn" that can be accessed using git: "git clone --branch dawn "https://gerrit.o-ran-sc.org/r/pti/rtp.git". Note that this branch is in maintenance and all new development is done in branch "master".
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).
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
D release source code, container images and deployment instructions
Docker image and instruction on how to install SMO O1 interface can be found here.
Docker image for instructions on how to install SMO O1/VES interface can be found here.
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).
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
D release source code, container images and deployment instructions
