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.

• 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.

5G NR SCH

• This module is completely encapuslated withing 5G NR MAC i.e. all interactions of the 5G NR SCH is via the 5G NR MAC.

• Schedules resources in UL and DL for cell and UE based procedures.

• SCH framework design supports plugging-in new scheduling algorithm easily. Refer to section “Scheduler Framework with plug-in support” in Developer-Guide document for details.

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

    • PAGING

  • 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 v02.00:

  • Global Procedures

    • E2 Setup

    • E2 Node Configuration Update

    • E2 Reset

  • 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, - If O1 interface is enabled, SMO sends cell configuration to DU APP. DU APP stores the configurations in its local database.

• If O1 interface is disabled, DU APP module uses static configuration.

• 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. If O1 is enabled, DU APP triggers an alarm to SMO to indicate the CELL is 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.

UE Related Procedure

The O-DU High supports

• All physical channels - PBCH, PRACH, PDCCH, PDSCH, PUSCH, PUCCH

• All control logical channels - UL CCCH, DL CCCH, UL DCCH, DL DCCH

• All control transport channels - BCH, UL-SCH, DL-SCH, RACH

The above channels are used to achieve the below messages:

• Cell broadcast of System Information which includes SSB and SIB1.

• RACH Procedure

  • RACH Indication

  • Random Access Response

  • RRC Setup Request

  • RRC Setup

• UE attach signalling flow

  • RRC Setup Complete

  • Registraton Request

  • NAS Authentication Request

  • NAS Authentication Response

  • NAS Security Mode Command

  • NAS Security Mode Complete

  • RRC Security Mode Command

  • RRC Security Mode Complete

  • Registraton Accept

  • Registraton Complete

  • RRC Reconfiguration

  • RRC Reconfiguration Complete

Figure 5 below depicts the above call flow, inclusive of all interfaces:

Figure 5 - UE Attach Flow

• UE Release Signalling flow

  • RRC Release

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

1. SMO commands ODU-High to bring the cell down via O1 interface.

2. 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.

3. 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.

4. 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.

5. Once all UEs are released, O-DU High sends STOP.Request to L1. L1 responds with stop indication.

6. 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.

7. 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.

Network Slicing procedure

This section describes the Network Slicing feature within O-DU High.

Figure 8 - Network Slicing flow

As seen in the Figure 8,

• Once the Cell is UP, Slice Configuration received from O1 to O-DU is processed. DU APP forwards the Slice Configuration Request towards MAC which is further forwarded to Scheduler.

• Scheduler stores the Slice Configuration in DB and sends the Slice Configuration Response for each Slice to MAC and further towards DU APP. Slice Configuration Procedure completes.

• Once a UE attaches and PDU session is established then RLC will periodically calculate the Slice Performance Metrics(UL and DL Throughput) for slices configured during UE Context Setup/Modification procedure.

• RLC sends the Consolidated Slice Metrics to DU APP at every 60 sec duration. This is further forwarded towards SMO/Non-RT RIC.

• SMO/Non-RT RIC analyses these metrics and may optimize the slice configuration(RRM Policies) for dedicated slice. This is received at MAC and Scheduler as Slice Reconfiguration Request from DU APP.

• Scheduler updates the received Slice Configuration in its DB and sends back the Slice Reconfiguration Response to MAC and further MAC forwards it to DU APP. Scheduler applies the optimized RRM policies for the dedicated slice.

Idle Mode Paging procedure

This section describes the Idle Mode Paging procedure within O-DU High.

Figure 9 - Idle Mode Paging flow

As seen in the Figure 9,

• When a Paging is received from O-CU and the Cell to be Paged is UP then DU APP will calculate Paging Frame(PF) and i_s(Index of Paging Ocassion/Slot) and groups the Paging of UEs falling on same PF/SFN together and stores in its Cell’s Databse.

• When a Slot Indication for SFN is received then DU APP extracts the Paging of all UEs whose PF is ahead by PAGING_DELTA and builds Paging RRC PDU. DU APP sends the same via DL PCCH Indication to MAC.

• MAC forwards to SCH as PAGING INDICATION.

• SCH stores the Page Message in its DB and when the SLOT_INDICATION for that SFN arrives, SCH performs scheduling and resource allocation for PDCCH (alongwith DCI 1_0 format) and PDSCH channels and sends to MAC through DL PAGING ALLOCATION message.

