[Epic-ID: ODUHIGH-517][Task-ID: ODUHIGH-540][SubTask-Id: ODUHIGH-549] Multi PDSCH...
[o-du/l2.git] / 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 - Lower MAC interfaces between the MAC and the O-DU Low. It implements all the messages of FAPI
98   specification. It has a receiver thread to handle messages from L1.
99
100 5G NR SCH
101 **********
102
103 - This module is completely encapuslated withing 5G NR MAC i.e. all interactions of the 5G NR SCH is via the 5G NR MAC.
104 - Schedules resources in UL and DL for cell and UE based procedures.
105 - SCH framework design supports plugging-in new scheduling algorithm easily. Refer to section "Scheduler Framework with plug-in support" in Developer-Guide document for details.
106
107 O-DU Utility and Common Functions
108 *********************************
109
110 These modules contain platform specific files and support O-DU High functionality and message exchanges.
111
112
113 O1 Module
114 *********
115
116 .. figure:: ODU-O1-Arch.jpg
117   :width: 554
118   :alt: Figure 2 O1 Architecture
119
120   Figure 2 - O1 Architecture 
121
122 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. 
123
124 O1 architecture has following components:
125
126 - Netconf Session Handler: Subscribe to Netconf YANG modules and events. Register callback handler methods.
127
128 - VES Agent : Sends the VES events to SMO
129
130 - Alarm Manager: Stores and manages(add/updated/delete) alarms.
131
132 - Alarm Interface : Provides an interface to O-DU High threads for sending the alarm messages to O1 module over Unix socket.
133
134 - Config Interface : Interface to handle the configurations sent from SMO to the stack
135
136 - Netopeer server: Serves the northbound SMO/OAM Netconf requests.
137
138 **********************
139 O-DU High Interfaces
140 **********************
141
142 This section describes the other modules that O-DU High interfaces with, as shown in below diagram.
143
144 .. figure:: O-DUHighInterfaces.jpg
145   :width: 600
146   :alt: O-DU High Interfaces
147
148   Figure 3 - O-DU High Interfaces
149
150
151 As shown in Figure 3, O-DU High interfaces with the following modules:
152
153 - O-CU: O-DU High communicates with O-CU on the F1AP interface. The control message exchanges are on F1-C while
154   data message exchanges are on F1-U interfaces. The below F1AP messages on F1-C are implemented, as per
155   3GPP 38.473-f60 v15.3:
156
157   - Interface Management
158
159     - F1 Setup
160
161     - gNB-DU Configuration Update
162
163     - F1 Reset
164
165     - PAGING
166
167   - UE Context Management 
168
169     - UE Context Setup
170
171     - UE Context Modification
172
173     - UE Context Release
174
175   - RRC Message Transfer
176                 
177     - Initial UL RRC Message Transfer
178
179     - DL RRC Message Transfer
180
181     - UL RRC Message Transfer
182
183     - RRC Delivery Report
184
185 - Near RT RIC: O-DU High communicates with Near RT RIC on the E2 interface. The below E2AP messages are
186   implemented, as per ORAN WG3.E2AP v02.00:
187
188   - Global Procedures
189
190     - E2 Setup
191
192     - E2 Node Configuration Update 
193     
194     - E2 Reset
195
196   - Near RT RIC Functional Procedures
197                 
198     - RIC Subscription
199
200     - RIC Indication
201
202 - O-DU Low: O-DU High communicates with O-DU Low on the FAPI interface. The below FAPI messages are supported, 
203   as per FAPI interface files shared by Intel:
204
205   - P5 messages - PHY mode control interface
206         
207     - PARAM.request/PARAM.response
208
209     - CONFIG.request/CONFIG.response
210
211     - START.request
212
213     - STOP.request
214
215     - STOP.indication
216
217   - P7 messages - Main data path interface
218
219     - DL_TTI.request
220
221     - UL_TTI.request
222
223     - SLOT.indication
224
225     - UL_DCI.request
226
227     - TX_Data.request
228
229     - RX_Data.indication
230
231     - CRC.indication
232
233     - UCI.indication
234
235     - RACH.indication
236
237 - OAM: O-DU High communicates with OAM on the O1 interface.
238
239
240
241 ***********************
242 O-DU High functionality
243 ***********************
244
245 ===============================
246 Cell Up and Broadcast Procedure
247 ===============================
248
249 This section describes the cell-up procedure within O-DU High.
250
251 .. figure:: CellUpAndBroadcast.png
252   :width: 720
253   :alt: Cell Up and Broadcast Procedure
254
255   Figure 4 - O-DU High Cell Up and Broadcast Procedure
256
257
258 As seen in the Figure 4,
259 - If O1 interface is enabled, SMO sends cell configuration to DU APP. DU APP stores the configurations in its local database.
260
261 - If O1 interface is disabled, DU APP module uses static configuration.
262
263 - 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.
264
265 - The O-CU responds with F1 Setup Response. This message contains a list of cells which must be activated.
266
267 - The O-DU High scans the list of cells received and sends corresponding cell configurations to 5G NR MAC.
268
269 - 5G NR MAC, in-turn configures the 5G NR SCH. It also configures the O-DU Low via the Lower MAC module.
270
271 - On receiving the cell config response, DU APP sends a gNB DU Config Update towards the O-CU. The O-CU responds with
272   gNB DU Config Update ACK towards the O-DU High.
273
274 - The DU APP now exchanges F1 Reset message with the O-CU to initialize the UE contexts.
275
276 - 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
277   Low.
278
279 - On receiving START.request, O-DU Low begins to send slot indications towards 5G NR MAC via the lower MAC.
280   The frequency of these slot indications is determined by the numerology(Mu) supported.
281   5G NR MAC forwards these slot indications to the 5G NR SCH and DU APP modules.
282
283 - 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.
284
285 - The 5G NR SCH, keeps tracking the SSB and SIB1 ocassions on receiving regular slot indications. 
286   On detecting the relevant ocassion, 5G NR SCH schedules SSB/SIB1 and forwards the DL Scheduling Information to 5G NR MAC.
287
288 - The 5G NR MAC mutiplexes the PDU and sends SSB/SIB1 packets towards the O-DU Low through the Lower MAC.
289
290
291 =====================
292 UE Related Procedure
293 =====================
294
295 The O-DU High supports 
296
297 - All physical channels - PBCH, PRACH, PDCCH, PDSCH, PUSCH, PUCCH
298
299 - All control logical channels - UL CCCH, DL CCCH, UL DCCH, DL DCCH
300
301 - All control transport channels - BCH, UL-SCH, DL-SCH, RACH
302
303 The above channels are used to achieve the below messages:
304
305 - Cell broadcast of System Information which includes SSB and SIB1.
306
307 - RACH Procedure
308
309   - RACH Indication
310
311   - Random Access Response
312
313   - RRC Setup Request
314
315   - RRC Setup
316
317 - UE attach signalling flow
318
319   - RRC Setup Complete
320
321   - Registraton Request
322
323   - NAS Authentication Request
324
325   - NAS Authentication Response
326
327   - NAS Security Mode Command
328
329   - NAS Security Mode Complete
330
331   - RRC Security Mode Command
332
333   - RRC Security Mode Complete
334
335   - Registraton Accept
336
337   - Registraton Complete
338
339   - RRC Reconfiguration
340
341   - RRC Reconfiguration Complete
342
343 Figure 5 below depicts the above call flow, inclusive of all interfaces:
344
345 .. figure:: UeAttach.png
346   :width: 800
347   :alt: O-DU High UE Attach Flow
348
349   Figure 5 - UE Attach Flow
350
351 - UE Release Signalling flow
352
353   - RRC Release
354
355 ================================
356 Closed Loop Automation Procedure
357 ================================
358
359 This section describes the closed loop automation procedure within O-DU High.
360
361 .. figure:: CLA_call_flow.png
362   :width: 720
363   :alt: Closed Loop Automation Procedure
364
365   Figure 6 - O-DU High Closed Loop Automation Procedure
366
367
368 1. SMO commands ODU-High to bring the cell down via O1 interface.
369
370 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.
371
372 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.
373    
374 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.
375
376 5. Once all UEs are released, O-DU High sends STOP.Request to L1. L1 responds with stop indication.
377
378 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.
379
380 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)
381
382 ===================================
383 O1 Netconf get-alarm list procedure
384 ===================================
385
386 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.
387
388
389 .. figure:: ODU-O1-GetAlarmListFlow.jpg
390   :width: 869
391   :alt: Figure 7 O1 get alarm-list flow  
392
393   Figure 7 - O1 get alarm-list flow
394
395 As seen in the Figure 7,
396
397 - 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.
398
399 - 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.
400
401 - Alarm Manager stores the alarm data in a list.
402
403 - 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.
404
405 - The callback function fetches the alarm list from Alarm Manager and sends it back to the client (SMO/OAM) via  Netconf interface. 
406
407 ==========================
408 Network Slicing procedure
409 ==========================
410
411 This section describes the Network Slicing feature within O-DU High.
412
413
414 .. figure:: Network_Slicing.png 
415   :width: 869
416   :alt: Network Slicing flow
417
418   Figure 8 -  Network Slicing flow
419
420 As seen in the Figure 8,
421
422 - 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.
423
424 - 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.
425
426 - 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.
427
428 - RLC sends the Consolidated Slice Metrics to DU APP at every 60 sec duration. This is further forwarded towards SMO/Non-RT RIC.
429
430 - 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.
431
432 - 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.
433
434 ==========================
435 Idle Mode Paging procedure
436 ==========================
437
438 This section describes the Idle Mode Paging procedure within O-DU High.
439
440
441 .. figure:: IDLE_mode_Paging.jpg
442   :width: 869
443   :alt: Idle Mode Paging flow
444
445   Figure 9 -  Idle Mode Paging flow
446
447 As seen in the Figure 9,
448
449 - 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.
450
451 - 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.
452
453 - MAC forwards to SCH as PAGING INDICATION.
454
455 - 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.
456
457 - MAC forwards the PAGE to PHY in TX_Data.Request.
458
459 ==============================
460 Inter-DU Handover within O-CU
461 ==============================
462
463 This section describes the handling of inter-DU handover of a UE within O-DU High.
464
465 .. figure:: Inter_DU_Handover_Within_OCU.png
466    :width: 600
467    :alt: Inter-DU Handover withing O-CU
468  
469    Figure 10 -  Inter_DU Handover call flow
470
471 Assumption: UE is RRC connected with DU and PDU data session is active.
472
473 - 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.
474
475 - Based on UE Measurement Report, O-CU makes a handover decision to another cell belonging to the target O-DU.
476
477 - The O-CU sends a UE CONTEXT MODIFICATION REQUEST message to source O-DU to query the latest configuration.
478
479 - The DU APP in source O-DU responds with a UE CONTEXT MODIFICATION RESPONSE message that includes latest full configuration information.
480
481 - 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.
482
483 - The target O-DU responds with a UE CONTEXT SETUP RESPONSE message if the target O-DU can admit resources for the handover.
484
485 - 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.
486
487 - 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.
488
489 - The source O-DU responds to the O-CU with UE CONTEXT MODIFICATION RESPONSE message.
490
491 - 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.
492
493 - Once Random Access procedure with target O-DU is complete, the UE responds to the target O-DU with a RRCReconfigurationComplete message.
494
495 - The target O-DU sends UL RRC MESSAGE TRANSFER message to O-CU to convey the received RRCReconfigurationComplete message.
496
497 - The downlink and uplink data packets are sent to/from the UE through the target O-DU.
498
499 - The O-CU sends UE CONTEXT RELEASE COMMAND message to the source O-DU.
500
501 - The source O-DU sends UE DELETE REQUEST to MAC/RLC layers to release the UE context and receives UE DELETE RESPONSE message.
502
503 - The source O-DU responds to O-CU with UE CONTEXT RELEASE COMPLETE message.
504
505 ==============================
506 Inter-CU Handover (Xn-Based)
507 ==============================
508
509 This section describes the handling of inter-CU handover of a UE over Xn interface.
510
511 .. figure:: Xn_Based_Inter_CU_Handover.png
512    :width: 600
513    :alt: Xn-Based Inter-CU Handover
514  
515    Figure 11 -  Xn-Based Inter-CU Handover call flow
516
517 Terminology:
518
519 - Source GNB : GNB to which UE is connected and will be handed over from .
520 - Source GNB DU : O-DU in source GNB
521 - Source GNB CU : O-CU in source GNB
522 - Target GNB : GNB to which UE will be handed over to.
523 - Target GNB DU : O-DU in target GNB
524 - Target GNB CU : O-CU in target GNB
525 - Xn Inteface : Interface between Source GNB CU and Target GNB CU
526 - UE : UE in handover from source GNB to target GNB
527
528 Assumptions: 
529
530 - Xn setup is established between the two GNB 
531 - UE is RRC connected with DU 
532 - PDU data session is active.
533
534 Call Flow :
535
536 - UE sends Measurement Report message to source GNB. This message is sent from O-DU to O-CU in the UL RRC MESSAGE TRANSFER message over F1AP interface.
537
538 - Based on UE Measurement Report, O-CU makes handover decision to a cell belonging to another GNB. Hereafter, this GNB will be referred to as target GNB.
539
540 - Before initiating the handover procedure, source GNB CU sends a UE CONTEXT MODIFICATION REQUEST message to source GNB DU to query the latest configurations.
541
542 - The source GNB DU responds with UE CONTEXT MODIFICATION RESPONSE message that includes latest full configuration information.
543
544 - To start the handover, source GNB CU sends HANDOVER REQUEST to target GNB CU with UE configuration received from source GNB DU.
545
546 - Target GNB CU sends a UE CONTEXT SETUP REQUEST message to target GNB DU to create a UE context and setup one or more data bearers. The UE CONTEXT SETUP REQUEST message includes Hand-overPreparationInformation. At 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.
547
548 - The target GNB DU responds with UE CONTEXT SETUP RESPONSE message if it can admit resources for the handover.
549
550 - Consequetively, target GNB CU sends HANDOVER REQUEST ACKNOWLEDGE message to source GNB CU to proceed with handover.
551
552 - Now source GNB CU sends UE CONTEXT MODIFICATION REQUEST message to source GNB DU, which includes RRCReconfiguration message towards the UE. The CU also indicates the DU to stop the data transmission for the UE.
553
554 - Source GNB DU forwards received RRCReconfiguration message to the UE and then sends DOWNLINK DATA DELIVERY STATUS message to CU to inform about successful delivery of message to UE.
555
556 - Source GNB DU also sends UE Reconfiguration Request to MAC/Scheduler and RLC layers to stop data scheduling as requested by CU. Once all layers have responded with UE reconfiguration response, source GNB DU send UE CONTEXT MODIFICATION RESPONSE message to source GNB CU.
557
558 - Using the information received in RRC Reconfiguration message, UE triggers Random Access procedure towards target GNB DU. This is a contention free random access if UE receives dedicated RACH resources information in RRC Reconfiguration message.
559
560 - Once Random Access procedure with target GNB is complete, UE responds to target GNB DU with a RRCReconfigurationComplete message.
561
562 - The target GNB DU sends UL RRC MESSAGE TRANSFER message to CU to convey the received RRCReconfigurationComplete message. This completes the UE attach to target GNB.
563
564 - The downlink and uplink data packets are now sent to/from the UE through target GNB.
565
566 - Once UE is successfully handed over to target GNB, its CU sends UE CONTEXT RELEASE message to source GNB CU.
567
568 - Hence, source GNB CU sends UE CONTEXT RELEASE COMMAND message to the source GNB DU. 
569
570 - DU releases UE context at all layers and responds to source GNB CU with UE CONTEXT RELEASE COMPLETE message.
571
572 =============================
573 Discontinuous reception (DRX)
574 =============================
575
576 This section describes the Discontinuous reception (DRX) feature within O-DU High.
577
578
579 .. figure:: Discontinuous_reception.PNG
580   :width: 600
581   :alt: Discontinuous reception flow
582
583   Figure 12 -  Discontinuous reception flow
584
585 - 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. 
586
587 - 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.
588
589 - 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. 
590
591 - 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. 
592
593 - 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. 
594
595 - 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.
596
597 - 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.
598
599 .. figure:: Drx_Onduration_Inactive_ShortCycle_Timer.png
600   :width: 600
601   :alt: onDurationTimer,InactivityTimer,ShortCycleTimer flow
602
603   Figure 13 -  onDurationTimer,InactivityTimer,ShortCycleTimer flow
604
605 - 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.
606
607 .. figure:: Drx_Dl_Harq_Retransmission_Timer.png
608   :width: 600
609   :alt: HARQ-RTT-TimerDL, RetransmissionTimerDL flow
610
611   Figure 14 - DL Harq Retransmission Timers flow
612
613 .. figure:: Drx_Ul_Harq_Retransmission_Timer.png
614   :width: 600
615   :alt: HARQ-RTT-TimerUL, RetransmissionTimerUL flow
616
617   Figure 15 - UL Harq Retransmission Timers flow
618
619 - 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. 
620
621 ***********************
622 OSC Testcases Supported
623 ***********************
624
625 The O-DU High partially supports below use-cases:
626
627 - Traffic Steering
628
629 - Health Check
630
631