LTE: Connected Mode DRX

In LTE, without Discontinuous Reception (DRX), the UE has to be awake all the time in order to decode downlink data, as the data in the downlink may arrive at any time. This means that UE has to be monitoring PDCCH in every subframe in order to check if there is downlink data available. This consumes a lot of the user equipment’s power
DRX in LTE is introduced to improve UE battery lifetime. In DRX, UE discontinuously receives PDCCH. This post discusses LTE Connected mode DRX.
The eNodeB configures DRX with a set of DRX parameters. These DRX parameters are selected based on the application type such that power and resource savings are maximized.
When DRX is enabled, there may be an extended delay in receiving data as, the UE may be in DRX Sleep state at the time of data arrival at the eNodeB, and the eNodeB would have to wait until the UE becomes ON. So the DRX parameters have to be carefully selected such that the packet delay is minimized and power saving is maximized.
During DRX mode, the UE powers down most of its circuitry when there are no packets to be received. During this time UE listens to the downlink (DL) occasionally which is called DRX Active state whereas the time during which UE doesn’t listen PDCCH is called DRX Sleep state
DRX is also beneficial to the eNodeB. Without DRX, the UE would be transmitting periodic CSI or SRS very frequently (based on the configuration). With DRX, during OFF periods, the UE is not allowed to transmit Periodic CSI or SRS, so the eNodeB can assign these resources to the other UEs to maximize resource utilization.

DRX Configuration
The eNodeB configures the following RRC parameters for DRX. Entire DRX configuration is sent under drx-config structure under MAC-MainConfig. Each DRX parameter and its’ purpose is explained below
In RRC specification, almost all the DRX timer values are specified in terms of psfs. psf is a PDCCH subframe in which UE listens for PDCCH. In FDD every subframe is a DL/UL subframe so every subframe can be a psf whereas in TDD, only DL subframes are considered to be psfs.
  • drx-Inactivity-Timer specifies the number of consecutive PDCCH-subframe(s) for which the UE should be Active after successfully decoding a PDCCH indicating a new transmission (UL or DL) . This timer is restarted upon receiving PDCCH for a new transmission (UL or DL). Upon the expiry of this timer the UE should go to DRX mode.
  • shortDRX-Cycle is the first type of DRX cycle (if configured) that needs to be followed when UE enters DRX mode. This IE indicates the length of the short cycle in subframes which include ON time followed by a possible OFF (inactivity) time.
  • drxShortCycleTimer expressed as multiples of shortDRX-Cycle. The timer value can vary from 1 to 16 (short DRX cycles). This timer indicates the number of initial DRX cycles to follow the short DRX cycle before entering the long DRX cycle
  • longDRX-CycleStartOffset defines long DRX cycle length as well as the DRX offset. DRX offset is used to calculate the starting subframe number for DRX cycle.
  • onDurationTimer specifies the number of consecutive PDCCH-subframe(s) at the beginning of each DRX Cycle (DRX ON). i.e., is the number of subframes over which the UE shall read PDCCH during every DRX cycle before entering the power saving mode (DRX OFF)
  • HARQ RTT Timer specifies the minimum amount of subframe(s) duration from the time new transmission is received and before the UE can expect a retransmission of the same packet. This timer is fixed and not configured by RRC. For FDD the HARQ RTT Timer is set to 8 subframes. For TDD the HARQ RTT Timer is set to k + 4 subframes, where k is the interval between the downlink transmission and the transmission of associated HARQ feedback
  • drx-RetransmissionTimer indicates the maximum number of subframes for which UE should be monitoring PDCCH when a retransmission from the eNodeB is expected by the UE.

Same onDurationTimer value is applied for both long and short DRX cycles
If shortDRX-Cycle is configured, the value of longDRX-Cycle shall be a multiple of the shortDRX-Cycle value
UE indicates the support of Short DRX cycle in featureGroupIndicators bit- 4
UE indicates the support of Long DRX cycle and DRX command MAC control element (together) in featureGroupIndicators bit – 5