• MAC forwards the PAGE to PHY in TX_Data.Request.

Inter-DU Handover within O-CU

This section describes the handling of inter-DU handover of a UE within O-DU High.

Figure 10 - Inter_DU Handover call flow

Assumption: UE is RRC connected with DU and PDU data session is active.

• The UE sends Measurement Report message to the source O-DU. This message is sent from O-DU to O-CU in the UL RRC MESSAGE TRANSFER message over F1AP interface.

• Based on UE Measurement Report, O-CU makes a handover decision to another cell belonging to the target O-DU.

• The O-CU sends a UE CONTEXT MODIFICATION REQUEST message to source O-DU to query the latest configuration.

• The DU APP in source O-DU responds with a UE CONTEXT MODIFICATION RESPONSE message that includes latest full configuration information.

• The O-CU sends a UE CONTEXT SETUP REQUEST message to the target O-DU to create an UE context and setup one or more data bearers. The UE CONTEXT SETUP REQUEST message includes Hand-overPreparationInformation. At target O-DU, DU APP sends UE Create Request to MAC and RLC layers to create the UE context with radio resources and receives UE Create Response from the respective protocol layers.

• The target O-DU responds with a UE CONTEXT SETUP RESPONSE message if the target O-DU can admit resources for the handover.

• The O-CU sends a UE CONTEXT MODIFICATION REQUEST message to the source O-DU, which includes RRCReconfiguration message towards the UE. The O-CU also indicates the source O-DU to stop the data transmission for the UE.

• The source O-DU forwards the received RRCReconfiguration message to the UE and then sends the UE Reconfiguration Request to MAC/Scheduler and RLC layer and get the UE Reconfiguration Response from the respective protocol layers.

• The source O-DU responds to the O-CU with UE CONTEXT MODIFICATION RESPONSE message.

• UE triggers Random Access procedure at the target O-DU. This is a contention free random access if UE was informed about its dedicated RACH resources in RRC Reconfiguration message.

• Once Random Access procedure with target O-DU is complete, the UE responds to the target O-DU with a RRCReconfigurationComplete message.

• The target O-DU sends UL RRC MESSAGE TRANSFER message to O-CU to convey the received RRCReconfigurationComplete message.

• The downlink and uplink data packets are sent to/from the UE through the target O-DU.

• The O-CU sends UE CONTEXT RELEASE COMMAND message to the source O-DU.

• The source O-DU sends UE DELETE REQUEST to MAC/RLC layers to release the UE context and receives UE DELETE RESPONSE message.

• The source O-DU responds to O-CU with UE CONTEXT RELEASE COMPLETE message.

Inter-CU Handover (Xn-Based)

This section describes the handling of inter-CU handover of a UE over Xn interface.

Figure 11 - Xn-Based Inter-CU Handover call flow

Terminology:

• Source GNB : GNB to which UE is connected and will be handed over from .

• Source GNB DU : O-DU in source GNB

• Source GNB CU : O-CU in source GNB

• Target GNB : GNB to which UE will be handed over to.

• Target GNB DU : O-DU in target GNB

• Target GNB CU : O-CU in target GNB

• Xn Inteface : Interface between Source GNB CU and Target GNB CU

• UE : UE in handover from source GNB to target GNB

Assumptions:

• Xn setup is established between the two GNB

• UE is RRC connected with DU

• PDU data session is active.

Call Flow :

• UE sends Measurement Report message to source GNB. This message is sent from O-DU to O-CU in the UL RRC MESSAGE TRANSFER message over F1AP interface.

• Based on UE Measurement Report, O-CU makes handover decision to a cell belonging to another GNB. Hereafter, this GNB will be referred to as target GNB.

• Before initiating the handover procedure, source GNB CU sends a UE CONTEXT MODIFICATION REQUEST message to source GNB DU to query the latest configurations.

• The source GNB DU responds with UE CONTEXT MODIFICATION RESPONSE message that includes latest full configuration information.

• To start the handover, source GNB CU sends HANDOVER REQUEST to target GNB CU with UE configuration received from source GNB DU.

• Target GNB CU sends a UE CONTEXT SETUP REQUEST message to target GNB DU to create a UE context and setup one or more data bearers. The UE CONTEXT SETUP REQUEST message includes Hand-overPreparationInformation. At DU, DU APP sends UE Create Request to MAC and RLC layers to create the UE context with radio resources and receives UE Create Response from the respective protocol layers.

