1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
2 .. SPDX-License-Identifier: CC-BY-4.0
11 O-DU implements the functional blocks of L2 layer of a 5G NR protocol stack in SA(StandAlone) mode.
12 These layers primarily include NR MAC, NR Scheduler and NR RLC layers.
14 O-DU modules are developed as shown in the below diagram.
16 .. figure:: ODUArch.jpg
18 :alt: Figure 1 O-DU High Architecture Diagram
20 Figure 1 - O-DU High Architecture Diagram
22 O-DU High Thread Architecture
23 -------------------------------
25 As shown in Figure 1, there are multiple entities within O-DU High. Modules sharing a
26 given color belong to one thread. O-DU architecture can be defined at a thread
29 - Thread 1: O-DU thread
31 - Thread 2: DU APP inclusive of Config Handler, DU Manager, UE Manager, EGTP Handler and ASN.1 Codecs
33 - Thread 3: 5G NR RLC DL and MAC (inclusive of 5G NR SCH and Lower MAC)
35 - Thread 4: 5G NR RLC UL
37 - Thread 5: SCTP Handler
39 - Thread 6: Lower MAC Handler
43 --------------------------
47 This module configures and manages all the operations of O-DU.
48 It interfaces with external entities as follows:
50 - OAM: DU APP interacts with OAM on the O1 interface for configuration, alarms and performance management.
52 - 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.
54 - RIC: DU APP interacts with RIC on E2 interface over SCTP.
57 DU App submodules are as follows:
59 - Config Handler manages the configurations received on O1 interfaces and stores them within DU APP context.
61 - DU Manager handles all cell operations at the DU APP.
63 - UE Manager handles UE contexts at the DU APP.
65 - SCTP handler is responsible for establishing SCTP connections with O-CU, RIC on the F1AP and E2AP interfaces
68 - EGTP handler is responsible for establishing EGTP connection with O-CU for data message exchange on the F1-U
71 - ASN.1 Codecs contain ASN.1 encode/decode functions which are used for System information, F1AP and E2AP messages.
75 This module provides services for transferring the control and data messages
76 between MAC layer and O-CU (via DU App).
78 5G NR RLC UL and 5G NR RLC DL are the sub modules of this module that implement
79 uplink and downlink functionality respectively.
83 This module uses the services of the NR physical layer to send and receive data
84 on the various logical channels.
85 Functions of the 5G NR MAC module are as follows:
87 - 5G NR MAC is responsible for multiplexing and de-multiplexing of the data on various logical channels.
89 - 5G NR SCH schedules resources in UL and DL for cell and UE based procedures.
90 5G NR SCH is completely encapsulated within the 5G NR MAC i.e., all interactions of the 5G NR SCH is via the 5G NR MAC.
92 - Lower MAC interfaces between the MAC and the O-DU Low. It implements all the messages of FAPI
93 specification. It has a receiver thread to handle messages from L1.
96 O-DU Utility and Common Functions
97 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
98 These modules contain platform specific files and support O-DU High functionality and message exchanges.
104 .. figure:: ODU-O1-Arch.jpg
106 :alt: Figure 2 O1 Architecture
108 Figure 2 - O1 Architecture
110 As shown in figure 2 the O1 module in O-DU High runs a separate process and communicates with ODU-High process over a TCP interface. O1 module uses API calls for interacting with the Netconf server(Netopeer) and datastore(sysrepo) for providing the Netconf interface.
112 O1 architecture has following components:
114 - Netconf Manager: Subscribe to Netconf YANG modules and events. Register callback handler methods.
116 - Alarm Manager: Stores and manages(add/updated/delete) alarms.
118 - TCP server: Receives the alarm messages sent from O-DU High over TCP socket.
120 - TCP Client Alarm Interface : Integrates with O-DU High module and provides an interface for sending the alarm messages to O1 module over TCP socket.
122 - Netopeer server: Serves the northbound SMO/OAM Netconf requests.
126 ======================
129 This section describes the other modules that O-DU High interfaces with, as shown in below diagram.
131 .. figure:: O-DUHighInterfaces.jpg
133 :alt: O-DU High Interfaces
135 Figure 3 - O-DU High Interfaces
138 As shown in Figure 3, O-DU High interfaces with the following modules:
140 - O-CU: O-DU High communicates with O-CU on the F1AP interface. The control message exchanges are on F1-C while
141 data message exchanges are on F1-U interfaces. The below F1AP messages on F1-C are implemented, as per
142 3GPP 38.473-f60 v15.3:
144 - Interface Management
148 - gNB-DU Configuration Update
152 - UE Context Management
156 - RRC Message Transfer
158 - Initial UL RRC Message Transfer
160 - DL RRC Message Transfer
162 - UL RRC Message Transfer
164 - RRC Delivery Report
166 - Near RT RIC: O-DU High communicates with Near RT RIC on the E2 interface. The below E2AP messages are
167 implemented, as per ORAN WG3.E2AP v01.00:
173 - Near RT RIC Functional Procedures
179 - O-DU Low: O-DU High communicates with O-DU Low on the FAPI interface. The below FAPI messages are supported,
180 as per FAPI interface files shared by Intel:
182 - P5 messages - PHY mode control interface
184 - PARAM.request/PARAM.response
186 - CONFIG.request/CONFIG.response
194 - P7 messages - Main data path interface
214 - OAM: O-DU High communicates with OAM on the O1 interface.
218 O-DU High functionality
219 ========================
222 Cell Up and Broadcast Procedure
223 --------------------------------
225 This section describes the cell-up procedure within O-DU High.
227 .. figure:: CellUpAndBroadcast.png
229 :alt: Cell Up and Broadcast Procedure
231 Figure 4 - O-DU High Cell Up and Broadcast Procedure
234 As seen in the Figure 4,
235 - 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.
237 - The O-CU responds with F1 Setup Response. This message contains a list of cells which must be activated.
239 - The O-DU High scans the list of cells received and sends corresponding cell configurations to 5G NR MAC.
241 - 5G NR MAC, in-turn configures the 5G NR SCH. It also configures the O-DU Low via the Lower MAC module.
243 - On receiving the cell config response, DU APP sends a gNB DU Config Update towards the O-CU. The O-CU responds with
244 gNB DU Config Update ACK towards the O-DU High.
246 - The DU APP now exchanges F1 Reset message with the O-CU to initialize the UE contexts.
248 - 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
251 - On receiving START.request, O-DU Low begins to send slot indications towards 5G NR MAC via the lower MAC.
252 The frequency of these slot indications is determined by the numerology(Mu) supported.
253 5G NR MAC forwards these slot indications to the 5G NR SCH and DU APP modules.
255 - When the first slot indication reaches the DU APP, cell is marked as up.
257 - The 5G NR SCH, keeps tracking the SSB and SIB1 ocassions on receiving regular slot indications.
258 On detecting the relevant ocassion, 5G NR SCH schedules SSB/SIB1 and forwards the DL Scheduling Information to 5G NR MAC.
260 - The 5G NR MAC mutiplexes the PDU and sends SSB/SIB1 packets towards the O-DU Low through the Lower MAC.
265 -----------------------
268 The O-DU High supports
270 - All physical channels - PBCH, PRACH, PDCCH, PDSCH, PUSCH, PUCCH
272 - All control logical channels - UL CCCH, DL CCCH, UL DCCH, DL DCCH
274 - All control transport channels - BCH, UL-SCH, DL-SCH, RACH
276 The above channels are used to achieve the below messages:
278 - Cell broadcast of System Information which includes SSB and SIB1.
284 - Random Access Response
290 - UE attach signalling flow
294 - Registraton Request
296 - Security Mode Command
298 - Security Mode Complete
302 - Registraton Complete
304 - Several NAS Message Exchanges
306 - RRC Reconfiguration
308 - RRC Reconfiguration Complete
310 Figure 5 below depicts the above call flow, inclusive of all interfaces:
312 .. figure:: UeAttach.png
314 :alt: O-DU High UE Attach Flow
316 Figure 5 - UE Attach Flow
319 O1 Netconf get-alarm list procedure
320 -----------------------------------
322 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 ODU-High based on the last self-check performed. The alarm-list is provided as the response to the request via O1 Netconf interface.
325 .. figure:: ODU-O1-GetAlarmListFlow.jpg
327 :alt: Figure 6 O1 get alarm-list flow
329 Figure 6 - O1 get alarm-list flow
332 As seen in the Figure 6,
334 - On the cell state change from de-active to activate, ODU High process raises a cell up alarm message and sends it over the TCP socket using the TCP client Alarm Interface API.
336 - On other side a TCP server, running as a thread, in O1 module receives the cell up alarm message and it passes the alarm information to the Alarm Manager.
338 - Alarm Manager stores the alarm data in a list.
340 - 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 Netconf Manager, is invoked.
342 - The callback function fetches the alarm list from Alarm Manager and sends it back to the client (SMO/OAM) via Netconf interface.
344 OSC Testcases Supported
345 =========================
347 The O-DU High partially supports below use-cases: