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 **********************
   9 O-DU High Architecture
  10 **********************
  11
  12 O-DU implements the functional blocks of L2 layer of a 5G NR protocol stack in SA(StandAlone) mode.
  13 These layers primarily include NR MAC, NR Scheduler and NR RLC layers.
  14
  15 O-DU modules are developed as shown in the below diagram.
  16
  17 .. figure:: ODUArch.jpg
  18   :width: 600
  19   :alt: Figure 1 O-DU High Architecture Diagram
  20
  21   Figure 1 - O-DU High Architecture Diagram
  22
  23 ==============================
  24 O-DU High Thread Architecture
  25 ==============================
  26
  27 As shown in Figure 1, there are multiple entities within O-DU High. Modules sharing a
  28 given color belong to one thread. O-DU architecture can be defined at a thread
  29 level as follows:
  30
  31 - Thread 1: O-DU thread
  32
  33 - Thread 2: DU APP inclusive of Config Handler, DU Manager, UE Manager, and ASN.1 Codecs
  34
  35 - Thread 3: 5G NR RLC DL and MAC (inclusive of 5G NR SCH and Lower MAC)
  36
  37 - Thread 4: 5G NR RLC UL
  38
  39 - Thread 5: SCTP Handler
  40
  41 - Thread 6: Lower MAC Handler
  42
  43 - Thread 7: EGTP Handler
  44
  45 - Thread 8: O1
  46
  47 =================
  48 O-DU High Modules
  49 =================
  50
  51 DU APP
  52 ************
  53
  54 This module configures and manages all the operations of O-DU.
  55 It interfaces with external entities as follows:
  56
  57 - OAM:  DU APP interacts with OAM on the O1 interface for configuration, alarms and performance management.
  58
  59 - 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.
  60
  61 - RIC: DU APP interacts with RIC on E2 interface over SCTP.
  62
  63
  64 DU App submodules are as follows:
  65
  66 - Config Handler manages the configurations received on O1 interfaces and stores them within DU APP context.
  67
  68 - DU Manager handles all cell operations at the DU APP.
  69
  70 - UE Manager handles UE contexts at the DU APP.
  71
  72 - SCTP handler is responsible for establishing SCTP connections with O-CU, RIC on the F1AP and E2AP interfaces
  73   respectively.
  74
  75 - EGTP handler is responsible for establishing EGTP connection with O-CU for data message exchange on the F1-U
  76   interface.
  77
  78 - ASN.1 Codecs contain ASN.1 encode/decode functions which are used for System information, F1AP and E2AP messages.
  79
  80 5G NR RLC
  81 ************
  82
  83 This module provides services for transferring the control and data messages
  84 between MAC layer and O-CU (via DU App).
  85
  86 5G NR RLC UL and 5G NR RLC DL are the sub modules of this module that implement
  87 uplink and downlink functionality respectively.
  88
  89 5G NR MAC
  90 ************
  91
  92 This module uses the services of the NR physical layer to send and receive data
  93 on the various logical channels.
  94 Functions of the 5G NR MAC module are as follows:
  95
  96 - 5G NR MAC is responsible for multiplexing and de-multiplexing of the data on various logical channels.
  97
  98 - 5G NR SCH schedules resources in UL and DL for cell and UE based procedures.
  99   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.
 100
 101 - Lower MAC interfaces between the MAC and the O-DU Low. It implements all the messages of FAPI
 102   specification. It has a receiver thread to handle messages from L1.
 103
 104
 105 O-DU Utility and Common Functions
 106 *********************************
 107
 108 These modules contain platform specific files and support O-DU High functionality and message exchanges.
 109
 110
 111 O1 Module
 112 ==========
 113
 114 .. figure:: ODU-O1-Arch.jpg
 115   :width: 554
 116   :alt: Figure 2 O1 Architecture
 117
 118   Figure 2 - O1 Architecture
 119
 120 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.
 121
 122 O1 architecture has following components:
 123
 124 - Netconf Session Handler: Subscribe to Netconf YANG modules and events. Register callback handler methods.
 125
 126 - VES Agent : Sends the VES events to SMO
 127
 128 - Alarm Manager: Stores and manages(add/updated/delete) alarms.
 129
 130 - Alarm Interface : Provides an interface to O-DU High threads for sending the alarm messages to O1 module over Unix socket.
 131
 132 - Config Interface : Interface to handle the configurations sent from SMO to the stack
 133
 134 - Netopeer server: Serves the northbound SMO/OAM Netconf requests.
 135
 136 **********************
 137 O-DU High Interfaces
 138 **********************
 139
 140 This section describes the other modules that O-DU High interfaces with, as shown in below diagram.
 141
 142 .. figure:: O-DUHighInterfaces.jpg
 143   :width: 600
 144   :alt: O-DU High Interfaces
 145
 146   Figure 3 - O-DU High Interfaces
 147
 148
 149 As shown in Figure 3, O-DU High interfaces with the following modules:
 150
 151 - O-CU: O-DU High communicates with O-CU on the F1AP interface. The control message exchanges are on F1-C while
 152   data message exchanges are on F1-U interfaces. The below F1AP messages on F1-C are implemented, as per
 153   3GPP 38.473-f60 v15.3:
 154
 155   - Interface Management
 156
 157     - F1 Setup
 158
 159     - gNB-DU Configuration Update
 160
 161     - F1 Reset
 162
 163     - PAGING
 164
 165   - UE Context Management
 166
 167     - UE Context Setup
 168
 169     - UE Context Modification
 170
 171     - UE Context Release
 172
 173   - RRC Message Transfer
 174
 175     - Initial UL RRC Message Transfer
 176
 177     - DL RRC Message Transfer
 178
 179     - UL RRC Message Transfer
 180
 181     - RRC Delivery Report
 182
 183 - Near RT RIC: O-DU High communicates with Near RT RIC on the E2 interface. The below E2AP messages are
 184   implemented, as per ORAN WG3.E2AP v02.00:
 185
 186   - Global Procedures
 187
 188     - E2 Setup
 189
 190     - E2 Node Configuration Update
 191
 192   - Near RT RIC Functional Procedures
 193
 194     - RIC Subscription
 195
 196     - RIC Indication
 197
 198 - O-DU Low: O-DU High communicates with O-DU Low on the FAPI interface. The below FAPI messages are supported,
 199   as per FAPI interface files shared by Intel:
 200
 201   - P5 messages - PHY mode control interface
 202
 203     - PARAM.request/PARAM.response
 204
 205     - CONFIG.request/CONFIG.response
 206
 207     - START.request
 208
 209     - STOP.request
 210
 211     - STOP.indication
 212
 213   - P7 messages - Main data path interface
 214
 215     - DL_TTI.request
 216
 217     - UL_TTI.request
 218
 219     - SLOT.indication
 220
 221     - UL_DCI.request
 222
 223     - TX_Data.request
 224
 225     - RX_Data.indication
 226
 227     - CRC.indication
 228
 229     - UCI.indication
 230
 231     - RACH.indication
 232
 233 - OAM: O-DU High communicates with OAM on the O1 interface.
 234
 235
 236
 237 ***********************
 238 O-DU High functionality
 239 ***********************
 240
 241 ===============================
 242 Cell Up and Broadcast Procedure
 243 ===============================
 244
 245 This section describes the cell-up procedure within O-DU High.
 246
 247 .. figure:: CellUpAndBroadcast.png
 248   :width: 720
 249   :alt: Cell Up and Broadcast Procedure
 250
 251   Figure 4 - O-DU High Cell Up and Broadcast Procedure
 252
 253
 254 As seen in the Figure 4,
 255 - If O1 interface is enabled, SMO sends cell configuration to DU APP. DU APP stores the configurations in its local database.
 256
 257 - If O1 interface is disabled, DU APP module uses static configuration.
 258
 259 - 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.
 260
 261 - The O-CU responds with F1 Setup Response. This message contains a list of cells which must be activated.
 262
 263 - The O-DU High scans the list of cells received and sends corresponding cell configurations to 5G NR MAC.
 264
 265 - 5G NR MAC, in-turn configures the 5G NR SCH. It also configures the O-DU Low via the Lower MAC module.
 266
 267 - On receiving the cell config response, DU APP sends a gNB DU Config Update towards the O-CU. The O-CU responds with
 268   gNB DU Config Update ACK towards the O-DU High.
 269
 270 - The DU APP now exchanges F1 Reset message with the O-CU to initialize the UE contexts.
 271
 272 - 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
 273   Low.
 274
 275 - On receiving START.request, O-DU Low begins to send slot indications towards 5G NR MAC via the lower MAC.
 276   The frequency of these slot indications is determined by the numerology(Mu) supported.
 277   5G NR MAC forwards these slot indications to the 5G NR SCH and DU APP modules.
 278
 279 - 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.
 280
 281 - The 5G NR SCH, keeps tracking the SSB and SIB1 ocassions on receiving regular slot indications.
 282   On detecting the relevant ocassion, 5G NR SCH schedules SSB/SIB1 and forwards the DL Scheduling Information to 5G NR MAC.
 283
 284 - The 5G NR MAC mutiplexes the PDU and sends SSB/SIB1 packets towards the O-DU Low through the Lower MAC.
 285
 286
 287 =====================
 288 UE Related Procedure
 289 =====================
 290
 291 The O-DU High supports
 292
 293 - All physical channels - PBCH, PRACH, PDCCH, PDSCH, PUSCH, PUCCH
 294
 295 - All control logical channels - UL CCCH, DL CCCH, UL DCCH, DL DCCH
 296
 297 - All control transport channels - BCH, UL-SCH, DL-SCH, RACH
 298
 299 The above channels are used to achieve the below messages:
 300
 301 - Cell broadcast of System Information which includes SSB and SIB1.
 302
 303 - RACH Procedure
 304
 305   - RACH Indication
 306
 307   - Random Access Response
 308
 309   - RRC Setup Request
 310
 311   - RRC Setup
 312
 313 - UE attach signalling flow
 314
 315   - RRC Setup Complete
 316
 317   - Registraton Request
 318
 319   - Security Mode Command
 320
 321   - Security Mode Complete
 322
 323   - Registraton Accept
 324
 325   - Registraton Complete
 326
 327   - Several NAS Message Exchanges
 328
 329   - RRC Reconfiguration
 330
 331   - RRC Reconfiguration Complete
 332
 333 Figure 5 below depicts the above call flow, inclusive of all interfaces:
 334
 335 .. figure:: UeAttach.png
 336   :width: 800
 337   :alt: O-DU High UE Attach Flow
 338
 339   Figure 5 - UE Attach Flow
 340
 341 - UE Release Signalling flow
 342
 343   - RRC Release
 344
 345 ================================
 346 Closed Loop Automation Procedure
 347 ================================
 348
 349 This section describes the closed loop automation procedure within O-DU High.
 350
 351 .. figure:: CLA_call_flow.png
 352   :width: 720
 353   :alt: Closed Loop Automation Procedure
 354
 355   Figure 6 - O-DU High Closed Loop Automation Procedure
 356
 357
 358 1. SMO commands ODU-High to bring the cell down via O1 interface.
 359
 360 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.
 361
 362 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.
 363
 364 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.
 365
 366 5. Once all UEs are released, O-DU High sends STOP.Request to L1. L1 responds with stop indication.
 367
 368 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.
 369
 370 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)
 371
 372 ===================================
 373 O1 Netconf get-alarm list procedure
 374 ===================================
 375
 376 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.
 377
 378
 379 .. figure:: ODU-O1-GetAlarmListFlow.jpg
 380   :width: 869
 381   :alt: Figure 7 O1 get alarm-list flow
 382
 383   Figure 7 - O1 get alarm-list flow
 384
 385 As seen in the Figure 7,
 386
 387 - 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.
 388
 389 - 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.
 390
 391 - Alarm Manager stores the alarm data in a list.
 392
 393 - 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.
 394
 395 - The callback function fetches the alarm list from Alarm Manager and sends it back to the client (SMO/OAM) via  Netconf interface.
 396
 397 ==========================
 398 Network Slicing procedure
 399 ==========================
 400
 401 This section describes the Network Slicing feature within O-DU High.
 402
 403
 404 .. figure:: Network_Slicing.png
 405   :width: 869
 406   :alt: Network Slicing flow
 407
 408   Figure 8 -  Network Slicing flow
 409
 410 As seen in the Figure 8,
 411
 412 - 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.
 413
 414 - 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.
 415
 416 - 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.
 417
 418 - RLC sends the Consolidated Slice Metrics to DU APP at every 60 sec duration. This is further forwarded towards SMO/Non-RT RIC.
 419
 420 - 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.
 421
 422 - 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.
 423
 424 ==========================
 425 Idle Mode Paging procedure
 426 ==========================
 427
 428 This section describes the Idle Mode Paging procedure within O-DU High.
 429
 430
 431 .. figure:: IDLE_mode_Paging.jpg
 432   :width: 869
 433   :alt: Idle Mode Paging flow
 434
 435   Figure 9 -  Idle Mode Paging flow
 436
 437 As seen in the Figure 9,
 438
 439 - 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.
 440
 441 - 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.
 442
 443 - MAC forwards to SCH as PAGING INDICATION.
 444
 445 - 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.
 446
 447 - MAC forwards the PAGE to PHY in TX_Data.Request.
 448
 449 ==============================
 450 Inter-DU Handover within O-CU
 451 ==============================
 452
 453 This section describes the handling of inter-DU handover of a UE within O-DU High.
 454
 455 .. figure:: Inter_DU_Handover_Within_OCU.png
 456    :width: 600
 457    :alt: Inter-DU Handover withing O-CU
 458
 459    Figure 10 -  Inter_DU Handover call flow
 460
 461 Assumption: UE is RRC connected with DU and PDU data session is active.
 462
 463 - 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.
 464
 465 - Based on UE Measurement Report, O-CU makes a handover decision to another cell belonging to the target O-DU.
 466
 467 - The O-CU sends a UE CONTEXT MODIFICATION REQUEST message to source O-DU to query the latest configuration.
 468
 469 - The DU APP in source O-DU responds with a UE CONTEXT MODIFICATION RESPONSE message that includes latest full configuration information.
 470
 471 - 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.
 472
 473 - The target O-DU responds with a UE CONTEXT SETUP RESPONSE message if the target O-DU can admit resources for the handover.
 474
 475 - 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.
 476
 477 - 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.
 478
 479 - The source O-DU responds to the O-CU with UE CONTEXT MODIFICATION RESPONSE message.
 480
 481 - 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.
 482
 483 - Once Random Access procedure with target O-DU is complete, the UE responds to the target O-DU with a RRCReconfigurationComplete message.
 484
 485 - The target O-DU sends UL RRC MESSAGE TRANSFER message to O-CU to convey the received RRCReconfigurationComplete message.
 486
 487 - The downlink and uplink data packets are sent to/from the UE through the target O-DU.
 488
 489 - The O-CU sends UE CONTEXT RELEASE COMMAND message to the source O-DU.
 490
 491 - The source O-DU sends UE DELETE REQUEST to MAC/RLC layers to release the UE context and receives UE DELETE RESPONSE message.
 492
 493 - The source O-DU responds to O-CU with UE CONTEXT RELEASE COMPLETE message.
 494
 495 =============================
 496 Discontinuous reception (DRX)
 497 =============================
 498
 499 This section describes the Discontinuous reception (DRX) feature within O-DU High.
 500
 501
 502 .. figure:: Discontinuous_reception.PNG
 503   :width: 600
 504   :alt: Discontinuous reception flow
 505
 506   Figure 11 -  Discontinuous reception flow
 507
 508 - 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.
 509
 510 - 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.
 511
 512 - 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.
 513
 514 - 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.
 515
 516 - 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.
 517
 518 - 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.
 519
 520 - 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.
 521
 522 .. figure:: Drx_Onduration_Inactive_ShortCycle_Timer.png
 523   :width: 600
 524   :alt: onDurationTimer,InactivityTimer,ShortCycleTimer flow
 525
 526   Figure 12 -  onDurationTimer,InactivityTimer,ShortCycleTimer flow
 527
 528 - 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.
 529
 530 .. figure:: Drx_Dl_Harq_Retransmission_Timer.png
 531   :width: 600
 532   :alt: HARQ-RTT-TimerDL, RetransmissionTimerDL flow
 533
 534   Figure 13 - DL Harq Retransmission Timers flow
 535
 536 .. figure:: Drx_Ul_Harq_Retransmission_Timer.png
 537   :width: 600
 538   :alt: HARQ-RTT-TimerUL, RetransmissionTimerUL flow
 539
 540   Figure 14 - UL Harq Retransmission Timers flow
 541
 542 - 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.
 543
 544 ***********************
 545 OSC Testcases Supported
 546 ***********************
 547
 548 The O-DU High partially supports below use-cases:
 549
 550 - Traffic Steering
 551
 552 - Health Check
 553
 554