• The target GNB DU responds with UE CONTEXT SETUP RESPONSE message if it can admit resources for the handover.

• Consequetively, target GNB CU sends HANDOVER REQUEST ACKNOWLEDGE message to source GNB CU to proceed with handover.

• Now source GNB CU sends UE CONTEXT MODIFICATION REQUEST message to source GNB DU, which includes RRCReconfiguration message towards the UE. The CU also indicates the DU to stop the data transmission for the UE.

• Source GNB DU forwards received RRCReconfiguration message to the UE and then sends DOWNLINK DATA DELIVERY STATUS message to CU to inform about successful delivery of message to UE.

• Source GNB DU also sends UE Reconfiguration Request to MAC/Scheduler and RLC layers to stop data scheduling as requested by CU. Once all layers have responded with UE reconfiguration response, source GNB DU send UE CONTEXT MODIFICATION RESPONSE message to source GNB CU.

• Using the information received in RRC Reconfiguration message, UE triggers Random Access procedure towards target GNB DU. This is a contention free random access if UE receives dedicated RACH resources information in RRC Reconfiguration message.

• Once Random Access procedure with target GNB is complete, UE responds to target GNB DU with a RRCReconfigurationComplete message.

• The target GNB DU sends UL RRC MESSAGE TRANSFER message to CU to convey the received RRCReconfigurationComplete message. This completes the UE attach to target GNB.

• The downlink and uplink data packets are now sent to/from the UE through target GNB.

• Once UE is successfully handed over to target GNB, its CU sends UE CONTEXT RELEASE message to source GNB CU.

• Hence, source GNB CU sends UE CONTEXT RELEASE COMMAND message to the source GNB DU.

• DU releases UE context at all layers and responds to source GNB CU with UE CONTEXT RELEASE COMPLETE message.

Discontinuous reception (DRX)

This section describes the Discontinuous reception (DRX) feature within O-DU High.

Figure 12 - Discontinuous reception flow

• The connected mode DRX is used to improve UE’s battery power consumption. This allows UE to be active for a certain amount of time to monitor PDCCH. UE shall become active or inactive based on the DRX timers.

• When UE is created at O-DU during RRC connection setup procedure, DU APP forwards the default DRX configuration to MAC, who then passes it to SCH as part of UE configuration request. SCH stores these configuration and will use it to calculate the start time and expiry time of various DRX timers. But these timers will only start after UE is RRC connected.

• O-DU may receive modified DRX-configuration in UE CONTEXT SETUP REQUEST from O-CU. DU APP forwards it to MAC who forwards it to SCH as part of UE reconfiguration request. In this case, SCH will stop all DRX timers, re-calculate the start time and expiry time of various timers based on updated configuration and restart the drx-onDurationTimer.

• Along with long cycle, DRX in O-DU high also supports short cycle which is enabled if short cycle configuration is recived in UE CONTEXT SETUP REQUEST.

• DRX timers supported in ODU-High are drx-onDurationTimer, drx-InactivityTimer, drx-ShortCycleTimer, drx-HARQ-RTT-TimerDL, drx-RetransmissionTimerDL, drx-HARQ-RTT-TimerUL and drx-RetransmissionTimerUL.

• UE is active when any of the following timers is running: drx-onDurationTimer, drx-InactivityTimer, drx-RetransmissionTimerDL or drx-RetransmissionTimerUL, else the UE is considered as inactive.

• Initially, drx-onDurationTimer is started based on long cycle length. While drx-onDurationTimer or drx-InactivityTimer are running, UE becomes active to monitor PDCCH and send data in UL/DL. When drx-InactivityTimer expires, drx-ShortCycleTimer starts. While drx-ShortCycleTimer is running, drx-onDurationTimer is started based on short cycle length. Once drx-ShortCycleTimer expires, long cycle length is used again. Refer to figure 12 below for detailed working of these timers.

Figure 13 - onDurationTimer,InactivityTimer,ShortCycleTimer flow

• If HARQ is received/sent, drx-HARQ-RTT-TimerDL or drx-HARQ-RTT-TimerUL is started. On its expiry drx-RetransmissionTimerDL or drx-RetransmissionTimerUL will start. While it is running, UE becomes active for retransmission of data in DL/UL. Refer to figure 13 and 14 below for detailed working of these timers.

Figure 14 - DL Harq Retransmission Timers flow

Figure 15 - UL Harq Retransmission Timers flow

• If O-DU receives DRX configuration release indicator IE as a part of UE CONTEXT MODIFICATION REQUEST from O-CU, DU APP will forward this indicator to MAC which forwards it to SCH as part of UE reconfiguration request. In this case SCH stops all DRX timers, deletes DRX configuration and marks UE as active by default.

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 H Release of O-DU-L2.

Version history

Date	Ver.	Author	Comment
2023-05-15	8.0.0	Radisys	H release
2022-12-15	7.0.3	Radisys, HCL Technologies Ltd.	G release
2022-06-16	6.0.0	Radisys, HCL Technologies Ltd.	F release
2022-01-14	5.0.0	Radisys, HCL Technologies Ltd.	e-release
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

H- release

This release contains the following:

• Multi-Scheduling algorithm framework design

• Alignment to “O-RAN WG8 AAD v07.00” Specification

• Mobility mode Support (Inter-CU handover)

• Upgrade to E2AP v3.0 and implementation of E2 messages

  • E2 Setup failure

  • Reset Procedure

• End-to-end integration support

  • Testing with TM500 UE simulator to detect broadcast message

G- release

This release contains the following:

• Improvement of code coverage

• Discontinuous reception (DRX)

• Alignment of O-DU high with the latest AAD WG8 specification (above 80% complaint)

• End-to-end integration support

  • WLS memory management update aligned with latest odu-low (FlexRAN 21.11 intel L1)

  • Upgrade to the latest FAPI Interface and vendor-specific messages

  • Successfully tested broadcast message reception at L1

F- release

This release contains the following:

• HARQ framework support and scheduler enhancement to prioritize retransmission

• Upgrade to E2AP version 2.0

• Support for IDLE Mode Paging

• Mobility mode Support (Intra-CU handover)

• O1 Module

  • Alarm notification for cell down.

  • Added support for standard defined VES format in alarm notification and PM messages.

e-release

This release contains the following:

• Support for multiple bearers per UE

• Support for multiple UEs per cell. Maximum 3 UEs supported in this release.

• Enhancement of scheduler for round robin scheduling of UEs

• Enhancement of scheduler to allocate grid resources to UL/DL channels based on slice(RRM Policies), UE and logical channel configurations

• Support for Network slicing

  • Measures the Slice performance and periodically reports the slice performance statistics to O1.

  • Adjusting/Improving Slice performance via Slice Reconfiguration with optimized resource quota from SMO.

• O1 Module

  • Support for cell configuration over O1 interface.

  • Support for RRM policy configuration over O1 interface.

  • Support VES PM data stream for sending slice metrics parameters to SMO.

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

H release

Project	ODUHIGH
Repo/commit-ID	o-du/l2/ I790792e199edecd7932fb7dc89c167b231708a5f
Release designation	H release
Release date	2023-06-13
Purpose of the delivery	H release

G release

Project	ODUHIGH
Repo/commit-ID	o-du/l2/ I18c6f314f9a927ae49db92e4f9b0e4a3113f3bdb
Release designation	G release
Release date	2022-12-05
Purpose of the delivery	G release

F release

Project	ODUHIGH
Repo/commit-ID	o-du/l2/ Ice63cef7030a5c08820bcced7ea06467e2c8 820b
Release designation	F release
Release date	2022-06-16
Purpose of the delivery	F release

e-release

Project	ODUHIGH
Repo/commit-ID	o-du/l2/ I4b894c652ef3a3584670a9f26de87c2b2b3b d8f2
Release designation	e-release
Release date	2022-01-14
Purpose of the delivery	e-release

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:

H-release

JIRA REFERENCE	SLOGAN
https://jira.o-ran-sc.org/browse/ODUHIGH-463	Inter-CU Handover
https://jira.o-ran-sc.org/browse/ODUHIGH-488	Alignment to ORAN WG8 AAD v7.0 specification and Enhancement for Multi-scheduling alogrithm framework
https://jira.o-ran-sc.org/browse/ODUHIGH-510	E2 upgrade to v3.0 and enhancement
https://jira.o-ran-sc.org/browse/ODUHIGH-475	Integration of ODU-High with L1