DRX Command MAC Control Element
We have seen that a number of timers which controls the UE’s DRX state (ON/OFF). In addition to these timers the eNodeB’s MAC can also control UE’s DRX behavior by transmitting a command called DRX Command as a MAC Control Element.
When the eNodeB doesn’t have any (more) data to be sent to the UE, it can transmit DRX Command MAC CE to the UE. Upon reception of DRX Command MAC CE, the UE enters short DRX cycle if configured, otherwise, the UE enters long DRX cycle.
In reality, DRX Command MAC CE shortens UE’s ON period. For example, if DRX Command MAC CE is received when either onDurationTimer or drx-Inactivity-Timer running, the UE stops the timer and enters into DRX cycle (Short/Long)
The DRX Command MAC control element is identified by a MAC PDU subheader with LCID as 11110. It has a fixed size of zero bits.

DRX Active Time
Active Time is the time during which the UE is considered to be monitoring PDCCH. The Active Time includes the time while:
onDurationTimer is running;
drx-InactivityTimer is running;
drx-RetransmissionTimer is running:
As an example, let us say that the UE has received new data in subframe #n on PDSCH. The UE starts HARQ RTT Timer in the same subframe #n. Upon the expiry of HARQ RTT timer, if the data for the corresponding HARQ process was not successfully decoded (CRC error) then the UE starts drx-RetransmissionTimer for the corresponding HARQ process. The UE needs to be monitoring PDCCH while this timer is running as the retransmission can be expected by the UE during this time.
mac-ContentionResolutionTimer is running:
The UE shall start mac-ContentionResolutionTimer from the next subframe after transmitting Msg3. Since the UE is waiting for the contention resolution which is via PDCCH reception on C-RNTI (in connected mode), the UE needs to be monitoring PDCCH. So the time duration in which mac-ContentionResolutionTimer is running is also considered as Active Time
Scheduling Request has been sent on PUCCH and is pending:
The UE has to be in active state from the next subframe after transmitting SR over the air on PUCCH. After transmitting SR, the UE should be DRX active in order to receive grant from the eNodeB
An uplink grant for a pending HARQ retransmission can occur and there is data in the corresponding HARQ buffer:
Let us say that the DCI0 for initial transmission is received at subframe #n, the UE shall become active at subframes n+8, n+16, n+24...n+(maxHARQTx-1)*8 for a possible retransmission
A PDCCH indicating a new transmission addressed to the C-RNTI of the UE has not been received after successful reception of a RAR for the preamble not selected by the UE
In the non-contention based RA, after receiving RAR, the UE should be in active state until PDCCH indicating new transmission addressed to C-RNTI of the UE is received

DRX Operation
When there is no data activity for drx-InactivityTimer amount of time (i.e., upon expiry of drx-InactivityTimer) or DRX Command MAC CE is received,
-  if the Short DRX cycle is configured, then the UE should  start or restart drxShortCycleTimer and start using Short DRX Cycle. Else if Short DRX cycle is not confired, the UE should use the Long DRX cycle
If drxShortCycleTimer expires, i.e., maximum number of short cycles are already used, then the UE should enter the Long DRX cycle
If a DRX Command MAC control element is received, the UE should stop onDurationTimer and drx-InactivityTimer
During the active time, the UE shall monitor the PDCCH; if the PDCCH indicates a new transmission (DL or UL) in subframe #n, then the UE should start/restart drx-InactivityTimer in subframe #n+1
The UE should start onDurationTimer in a subframe which satisfies the following equation (based on whether short DRX cycle is configured or not):
If the Short DRX Cycle is used,
[(SFN * 10) + subframe number] modulo (shortDRX-Cycle) = (drxStartOffset) modulo (shortDRX-Cycle)
else if the Long DRX Cycle is used
[(SFN * 10) + subframe number] modulo (longDRX-Cycle ) =  drxStartOffset
When downlink assignment has been configured (DL SPS), and if the configured assignment recurs in subframe that does not fall in Active time, the UE need not decode PDSCH. It is the eNodeB’s responsibility to make sure that the configured assignment falls in onDurationTimer
During RAR-window, if a subframe falls in non-Active time, then the UE monitors PDCCH only for RA-RNTI
Regardless of whether the UE is monitoring PDCCH or not, the UE receives and transmits HARQ feedback when such is expected.
When more than one serving cell is configured (CA), the same active time applies to all activated serving cell(s). For FDD, The UE maintains a set of 8 HARQ-RTT/drx-RetransmissionTimers for each serving cell. The UE monitors PDCCH on all serving cells, even if the active time corresponds to only one serving cell

