# Introduction to O-DU

:::info
**Resources**
* [TrainingCourse-ODU](https://univindonesia-my.sharepoint.com/:p:/g/personal/jonathan61_office_ui_ac_id/EZgWNTXM3JlMuxi3TJmCwjQBQCLb4tz03FuJ_fntp-prOg?rtime=cgz3fNAy20g)
* [Bryan's notes: Intro to O-DU](https://hackmd.io/gQjZmMPDRLWLji7oiYLqdw)
* [Bryan's notes: O-DU High Overview](https://hackmd.io/YxuEWSC5S4OzBUSSYDGTtg?view)
* [O-DU High](https://docs.o-ran-sc.org/projects/o-ran-sc-o-du-l2/en/latest/index.html)
:::

## Open-RAN Distributed Unit
Open Distributed Unit (O-DU) is a commercial off-the-shelf (COTS) edge servers that can function as **baseband processing unit to handles high PHY layer, MAC, and RLS layer** with network function virtualization (NFV) or Containers.


* The **COTS server will be installed firstly** using NFVI layer software. This will enable to use server resource, such as Compute, Storage, and Network, of virtual and shareable for VNFs Application.
* The vendor of **O-DU software** can be installed **on top of NFVI layer**.
* At the top, **orchestration software** is required to manage the underlying software and hardware.

## O-DU LOW
:::info
[Bryan's notes](https://hackmd.io/iKtte_usSbiGWago4I_Rgg?view)
[docs.o-ran](https://docs.o-ran-sc.org/projects/o-ran-sc-o-du-phy/en/latest/overview1.html)
:::

### Relations of ORAN O-CU, O-DU, and O-RU blocks for gNB implementation

- The O-DU Low uses FAPI interface by 5G FAPI TM module.
- The OFH-U and OFH-C interfaces are for FHI library and the functionality of the High-PHY.
- Between those network functions, L1 is used for communication on open interfaces.


- **Interface between O-DU Low and O-DU High:** Uses the FAPI interface based on the WG8 AAL specification.

### Functional Blocks of O-DU Low

## O-DU HIGH
- **O-DU High** implements the functional blocks of **L2 layers** of a 5G NR protocol stack in Stand Alone (SA) mode. The **L2 layers are NR RLC (Radio Link Control), NR MAC (Medium Access Control), and NR Scheduler**. These layers aid in the transmssion of traffic from the UE to the 5G Core network.
- 5G NR RLC layer provides services for transferring the control and data messages between MAC layer and O-CU (via DU App).
- 5G NR MAC layer uses the services of the NR physical layer (O-DU Low) to send and receive data on the various logical channels using multiplexing and demultiplexing techniques.
- 5G NR SCH layer allocates resources in UL and DL for cell and UE based procedures.

### ARCHITECTURE OF O-DU HIGH

#### 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 exchange on the F1-C interface and data messages on the F1-U interface.
* **Near RT RIC**: DU APP will interacts on E2 interface over SCTP.

#### DU APP Submodules
* **Config Handler**: Manages the configurations received on O1 interfaces and stores them within DU APP context.
* **DU Manager**: Handles all cell operations
* **UE Manager**: Handles UE contexts
* **SCTP Handler**: Responsible for establishing SCTP connections with O-CU, RIC on the F1AP and E2AP interfaces respectively.
* **EGTP Handler**: Responsible for establshing 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
* Provides services for transferring the control and data messages between MAC layer and O-CU by using 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
* Uses the services of the NR physical layer to send and receive data on the various logical channels.
* **5G NR MAC:** responsible for multiplexing and demultiplexing of the data
* **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 and all interactions of the 5G NR SCH is via the 5G NR MAC.

### O-DU HIGH UTILITY AND COMMON FUNCTION
These modules contain platform specific files and support O-DU High functionality and message exchanges.

### O1 Module

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.

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

### O-DU HIGH INTERFACES

**1. O-CU**: O-DU High communicates with O-CU on the F1AP interface. The control messages exchanges are on F1-C while data messages exchanges are on F1-U interfaces.
:::spoiler **F1AP messages on F1-C**
* 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
:::

**2. Near RT RIC**: O-DU High communicates with Near RT RIC on E2 interface.
:::spoiler **E2AP messages**
* Global Procedures
* E2 setup
* E2 Node Configuration Update
* Near RT RIC Functional Procedures
* RIC Subscription
* RIC Indication
:::

**3. O-DU Low**: O-DU High communicates with O-DU Low on the FAPI Interface.
:::spoiler **FAPI messages**
* 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
:::

**4. OAM:** O-DU High communicates with OAM on the O1 interface.

### O-DU HIGH FUNCTIONALITY

#### **1. CELL UP AND BROADCAST PROCEDURE**


**Steps:**
* 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.

#### **2. UE RELATED PROCEDURE**
O-DU High supports:
**All physicial channels**:
* PBCH (physical broadcast channel), used in E-UTRA to carry the RRC MIB (Master Information Block)
* PRACH (physical random access channel), used in the uplink of cellular systems for initial access requests from the users.
* PDCCH (physical downlink control channel, used to carry scheduling information to individual UEs
* PDSCH (physical downlink shared channel) is used to carry data from DSCH
* PUSCH (physical uplink shared channel), the main uplink channel and used to carry the UL-SCH (uplink shared channel) transport channel. It carries both signalling and user data, in addition to UCI.
* PUCCH (physical uplink control channel) can be used to acknowledge that data was received

**All control logical channels:**
* UL CCCH (common control channel) and DL CCCH, used for transmitting control informatiion to and from the user equipments or mobiles. The channel is used for initial access, i.e. those mobiles that **don't have a radio resource control, RRC connection**
* UL DCCH (dedicated control channel) and DL DCCH, used to carry dedicated control information between the UE or mobile an the network. It is used by the UE and the network **after a RRC connection has been established**.

**All control transport channels**
* BCH (broadcast channel), used in the downlink only for transmitting the BCCH system information and specifically the Master Information Block (MIB) information
* DL-SCH (downlink shared channel), the main transport channel used for transmission of downlink data in NR. DL-SCH is also used for transmission of the parts of the BCCH system information not mapped to the BCH. Each device has a DL-SCH per cell it is connected to.
* UL-SCH, the uplink counterpart to the DL-SCH
* RACH, shared channel used by wireless terminals to access the mobile network (TDMA/FDMA, and CDMA based network) for call set-up and bursty data transmission


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
* Security Mode Command
* Security Mode Complete
* Registraton Accept
* Registraton Complete
* Several NAS Message Exchanges
* RRC Reconfiguration
* RRC Reconfiguration Complete

#### **3. CLOSED LOOP AUTOMATION PROCEDURE**
**Steps:**
* 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)

#### **4. O1 NETCONF GET-ALARM LIST PROCEDURE**
**O-DU High health-check:**
* Health Status Retrieval scenario
* Enables a northbound client (SMO) to retrieve the health of the O-DU High based on the last self-check performed
* Alarm-list is provided as the response to the request via O1 Netconf interface

**Steps:**
* 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.
#### **5. NETWORK SLICING PROCEDURE**
**Steps:**
* 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.

#### **6. IDLE MODE PAGING PROCEDURE**
**Steps:**
* 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.
#### **7. INTER-DU HANDOVER WITHIN O-CU**
Assumption: UE is RRC connected with DU and PDU data session is active.

**Steps:**
* 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.
#### **8. DISCONTINUOUS RECEPTION (DRX)**
**Steps**
* 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.
* 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.
* 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.