G-release

JIRA REFERENCE	SLOGAN
https://jira.o-ran-sc.org/browse/ODUHIGH-461	Improvement of code coverage
https://jira.o-ran-sc.org/browse/ODUHIGH-462	Implementation of Discontinuous Reception(DRX)
https://jira.o-ran-sc.org/browse/ODUHIGH-464	Alignment to latest ORAN WG8 AAD specification
https://jira.o-ran-sc.org/browse/ODUHIGH-475	Integration of ODU-High with L1

F-release

JIRA REFERENCE	SLOGAN
https://jira.o-ran-sc.org/browse/ODUHIGH-402	Support for HARQ and scheduler enhancement to prioritize retransmission
https://jira.o-ran-sc.org/browse/ODUHIGH-404	Support for E2AP version 2.0
https://jira.o-ran-sc.org/browse/ODUHIGH-405	Support for Inter-DU Handover
https://jira.o-ran-sc.org/browse/ODUHIGH-406	Support for Idle Mode Paging
https://jira.o-ran-sc.org/browse/ODUHIGH-429	O1 Enhancements

e-release

JIRA REFERENCE	SLOGAN
https://jira.o-ran-sc.org/browse/ODUHIGH-351	Support for Multi bearers
https://jira.o-ran-sc.org/browse/ODUHIGH-352	Support for Multi UE
https://jira.o-ran-sc.org/browse/ODUHIGH-363	Network Slicing support
https://jira.o-ran-sc.org/browse/ODUHIGH-340	Resource allocation in time domain changes to meet flexible k0, k1 and k2 values
https://jira.o-ran-sc.org/browse/ODUHIGH-361	Support for cell configuration over O1 interface
https://jira.o-ran-sc.org/browse/ODUHIGH-395	Optimization, scaling and rework

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

• Current code is locally tested to support upto three UEs.

• NR-MAC supports Round Robin scheduling currently, however the framework provides support to plug-in any other scheduling algorthim easily.

• 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.

• Cell configuration is supported by CM on O1 interface. All other configurations are static.

• O-DU High has not been integrated with O-CU.(Using Radisys commercial CU as a test fixture)

• Netconf TLS connection is not supported

• Current code supports two Network Slices, One Default and other one Dedicated Slice.

• We have to manually download the 3GPP yang models and install.

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

1. ORAN-WG8.AAD.0-v07.00.00

2. O-RAN.WG5.C.1-v05.00

3. ORAN WG3.E2AP v03.00

4. 3GPP 38.473-f60 v15.3

5. 3GPP TS 38.211 v15.3

6. 3GPP TS 38.212 v15.3

7. 3GPP TS 38.213 v15.3

8. 3GPP TS 38.214 v15.3

9. 3GPP TS 38.321 v15.3

10. 3GPP TS 38.331 v15.3

11. 5G PHY FAPI Specification v1.0.5

12. 3GPP TS 28.541 Specfication V16.6

13. O-RAN WG1.O1-Interface v04.00

14. O-RAN WG1.OAM-Architecture v04.00

O-DU High Installation Guide

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

Version history

Date	Ver.	Author	Comment
2023-06-13	6.0.1	Radisys	H release
2022-12-15	5.0.1	Radisys, HCL Technologies Ltd.	G release
2022-06-16	4.0.0	Radisys, HCL Technologies Ltd.	F release
2022-01-14	3.0.0	Radisys, HCL Technologies Ltd.	e-release
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

    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 oamVesConfig.json and edit the details of OAM VES collector.

    Open the smoVesConfig.json and edit the details of SMO 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

• In case standard defined VES format is to be enabled (this step is optional):

  cd l2/src/o1/ves

  Enable the Macro “StdDef” in file VesUtils.h

  #define StdDef

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 H 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

1. 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” )

2. 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

3. 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

4. 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.

In case O1 is enabled and SMO is not available run section D to start the stack.

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:8.0.1

  • docker pull nexus3.o-ran-sc.org:10004/o-ran-sc/o-du-l2-cu-stub:

• 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:8.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:8.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 radio mode.

I. Pre-requisites

1. Install O-DU High as per installation-guide .

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

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

   2. https://github.com/intel/FlexRAN

3. 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

