Welcome to O-RAN SC O-DU-L2 Documentation¶

O-DU High Overview¶

O-DU High Architecture¶

O-DU implements the functional blocks of L2 layer of a 5G NR protocol stack in SA(StandAlone) mode. These layers primarily include NR MAC, NR Scheduler and NR RLC layers.

O-DU modules are developed as shown in the below diagram.

Figure 1 - O-DU High Architecture Diagram¶

O-DU High Thread Architecture¶

As shown in Figure 1, there are multiple entities within O-DU High. Modules sharing a given color belong to one thread. O-DU architecture can be defined at a thread level as follows:

Thread 1: O-DU thread
Thread 2: DU APP inclusive of Config Handler, DU Manager, UE Manager, and ASN.1 Codecs
Thread 3: 5G NR RLC DL and MAC (inclusive of 5G NR SCH and Lower MAC)
Thread 4: 5G NR RLC UL
Thread 5: SCTP Handler
Thread 6: Lower MAC Handler
Thread 7: EGTP Handler
Thread 8: O1

O-DU High Modules¶

DU APP¶

This module configures and manages all the operations of O-DU. It interfaces with external entities as follows:

OAM: DU APP interacts with OAM on the O1 interface for configuration, alarms and performance management.
O-CU: DU APP interacts with O-CU for RAN functionalities over the F1 interface which is built on SCTP. Control messages are exchanged on the F1-C interface and data messages on the F1-U interface.
RIC: DU APP interacts with RIC on E2 interface over SCTP.

DU App submodules are as follows:

Config Handler manages the configurations received on O1 interfaces and stores them within DU APP context.
DU Manager handles all cell operations at the DU APP.
UE Manager handles UE contexts at the DU APP.
SCTP handler is responsible for establishing SCTP connections with O-CU, RIC on the F1AP and E2AP interfaces respectively.
EGTP handler is responsible for establishing EGTP connection with O-CU for data message exchange on the F1-U interface.
ASN.1 Codecs contain ASN.1 encode/decode functions which are used for System information, F1AP and E2AP messages.

5G NR RLC¶

This module provides services for transferring the control and data messages between MAC layer and O-CU (via DU App).

5G NR RLC UL and 5G NR RLC DL are the sub modules of this module that implement uplink and downlink functionality respectively.

5G NR MAC¶

This module uses the services of the NR physical layer to send and receive data on the various logical channels. Functions of the 5G NR MAC module are as follows:

5G NR MAC is responsible for multiplexing and de-multiplexing of the data on various logical channels.
5G NR SCH schedules resources in UL and DL for cell and UE based procedures. 5G NR SCH is completely encapsulated within the 5G NR MAC i.e., all interactions of the 5G NR SCH is via the 5G NR MAC.
Lower MAC interfaces between the MAC and the O-DU Low. It implements all the messages of FAPI specification. It has a receiver thread to handle messages from L1.

O-DU Utility and Common Functions¶

These modules contain platform specific files and support O-DU High functionality and message exchanges.

O1 Module¶

Figure 2 - O1 Architecture¶

As shown in figure 2 the O1 module runs as a thread in O-DU High. Alarm communication happens over a Unix socket between the O1 and O-DU threads. O1 module uses API calls for interacting with the Netconf server(Netopeer) and datastore(sysrepo) for providing the Netconf interface.

O1 architecture has following components:

Netconf Session Handler: Subscribe to Netconf YANG modules and events. Register callback handler methods.
VES Agent : Sends the VES events to SMO
Alarm Manager: Stores and manages(add/updated/delete) alarms.
Alarm Interface : Provides an interface to O-DU High threads for sending the alarm messages to O1 module over Unix socket.
Config Interface : Interface to handle the configurations sent from SMO to the stack
Netopeer server: Serves the northbound SMO/OAM Netconf requests.

O-DU-High Interfaces¶

This section describes the other modules that O-DU High interfaces with, as shown in below diagram.

Figure 3 - O-DU High Interfaces¶

As shown in Figure 3, O-DU High interfaces with the following modules:

O-CU: O-DU High communicates with O-CU on the F1AP interface. The control message exchanges are on F1-C while data message exchanges are on F1-U interfaces. The below F1AP messages on F1-C are implemented, as per 3GPP 38.473-f60 v15.3:
- Interface Management
  - F1 Setup
  - gNB-DU Configuration Update
  - F1 Reset
- UE Context Management
  - UE Context Setup
  - UE Context Modification
  - UE Context Release
- RRC Message Transfer
  - Initial UL RRC Message Transfer
  - DL RRC Message Transfer
  - UL RRC Message Transfer
  - RRC Delivery Report
Near RT RIC: O-DU High communicates with Near RT RIC on the E2 interface. The below E2AP messages are implemented, as per ORAN WG3.E2AP v01.00:
- Global Procedures
  - E2 Setup
- Near RT RIC Functional Procedures
  - RIC Subscription
  - RIC Indication
O-DU Low: O-DU High communicates with O-DU Low on the FAPI interface. The below FAPI messages are supported, as per FAPI interface files shared by Intel:
- P5 messages - PHY mode control interface
  - PARAM.request/PARAM.response
  - CONFIG.request/CONFIG.response
  - START.request
  - STOP.request
  - STOP.indication
- P7 messages - Main data path interface
  - DL_TTI.request
  - UL_TTI.request
  - SLOT.indication
  - UL_DCI.request
  - TX_Data.request
  - RX_Data.indication
  - CRC.indication
  - UCI.indication
  - RACH.indication
OAM: O-DU High communicates with OAM on the O1 interface.

O-DU High functionality¶

Cell Up and Broadcast Procedure¶

This section describes the cell-up procedure within O-DU High.

Figure 4 - O-DU High Cell Up and Broadcast Procedure¶

As seen in the Figure 4, - The DU APP module of O-DU High sends F1 Setup Request to O-CU. This message contains a list of cells that the O-DU High has been configured with.

The O-CU responds with F1 Setup Response. This message contains a list of cells which must be activated.
The O-DU High scans the list of cells received and sends corresponding cell configurations to 5G NR MAC.
5G NR MAC, in-turn configures the 5G NR SCH. It also configures the O-DU Low via the Lower MAC module.
On receiving the cell config response, DU APP sends a gNB DU Config Update towards the O-CU. The O-CU responds with gNB DU Config Update ACK towards the O-DU High.
The DU APP now exchanges F1 Reset message with the O-CU to initialize the UE contexts.
DU APP sends Cell Start Req towards 5G NR MAC. This message is translated by the Lower MAC into the FAPI message START.request towards the O-DU Low.
On receiving START.request, O-DU Low begins to send slot indications towards 5G NR MAC via the lower MAC. The frequency of these slot indications is determined by the numerology(Mu) supported. 5G NR MAC forwards these slot indications to the 5G NR SCH and DU APP modules.
When the first slot indication reaches the DU APP, cell is marked as up.
The 5G NR SCH, keeps tracking the SSB and SIB1 ocassions on receiving regular slot indications. On detecting the relevant ocassion, 5G NR SCH schedules SSB/SIB1 and forwards the DL Scheduling Information to 5G NR MAC.
The 5G NR MAC mutiplexes the PDU and sends SSB/SIB1 packets towards the O-DU Low through the Lower MAC.

Closed Loop Automation Procedure¶

This section describes the closed loop automation procedure within O-DU High.

Figure 6 - O-DU High Closed Loop Automation Procedure¶

