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, EGTP Handler 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
  42 O-DU High Modules
  43 --------------------------
  44
  45 DU APP
  46 ^^^^^^^^^^^^^^^^^^
  47 This module configures and manages all the operations of O-DU.
  48 It interfaces with external entities as follows:
  49
  50 - OAM:  DU APP interacts with OAM on the O1 interface for configuration, alarms and performance management.
  51
  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.
  53
  54 - RIC: DU APP interacts with RIC on E2 interface over SCTP.
  55
  56
  57 DU App submodules are as follows:
  58
  59 - Config Handler manages the configurations received on O1 interfaces and stores them within DU APP context.
  60
  61 - DU Manager handles all cell operations at the DU APP.
  62
  63 - UE Manager handles UE contexts at the DU APP.
  64
  65 - SCTP handler is responsible for establishing SCTP connections with O-CU, RIC on the F1AP and E2AP interfaces
  66   respectively.
  67
  68 - EGTP handler is responsible for establishing EGTP connection with O-CU for data message exchange on the F1-U
  69   interface.
  70
  71 - ASN.1 Codecs contain ASN.1 encode/decode functions which are used for System information, F1AP and E2AP messages.
  72
  73 5G NR RLC
  74 ^^^^^^^^^^^^^^^^^^
  75 This module provides services for transferring the control and data messages
  76 between MAC layer and O-CU (via DU App).
  77
  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.
  80
  81 5G NR MAC
  82 ^^^^^^^^^^^^^^^^^^
  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:
  86
  87 - 5G NR MAC is responsible for multiplexing and de-multiplexing of the data on various logical channels.
  88
  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.
  91
  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.
  94
  95
  96 O-DU Utility and Common Functions
  97 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  98 These modules contain platform specific files and support O-DU High functionality and message exchanges.
  99
 100
 101 O1 Module
 102 ^^^^^^^^^^
 103
 104 .. figure:: ODU-O1-Arch.jpg
 105   :width: 600
 106   :alt: Figure 2 O1 Architecture
 107
 108   Figure 2 - O1 Architecture
 109
 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.
 111
 112 O1 architecture has following components:
 113
 114 - Netconf Manager: Subscribe to Netconf YANG modules and events. Register callback handler methods.
 115
 116 - Alarm Manager: Stores and manages(add/updated/delete) alarms.
 117
 118 - TCP server: Receives the alarm messages sent from O-DU High over TCP socket.
 119
 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.
 121
 122 - Netopeer server: Serves the northbound SMO/OAM Netconf requests.
 123
 124
 125 O-DU-High Interfaces
 126 ======================
 127
 128
 129 This section describes the other modules that O-DU High interfaces with, as shown in below diagram.
 130
 131 .. figure:: O-DUHighInterfaces.jpg
 132   :width: 600
 133   :alt: O-DU High Interfaces
 134
 135   Figure 3 - O-DU High Interfaces
 136
 137
 138 As shown in Figure 3, O-DU High interfaces with the following modules:
 139
 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:
 143
 144   - Interface Management
 145
 146     - F1 Setup
 147
 148     - gNB-DU Configuration Update
 149
 150     - F1 Reset
 151
 152   - UE Context Management
 153
 154     - UE Context Setup
 155
 156   - RRC Message Transfer
 157
 158     - Initial UL RRC Message Transfer
 159
 160     - DL RRC Message Transfer
 161
 162     - UL RRC Message Transfer
 163
 164     - RRC Delivery Report
 165
 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:
 168
 169   - Global Procedures
 170
 171     - E2 Setup
 172
 173   - Near RT RIC Functional Procedures
 174
 175     - RIC Subscription
 176
 177     - RIC Indication
 178
 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:
 181
 182   - P5 messages - PHY mode control interface
 183
 184     - PARAM.request/PARAM.response
 185
 186     - CONFIG.request/CONFIG.response
 187
 188     - START.request
 189
 190     - STOP.request
 191
 192     - STOP.indication
 193
 194   - P7 messages - Main data path interface
 195
 196     - DL_TTI.request
 197
 198     - UL_TTI.request
 199
 200     - SLOT.indication
 201
 202     - UL_DCI.request
 203
 204     - TX_Data.request
 205
 206     - RX_Data.indication
 207
 208     - CRC.indication
 209
 210     - UCI.indication
 211
 212     - RACH.indication
 213
 214 - OAM: O-DU High communicates with OAM on the O1 interface.
 215
 216
 217
 218 O-DU High functionality
 219 ========================
 220
 221
 222 Cell Up and Broadcast Procedure
 223 --------------------------------
 224
 225 This section describes the cell-up procedure within O-DU High.
 226
 227 .. figure:: CellUpAndBroadcast.png
 228   :width: 720
 229   :alt: Cell Up and Broadcast Procedure
 230
 231   Figure 4 - O-DU High Cell Up and Broadcast Procedure
 232
 233
 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.
 236
 237 - The O-CU responds with F1 Setup Response. This message contains a list of cells which must be activated.
 238
 239 - The O-DU High scans the list of cells received and sends corresponding cell configurations to 5G NR MAC.
 240
 241 - 5G NR MAC, in-turn configures the 5G NR SCH. It also configures the O-DU Low via the Lower MAC module.
 242
 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.
 245
 246 - The DU APP now exchanges F1 Reset message with the O-CU to initialize the UE contexts.
 247
 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
 249   Low.
 250
 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.
 254
 255 - When the first slot indication reaches the DU APP, cell is marked as up.
 256
 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.
 259
 260 - The 5G NR MAC mutiplexes the PDU and sends SSB/SIB1 packets towards the O-DU Low through the Lower MAC.
 261
 262
 263
 264 UE Related Procedure
 265 -----------------------
 266
 267
 268 The O-DU High supports
 269
 270 - All physical channels - PBCH, PRACH, PDCCH, PDSCH, PUSCH, PUCCH
 271
 272 - All control logical channels - UL CCCH, DL CCCH, UL DCCH, DL DCCH
 273
 274 - All control transport channels - BCH, UL-SCH, DL-SCH, RACH
 275
 276 The above channels are used to achieve the below messages:
 277
 278 - Cell broadcast of System Information which includes SSB and SIB1.
 279
 280 - RACH Procedure
 281
 282   - RACH Indication
 283
 284   - Random Access Response
 285
 286   - RRC Setup Request
 287
 288   - RRC Setup
 289
 290 - UE attach signalling flow
 291
 292   - RRC Setup Complete
 293
 294   - Registraton Request
 295
 296   - Security Mode Command
 297
 298   - Security Mode Complete
 299
 300   - Registraton Accept
 301
 302   - Registraton Complete
 303
 304   - Several NAS Message Exchanges
 305
 306   - RRC Reconfiguration
 307
 308   - RRC Reconfiguration Complete
 309
 310 Figure 5 below depicts the above call flow, inclusive of all interfaces:
 311
 312 .. figure:: UeAttach.png
 313   :width: 800
 314   :alt: O-DU High UE Attach Flow
 315
 316   Figure 5 - UE Attach Flow
 317
 318
 319 O1 Netconf get-alarm list procedure
 320 -----------------------------------
 321
 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.
 323
 324
 325 .. figure:: ODU-O1-GetAlarmListFlow.jpg
 326   :width: 720
 327   :alt: Figure 6 O1 get alarm-list flow
 328
 329   Figure 6 - O1 get alarm-list flow
 330
 331
 332 As seen in the Figure 6,
 333
 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.
 335
 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.
 337
 338 - Alarm Manager stores the alarm data in a list.
 339
 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.
 341
 342 - The callback function fetches the alarm list from Alarm Manager and sends it back to the client (SMO/OAM) via  Netconf interface.
 343
 344 OSC Testcases Supported
 345 =========================
 346
 347 The O-DU High partially supports below use-cases:
 348
 349 - Traffic Steering
 350
 351 - Health Check
 352
 353