1. Build ODU :

   1. 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.

   2. 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

   3. Navigate to build folder

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

   4. Build ODU Binary:

      • make odu PHY=INTEL_L1 MACHINE=BIT64 MODE=FDD

III. Execution

1. Execute O-DU Low:

   1. Setup environment:

      • cd <O-DU Low Directory>/phy/

      • source ./setupenv.sh

   2. 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

2. Execute FAPI Translator:

   1. Setup environment:

      • cd <O-DU Low Directory>/phy/

      • source ./setupenv.sh

   2. Run FAPI translator binary:

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

      • ./oran_5g_fapi –cfg=oran_5g_fapi.cfg

3. Execute CU Stub and RIC Stub:

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

4. Execute DU:

   1. DU execution folder

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

   2. Export WLS library path

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

   3. 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 16 - 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. Push cell and slice configuration over O1 using netopeer-cli

When O-DU High is run with O1 enabled it waits for initial cell configuration to be pushed by SMO before starting the stack. In case the SMO is not available then these configurations can be pushed via netopeer-cli as follows:

$cd l2/build/config

$netopeer2-cli

> connect –login netconf

Interactive SSH Authentication

Type your password:

Password: netconf!

> edit-config –target candidate –config=cellConfig.xml

> OK

> commit

> OK

> edit-config –target candidate –config=rrmPolicy.xml

> OK

> commit

> OK

For pushing these configurations in subsequent runs please edit cellConfig.xml and rrmPolicy.xml and increment number in the <id> tag to a new value e.g.

<id>rrm-2</id

E. How to execute the Health Check using netopeer-cli : get alarm-list

In case the SMO is not available the alarm list can be checked using netopeer-cli as follows:

netopeer2-cli

> connect –login netconf

Interactive SSH Authentication

Type your password:

Password: netconf!

> 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 H release o-du/l2.

Introduction

This document tabulates the APIs Aligned(Implemented)/Not Implemented/Additional APIs between various modules of ODU-High and their functionality. These are in line with ORAN-WG8.AAD-v7.00.00, hereafter referred to as AAD Spec.

Note: DU APP module consist functionality related to F1 Handler and O1 Handler

API Table

Interface	API	Status	Section	Remark
SMO-OAM & DU APP	Cell Configuration	Aligned	11.2.1.1
	Slice Configuration	Aligned	11.2.1.2
	Bring Cell Up	Additional API		Notify DU to bring specific cell up
	Bring Cell Down	Additional API		Notify DU to bring specific cell down
	Slice PM	Additional API		DU APP sends PM for all Slices every 60s
	Raise Cell Alarm	Additional API		DU APP alarms during cell state change
	Set the cell operational state	Additional API		DU APP inform cell state[ACTIVE/INACTIVE]
RLC & MAC	DL Transfer	Aligned	11.2.3.1
	UL Transfer	Aligned	11.2.3.2
	Schedule Result Reporting(DL)	Aligned	11.2.3.3
	Buffer Status Report(UL)	Aligned	11.2.3.4
MAC to SCH	Air Interface Time	Aligned	11.2.4.1.1
	Cell Configuration Request	Aligned	11.2.4.2.1
	Cell Delete Request	Aligned	11.2.4.2.2
	Slice Configuration Request	Aligned	11.2.4.2.3
	Slice Reconfiguration Request	Aligned	11.2.4.2.4
	Add UE Configuration Request	Aligned	11.2.4.2.5
	UE Reconfiguration Request	Aligned	11.2.4.2.6
	Delete UE Request	Aligned	11.2.4.2.7
	DL HARQ Indication	Aligned	11.2.4.2.8
	UL Harq Indication(CRC)	Aligned	11.2.4.2.9
	UL Channel Quality Information	Not Implemented	11.2.4.2.10
	DL Channel Quality Information	Not Impelemented	11.2.4.2.11
	RACH Indication Contents	Aligned	11.2.4.2.12
	Paging Indication Contents	Aligned	11.2.4.2.13
	RACH Resource Request	Aligned	11.2.4.2.14
	RACH Resource Release	Aligned	11.2.4.2.15
	DL RLC Buffer Status Info	Aligned	11.2.4.2.16
	Scheduling Request Indication	Aligned	11.2.4.2.17
	UL Buffer Status Report Ind	Aligned	11.2.4.2.18
	Power Headroom Indication	Aligned	11.2.4.2.19