SMO commands ODU-High to bring the cell down via O1 interface.
DU-APP module of ODU-High sends GNB-DU configuration update message to O-CU. It contains the details of cell to be deleted. O-CU acknowledges this message by sending GNB-DU configuration update acknowledgment.
For each UE, DU APP sends UE Context Release Request to O-CU with information about the to be released. O-CU responds with UE Context Release request. It contains the RRC release message. O-DU high sends this RRC Release message to UE.
DU APP then sends UE delete request to MAC and RLC. Once a confirmation is received from both MAC and RLC, DU APP deletes UE from its own database as well.

Once all UEs are released, O-DU High sends STOP.Request to L1. L1 responds with stop indication.
Once cell has stopped, DU APP sends cell delete request to MAC. On receiving confimation from MAC, DU APP deletes cell information from its own database as well and sends UE Context Release Complete.
On receiving cell bring up command from SMO, the complete Cell bring up and UE attach procedure will be repeated (as explained in above sections)

O1 Netconf get-alarm list procedure¶

This section describes the Health Status Retrieval scenario of O-DU High health-check. It enables a northbound client(SMO) to retrieve the health of the O-DU High based on the last self-check performed. The alarm-list is provided as the response to the request via O1 Netconf interface.

Figure 7 - O1 get alarm-list flow¶

As seen in the Figure 7,

On the cell state change from de-active to activate, DU APP module raises a cell up alarm message and sends it over the Unix socket using the Alarm Interface API.
On other side a Unix socket server, running as a thread, in O1 module receives the cell up alarm message and it passes on the alarm information to the Alarm Manager.
Alarm Manager stores the alarm data in a list.
Whenever SMO/OAM requires the current alarm list, it sends a Netconf get request. The request is received by the Netopeer Server and a callback method, registered with the Session Handler, is invoked.
The callback function fetches the alarm list from Alarm Manager and sends it back to the client (SMO/OAM) via Netconf interface.

OSC Testcases Supported¶

The O-DU High partially supports below use-cases:

Traffic Steering
Health Check

Release-Notes¶

This document provides the release notes for D Release of O-DU-L2.

Version history ¶

Date	Ver.	Author	Comment
2021-09-06	4.0.0	Radisys, HCL Technologies Ltd.	D Release
2020-12-04	3.0.0	Radisys, HCL Technologies Ltd.	Cherry Release
2020-06-17	2.0.0	Radisys	Bronze Release
2019-12-29	1.0.0	Radisys	Amber Release

Summary ¶

D ¶

This release contains the following:

UL/DL Data transmission on FDD/Mu0/20MHz.

Support for static TDD at O-DU High on 100 MHz Bandwidth, numerology 1.

Support for Closed Loop automation use case at O-DU High.

O-DU low – O-DU high pairwise testing in Radio mode (Broadcast message successfully received at O-DU Low).

O1 Module
Re-structure O1 module to run as a thread in ODU-High.

CM Support - IP and Port configuration for DU, CU stub and RIC stub via Netconf interface.

VES PNF Registration.

Support for Closed Loop Automation use-case.

Maintenance release includes :

Memory handling optimization and fixes.

Improvement in logging.

K0, K1 and K2 configuration.

Fixes in proccessing of RACH Indication and RAR.

Cherry ¶

This release contains the following:

Implementation of UE attach signalling procedure on single carrier. All message exchanges within O-DU High are in line with WG8 AAD spec.
Enhancements to F1-C interface as required for UE attach procedure.
Enhancements to FAPI interface towards O-DU Low as required for UE attach procedure.
Support for all short PRACH formats.
Integration of FAPI P5 messages with Intel’s O-DU Low in Timer mode.
Code support for alignment with latest FAPI interface files from Intel.
Implementation of O1 interface.
Partial implementation of Health Check use-case with get-Alarm list API.

Bronze ¶

This release contains the following:

Enhancements to F1-C interface for UE attach procedure.
Implementation of F1-U interface.
Implementation of E2 interface.
Support for traffic steering usecase.
Support for single carrier.
Implementation of basic scheduler.
Implementation of Cell broadcast procedure.
Implementation of UE procedure till msg-4 for single UE. Complete testing of these messages is in progress.
Implementation of FAPI interface towards O-DU Low using WLS.
Partial implementation of RLC layer interfaces towards upper and lower layers conforming to AAD spec.

Amber ¶

This release contains the following:

O-DU layer intilaizations
Implementation of F1-C interface
Exchange of F1 Setup Request, F1 Setup Response, GNB DU Config Update and GNB DU Config Update ACK between the ODU and CU STUB.

Release Data ¶

D ¶

Project	ODUHIGH
Repo/commit-ID	o-du/l2/ e8fdaea4192b41240b8c43f48adf92eed0c3 b99e
Release designation	D Release
Release date	2021-09-06
Purpose of the delivery	D Release

Cherry ¶

Project	ODUHIGH
Repo/commit-ID	o-du/l2/ fc0bcf28e944ae7ba2423ad3c9a5c794df2dc 4ff
Release designation	Cherry Release
Release date	2020-12-04
Purpose of the delivery	Cherry Release

Bronze ¶

Project	ODUHIGH
Repo/commit-ID	o-du/l2/ 27844f9c01c08472b86b1a75adaed0e450a88 907
Release designation	Bronze Release
Release date	2020-06-17
Purpose of the delivery	Bronze Release

Amber ¶

Project	ODUHIGH
Repo/commit-ID	o-du/l2/ d349ae65e1495488772f87e5cfa1ae71d9eab 075
Release designation	Amber Release
Release date	2019-12-29
Purpose of the delivery	Amber Release

Feature Additions ¶

JIRA BACK-LOG:

D ¶

JIRA REFERENCE	SLOGAN
https://jira.o-ran-sc.org/browse/ODUHIGH-264	Support for Mu1
https://jira.o-ran-sc.org/browse/ODUHIGH-265	Support for 100 MHz
https://jira.o-ran-sc.org/browse/ODUHIGH-266	Support for TDD mode
https://jira.o-ran-sc.org/browse/ODUHIGH-267	Integration with O-DU Low in Radio mode
https://jira.o-ran-sc.org/browse/ODUHIGH-268	Integration with O-CU
https://jira.o-ran-sc.org/browse/ODUHIGH-269	Support for E2E testing
https://jira.o-ran-sc.org/browse/ODUHIGH-299	Closed Loop Automation use-case
https://jira.o-ran-sc.org/browse/ODUHIGH-196	Netconf session for O1 interface for CM
https://jira.o-ran-sc.org/browse/ODUHIGH-340	Resource allocation in time domain changes to meet flexible k0, k1 and k2 values

Cherry ¶

JIRA REFERENCE	SLOGAN
https://jira.o-ran-sc.org/browse/ODUHIGH-10	UE attach procedure with basic scheduling
https://jira.o-ran-sc.org/browse/ODUHIGH-188	Support for all short PRACH formats
https://jira.o-ran-sc.org/browse/ODUHIGH-191	Explore O1 interface
https://jira.o-ran-sc.org/browse/ODUHIGH-189	Integration with O-DU Low
https://jira.o-ran-sc.org/browse/ODUHIGH-184	UE UL Data path
https://jira.o-ran-sc.org/browse/ODUHIGH-185	UE DL Data path
https://jira.o-ran-sc.org/browse/ODUHIGH-186	Applying 64 QAM Modulation in DL
https://jira.o-ran-sc.org/browse/ODUHIGH-187	Applying 16 QAM Modulation in UL
https://jira.o-ran-sc.org/browse/ODUHIGH-190	Integration with VIAVI Software
https://jira.o-ran-sc.org/browse/ODUHIGH-214	get-AlarmList implementation on O1 interface
https://jira.o-ran-sc.org/browse/ODUHIGH-196	CM Support on O1 interface