Periodic CSI on PUCCH and SRS in DRX mode
When not in Active time, the UE shall not transmit periodic SRS (type-0 triggered SRS)
A release-8 UE shall not transmit periodic CSI on PUCCH when not in Active time.
In release-9, CQI-mask IE is introduced which limits CQI/PMI/PTI/RI reports to the on duration period of the DRX cycle. If the IE CQI-mask is not setup by RRC, CQI/PMI/RI/PTI on PUCCH shall not be reported when not in Active time; else UE should send CQI/PMI/RI/PTI on PUCCH only if onDurationTimer is running

When more than one serving cell is configured (CA), one value of cqi-Mask applies for all serving cells (the associated functionality is common i.e. not performed independently for each cell)


Reference: 3GPP TS 36.321, 36.213, 36.331
DRX calculations

Long DRX-cycle           Offset          onDurationTimer           Short DRX-cycle
                                                    

                                                                                              UL-DL Config
        Is Short DRX?         Is TDD?         

Long DRX Occasions
Long DRX Occasions will be displayed here


Short DRX Occasions
Short DRX Occasions will be displayed here


49 comments:

  1. Hi Kumar , If shortDRX-Cycle is configured, the value of longDRX-Cycle shall be a multiple of the shortDRX-Cycle value , could you please explain this ?? Why it has to be multiple of that?

    ReplyDelete
    Replies
    1. One reason could be based on the above shortDRXcycle equation: if the above condition is not satisfied, the OFF duration of the short cycle might overlap in the Onduration of LongCycle.

      Delete
    2. Yeah , that even i thought . But these two cycles are independent , right ? And what happens when Drx-inactivity Timer overlap either On Duration or Off duration ,or both??

      Delete
    3. Yes I wounder this too. First ShortDRXcycle starts, and after this starts LongDRXcycle. They do not run simultainiously?

      Also another question; is there any limitation to which of these parameters that cannot be changed in practice? Do you have any good reference to readn about practical implementration in an easy way?

      Delete
  2. This comment has been removed by the author.

    ReplyDelete
  3. This comment has been removed by the author.

    ReplyDelete
  4. Hi Kumar , can OnDurationTimer value be equal to ShortDrxCycle value ?

    ReplyDelete
  5. Hello KSP,

    Nice article. I have a question. Why DRX parameters are send by ENB to MME via Attach Request message ? I mean to say what does MME do with this DRX parameters.

    Thanks,

    ReplyDelete
  6. Hi Sakshi,

    The DRX parameter that you are referring to is Idle mode DRX parameter which is UE specific...

    The UE specific DRX parameter may be included in the DRX Parameter IE in the TRACKING AREA UPDATE REQUEST or ATTACH REQUEST message. The network shall replace any stored UE specific DRX parameter with the received parameter and use it for the downlink transfer of signalling and user data

    ReplyDelete
  7. Hello Kumar,

    Thank you for writing this blog.

    When LongDrxCycle=20 & OnDurationTimer=8 on TDD-Config2, the DRX behavior is shown as:

    On duration start : SFN = 0, Subframe = 0
    On duration stop : SFN = 0, Subframe = 9

    On duration start : SFN = 2, Subframe = 0
    On duration stop : SFN = 2, Subframe = 9

    Does it mean that UE listens to PDCCH from subframe 0 to 9 inclusively?

    Thanks in advance
    CC

    ReplyDelete
    Replies
    1. Yes your understanding is correct. Since OnDurationTimer = 8, the UE monitors PDCCH for 8 PDCCH subframes.

      Delete
    2. Hello Kumar,

      Thanks so much for your reply. Would you mind answering my question in the following scenario with drx-InactivityTimer & LongDRXCycle?

      Configuration:
      TDD ULDLConfig = 2
      LongDRXCycle = 20
      OnDurationTimer = 8
      DRXInactivityTimer = 4
      DRXRetransmissionTimer = 4
      DRXStartOffset = 0

      Abbreviation: x.y = SysFrame.SubFrame

      With the config above, here is a scenario:

      At 676.0: UE starts OnDuration
      At 676.9: OnDuration is expected to stop
      From 677.0 to 677.9: UE radio is expected to be off
      At 678.0: UE starts OnDuration

      Suppose, at 676.8, UE detects a PDCCH (new tx).
      At 677.3, DRXInactivityTimer expiries.

      This DRXInactivityTimer expiry instance falls into 677.0-677.9, does UE go radio off for 6 subframes & wakes up at 678.0 according to the DRX config?

      Hopfully the description above is clear enough to state my confusion. Otherwise, pls kindly let me rewrite my question.

      Thanks in advance
      CC

      Delete
    3. hello!
      I have the same question..Did you find the answer??
      Thank you in advance,
      katerina

      Delete
  8. Hi, I am new to LTE and just stumbled upon your blog, while looking for DRX operation in LTE. I have a query.. Is it possible for UE to send SR when DRX is on and none of the active timer (i.e. onDurationTimer or drx-InactivityTimer or drx-RetransmissionTimer or mac-ContentionResolutionTimer) is running; which means UE is actually not listening to any PDCCH?


    ReplyDelete
    Replies
    1. yes,
      When a DRX cycle is configured, the Active Time includes the time while: (Ref: 3GPP TS 36.321)
      - a Scheduling Request is sent on PUCCH and is pending.

      Delete
    2. Yes, the UE can send SR when not in Active time. Just remember the fact that DRX is meant for Reception but not for transmission. The UE could transmit even when in DRX-sleep...

      Delete
    3. Hi, are you sure UE can transmit even when in DRX sleep mode.?

      Delete
  9. This comment has been removed by the author.

    ReplyDelete
  10. Hello!! The period before the satisfaction of the equation to start the DRX-Cycle (after inactivity timer expiry or the reception of MAC control element) is ON or OFF ??? I think is OFF but i'm not sure.

    I would appreciated it if you could answer!!!
    Thank you in advance,
    katerina

    ReplyDelete
  11. Hello Kumar,

    Thanks for your blog.

    Could you please answer the below query I have:
    1. What is the impact of DRX on counter based DL latency
    2. What would happen to latency if i change the LongDRXCycle from 80ms to 320ms without ShortDRXCycle
    3. What would happen to latency if i increase the Ondurationtimer

    ReplyDelete
  12. Hello Kumar Sir,

    I have observed through Ping Test that when cDRX is ON. UE takes additional time to generate Scheduling Request on MAC layer compared to cDRX OFF. It can affect overall Ping RTT by ~20-30ms.

    But I am not sure why Ping packet generated at Application layer gets delayed to reach MAC layer within UE incase of cDRX ON.

    ReplyDelete
    Replies
    1. Hi,

      There shouldn't be any difference as far as the UL packet is concerned. It could be that the when the DL packet arrives at the eNB, the UE might be in sleep state, and the eNB sends the packet as soon as the active period starts.

      Try to reduce DRX cycle length to minimum or increase ON duration timer to the max. extent and see if it supports the theory above.

      Delete
    2. Hi Sir,

      Since DRX Inactivity Timer is already 100ms that means once UL Grant is allocated for UL Ping Request UE would not start short DRX cycle until next 100TTI and this is enough for Packet to go Server and come back to eNB.

      Since in my case, enb->sgw->server->sgw->enb this whole RTT is less than 20ms.

      I observe that main delay is between once packet is generated on Application layer and packet scheduled on PUSCH.

      Delete
    3. It appears to me that it is a bug on the UE's application side. Don't understand what it could be as I don't have any idea about your application implementation.

      Delete
  13. This comment has been removed by the author.

    ReplyDelete
  14. Hi,

    Thanks. If your question is about the UE connected to two serving cells (Carrier Aggregation) case, then the same DRX configuration applies to both of the cells.

    ReplyDelete
  15. Excellent Sir, thanks to make DRX understanding in such simple manner!!

    ReplyDelete
  16. This comment has been removed by the author.

    ReplyDelete
  17. Hi Kumar,
    Thanks for the artice. I does explain the concept and details.
    I have a question on how DRx is normally configured on network side?
    - Is it individual to an eNodeB, and the configured DRx times applicable to all the devices connecting on that ?
    - or can it be configured higher up in the network architecture and have custom settings for specific set of devices , say devices in a custom ID range, no matter where they connect?

    for eg, say LTE CAT1 IoT devices which prefer higher sleep times?
    Thank you

    ReplyDelete
    Replies
    1. I am guessing: It could be that the Core Network may provide the eNB with the information about the UE's subscription including QoS requirements ...so that the the eNB can provide the UE with a specific DRX configuration.

      Delete
  18. Hi Kumar,

    In case of TDD, does the UE monitor PDCCH in DwPTS and is it the special subframe also counted towards On duration subframes? Any spec reference for this behavior?

    Thanks!

    ReplyDelete
    Replies
    1. Yes. subframes including DwPTS are PDCCH subframes and they should be counted towards onDuration subframe.

      36.321 excerpts below
      For TDD serving cells, all downlink subframes and subframes including DwPTS of the TDD UL/DL configuration indicated by tdd-Config [8] of the cell represent PDCCH-subframes.

      onDurationTimer: Specifies the number of consecutive PDCCH-subframe(s) at the beginning of a DRX Cycle.

      Delete
  19. This comment has been removed by the author.

    ReplyDelete
  20. Hi Kumar,

    I don't understand the difference between the two if statement mentioned in 36.321 i.e.

    - if the PDCCH indicates a DL transmission or if a DL assignment has been configured for this subframe:
    - start the HARQ RTT Timer for the corresponding HARQ process;
    - stop the drx-RetransmissionTimer for the corresponding HARQ process.

    - if the PDCCH indicates a new transmission (DL or UL):
    - start or restart drx-InactivityTimer.

    Can you please help me in this.

    ReplyDelete
  21. Hi Sir,
    What happens if Inactive timer expires after next on duration cycle.
    Basically what if inactive timer enters into next Drx cycle.

    Or Is it mandatory to keep inactive timer so less that It expires in OFF period only ?

    Regards

    ReplyDelete
  22. Hi Kumar, Can Inactivity timer overlap with next On duration timer ??
    If it overlaps then what happens ?

    Regards,

    ReplyDelete
  23. in my network, drxLongCycle = 80ms
    but in log file DRX setting i have longDRX-CycleStartOffset:- sf320 means 3.2s.
    how to know from DRX log file setting, the value of long DRX cycle (On duration+sleep) ?

    ReplyDelete
  24. In DRX L3 Drive Test i have
    onDurationTimer: 6 ( psf8)
    This means normaly 8ms.
    But in my configuration setting, for that cell, i have 6ms
    Which is the correct value of onDurationTimer ? 6 or 8ms.

    ReplyDelete
  25. Hi,
    From deployment guidelines for VOIP , its seen that shortDrxCycle should be set to zero.
    Query is :
    What is the reason to recommend not to use ShortDrxCycle? 
    -Possible improvement from not using. 
    -Possible impact for using it.

    ReplyDelete
  26. Hi,
    What happens after longDRX-Cycle expires. UE starts shortDRX-Cycles or again a longDRX-Cucle is started?

    ReplyDelete
  27. What happens if PDCCH is not decoded during CDRX?

    ReplyDelete
  28. Hi,
    does measurement gap need to align with DRX ?
    What if measurement gap falls on sleep duration ?
    Thank you!!.
    BR

    ReplyDelete
  29. This comment has been removed by the author.

    ReplyDelete
  30. Hi Kumar,
    I'm having doubt in the below statement
    " If the IE CQI-mask is not setup by RRC, CQI/PMI/RI/PTI on PUCCH shall not be reported when not in Active time; else UE should send CQI/PMI/RI/PTI on PUCCH only if onDurationTimer is running"

    1. CQI/PMI/RI/PTI on PUCCH shall not be reported when not in Active time ==> this imply it can be transmitted in Active time
    2. UE should send CQI/PMI/RI/PTI on PUCCH only if onDurationTimer is running
    ==>on Durationtimer is running means ,UE is in active time right ?
    So whether CQI mask IE is there or not ,UE can send the CSI reports only when in active time ..
    So what is the actual use of CQI mask IE.
    Please correct me, if my understanding is wrong..

    ReplyDelete