The O-RAN Software Community (SC) Documentation.

Welcome to O-RAN SC Cherry Documentation Home

O-RAN Alliance (https://www.o-ran.org/) members and contributors have committed to evolving Radio Access Networks (RAN) around the world. Future RANs will be built on a foundation of virtualized network elements, white-box hardware and standardized interfaces that fully embrace O-RAN’s core principles of intelligence and openness. An ecosystem of innovative new products is already emerging that will form the underpinnings of the multi-vendor, interoperable, autonomous RAN, envisioned by many in the past, but only now enabled by the global industry-wide vision, commitment and leadership of O-RAN Alliance members and contributors.

O-RAN SC is partnering with the O-RAN Alliance and Linux Foundation to support the software development for an open RAN solution that is available to everyone. The community will align with the architecture and specifications that are created in the O-RAN Alliance working groups to create a working software solution to enable an open and intelligent 5G RAN.

Cheery release introduction:

Near-Real-time RIC X-APPs (RICAPP)

Traffic steering use case: Integrate KPIMON (by Samsung) in the use case. KPIMON uses E2 (KPM SM) to collect data about cells and UEs - the E2SM will be initially implemented by the E2 SIM using data generated by Viavi RAN simulator. Enhance QP xApp with a real ML model trained with Viavi data (AT&T, HCL). Enhance TS xApp to send E2 Control message to trigger handover - E2 message will be handled by the E2 SIM.

New xApps: Anomaly Detection (AD by HCL) uses ML model to detect anomalies in data collected by KPIMON. Load Predictor (LD by China Mobile) uses ML model to predict the load of a cell (using data collected by KPIMON) Signal Storm Protection (SSP by Samsung) implements the initial steps towards a realization of the Signal Storm Protection use case (WG-1). Code coverage and updates to use xApp SDK for existing xApps.

Near-Real-time RAN Intelligent Controller Platform (E2 Interface) (RICPLT)

More manageability of the RIC platform, including platform alarms, platform stats from E2 and A1 and support for direct RMR-to-VES event conversion for VES stats, Support operator-initiated health-check via E2 and E2 connection state, E2 can reject new connection setup requests. REST interface for E2 subscriptions, further xApp framework APIs.

Non-Real-time RIC (A1 Interface) (NONRTRIC)

A1 Policies: A1 Policy Management Service (hosted in ONAP CCSDK) A1 Policy Controller Adapter (hosted in ONAP CCSDK) A1 Simulator / test stub (SIM project) A1 Policy Control-Panel (PORTAL project) Support A1-AP v2.0.

A1 Enrichment Information: Initial version of A1 EI Job coordination function/service Deployment/Integration Docker-based & OSC Kubernetes deployment & ONAP OOM Kubernetes deployment (Overlaps with SMO project)

rApps: Very simple hello-world rApp TrafficSteering usecase Healthcheck usecase

rApp support: Initial rApp catalogue/inventory Initial approach with rApp packaging (overlaps with “common App” usecase, & SMO project) Requirement gathering & initial test/integration with ML supporting functions in NONRTRIC/SMO Requirement gathering & initial test/integration with data collection & coordination functions in NONRTRIC/SMO Requirement gathering & initial test/integration with CMDB (if progressed in ONAP), Topology & Inventory functions in SMO

OAM (O1 Interface)

Switch to Java11 Switch to OpenDaylight version Sodium (O1 termination NetConf) https only support for VES-Collector (O1 termination VES) full IPv6 support

O-RAN Central Unit (OCU)

RRC: support Broadcast of system information£ support RRC connection control

NG: support PDU Session Management Procedures support UE Context Management Procedures support Transport of NAS Messages Procedures support Interface Management Procedures

E1: support Interface Management procedures support Bearer Context Management procedures

F1: support Interface Management procedures support UE Context Management procedures support RRC Message Transfer procedures support System Information Procedures

O-DU High

Implement UE attach procedure with basic scheduling on FDD, mu=0, BW=20 MHz Implement single UE DL and UL data path and bench-marking Add support for 64QAM modulation scheme in DL and 16QAM in UL Add support for all short PRACH formats Integrate O-DU High with O-DU Low Integrate with Viavi sim/O-CU Explore O1 interface Establish Netconf session for O1 interface for CM Support Health Check use-case

O-DU Low

O-DU Low and O-DU High integration according to RSAC and INT project alignment features and scope. O-DU Low and O-RU/RRU emulator integration according to RSAC and INT project alignment features and scope. E2E integration according to RSAC and INT project alignment features and scope O-DU Low integrated with thirty party commercial SW to verify the UE attachment and traffic, update the O-DU Low version according.

Simulators (SIM)

1 Simulator enhancements Upgrade NETCONF Server framework E2 Simulator enhancements Implement more message types Assess if E2 Simulator can be used for benchmarking Maintain alignment with latest YANG models

Infrastructure (INF)

2 servers. 2 AIO servers with HA (high availability), the controller functionality and storage functionality will be deployed at the 2 servers with standby-active mode managed by “service management”. If one server or one service in one server has error, it will be switched from active to standby one to maintain the service availability. 2 AIO servers with additional worker node.

Integration and Test (INT)

Automated CLM and SonarQube Scanning CI Jobs Improve CI for OSC projects Validate and and Test platform and use cases

Service Management and Orchestration (SMO)

SMO entered the Cherry release in the middle of third sprint of code development. As such its scope is fairly modest. They are validation of application packages, assuming that we can agree on the format of the package, on boarding of applications and storing them in a package catalog which also has to be agreed upon, and as a stretch goal, setting up an environment where YANG modules that will be used by O-RAN, whether they are from 3GPP, and O-RAN itself can be used by vendors developing RIC, CU, DU and the RU to test a MVP configuration.

Please find some guidance here on the content of O-RAN SC documentation.