Previous Releases ¶

JIRA REFERENCE	SLOGAN
https://jira.o-ran-sc.org/browse/ODUHIGH-1	F1-C enhancement
https://jira.o-ran-sc.org/browse/ODUHIGH-5	F1-U implementation
https://jira.o-ran-sc.org/browse/ODUHIGH-11	E2 implementation
https://jira.o-ran-sc.org/browse/ODUHIGH-9	Cell broadcast procedure
https://jira.o-ran-sc.org/browse/ODUHIGH-10	UE attach procedure till msg-4
https://jira.o-ran-sc.org/browse/ODUHIGH-8	FAPI interface implementation
https://jira.o-ran-sc.org/browse/ODUHIGH-27	RLC layer interface enhancements

Bug Corrections ¶

JIRA TICKETS:

NA

Deliverables ¶

Software Deliverables ¶

This release contains O-DU High code, along with test code in the form of CU stub, RIC stub and phy stub. Instructions to build and execute ODU, CU and RIC stub binaries are also present. All of the above can be found in the o-du/l2 repo.

Documentation Deliverables ¶

This release contains

README with instruction to build and execute binaries.
overview.rst
release-notes.rst
installation-guide.rst
user-guide.rst
api-docs.rst
developer-guide.rst

Known Limitations, Issues and Workarounds ¶

System Limitations ¶

Current code contains support only for below configuration:

[TDD] [Mu1] [100MHz]

[FDD] [Mu0] [ 20MHz]

Freuency Range = FR 1

DL/UL Modulation = QPSK

single UE.
This release implements a basic scheduler with fixed scheduling for single UE.
Cell broadcast is for SSB and SIB1 only.
FAPI files not in-line with SCF FAPI 1.0.5. O-DU High currently compatible with FAPI files provided by Intel.
Implementation of F1 reset is limited to intializing UE contexts.
E2 interface is limited to Traffic Steering Usecase.
Forming of RIC event trigger definition, RIC indication header and RIC indication message is unclear in the E2AP draft spec versions. Therefore, implementation does not contain accurate values. Contents of RIC indication message are mocked and triggered just once.
On the F1-U interface, UE, RB and tunnel configurations are static.
System runs on preconfigured values due to absence of CM support on O1 interface.
O-DU High has not been integrated with O-CU.(Using Radisys commercial CU as a test fixture)
Netconf TLS connection is not supported

Known Issues ¶

PDSCH DMRS must not be interleaved with PDSCH allocations.
PUSCH DMRS must not be interleaved with PUSCH allocations.
Frequency domain allocation in DCI is a bit map where:

As per spec : the most significant bit corresponds to the group of lowest frequency.

As per L1 : the least significant bit corresponds to the lowest frequency group.
Only Resource allocation type 1 (i.e RB allocation using Start RB and Number of RBs) is supported for PDSCH.
Only mapping type = 1 (i.e. Type A) supported for PDSCH.
L1 unable to process SIB1 with hardware accelerator enabled.

JIRA TICKETS:

NA

Workarounds ¶

O-DU High uses FAPI interface files provided by Intel and therefore, not completely in-line with SCF FAPI 1.0.5.

References ¶

ORAN-WG8.AAD.0-v02.05.00
ORAN WG3.E2AP v01.00
ORAN WG3.E2SM v01.00
3GPP 38.473-f60 v15.3
3GPP TS 38.211 v15.3
3GPP TS 38.212 v15.3
3GPP TS 38.213 v15.3
3GPP TS 38.214 v15.3
3GPP TS 38.321 v15.3
3GPP TS 38.331 v15.3
5G PHY FAPI Specification v1.0.5

O-DU High Installation Guide

O-DU High Installation Guide ¶

Abstract ¶

This document describes how to install O-DU High, it’s dependencies and required system resources.

Version history

Date	Ver.	Author	Comment
2021-07-07	2.0.0	Radisys, HCL Technologies Ltd.	D Release
2020-12-04	1.0.1	HCL Technologies Ltd.	Cherry Release
2020-12-04	1.0	Radisys	Cherry Release

Introduction ¶

This document describes the hardware and software requirements along with guidelines on how to install O-DU High.

The audience of this document is assumed to have good knowledge in RAN concepts and Linux system.

Preface ¶

O-DU High images can be built using the source code or corresponding docker images can be downloaded.

Hardware requirements ¶

Following minimum hardware requirements must be met for installation of O-DU High

HW Aspect	Requirement
# of servers	1
CPU	4
RAM	8G
Disk	500G
NICs	1

Software installation and deployment ¶

This section describes the installation of the O-DU High on the reference hardware.

Libraries ¶

Following libraries are required to compile and execute O-DU High:

GCC
- Ubuntu : sudo apt-get install -y build-essential
- CentOS : sudo yum groups mark install -y “Development Tools”
Ensure the version is 4.6.3 and above using
- gcc –version
LKSCTP
- Ubuntu : sudo apt-get install -y libsctp-dev
- CentOS : sudo yum install -y lksctp-tools-devel
PCAP:
- Ubuntu : sudo apt-get install -y libpcap-dev
- CentOS : sudo yum install -y libpcap-devel

Cloning code ¶

Create a folder to clone the O-DU High code into. The folder is hereafter referred to as <O-DU High Directory>.
Clone code into <O-DU High Directory>

git clone “https://gerrit.o-ran-sc.org/r/o-du/l2”

Setting up Netconf server (Only if O1 interface enabled)¶

Following steps are required to compile and run ODU with O1 interface enabled.

Create a new netconf user
Switch to root user or use sudo and run following commands
- Ubuntu :
  
  cd <O-DU High Directory>/l2/build/scripts
  
  sudo ./add_netconf_user.sh
Install Netconf libraries:
libssh, libyang, libnetconf2, sysrepo, netopeer2

Script is provided in the following folder to install these libraries
- Ubuntu :
  
  cd <O-DU High Directory>/l2/build/scripts
  
  sudo ./install_lib_O1.sh -c
Install the YANG modules and load initial configuration
Navigate to config folder and update the desired initial configuration
- Ubuntu :
  
  cd <O-DU High Directory>/l2/build/config
  
  Open the startup_config.xml and edit the desired IP and Port for CU, DU and RIC.
  
  Open the nacm_config.xml and edit the desired user name to provide the access to that user.
  
  Open the netconf_server_ipv6.xml and edit the desired netconf server configuration.
  
  Open the vesConfig.json and edit the details of VES collector.
  
  Open the netconfConfig.json and edit the details of Netopeer server.
  
  Install the yang modules and load initial configuration.
- Ubuntu :
  
  cd <O-DU High Directory>/l2/build/scripts
  
  sudo ./load_yang.sh
Start Netopeer2-server:
- Ubuntu :
  
  cd <O-DU High Directory>/l2/build/scripts
  
  sudo ./netopeer-server.sh start

Compilation ¶

Build O-DU High:
- Navigate to Build folder
  
  cd <O-DU High Directory>/l2/build/odu
- Clean O-DU High binary
  
  make clean_odu MACHINE=BIT64 MODE=FDD
- Compile O-DU High binary
  
  make odu MACHINE=BIT64 MODE=FDD
