Configuring Connected-mode Discontinuous Reception (C-DRX) in 5G-ORAN

Connected-mode Discontinuous Reception (C-DRX) is essential to preserve user equipment’s (UE) battery while there is no user traffic and UE is in RRC_connected state.

C-DRX was introduced first in LTE and is enhanced a bit in 5G. If C-DRX is enabled for UE and network, the UE, while still in RRC_connected mode, would remain asleep and only wake up for a short interval of time to check if 5G gNB has scheduled some data for it or not. This wake-up period is called UE Active time.

If no data is scheduled, UE would go back to sleep again and would wake up after a certain interval. If, however, any data is scheduled during the Active time, UE would start a timer to remain ACTIVE for a certain duration and gNB would ensure to transfer of as much data as possible during this ACTIVE PERIOD. There is more to C-DRX which this article has explained in a pretty comprehensive manner. We will not be discussing details of C-DRX in this article.

In this article, we will discuss how in an ORAN-enabled system with disintegrated gNB-CU and gNB-DU would enable DRX configuration parameters (DRX-Config) in the gNB and in the UE.

DRX Functionalities at gNB

Fig.1 below shows the flow diagram for UE to configure C-DRX in the UE and the gNB.

The DRX configuration parameters, DRX-Config contains the following list: {drx-onDuration, drx-InactivityTimer, drx-ShortCycle, drx-ShortCyccleTimer, drx-HARQ-RTT-TimerDL, drx-HARQ-RTT-TimerUL, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, drx-SlotOffset}. Details of these params are present in Section 6 of TS 38.331 or here.

The DRX-Config is sent via RRC message from gNB-CU to the UE. The RRC message for this purpose could be either RRC-Setup or RRC-Reconfiguration. (Note that sending DRX-config via RRC-Reconfiguration message make more sense to me since UE would be in RRC-connected mode. However, in case of RRC-setup procedure, I suppose the DRX-Config info could still be transferred, but perhaps not the best practice !).

But, how does gNB-CU knows the DRX-Config paramters that it need to send to UE? The flow-diagram above should explain it pretty well, but I will explain here as well.

Everything in ORAN enabled gNB starts with a central entity known as Service Management & Orchestration (SMO). The default values of DRX-config parameters are sent from SMO to gNB-CU and gNB-DU. Based on 3GPP specs requirement and system design optimization requirement, some params are sent to gNB-CU while rest are sent to gNB-DU. This is shown in Step 1 and Step 2 of the floa diagram.

In Steps 3–5, we have shown the steps for UE to get to RRC-connected mode. They are pretty standard steps and need no discussion here.

Role of gNB-DU in the C-DRX operations

gNB-DU has the most important role when it comes to C-DRX. Since the data scheduler is located at the L2 MAC layer within the gNB-DU, it should make sure that data is ALWAYS sent to UE(s) during the period when they are active. If, for example, DU schedules the data during the inactive period (i.e. DRX period) of the UE then it is of no use. Similarly, DU should be aware of exactly when and for how long the drx-InactivityTimer would run in the UE or at what slot/symbol UE would get to the ACTIVE state

Hence, DU should be aware of all the DRX-config parameters and must be aligned in time with the UE. Hence, in Step 6 gNB-CU share the DRX-Cycle params (that the SMO has earlier shared with gNB-CU). DU may use the default values as sent by the SMO (and also gNB-CU) or may change the values to optimize network performance. There are propriety algorithms for this purpose for each vendor.

Finally, the gNB-DU performs parameter aggregation to form a drx-Config element list which it uses while scheduling the data in the PDSCH. gNB-DU also shares drx-Config with gNB-CU as well so that gNB-CU can share it in the RRC message with the UE.

This is the simplified version of how DRX-config is shared between UE and several other gNB entities.

If you want to learn more about topics related got 5G, please subscribe to my profile on Medium as I write on similar topics every week.

Disclaimer: Everything covered in this document is 3GPP specification compliant and does not contain any proprietary information.