docs/overview.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. SPDX-License-Identifier: CC-BY-4.0
   3
   4
   5 O-DU High Overview
   6 *********************
   7
   8 O-DU High Architecture
   9 ======================
  10
  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.
  13
  14 O-DU modules are developed as shown in the below diagram.
  15
  16 .. figure:: ODUArch.jpg
  17   :width: 600
  18   :alt: Figure 1 O-DU High Architecture Diagram
  19
  20   Figure 1 - O-DU High Architecture Diagram
  21
  22 O-DU High Thread Architecture
  23 -------------------------------
  24
  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
  27 level as follows:
  28
  29 - Thread 1: O-DU thread
  30
  31 - Thread 2: DU APP inclusive of Config Handler, DU Manager, UE Manager, and ASN.1 Codecs
  32
  33 - Thread 3: 5G NR RLC DL and MAC (inclusive of 5G NR SCH and Lower MAC)
  34
  35 - Thread 4: 5G NR RLC UL
  36
  37 - Thread 5: SCTP Handler
  38
  39 - Thread 6: Lower MAC Handler
  40
  41 - Thread 7: EGTP Handler
  42
  43 - Thread 8: O1
  44
  45 O-DU High Modules
  46 --------------------------
  47
  48 DU APP
  49 ^^^^^^^^^^^^^^^^^^
  50 This module configures and manages all the operations of O-DU.
  51 It interfaces with external entities as follows:
  52
  53 - OAM:  DU APP interacts with OAM on the O1 interface for configuration, alarms and performance management.
  54
  55 - 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.
  56
  57 - RIC: DU APP interacts with RIC on E2 interface over SCTP.
  58
  59
  60 DU App submodules are as follows:
  61
  62 - Config Handler manages the configurations received on O1 interfaces and stores them within DU APP context.
  63
  64 - DU Manager handles all cell operations at the DU APP.
  65
  66 - UE Manager handles UE contexts at the DU APP.
  67
  68 - SCTP handler is responsible for establishing SCTP connections with O-CU, RIC on the F1AP and E2AP interfaces
  69   respectively.
  70
  71 - EGTP handler is responsible for establishing EGTP connection with O-CU for data message exchange on the F1-U
  72   interface.
  73
  74 - ASN.1 Codecs contain ASN.1 encode/decode functions which are used for System information, F1AP and E2AP messages.
  75
  76 5G NR RLC
  77 ^^^^^^^^^^^^^^^^^^
  78 This module provides services for transferring the control and data messages
  79 between MAC layer and O-CU (via DU App).
  80
  81 5G NR RLC UL and 5G NR RLC DL are the sub modules of this module that implement
  82 uplink and downlink functionality respectively.
  83
  84 5G NR MAC
  85 ^^^^^^^^^^^^^^^^^^
  86 This module uses the services of the NR physical layer to send and receive data
  87 on the various logical channels.
  88 Functions of the 5G NR MAC module are as follows:
  89
  90 - 5G NR MAC is responsible for multiplexing and de-multiplexing of the data on various logical channels.
  91
  92 - 5G NR SCH schedules resources in UL and DL for cell and UE based procedures.
  93   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.
  94
  95 - Lower MAC interfaces between the MAC and the O-DU Low. It implements all the messages of FAPI
  96   specification. It has a receiver thread to handle messages from L1.
  97
  98
  99 O-DU Utility and Common Functions
 100 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 101 These modules contain platform specific files and support O-DU High functionality and message exchanges.
 102
 103
 104 O1 Module
 105 ^^^^^^^^^^
 106
 107 .. figure:: ODU-O1-Arch.jpg
 108   :width: 554
 109   :alt: Figure 2 O1 Architecture
 110
 111   Figure 2 - O1 Architecture
 112
 113 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.
 114
 115 O1 architecture has following components:
 116
 117 - Netconf Session Handler: Subscribe to Netconf YANG modules and events. Register callback handler methods.
 118
 119 - VES Agent : Sends the VES events to SMO
 120
 121 - Alarm Manager: Stores and manages(add/updated/delete) alarms.
 122
 123 - Alarm Interface : Provides an interface to O-DU High threads for sending the alarm messages to O1 module over Unix socket.
 124
 125 - Config Interface : Interface to handle the configurations sent from SMO to the stack
 126
 127 - Netopeer server: Serves the northbound SMO/OAM Netconf requests.
 128
 129
 130 O-DU-High Interfaces
 131 ======================
 132
 133
 134 This section describes the other modules that O-DU High interfaces with, as shown in below diagram.
 135
 136 .. figure:: O-DUHighInterfaces.jpg
 137   :width: 600
 138   :alt: O-DU High Interfaces
 139
 140   Figure 3 - O-DU High Interfaces
 141
 142
 143 As shown in Figure 3, O-DU High interfaces with the following modules:
 144
 145 - O-CU: O-DU High communicates with O-CU on the F1AP interface. The control message exchanges are on F1-C while
 146   data message exchanges are on F1-U interfaces. The below F1AP messages on F1-C are implemented, as per
 147   3GPP 38.473-f60 v15.3:
 148
 149   - Interface Management
 150
 151     - F1 Setup
 152
 153     - gNB-DU Configuration Update
 154
 155     - F1 Reset
 156
 157   - UE Context Management
 158
 159     - UE Context Setup
 160
 161     - UE Context Modification
 162
 163     - UE Context Release
 164
 165   - RRC Message Transfer
 166
 167     - Initial UL RRC Message Transfer
 168
 169     - DL RRC Message Transfer
 170
 171     - UL RRC Message Transfer
 172
 173     - RRC Delivery Report
 174
 175 - Near RT RIC: O-DU High communicates with Near RT RIC on the E2 interface. The below E2AP messages are
 176   implemented, as per ORAN WG3.E2AP v01.00:
 177
 178   - Global Procedures
 179
 180     - E2 Setup
 181
 182   - Near RT RIC Functional Procedures
 183
 184     - RIC Subscription
 185
 186     - RIC Indication
 187
 188 - O-DU Low: O-DU High communicates with O-DU Low on the FAPI interface. The below FAPI messages are supported,
 189   as per FAPI interface files shared by Intel:
 190
 191   - P5 messages - PHY mode control interface
 192
 193     - PARAM.request/PARAM.response
 194
 195     - CONFIG.request/CONFIG.response
 196
 197     - START.request
 198
 199     - STOP.request
 200
 201     - STOP.indication
 202
 203   - P7 messages - Main data path interface
 204
 205     - DL_TTI.request
 206
 207     - UL_TTI.request
 208
 209     - SLOT.indication
 210
 211     - UL_DCI.request
 212
 213     - TX_Data.request
 214
 215     - RX_Data.indication
 216
 217     - CRC.indication
 218
 219     - UCI.indication
 220
 221     - RACH.indication
 222
 223 - OAM: O-DU High communicates with OAM on the O1 interface.
 224
 225
 226
 227 O-DU High functionality
 228 ========================
 229
 230
 231 Cell Up and Broadcast Procedure
 232 --------------------------------
 233
 234 This section describes the cell-up procedure within O-DU High.
 235
 236 .. figure:: CellUpAndBroadcast.png
 237   :width: 720
 238   :alt: Cell Up and Broadcast Procedure
 239
 240   Figure 4 - O-DU High Cell Up and Broadcast Procedure
 241
 242
 243 As seen in the Figure 4,
 244 - 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.
 245
 246 - The O-CU responds with F1 Setup Response. This message contains a list of cells which must be activated.
 247
 248 - The O-DU High scans the list of cells received and sends corresponding cell configurations to 5G NR MAC.
 249
 250 - 5G NR MAC, in-turn configures the 5G NR SCH. It also configures the O-DU Low via the Lower MAC module.
 251
 252 - On receiving the cell config response, DU APP sends a gNB DU Config Update towards the O-CU. The O-CU responds with
 253   gNB DU Config Update ACK towards the O-DU High.
 254
 255 - The DU APP now exchanges F1 Reset message with the O-CU to initialize the UE contexts.
 256
 257 - 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
 258   Low.
 259
 260 - On receiving START.request, O-DU Low begins to send slot indications towards 5G NR MAC via the lower MAC.
 261   The frequency of these slot indications is determined by the numerology(Mu) supported.
 262   5G NR MAC forwards these slot indications to the 5G NR SCH and DU APP modules.
 263
 264 - When the first slot indication reaches the DU APP, cell is marked as up.
 265
 266 - The 5G NR SCH, keeps tracking the SSB and SIB1 ocassions on receiving regular slot indications.
 267   On detecting the relevant ocassion, 5G NR SCH schedules SSB/SIB1 and forwards the DL Scheduling Information to 5G NR MAC.
 268
 269 - The 5G NR MAC mutiplexes the PDU and sends SSB/SIB1 packets towards the O-DU Low through the Lower MAC.
 270
 271
 272
 273 UE Related Procedure
 274 -----------------------
 275
 276
 277 The O-DU High supports
 278
 279 - All physical channels - PBCH, PRACH, PDCCH, PDSCH, PUSCH, PUCCH
 280
 281 - All control logical channels - UL CCCH, DL CCCH, UL DCCH, DL DCCH
 282
 283 - All control transport channels - BCH, UL-SCH, DL-SCH, RACH
 284
 285 The above channels are used to achieve the below messages:
 286
 287 - Cell broadcast of System Information which includes SSB and SIB1.
 288
 289 - RACH Procedure
 290
 291   - RACH Indication
 292
 293   - Random Access Response
 294
 295   - RRC Setup Request
 296
 297   - RRC Setup
 298
 299 - UE attach signalling flow
 300
 301   - RRC Setup Complete
 302
 303   - Registraton Request
 304
 305   - Security Mode Command
 306
 307   - Security Mode Complete
 308
 309   - Registraton Accept
 310
 311   - Registraton Complete
 312
 313   - Several NAS Message Exchanges
 314
 315   - RRC Reconfiguration
 316
 317   - RRC Reconfiguration Complete
 318
 319 Figure 5 below depicts the above call flow, inclusive of all interfaces:
 320
 321 .. figure:: UeAttach.png
 322   :width: 800
 323   :alt: O-DU High UE Attach Flow
 324
 325   Figure 5 - UE Attach Flow
 326
 327 - UE Release Signalling flow
 328
 329   - RRC Release
 330
 331 Closed Loop Automation Procedure
 332 -----------------------------------
 333
 334 This section describes the closed loop automation procedure within O-DU High.
 335
 336 .. figure:: CLA_call_flow.png
 337   :width: 720
 338   :alt: Closed Loop Automation Procedure
 339
 340   Figure 6 - O-DU High Closed Loop Automation Procedure
 341
 342
 343 1. SMO commands ODU-High to bring the cell down via O1 interface.
 344
 345 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.
 346
 347 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.
 348
 349 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.
 350
 351 4. Once all UEs are released, O-DU High sends STOP.Request to L1. L1 responds with stop indication.
 352
 353 5. 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.
 354
 355 6. 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)
 356
 357
 358 O1 Netconf get-alarm list procedure
 359 -----------------------------------
 360
 361 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.
 362
 363
 364 .. figure:: ODU-O1-GetAlarmListFlow.jpg
 365   :width: 869
 366   :alt: Figure 6 O1 get alarm-list flow
 367
 368   Figure 7 - O1 get alarm-list flow
 369
 370 As seen in the Figure 7,
 371
 372 - 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.
 373
 374 - 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.
 375
 376 - Alarm Manager stores the alarm data in a list.
 377
 378 - 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.
 379
 380 - The callback function fetches the alarm list from Alarm Manager and sends it back to the client (SMO/OAM) via  Netconf interface.
 381
 382 OSC Testcases Supported
 383 =========================
 384
 385 The O-DU High partially supports below use-cases:
 386
 387 - Traffic Steering
 388
 389 - Health Check
 390
 391