Build CU Stub :
- Navigate to Build folder
  
  cd <O-DU High Directory>/l2/build/odu
- Clean CU Stub binary
  
  make clean_cu NODE=TEST_STUB MACHINE=BIT64 MODE=FDD
- Compile CU Stub binary
  
  make cu_stub NODE=TEST_STUB MACHINE=BIT64 MODE=FDD
Build RIC Stub :
- Navigate to Build folder
  
  cd <O-DU High Directory>/l2/build/odu
- Clean RIC Stub binary
  
  make clean_ric NODE=TEST_STUB MACHINE=BIT64 MODE=FDD
- Compile RIC Stub binary
  
  make ric_stub NODE=TEST_STUB MACHINE=BIT64 MODE=FDD

Compilation with O1 interface enabled ¶

Build O-DU High:
- Navigate to Build folder
  
  cd <O-DU High Directory>/l2/build/odu
- Clean O-DU High binary
  
  make clean_odu MACHINE=BIT64 MODE=FDD O1_ENABLE=YES
- Compile O-DU High binary
  
  make odu MACHINE=BIT64 MODE=FDD O1_ENABLE=YES
Build CU Stub :
- Navigate to Build folder
  
  cd <O-DU High Directory>/l2/build/odu
- Clean CU Stub binary
  
  make clean_cu NODE=TEST_STUB MACHINE=BIT64 MODE=FDD O1_ENABLE=YES
- Compile CU Stub binary
  
  make cu_stub NODE=TEST_STUB MACHINE=BIT64 MODE=FDD O1_ENABLE=YES
Build RIC Stub :
- Navigate to Build folder
  
  cd <O-DU High Directory>/l2/build/odu
- Clean RIC Stub binary
  
  make clean_ric NODE=TEST_STUB MACHINE=BIT64 MODE=FDD O1_ENABLE=YES
- Compile RIC Stub binary
  
  make ric_stub NODE=TEST_STUB MACHINE=BIT64 MODE=FDD O1_ENABLE=YES

The above generated images can be found at:

O-DU High - <O-DU High Directory>/l2/bin/odu
CU Stub - <O-DU High Directory>/l2/bin/cu_stub
RIC Stub - <O-DU High Directory>/l2/bin/ric_stub

User Guide¶

This is the user guide for D release of O-DU/l2. Follow installation-guide to get all the dependencies ready.

A. Execution:
- I. Execution - On locally compiling O-DU High Source Code
- II. Execution - Using Docker Images
B. Pairwise testing with Intel O-DU Low:
C. Message Flow:
D. Health Check execution: get alarm-list

A. Execution:¶

I. Execution - On locally compiling O-DU High Source Code ¶

Assign virtual IP addresses as follows:
1. ifconfig <interface name>:ODU “192.168.130.81”
2. ifconfig <interface name>:CU_STUB “192.168.130.82”
3. ifconfig <interface name>:RIC_STUB “192.168.130.80”

PS: If O1 interface is enabled, IPs should match those configured in “startup_config.xml”: ( Refer Installation Guide - “Setting up Netconf server” )

Execute CU Stub:
1. Navigate to CU execution folder
  - cd <O-DU High Directory>/l2/bin/cu_stub
2. Run CU Stub binary
  - ./cu_stub
Execute RIC Stub:
1. Navigate to RIC execution folder
  - cd <O-DU High Directory>/l2/bin/ric_stub
2. Run RIC Stub binary
  - ./ric_stub
Execute O-DU High:
1. Navigate to ODU execution folder
  - cd <O-DU High Directory>/l2/bin/odu
2. Run ODU binary
  - ./odu

PS: CU stub and RIC stub must be run (in no particular sequence) before ODU.

II. Execution - Using Docker Images ¶

The call flow between O-DU High and CU Stub can be achieved by executing docker containers.

Pull the last built docker images:
- docker pull nexus3.o-ran-sc.org:10004/o-ran-sc/o-du-l2:4.0.1
- docker pull nexus3.o-ran-sc.org:10004/o-ran-sc/o-du-l2-cu-stub:4.0.1
Run CU Stub docker:
- docker run -it –privileged –net=host –entrypoint bash nexus3.o-ran-sc.org:10004/o-ran-sc/o-du-l2-cu-stub:4.0.1
- ./cu_stub
Run ODU docker:
- docker run -it –privileged –net=host –entrypoint bash nexus3.o-ran-sc.org:10004/o-ran-sc/o-du-l2:4.0.1
- ./odu

B. Pairwise testing with Intel O-DU Low:¶

This section describes the changes required in compilation and execution of O-DU High binaries to successfully integrate with Intel O-DU Low in timer mode.

I. Pre-requisites ¶

Install O-DU High as per installation-guide .

Clone O-DU Low code in <O-DU Low Directory> from

https://gerrit.o-ran-sc.org/r/admin/repos/o-du/phy and,

https://github.com/intel/FlexRAN

Install O-DU Low as per https://docs.o-ran-sc.org/projects/o-ran-sc-o-du-phy/en/latest/index.html .

II. Compilation ¶

Build ODU :

Create folder <O-DU High Directory>/l2/src/wls_lib. Copy wls_lib.h from <O-DU Low Directory>/phy/wls_lib/ to <O-DU High Directory>/l2/src/wls_lib.

Create folder <O-DU High Directory>/l2/src/dpdk_lib. Copy following files from <O-DU Low Directory>/dpdk-19.11/x86_64-native-linuxapp-gcc/include/ to <O-DU High Directory>/l2/src/dpdk_lib.

rte_branch_prediction.h

rte_common.h

rte_config.h

rte_dev.h

rte_log.h

rte_pci_dev_feature_defs.h

rte_bus.h

rte_compat.h

rte_debug.h

rte_eal.h

rte_os.h

rte_per_lcore.h

Navigate to build folder

cd <O-DU High Directory>/l2/build/odu

Build ODU Binary:

make odu PHY=INTEL_L1 MACHINE=BIT64 MODE=FDD

III. Execution ¶

Execute O-DU Low:

Setup environment:

cd <O-DU Low Directory>/phy/

source ./setupenv.sh

Run O-DU Low binary :

cd <O-DU Low Directory>/FlexRAN/l1/bin/nr5g/gnb/l1

To run in radio mode : ./l1.sh -xran

L1 is up when following prints are seen on console:

Non BBU threads in application

==================================================================

nr5g_gnb_phy2mac_api_proc_stats_thread: [PID: 8659] binding on [CPU 0] [PRIO: 0] [POLICY: 1]

wls_rx_handler (non-rt): [PID: 8663] binding on [CPU 0]

==================================================================

PHY>welcome to application console

Execute FAPI Translator:

Setup environment:

cd <O-DU Low Directory>/phy/

source ./setupenv.sh

Run FAPI translator binary:

cd <O-DU Low Directory>/phy/fapi_5g/bin/

./oran_5g_fapi –cfg=oran_5g_fapi.cfg

Execute CU Stub and RIC Stub:

Run steps in sections A.I.1 through A.I.3 .

Execute DU:

DU execution folder

cd <O-DU High Directory>/l2/bin/odu

Export WLS library path

export LD_LIBRARY_PATH=<O-DU Low Directory>/phy/wls_lib/lib:$LD_LIBRARY_PATH

Run ODU binary

./odu

C. Message Flow:¶

O-DU High opens WLS interface during bring up. Message exchanges can begin once the interface is ready. Following diagram shows P5 messages exchanged with O-DU Low in timer mode.