SCH to MAC	Cell Configuration Response	Aligned	11.2.4.3.1
	Cell Delete Response	Aligned	11.2.4.3.2
	Slice Configuration Response	Aligned	11.2.4.3.3
	Slice ReConfiguration Response	Aligned	11.2.4.3.4
	UE Configuration Response	Aligned	11.2.4.3.5
	UE ReConfiguration Response	Aligned	11.2.4.3.6
	UE Delete Response	Aligned	11.2.4.3.7
	DL Scheduling Information	Aligned	11.2.4.3.8
	UL Scheduling Information	Aligned	11.2.4.3.9
	RAR Information	Not Required	11.2.4.3.10	Included in DL Scheduling Info
	Downlink Control Channel Info	Not Required	11.2.4.3.11	Included in DL Scheduling Info
	Downlink Broadcast Allocation	Not Required	11.2.4.3.12	Included in DL Scheduling Info
	Downlink Paging Allocation	Aligned	11.2.4.3.13
	HARQ Process Release	Additional API		SCH indicates MAC to release a HARQ process in case a positive acknowledement is received or achieved maximum retrans.
	RACH Resource Response	Additional API		Response to RACH Resource Request for dedicated resource for CF-RA
DU APP & MAC	Cell Start	Aligned	1.1.1.1
	Cell Stop	Aligned	1.1.1.2
	Cell Configuration Request	Additional API		Configures cell information at MAC.
	Cell Configuration Response	Additional API		Response to cell Cfg Req from DUAPP
	Cell Delete Request	Additional API		Deletes cell information at MAC.
	Cell Delete Response	Additional API		Response to Cell Del request from DU APP
	Slice Configuration Request	Additional API		Configures Slice at MAC
	Slice ReConfiguration Request	Additional API		ReConfigures Slice at MAC
	Slice Configuration Response	Additional API		Response to Slice Cfg req from DU APP
	Slice ReConfiguration Response	Additional API		Response to Slice ReCfg req from DU APP
	UE Create Request	Aligned	1.1.1.3
	UE Create Response	Aligned	1.1.1.4
	UE Reconfiguration Request	Aligned	1.1.1.5
	UE Reconfiguration Response	Aligned	1.1.1.6
	UE Delete Request	Aligned	1.1.1.7
	UE Delete Response	Aligned	1.1.1.8
	RACH Resource Request	Aligned	1.1.1.9
	RACH Resource Response	Aligned	1.1.1.10
	RACH Resource Release	Aligned	1.1.1.11
	UE Reset Request	Not Implemented	1.1.1.12
	UE Reset Response	Not Implemented	1.1.1.13
	UE Sync Status Indication	Not Implemented	1.1.1.14
	UL CCCH Indication	Aligned	1.1.1.15
	DL CCCH Indication	Aligned	1.1.1.16
	DL PCCH Indication	Aligned	1.1.1.17
	DL Broadcast Request	Not Implemented	1.1.1.18
	Slot Indication	Additional API		Indication about the ongoing SFN and Slot information to DU APP
DU APP & RLC	UE Create	Aligned	11.2.5.1
	UE Create Response	Aligned	11.2.5.2
	UE Reconfiguration	Aligned	11.2.5.3
	UE Reconfiguration Response	Aligned	11.2.5.4
	UE Delete	Aligned	11.2.5.5
	UE Delete Response	Aligned	11.2.5.6
	DL-RRC Message Transfer	Aligned	11.2.5.7
	UL-RRC Message Transfer	Aligned	11.2.5.8
	UL-RRC Message Delivery Report	Aligned	11.2.5.9
	RLC Max Retransmission Reached	Not Implemented	11.2.5.10
	UL-RLC Re-establishment Request	Not Implemented	11.2.5.11
	UL-RLC Re-establshment Response	Not Implemented	11.2.5.12
	DL RRC Message Response	Additional API		Informs DU APP if a DL RRC Message was successfuly procesed at RLC & sent to MAC
	DL User Data	Additional API		DL user data exchanged from DUAPP to RLC
	UL User Data	Additional API		UL user data exchanged from RLC to DUAPP
	Slice Performance Metrics	Additional API		Performance Metrics informed to DUAPP every 60sec for every slice configured

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:

1. 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.

2. Every block must be indented by 3 spaces.

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

4. The line width should not exceed more than 120 characters.

Figure 17 : 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)

1. Creates a thread by declaring a thread id

2. Inputs

   • priority - Priority of the task

   • stskId - Thread Id

Setting a core affinity:

ODU_SET_THREAD_AFFINITY (tskId, mode, coreId, tskAssociatedTskId)

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

2. 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

3. 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)

1. 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)

1. 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)

1. Allocates static buffer

2. Inputs:

   • bufPtr - pointer to store address of the memory allocated

   • size - size of memory to be allocated

3. Result:

   • If allocation is sucessful, butPtr stores memory address

   • If allocation fails, bufPtr is NULL.

XX_FREE(bufPtr, size)

1. Frees static buffer

2. 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)

1. Allocates sharable buffer

2. Inputs:

   • bufPtr - pointer to store address of the memory allocated

   • size - size of memory to be allocated

3. Result:

   • If allocation is sucessful, butPtr stores memory address

   • If allocation fails, bufPtr is NULL.

XX_FREE_SHRABL_BUF(region, pool, bufPtr, size)

1. Frees sharabale buffer

2. 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)

1. Allocates memory for message buffer

2. Inputs:

   • region - region of sending layer

   • pool - pool of sending layer

   • mBuf - pointer to message buffer

ODU_PUT_MSG_BUF(mBuf)

1. Frees memory for message

2. 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)

1. Allocates WLS memory block

2. Inputs:

   • ptr - pointer to store address of the memory allocated

   • size - size of memory to be allocated

3. Result:

   • If allocation is sucessful, ptr stores memory address

   • If allocation fails, ptr is NULL.

LWR_MAC_FREE(ptr, size)

1. Frees WLS block

2. 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:

1. 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

2. 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 18: Mode of communication between O-DU High entities

Steps of Communication

1. 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;

2. 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

3. 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)

   1. Inputs

      • pst - post structure mentioned above

      • mBuf - message

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

Figure 19: 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.

1. WLS_Open

   void* WLS_Open(const char *ifacename, unsigned int mode, uint64_t *nWlsMacMemorySize, uint64_t *nWlsPhyMemorySize)

   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.

      • nWlsMacMemorySize - returns the value of WLS MAC memory Size as O-DU High acts as MASTER

      • nWlsPhyMemorySize - returns the value of WLS PHY memory Size as O-DU High acts as MASTER

   3. Returns pointer handle to WLS interface for future use by WLS functions

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

Scheduler Framework with plug-in support

5G NR SCH module is encapsulated within 5G NR MAC of ODU-High. Any communication to/from SCH will happen only through MAC. The scheduler framework in ODU-High provides support to plug-in multiple scheduling algorithms easily.

Design

Figure 20: 5G NR Scheduler Framework Design

• The code for scheduler has been divided into 2 parts i.e. the common APIs and scheduler-specific APIs.

• Any code (structure/API) which is specific to a scheduling algorithm must be within scheduler-specific files such as sch_rr.c and sch_rr.h for round-roubin scheduler.

• Function pointers are used to identify and call APIs belonging to the scheduling algorithm in use at any given point in time.

• All supported scheduling algorithm are listed in SchType enum in sch.h file.

• All function pointers are declared in SchAllApis structure in sch.h

• For each scheduling algorithm, function pointers must be initialised to scheduler-specific APIs during scheduler initialisation.

Call Flow

• In any call flow, a common API calls the scheduler-specific API using function pointer and its output is returned back to the common API, which will be further processed and communicated to MAC.

Figure 21: Example of a call flow in multi-scheduling algorithm framework

Additional Utility Functions

1. 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

2. 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

3. 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

4. ODU_GET_PROCID()

   1. Finds and returns the local processor id on which the calling task is running

   2. Inputs

      • void

5. 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

6. 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

7. ODU_EXIT_TASK()

   1. Gracefully exits the process

   2. Inputs

      • void

8. 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

9. 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

10. 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.

11. 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.

12. 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).

13. 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

14. 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

15. 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

16. 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

17. 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

O1 Module

Coding Style

O1 uses GNU C++ language.

ODU - O1 Communication

O1 module runs as a thread in O-DU High.

Alarm communication between the threads happen on a Unix socket.

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

• Index

• Module Index

• Search Page