Figure 7 - O-DU High - O-DU Low Message Flow Diagram¶

Note: UL IQ-Sample request and response are needed by Intel O-DU Low in timer mode(testing mode) only. Code changes for these are guarded under INTEL_TIMER_MODE flag which can be enabled using compilation option “PHY_MODE=TIMER”, as mentioned in section B.I.1.d .

D. Health Check execution: get alarm-list ¶

To execute the get alarm-list flow, following steps are required to be executed:

Start Netconf netopeer client

Connect to the server with

user: netconf

pwd: netconf!

Send a Netconf get request for alarms xpath

Here are the steps as executed in the terminal

netopeer2-cli

> connect –login netconf

Interactive SSH Authentication

Type your password:

Password:

> get –filter-xpath /o-ran-sc-odu-alarm-v1:odu/alarms

DATA

<odu xmlns="urn:o-ran:odu:alarm:1.0">

<alarms>

<alarm>

<alarm-id>1009</alarm-id>

<alarm-text>cell id [1] is up</alarm-text>

<severity>2</severity>

<status>Active</status>

<additional-info>cell UP</additional-info>

</alarm>

</alarms>

</odu>

The XML output is a list of active alarms in the O-DU High system.

API-Docs¶

This is the API-docs for D relase o-du/l2.

Introduction
API Functions
Additional APIs

Introduction ¶

This document lists the APIs implemented between various modules of ODU-High and their functionality. These are in line with ORAN-WG8.AAD-v3.00.00, hereafter referred to as AAD Spec.

API Functions ¶

RLC-MAC Interface
- AAD Spec : section 9.2.1
1. RLC to MAC
  1. Data Transfer(DL) : Transfers DL data to MAC as per Section 9.2.1.1 of the AAD Spec
  2. Buffer Status Reporting(DL) : Reports DL data volume pending in the RLC entity, as per Section 9.2.1.4 of the AAD Spec
2. MAC to RLC
  1. Data Transfer(UL) : Transfers UL data to RLC as per Section 9.2.1.2 of the AAD Spec
  2. Schedule Result Reporting (DL) : Reports DL schedule result to RLC as per Section 9.2.1.3 of the AAD Spec
MAC-Scheduler Interface
- AAD Spec : section 9.2.2
1. MAC to Scheduler
  1. Air Interface Time : Sends timing information over air interface in terms of SFN and slo, as per Section 9.2.2.1.1 of the AAD Spec
  2. Cell Configuration Request : MAC provides SCH the cell configuration as per Section 9.2.2.2.1 of the AAD Spec
  3. Add UE Configuration Request : MAC provides SCH the configuration/capabilities of a UE as per Section 9.2.2.2.3 of the AAD Spec
  4. Modify UE Reconfiguration Request : MAC provides SCH the re-configuration of UE, also used to add/release/modify existing bearers, as per Section 9.2.2.2.4 of the AAD Spec
  5. RACH Indication : MAC receives the RACH Indication and share the contents with SCH as per Section 9.2.2.2.10 of the AAD Spec
  6. DL RLC Buffer Status Information : Reports data volume per LC when it is received at MAC as per Section 9.2.2.2.14 of the AAD Spec
  7. UL Buffer Status Report Indication : On reception and decoding of received BSR from the UE, MAC provides SCH buffer status report for UL scheduling, as per Section 9.2.2.2.16 of the AAD Spec
  8. UE Delete Request : MAC receives UE delete request and forwards the request to SCH as per Section 9.2.2.2.5 of the AAD spec.
  9. Cell Delete Request : MAC receives UE delete request and forwards the request to SCH as per Section 9.2.2.2.2 of the AAD spec.
2. Scheduler to MAC
  1. Cell Configuration Response - Response to cell configuration request from MAC, as per Section 9.2.2.3.1 of the AAD Spec
  2. UE Reconfiguration Response - Response to UE reconfiguration request from MAC, as per Section 9.2.2.3.3 of the AAD Spec
  3. DL Scheduling Information - Provides scheduling information for a given slot for downlink data, as per Section 9.2.2.3.5 of the AAD spec.
  4. UL Scheduling Information - Provides scheduled information for MAC to form the UL_TTI.request towards O-DU Low, as per Section 9.2.2.3.6 of the AAD Spec.
  5. RAR Information - Informs MAC of uplink scheduling and Msg3 scheduling information, as per Section 9.2.2.3.7 of the AAD Spec.
  6. Downlink Control Channel Information - Provides DCI scheduling information for a given slot on PDCCH, as per Section 9.2.2.3.8 of the AAD Spec
  7. Downlink Broadcast Allocation - Provides DCI and DL data scheduling information for SIB1 for a given slot for Broadcast Channel, as per Section 9.2.2.3.9 of the AAD Spec.
  8. UE Delete Response - Response to UE delete request from MAC, as per Section 9.2.2.3.4
  9. Cell Delete Response - Response to Cell delete response from MAC, as per Section 9.2.2.3.2
DU APP - MAC Interface
- AAD Spec : section 9.2.3
1. DU APP to MAC
  1. Cell Start - Commands MAC to start cell at L1 and to start broadcasting system information, as per Section 9.2.3.1 of the AAD Spec.
  2. UE Create Request - Adds UE information at MAC as per Section 9.2.3.3 of the AAD Spec.
  3. UE Reconfiguration Request - Reconfigure UE information for a UE already added at MAC, as per Section 9.2.3.5 of the AAD Spec.
  4. DL CCCH Indication - Sends DL CCCH Message to MAC to be sent to UE, as per Section 9.2.3.16 of the AAD Spec.
  5. Cell Stop - Commands MAC to stop cell at L1, as per Section 9.2.3.2 of the AAD spec.
  6. UE Delete Request - Deletes UE information at MAC as per Section 9.2.3.7 of the AAD Spec.
2. MAC to DU APP
  1. UE Create Response - Response to UE Create Request from DU Manager as per Section 9.2.3.4 of the AAD Spec.
  2. UE Reconfiguration Response - Response to UE Reconfiguration Request from DU APP as per Section 9.2.3.6 of the AAD Spec.
  3. UL-CCCH Indication - Sends the UL CCCH Message received from UE to DU APP as per Section 9.2.3.15 of AAD Spec.
  4. UE Delete Response - Response to UE Delete Request from DU Manager as per Section 9.2.3.8 of the AAD Spec.
DU APP - RLC Interface
- AAD Spec : section 9.2.4
1. DU APP to RLC
  1. UE Create - Adds UE associated RLC entity and related information as per Section 9.2.4.1 of the AAD Spec.
  2. UE Reconfiguration - Reconfigures the UE associated RLC entity previously added at RLC, as per Section 9.2.4.3 of the AAD Spec.
  3. DL RRC Message Transfer - Requests RLC to deliver RRC message from CU to the UE, as per Section 9.2.4.7 of the AAD Spec.
  4. UE Delete Request - Deletes UE associated RLC entity and related information as per Section 9.2.4.5 of the AAD Spec.
2. RLC to DU APP
  1. UE Create Response - Response to UE Create Request from DU APP, as per Section 9.2.4.3
  2. UE Reconfiguration Response - Response to UE Recofiguration Request from DU APP, as per Section 9.2.4.4
  3. UL RRC Message Tranfer - Delivers RRC Message from UE to CU as per Section 9.2.4.8 of the AAD spec.
  4. RRC Message Delivery Report - Informs DU Manager on failed/successful delivery of a DL RRC message to UE, as per Section 9.2.4.9 of the AAD Spec.
  5. UE Delete Response - Response to UE Delete Request from DU APP, as per section 9.2.4.6

Additional APIs ¶

DU APP - MAC Interface
1. DU APP to MAC
  1. Cell Configuration Request - Configures cell information at MAC
  2. Cell Delete Request - Deletes cell information at MAC
2. MAC to DU APP
  1. Cell Configuration Response - Response to Cell Configuration Request from DU APP
  2. Cell Delete Response - Response to Cell Delet request from DU APP
DU APP - RLC Interface
1. RLC to DU APP
  1. DL RRC Message Response - Informs DU APP if a DL RRC Message was successfuly processed at RLC and sent to MAC.
DU APP - O1 Interface
1. Bring cell up - Informs DU to bring a specific cell up
2. Bring cell down - Informs DU to bring specific cell up
3. Set the cell operational state - Sets the cell state to ACTIVE/INACTIVE
4. Raise a cell alarm - Raise an alarm when the cell is ACTIVE/INACTIV

Developer-Guide¶

Introduction ¶

This document provides information required to work on O-DU High code-base.

Coding Style ¶

O-DU High uses C languages. The coding guidelines followed are:

A new file should have License Header and Footer with exception of auto-generated files like files generated by ASN tool. Refer to the diagram below for License header.

Every block must be indented by 3 spaces.

Any header file must be included only in .c file, not in other header files.

The line width should not exceed more than 120 characters.

Figure 8 : License Header and Footer¶

O-DU High code ¶

Refer to O-DU High code-base at: https://gerrit.o-ran-sc.org/r/gitweb?p=o-du/l2.git;a=tree

Technical Details ¶

Below section references coding specifics of O-DU High components.

Thread Management ¶

Creation of Thread:¶

In O-DU High, multiple threads are created using below macro

ODU_CREATE_TASK (priority, stskId)

Creates a thread by declaring a thread id

Inputs

priority - Priority of the task

stskId - Thread Id

Setting a core affinity:¶

ODU_SET_THREAD_AFFINITY (tskId, mode, coreId, tskAssociatedTskId)

Sets the processor/core affinity for a thread based on the mode supplied by the caller.

Inputs

tskId - thread Id

mode - mode according to which the affinity is set

coreId - coreId to which the affinity has to be set

tskAssociatedTskId - thread Id of the associated layer

Returns ROK on success and RFAILED on failure

Registering Entities:¶

All logical entities in O-DU High must be registered into the database.

ODU_REG_TTSK (ent, inst, ttype, prior, initTsk, actvTsk)

Inputs

ent - Id of the entity to activate. Example: ENTDUAPP, ENTSCTP, ENTEGTP etc

Inst - Instance of the entity to activate. It distinguishes between multiple instances of the same entity on a given processor. Example: RLC_UL_INST (Instance id 0) and RLC_DL_INST (Instance id 1) belong to the same entity id, ENTRLC.

ttype - Type of entity

prior - Priority, ranges from 0(Highest) to 3(Lowest).

initTsk - Initialization function(xxActvInit) of the entity being registered gets invoked. Example: duActvInit initializes DU APP

actvTsk - This function(xxActvTsk) is responsible to receive any incoming message to that entity. Example: duActvTsk is triggerred when a message comes to DU APP

Attaching Entity to Thread:¶

Every entity must be attached to a thread to schedule its activation based on priority and incoming events. Any number of entities can be attached to a system task.

ODU_ATTACH_TTSK (ent, inst, stskId)

Inputs

ent - Entity Id of the task

inst - Instance Id of the task

stskId - Thread Id to use

Memory Management ¶

Configuration ¶

Memory is divided into multiple regions(identified by region id) and each region is divided into multiple pools(identified by pool id). The configurations are present in mt_ss.h and mt_ss.c at <rsys_directory>/l2/src/mt. Currently, the number of regions configured are 6 and each region has 5 pools.

Region and pool used by each layer is identified by following macros:

MAC - MAC_MEM_REGION and MAC_POOL

SCH - SCH_MEM_REGION and SCH_POOL

RLC UL - RLC_MEM_REGION_UL and RLC_POOL

RLC_DL - RLC_MEM_REGION_DL and RLC_POOL

DU APP - DU_APP_MEM_REGION and DU_POOL

Static Memory ¶

Macros are defined at each layer for static memory allocation/deallocation from that layer’s region and pool.

XX_ALLOC(bufPtr, size)

Allocates static buffer

Inputs:

bufPtr - pointer to store address of the memory allocated

size - size of memory to be allocated

Result:

If allocation is sucessful, butPtr stores memory address

If allocation fails, bufPtr is NULL.

XX_FREE(bufPtr, size)

Frees static buffer

Inputs:

bufPtr - pointer to memory to be freed

size - size of memory to be freed

Here, XX stands for various ODU-High entity i.e.

MAC - MAC_ALLOC & MAC_FREE

SCH - SCH_ALLOC & SCH_FREE

RLC - RLC_ALLOC & RLC_FREE

DU APP - DU_ALLOC & DU_FREE

Sharable Memory ¶

One of the methods of communication between layers is through sharabale memory. The sender will allocate sharable buffer from its own region and pool. This memory will be freed by receiving layer and returned back to sender’s region and pool.

XX_ALLOC_SHRABL_BUF(bufPtr, size)

Allocates sharable buffer

Inputs:

bufPtr - pointer to store address of the memory allocated

size - size of memory to be allocated

Result:

If allocation is sucessful, butPtr stores memory address

If allocation fails, bufPtr is NULL.

XX_FREE_SHRABL_BUF(region, pool, bufPtr, size)

Frees sharabale buffer

Inputs:

region - region where this buffer is allocated from

pool - pool where this buffer is allocated from

bufPtr - pointer to memory to be freed

size - size of memory to be freed

Here, XX stands for various ODU-High entities i.e.

MAC - MAC_ALLOC_SHRABL_BUF & MAC_FREE_SHRABL_BUF

SCH - Since scheduler communicates only with MAC and is tightly coupled, sharable buffers are not needed.

RLC - RLC_ALLOC_SHRABL_BUF & RLC_FREE_SHRABL_BUF

DU APP - DU_ALLOC_SHRABL_BUF & DU_FREE_SHRABL_BUF

Message Buffer ¶

A message is an ordered sequence of bytes. It stores both the control information and the data being communicated. Message buffers are allocated from dynamic memory.

ODU_GET_MSG_BUF(region, pool, mBuf)

Allocates memory for message buffer

Inputs:

region - region of sending layer

pool - pool of sending layer

mBuf - pointer to message buffer

ODU_PUT_MSG_BUF(mBuf)

Frees memory for message

Inputs:

mBuf - message pointer

WLS Memory ¶

WLS memory is allocated for message exchanges between O-DU High and O-DU Low.

LWR_MAC_ALLOC(ptr, size)

Allocates WLS memory block

Inputs:

ptr - pointer to store address of the memory allocated

size - size of memory to be allocated

Result:

If allocation is sucessful, ptr stores memory address

If allocation fails, ptr is NULL.

LWR_MAC_FREE(ptr, size)

Frees WLS block

Inputs:

bufPtr - pointer to memory to be freed

size - size of memory to be freed

Intra O-DU High Communication ¶

O-DU high entities communicate with each other through one of the following:

Types of Communication ¶

Direct API Call¶

Interface APIs invoked from one entity translate into direct function calls into the destination entity. Control returns to the calling entity after the called entity has completed processing the called function.

Macro to select this communication mode : ODU_SELECTOR_TC

Serialization¶

Interface API invoked from one entity is packed into a message and then sent to destination entity through system services. Control returns to the caller immediately after the message is posted, before the destination has seen or processed it. There are two serialization methods supported:

Pack/Unpack data

The interface data is packed into the message. Receiver will unpack this, parameter by parameter.

Macro to select this communication mode : ODU_SELECTOR_LC

Pack/Unpack pointer

The pointer to data is packed and sent. Receiver will unpack the pointer and directly access data at this address.

Macro to select this communication mode : ODU_SELECTOR_LWLC

Below figure depicts the mode of communication between various entities registered in O-DU High. Here,

TC stands for Direct API call

LC stands for Serialization by packing/unpacking of data

LWLC stands for Serialization by packing/unpacking of pointers

Figure 9: Mode of communication between O-DU High entities¶

Steps of Communication ¶

Fill Post Structure

Information needed by system services to route API to the destination layer is stored in post structure.

typedef struct pst

{

ProcId dstProcId; /* destination processor ID */

ProcId srcProcId; /* source processor ID */

Ent dstEnt; /* destination entity */

Inst dstInst; /* destination instance */

Ent srcEnt; /* source entity */

Inst srcInst; /* source instance */

Prior prior; /* priority */

Route route; /* route */

Event event; /* event */

Region region; /* region */

Pool pool; /* pool */

Selector selector; /* selector */

uint16_t spare1; /* spare for alignment */

} Pst;
Pack API into message

At sender, API is packed i.e. the data is stored into a message in ordered sequence of bytes. At receiver, the data is unpacked from the message and its corresponding handler is invoked.
1. If pst->selector is LC, each parameter is packed/unpacked one by one using one of the below.
  - oduPackUInt8(val, mBuf) - Packs 8-bits value(val) into message(mBuf)
  - oduUnpakcUInt8(val, mBuf) - Unpacks 8-bits from message(mBuf) and stores in val
  - oduPackUInt16(val, mBuf) - Packs 16-bits value(val) into message(mBuf)
  - oduUnpakcUInt16(val, mBuf) - Unpacks 16-bits from message(mBuf) and stores in val
  - oduPackUInt32(val, mBuf) - Packs 32-bits value(val) into message(mBuf)
  - oduUnpakcUInt32(val, mBuf) - Unpacks 16-bits from message(mBuf) and stores in val
  The sequence in which the parameters are unpacked must be reverse of the packing sequence.
2. If pst->selector is LWLC, pointer to the interface structure is packed/unpacked.
  - oduPackPointer(ptr, mBuf) - Packs pointer value(ptr) into message(mBuf)
  - oduUnpackPointer(ptr, mBuf) - Unpacks pointer value from message(mBuf) and stores in ptr
Post the message

Once the post information is filled and API is packed into a message, it is posted to destination using:
ODU_POST_TASK(pst, mBuf)
Inputs

pst - post structure mentioned above

mBuf - message

Below figure summarized the above steps of intra O-DU High communication

Figure 10 Communication between entities

Figure 10: Steps of Communication between O-DU High entities¶

Communication with Intel O-DU Low ¶

Intel O-DU Low communicates with O-DU High over WLS interface. Hence, Intel’s “wls_lib.h” library is required for using the following APIs for communication.

WLS_Open

void* WLS_Open(const char *ifacename, unsigned int mode, unsigned long long nWlsMemorySize)
1. Description
  - Opens the WLS interface and registers as instance in the kernel space driver.
  - Control section of shared memory is mapped to application memory.
2. Inputs:
  - ifacename - pointer to string with device driver name (/dev/wls)
  - mode - mode of operation (Master or Slave). Here, O-DU High acts as MASTER.
3. Returns pointer handle to WLS interface for future use by WLS functions
WLS_Ready

int WLS_Ready(void *h)
1. Description
  - Checks the state of remote peer of WLS interface
2. Inputs - handle of WLS interface
3. Returns 0 if peer is available i.e. one to one connection is established
WLS_Close

int WLS_Close(void *h)
1. Description
  - Closes the WLS interface and de-registers as instance in the kernel space driver
  - Control section of shared memory is unmapped form user space application
2. Input - handle of WLS interface to be closed
3. Returns 0 if operation is successful
WLS_Alloc

void* WLS_Alloc(void* h, unsigned int size)
1. Description
  - Allocates memory block for data exchange shared memory. Memory block is backed by huge pages.
  - Memory is allocated only once for L2, and divided into various regions.
2. Input
  - h - handle of WLS interface
  - size - size of memory block to allocate
3. Returns
  - Pointer to allocated memory block
  - NULL on memory allocation failure
WLS_Free

int WLS_Free(void* h, void* pMsg)
1. Description
  - Frees memory block for data exchanged on shared memory.
2. Input
  - h - handle of WLS interface
  - pMsg - pointer to WLS memory
3. Returns 0 if operation is sucessful
WLS_Put

int WLS_Put(void* h, unsigned long long pMsg, unsigned int MsgSize, unsigned short MsgTypeID, unsigned short Flags)
1. Description
  - Puts memory block (or group of blocks) allocated from WLS memory into the interface to transfer to remote peer
2. Input
  - h - handle of WLS interface
  - pMsg - pointer to memory block (physical address) with data to be transfered to remote peer
  - MsgSize - size of memory block to send (should be less than 2 MB)
  - MsgTypeID - application specific identifier of message type
  - Flags - Scatter/Gather flag if memory block has multiple chunks
3. Returns 0 if operation is successful
WLS_Check

int WLS_Check(void* h)
1. Description
  - Checks if there are memory blocks with data from remote peer
2. Input - handle of WLS interface
3. Returns number of blocks available for “get” operation
WLS_Wait

int WLS_Wait(void* h)
1. Description
  - Waits for new memory block from remote peer
  - Blocking call
2. Input - the handle of WLS interface
3. Returns number of blocks available for “get” operation
WLS_Get

unsigned long long WLS_Get(void* h, unsigned int *MsgSize, unsigned short *MsgTypeID, unsigned short *Flags)
1. Description
  - Gets memory block from interface received from remote peer.
  - Non-blocking operation
2. Input
  - h - handle of WLS interface
  - MsgSize - pointer to set size of memory block
  - MsgTypeID - pointer to application specific identifier of message type
  - Flags - pointer to Scatter/Gather flag if memory block has multiple chunks
3. Returns
  - Pointer to memory block (physical address) with data received from remote peer
  - NULL if error or no blocks available
WLS_WGet

unsigned long long WLS_WGet(void* h, unsigned int *MsgSize, unsigned short *MsgTypeID, unsigned short *Flags)
1. Description
  - Gets memory block from interface received from remote peer
  - It is a blocking operation and waits for next memory block from remote peer
2. Input
  - h - handle of WLS interface
  - MsgSize - pointer to set size of memory block
  - MsgTypeID - pointer to application specific identifier of message type
  - Flags - pointer to Scatter/Gather flag if memory block has multiple chunks
3. Returns
  - Pointer to memory block (physical address) with data received from remote peer
  - NULL if error or no blocks available
WLS_WakeUp

int WLS_WakeUp(void* h)
1. Description
  - Performs “wakeup” notification to remote peer to unblock “wait” operations pending
2. Input - handle of WLS interface
3. Returns 0 if operation is successful
WLS_VA2PA

unsigned long long WLS_VA2PA(void* h, void* pMsg)
1. Description
  - Converts virtual address (VA) to physical address (PA)
2. Input
  - h - handle of WLS interface
  - pMsg - virtual address of WLS memory block
3. Returns
  - Physical address of WLS memory block
  - NULL, if error
WLS_PA2VA

void* WLS_PA2VA(void* h, unsigned long long pMsg)
1. Description
  - Converts physical address (PA) to virtual address (VA)
2. Input
  - h - handle of WLS interface
  - pMsg - physical address of WLS memory block
3. Returns
  - Virtual address of WLS memory block
  - NULL, if error
WLS_EnqueueBlock

int WLS_EnqueueBlock(void* h, unsigned long long pMsg)
1. Description
  - Used by the Master to provide memory blocks to slave for next slave-to-master data transfer
2. Input
  - h - handle of WLS interface
  - pMsg - physical address of WLS memory block
3. Returns 0 if opertaion is successful
WLS_DequeueBlock

unsigned long long WLS_DequeueBlock(void* h)
1. Description
  - Used by the Master and Slave to get block from master-to-slave queue of available memory blocks
2. Input - handle of WLS interface
3. Returns
  - Physical address of WLS memory block
  - NULL, if error
WLS_NumBlocks

int WLS_NumBlocks(void* h)
1. Description
  - Returns number of current available block provided by the Master for new transfer of data from slave
2. Input - handle of WLS interface
3. Returns number of available blocks in slave to master queue

Additional Utility Functions ¶

ODU_START_TASK(startTime, taskId)
1. Gives current time through input parameter
2. Input
  - startTime - stores current time to be returned
  - taskId - task id of calling entity
ODU_STOP_TASK(startTime, taskId)
1. Calculates difference of start time and current time.
2. Input
  - startTime - start time of this task
  - taskId - taskId of calling entity
ODU_SET_PROC_ID(procId)
1. Processors are identified by processor identifiers (ProcId) that are globally unique. It sets the procId for the local processor. In O-DU High, procId is 0 (DU_PROC)
2. Inputs
  - procId - process id to be set
ODU_GET_PROCID()
1. Finds and returns the local processor id on which the calling task is running
2. Inputs
  - void
ODU_CAT_MSG(mbuf1, mbuf2, order)
1. Concatenates the given two message.
2. Inputs
  - mbuf1 - pointer to message buffer 1
  - mbuf2 - pointer to message buffer 2
  - order - order in which the messages are concatenated
ODU_GET_MSG_LEN(mBuf, lngPtr)
1. Determines length of the data contents of a message
2. Inputs
  - mBuf - pointer to the message buffer
  - lngPtr - pointer to store length value
ODU_EXIT_TASK()
1. Gracefully exits the process
2. Inputs
  - void
ODU_PRINT_MSG(mBuf, src, dst)
1. Prints information about message buffer.
2. Inputs
  - mBuf - pointer to the message buffer
  - src - source Id
  - dest - destination Id
ODU_REM_PRE_MSG(dataPtr, mBuf)
1. Removes one byte of data from the beginning of a message
2. Inputs
  - dataPtr - pointer to the location where one byte of data is placed
  - mBuf - pointer to the message buffer
ODU_REM_PRE_MSG_MULT(dst, cnt, mBuf)
1. Removes the specified number of bytes of data from the beginning of a message
2. Inputs
  - dst - pointer to the location where the data bytes are placed.
  - cnt - number of bytes to be removed from the message.
  - mBuf- pointer to the message.
ODU_REG_TMR_MT(ent, inst, period, func)
1. Registers timer function of an entity with system services
2. Inputs
  - ent - entity ID of task registering the timer.
  - inst - instance of task registering the timer.
  - period - period in system ticks between system service sccessive scheduling of the timer function in the entity
  - func - timer function.
ODU_SEGMENT_MSG(mBuf1, idx, mBuf2)
1. Segments a message into two messages at the specified index.
2. Inputs
  - mBuf1 - Message 1, original message to be segmented
  - idx - index in message 1 from which message 2 is created.
  - mBuf2 - pointer to message buffer 2 (new message).
ODU_ADD_PRE_MSG_MULT(src, cnt, dst)
1. Copies consecutive bytes of data to the beginning of a message
2. Inputs
  - src - source buffer
  - cnt - number of bytes
  - dst - destination message
ODU_ADD_PRE_MSG_MULT_IN_ORDER(src, cnt, dst)
1. Copies consecutive bytes of data to the beginning of a message and keeps the bytes order preserved
2. Inputs
  - src - source buffer
  - cnt - number of bytes
  - dst - destination message
ODU_ADD_POST_MSG_MULT(src, cnt, dst)
1. Copies consecutive bytes of data to the end of a message
2. Inputs
  - src - source buffer
  - cnt - number of bytes
  - dst - destination message
ODU_COPY_MSG_TO_FIX_BUF(src, srcIdx, cnt, dst, ccnt)
1. Copies data from a message buffer into a fixed buffer
2. Inputs
  - src - source message
  - srcIdx - start index of source buffer to be copied
  - cnt - number of bytes to be copied
  - dst - destination buffer
  - ccnt - number of bytes copied
ODU_COPY_FIX_BUF_TO_MSG(src, dst, dstIdx, cnt, ccnt)
1. Copies data from a fixed buffer to a message buffer
2. Inputs
  - src - source buffer
  - dst - destination message
  - dstIdx - index in destination message to starting copying bytes from
  - cnt - number of bytes to be copied
  - ccnt - number of bytes copied

O-DU High sends alarm messages in the following structure using Alarm Interface APIs.

Alarm Structure: typedef struct

{

MsgHeader msgHeader; /* Alarm action raise/clear */

EventType eventType; /* Alarm event type */

char objectClassObjectInstance[OBJ_INST_SIZE]; /* Name of object that raise/clear an alarm */

char alarmId[ALRM_ID_SIZE]; /* Alarm Id */

char alarmRaiseTime[DATE_TIME_SIZE]; /* Time when alarm is raised */

char alarmChangeTime[DATE_TIME_SIZE]; /* Time when alarm is updated */

char alarmClearTime[DATE_TIME_SIZE]; /* Time when alarm is cleared */

char probableCause[TEXT_SIZE]; /* Probable cause of alarm */

SeverityLevel perceivedSeverity; /* Severity level of alarm */

char rootCauseIndicator[TEXT_SIZE]; /* Root cause of alarm */

char additionalText[TEXT_SIZE]; /* Additional text describing alarm */

char additionalInfo[TEXT_SIZE]; /* Any additional information */

char specificProblem[TEXT_SIZE]; /* Any specific problem related to alarm */

}AlarmRecord;

O1 - Netconf Communication ¶

O1 communicates with the Netconf server using sysrepo and libyang APIs

Welcome to O-RAN SC O-DU-L2 Documentation¶

O-DU High Overview¶

O-DU High Architecture¶

O-DU High Thread Architecture¶

O-DU High Modules¶

DU APP¶

5G NR RLC¶

5G NR MAC¶

O-DU Utility and Common Functions¶

O1 Module¶

O-DU-High Interfaces¶

O-DU High functionality¶

Cell Up and Broadcast Procedure¶

UE Related Procedure¶

Closed Loop Automation Procedure¶

O1 Netconf get-alarm list procedure¶

OSC Testcases Supported¶

Release-Notes¶

User Guide¶

API-Docs¶

Developer-Guide¶

Direct API Call¶

Serialization¶