DRX — Discontinuous Reception in 5G NR

1. Why DRX Exists, and What It Costs

A UE in RRC_CONNECTED has no way of knowing when the gNB will schedule it. The only safe default is to decode every PDCCH monitoring occasion the network has configured, on every serving cell, forever. That default is ruinous. Keeping an FR1 receiver chain, its LNA, its ADCs and the PDCCH blind-decoding engine powered and running costs on the order of a hundred times what a deep-sleep state costs, and for a phone with a chat app open the overwhelming majority of those decodes find nothing addressed to it.

Discontinuous Reception is the negotiated escape. The network tells the UE, in advance and in exact frame arithmetic, which monitoring occasions it is actually required to decode. Everything else the UE may skip, and skipping means it may power down the receiver entirely. Nothing else about the protocol changes: the search spaces, the DCI formats, the HARQ processes and the RNTIs are the same as without DRX. DRX only removes obligations.

The cost is latency, and it is paid asymmetrically. Uplink data is barely affected — the UE knows it has something to send, so it can send a Scheduling Request immediately and an SR pending on PUCCH is itself part of Active Time (§3). Downlink data is the problem. A packet that arrives at the gNB one millisecond after the UE went to sleep waits for the next cycle occasion, and with a 160 ms cycle that is up to 152 ms of pure, unrecoverable delay before the first PDCCH can even be sent (§11).

Table 1. Everything that can change the DRX state, who decides it, and what it looks like from outside. Only two rows are network-signalled; the rest happen silently inside the UE.

2. The Basic Cycle: onDuration, Sleep, and the Inactivity Extension

The skeleton is two numbers. drx-LongCycle sets the period; drx-onDurationTimer sets how much of each period the UE must spend monitoring. Once per cycle, at a moment both sides compute identically from the SFN (§5), the UE starts drx-onDurationTimer and monitors PDCCH until it expires. If nothing arrives, it stops monitoring and the receiver can go down until the next occasion.

That alone would be useless for real traffic, because a burst that starts in the last symbol of an onDuration would be truncated. drx-InactivityTimer fixes it: every PDCCH that indicates a new downlink or uplink transmission for this UE restarts it from zero TS 38.321 cl. 5.7. While it runs, the UE keeps monitoring. So a continuous stream of grants keeps the UE awake indefinitely, and Active Time collapses back to the onDuration floor only after the traffic actually stops for drx-InactivityTimer milliseconds.

Three consequences follow directly, and all three show up in logs:

• The duty cycle you configure is a floor, not a prediction. With any traffic at all the UE is awake far more than onDuration / cycle. Vendor power figures quoted against the floor are best-case only.
• A single grant can cost more than the whole onDuration. With drx-onDurationTimer ms4 and drx-InactivityTimer ms100, one stray grant buys 100 ms of monitoring for one transport block. This is why drx-InactivityTimer is the single most consequential DRX parameter for battery life, and why the DRX Command MAC CE exists (§7).
• The UE is never obliged to sleep. Every DRX rule is permissive. A UE that keeps its receiver on through the sleep window is fully compliant and indistinguishable from one that sleeps, from the network's side. Real power savings depend on the UE implementation actually taking the permission.

3. Active Time: the Definition That Decides Whether the Receiver Is On

Active Time is the term the spec actually uses, and it is the only thing that matters. onDuration and the inactivity extension are two of its contributors, not the whole of it. Active Time is defined as a union of conditions TS 38.321 cl. 5.7: if any one of them holds, the UE monitors PDCCH in that occasion. There is no priority and no ordering — a UE can be in Active Time with drx-onDurationTimer long expired.

Table 2. The Active Time union, TS 38.321 cl. 5.7. A UE monitoring PDCCH outside any onDuration is almost always one of the last four rows.

3.1 What the UE still does outside Active Time

Not monitoring PDCCH is not the same as transmitting nothing. Outside Active Time the UE still transmits HARQ feedback for transport blocks it already received, and still sends aperiodic CSI on PUSCH and aperiodic SRS when they have been triggered — those obligations were incurred while it was awake and are not cancelled. What it may skip is periodic CSI reporting on PUCCH and periodic or semi-persistent SRS. This asymmetry is why a UE deep in a long cycle can still be seen transmitting: the transmissions are the tail of earlier scheduling, not evidence that it is listening.

4. The Timer Set in Full

Ten fields inside DRX-Config describe the whole mechanism. Two of them are in symbols, two in slots, and the rest in milliseconds or fractions of a millisecond — mixing the units up is the most common arithmetic error when reading a configuration.

drx-onDurationTimer

drx-InactivityTimer

drx-LongCycleStartOffset

drx-SlotOffset

drx-ShortCycle

drx-ShortCycleTimer

drx-HARQ-RTT-TimerDL

drx-HARQ-RTT-TimerUL

drx-RetransmissionTimerDL

drx-RetransmissionTimerUL

Table 3. DRX-Config, TS 38.331. Enumerations abridged where the pattern is obvious; ... members and spares omitted. Slot- and symbol-based timers scale with the numerology of the active BWP, so the same configuration is a different wall-clock duration on a 30 kHz and a 120 kHz BWP.

5. Cycle Arithmetic: Exactly When onDuration Starts

Both sides must agree on the wake-up instant to the symbol, and they do it without signalling by evaluating the same congruence on the frame counter. The subframe index is used rather than the slot index precisely so the test is numerology-independent TS 38.321 cl. 5.7:

Long DRX cycle in use:
    [(SFN x 10) + subframe] modulo (drx-LongCycle)  ==  drx-StartOffset

Short DRX cycle in use:
    [(SFN x 10) + subframe] modulo (drx-ShortCycle)
                                  ==  drx-StartOffset modulo (drx-ShortCycle)

If the condition holds:
    start drx-onDurationTimer  drx-SlotOffset x (1/32) ms  after the
    beginning of that subframe

  SFN               0 .. 1023, wraps every 10240 ms
  subframe          0 .. 9, always 1 ms regardless of SCS
  drx-LongCycle     the CHOICE branch of drx-LongCycleStartOffset, in ms
  drx-StartOffset   the INTEGER inside that branch, 0 .. (cycle - 1)
  drx-SlotOffset    0 .. 31, in units of 1/32 ms

5.1 Worked example: a long cycle

5.2 Worked example: the same offset on the short cycle

The subframe index in the condition is deliberate. Slots per subframe vary with SCS (1, 2, 4, 8, 16), so a slot-based congruence would give different wake-up instants on different BWPs of the same cell. Working in subframes makes the cycle a wall-clock quantity, and drx-SlotOffset — in 1/32 ms — then provides sub-subframe placement that is still numerology-independent as a duration, even though which slot it lands on depends on the SCS. See the companion 02 Radio Frame Structure document for the SFN and slot numbering this rests on.

6. Short Cycle, Long Cycle, and the Transitions Between Them

One cycle length cannot serve both ends of a session. Immediately after a burst ends, more data is likely and a short cycle keeps latency low for a modest power cost. Ten seconds later, more data is unlikely and a long cycle is worth the latency. shortDRX gives the UE both, with an automatic one-way decay from short to long.

Table 4. The complete cycle-selection state table, TS 38.321 cl. 5.7. There is no transition from long back to short except by way of Active Time — the UE must be given traffic first.

Sizing is a two-parameter decision, and the useful quantity is the product. With drx-ShortCycle = ms40 and drx-ShortCycleTimer = 8, the UE spends 320 ms on the short cycle after every burst before falling back — which is eight extra wake-ups if no further data arrives. Set against a drx-LongCycle of ms160 that is two long-cycle periods spent at four times the wake-up rate, so the short cycle must earn its place from the actual inter-burst distribution of the traffic, not from intuition.

7. The DRX MAC Control Elements

Two MAC Control Elements exist purely to shorten Active Time, and both are zero-length: they carry no payload at all, and the LCID in the subheader is the entire message TS 38.321 cl. 6.1.3.3, 6.1.3.4. They travel on DL-SCH like any other CE, so they are subject to HARQ, they can be lost, and there is no acknowledgement at MAC or RRC level.

Table 5. The two DRX CEs, TS 38.321 Table 6.2.1-1. Encoded as a single octet each: two reserved bits then the six-bit LCID, giving 0x3C and 0x3B on the wire.

8. DRX and HARQ: Sleeping Through a Retransmission

HARQ creates an obligation that outlives Active Time. If the UE NACKs a transport block, a retransmission is owed to it, and the UE must be listening when the grant arrives. Naively that means staying awake from the NACK until the retransmission — potentially a long time on a loaded cell. The four HARQ-related DRX timers exist to cut that window down to only the part where a grant is actually possible.

The mechanism has two halves, and they do opposite things:

• drx-HARQ-RTT-TimerDL is a licence to sleep. It starts in the first symbol after the end of the transmission carrying the HARQ feedback for that process, and it encodes the minimum turnaround the gNB physically needs to process the NACK and prepare a retransmission. During it, no grant for that process can arrive, so the UE has nothing to listen for. It is not an Active Time contributor.
• drx-RetransmissionTimerDL is an obligation to listen. It starts when the RTT timer expires and the transport block was not successfully decoded. It is an Active Time contributor, and it bounds how long the UE will wait for the retransmission grant before giving up on it.

Both are per-HARQ-process. A UE with eight processes can have eight RTT timers and eight retransmission timers in different states at once, which is why PDCCH monitoring outside onDuration often looks ragged rather than block-shaped in a log. The uplink pair works identically, with drx-HARQ-RTT-TimerUL starting after the end of the first repetition of the corresponding PUSCH transmission.

The interaction runs the other way too. If drx-RetransmissionTimerDL is configured too short for the cell's actual scheduling delay, the UE stops listening before the gNB gets round to the retransmission. The gNB sends it anyway, gets no HARQ feedback, and the process stalls until RLC notices the missing PDU and asks for it again — turning a 1 ms HARQ recovery into a tens of milliseconds RLC recovery. In logs this appears as HARQ DTX on retransmissions only, never on first transmissions.

9. DRX Groups, Carrier Aggregation and Dual Connectivity

DRX is configured per cell group, inside mac-CellGroupConfig. That one sentence answers most carrier-aggregation questions: all serving cells of a cell group share one DRX configuration and one Active Time, so a UE with a PCell and three SCells wakes and sleeps on all four together. It cannot monitor the PCell while an SCell sleeps, because there is only one set of timers.

Table 6. DRX scoping across CA and DC. The one-Active-Time-per-cell-group rule is the fact that resolves most confusion; the Rel-16 second DRX group is the only partial exception.

10. C-DRX and I-DRX: Two Mechanisms, One Name

The word DRX is used for two things that share only a concept. Connected-mode DRX (C-DRX) is everything above: dedicated RRC configuration, PDCCH monitoring for the UE's own C-RNTI, timers that react to grants. Idle-mode DRX (I-DRX) is the paging cycle: broadcast configuration, PDCCH monitoring for the P-RNTI, no reaction to anything because there is nothing scheduled to react to. They are specified in different documents and do not interact except in one place — a UE in RRC_CONNECTED does not monitor paging occasions for its own paging, because the network can reach it directly.

Table 7. C-DRX and I-DRX side by side. The companion 19 Paging document covers the I-DRX column in full; the companion 14 RRC States document covers which applies when.

11. Power, Latency and Duty Cycle: Worked Numbers

The trade-off is quantifiable, and it is worth doing the arithmetic once because the intuition is wrong. Power saving saturates quickly; latency does not.

11.1 Duty cycle and receiver power

11.2 The latency a sleeping UE adds to a downlink packet

A packet arriving while the UE is asleep waits until the next onDuration. For a packet arrival uniformly distributed over the cycle, with cycle C and onDuration On, the added delay is zero with probability On/C and uniform on [0, C − On] otherwise:

worst case  =  C - On
mean        =  ((C - On) / C)  x  ((C - On) / 2)   =  (C - On)^2 / 2C

Table 8. Illustrative profile shapes with the arithmetic of §11.2 applied. Duty figures are the no-traffic floor. The last row is the interesting one: matching the cycle to a known packet period beats any generic tuning, because the mean added latency stops being (C-On)^2/2C and becomes approximately zero.

12. Rel-16 Power Saving Beyond DRX

Rel-16 added a set of features that do not replace DRX but adapt it dynamically. The common theme is that Rel-15 DRX is a static contract — the wake-up pattern is fixed until RRC reconfigures it — and the network often knows, a few milliseconds in advance, that a particular wake-up will be wasted.

12.1 DCP: the wake-up signal (DCI format 2_6)

DCP — DCI with CRC scrambled by PS-RNTI — is a small group-common DCI monitored shortly before the onDuration would start TS 38.213 cl. 10.3. It carries one wake-up indication bit per UE in the group, at a bit position given by ps-PositionDCI-2-6 in a payload of sizeDCI-2-6 bits. If the bit says wake, the UE starts drx-onDurationTimer normally. If it says sleep, the UE does not start it at all and the whole onDuration is skipped.

ps-RNTI

ps-Offset

sizeDCI-2-6

ps-PositionDCI-2-6

ps-Wakeup

ps-TransmitPeriodicL1-RSRP

Table 9. DCP-Config fields, TS 38.331. ps-Wakeup is the field to read first when diagnosing anything DCP-related.

12.2 Search space set group switching

Rather than deciding whether to monitor at all, SSSG switching changes how much the UE monitors. Search space sets are tagged into groups by searchSpaceGroupIdList, and the network moves the UE between groups — typically a dense group for active traffic and a sparse group for idle periods — either explicitly with a bit in DCI format 2_0, or implicitly after searchSpaceSwitchTimer slots without scheduling. searchSpaceSwitchDelay bounds how long the UE may take to apply the change. The saving comes from fewer blind decodes per slot rather than fewer awake slots, so it composes with DRX instead of competing with it. See the companion 08 Scheduling document for the search space structures involved.

12.3 Cross-slot scheduling adaptation

A UE that might be scheduled with K0 = 0 — PDSCH in the same slot as its PDCCH — has to buffer every slot's samples while it decodes PDCCH, because the data might already have arrived. Rel-16 lets the network signal a minimum applicable scheduling offset (minimumSchedulingOffsetK0 for downlink, the K2 equivalent for uplink) and change it with DCI. Once the minimum is at least one slot, the UE can stop buffering speculatively, run its receiver front-end at lower power, and micro-sleep between PDCCH and PDSCH. The cost is a slot or more of added scheduling latency on every transmission, which is why the value is adapted rather than fixed.

12.4 SCell dormancy and dormantBWP

Deactivating an SCell and re-activating it is expensive — hundreds of milliseconds including CSI re-acquisition. A dormant BWP is the cheap middle state: the SCell is switched to the BWP identified by dormantBWP-Id, in which the UE performs no PDCCH monitoring but continues CSI measurement and reporting. Reactivation is therefore immediate, because the channel estimate is current. Dormancy is indicated by DCI format 1_1 while the UE is in Active Time (withinActiveTimeConfig) and by DCI format 2_6 while it is not (outsideActiveTimeConfig), so DCP and dormancy share one DCI.

13. Rel-17 and Rel-18: eDRX, PEI and PDCCH Skipping

Rel-17's power-saving work is aimed mostly at the idle-mode side and at RedCap devices, which have very different economics from a smartphone: a sensor that reports twice an hour cares nothing about a two-second paging delay and everything about ten years of battery.

• Extended DRX (eDRX) raises the idle- and inactive-mode paging cycle beyond the Rel-15 ceiling of 2.56 s, up to 10.24 s, by locating the paging occasion within a paging hyperframe rather than within the 1024-frame SFN space. It is gated by broadcast permission and by UE capability, and it is specific to RedCap and low-power use — a normal smartphone is not offered it.
• Paging Early Indication (PEI) puts a small group-common DCI (format 2_7, with PEI-RNTI) shortly before a paging occasion, so a UE can learn there is no page for my group without decoding the Paging PDCCH and its PDSCH. It is the idle-mode analogue of DCP. Configured by pei-Config in SIB.
• PDCCH monitoring adaptation extends the Rel-16 SSSG idea with explicit PDCCH skipping: a field in a scheduling DCI (formats 0_1/1_1/0_2/1_2) tells the UE to skip PDCCH monitoring for a duration drawn from pdcch-SkippingDurationList. Unlike DRX this is immediate and per-DCI, so the network can stop monitoring the instant it knows a burst has ended, without spending a MAC CE.

Rel-18 shifts the emphasis from UE power to network power. Cell DTX/DRX gives the gNB its own discontinuous transmission and reception pattern, so a lightly loaded cell can stop transmitting reference signals and stop listening for uplink during configured windows. For DRX debugging this matters in one specific way: a UE's onDuration can now land inside a cell's non-transmission window, and the resulting missed scheduling opportunity is a network-side energy-saving decision, not a UE fault.

14. Configuration Reference (ASN.1 and Ranges)

DRX-Config sits at CellGroupConfig -> mac-CellGroupConfig -> drx-Config, as a SetupRelease. Abridged to the fields that determine behaviour; ... marks omitted enumeration members, spares and extension markers:

DRX-Config ::= SEQUENCE {
    drx-onDurationTimer               CHOICE {
        subMilliSeconds                   INTEGER (1..31),
        milliSeconds                      ENUMERATED {
            ms1, ms2, ms3, ms4, ms5, ms6, ms8, ms10, ms20, ms30, ms40,
            ms50, ms60, ms80, ms100, ms200, ms300, ms400, ms500, ms600,
            ms800, ms1000, ms1200, ms1600, spare8, ... }
    },
    drx-InactivityTimer               ENUMERATED {
        ms0, ms1, ms2, ms3, ms4, ms5, ms6, ms8, ms10, ms20, ms30, ms40,
        ms50, ms60, ms80, ms100, ms200, ms300, ms500, ms750, ms1280,
        ms1920, ms2560, spare10, ... },
    drx-HARQ-RTT-TimerDL              INTEGER (0..56),   -- symbols
    drx-HARQ-RTT-TimerUL              INTEGER (0..56),   -- symbols
    drx-RetransmissionTimerDL         ENUMERATED {
        sl0, sl1, sl2, sl4, sl6, sl8, sl16, sl24, sl33, sl40, sl64,
        sl80, sl96, sl112, sl128, sl160, sl320, spare15, ... },
    drx-RetransmissionTimerUL         ENUMERATED { ... same list ... },
    drx-LongCycleStartOffset          CHOICE {
        ms10     INTEGER (0..9),
        ms20     INTEGER (0..19),
        ms32     INTEGER (0..31),
        ms40     INTEGER (0..39),
        ms60     INTEGER (0..59),
        ms64     INTEGER (0..63),
        ms70     INTEGER (0..69),
        ms80     INTEGER (0..79),
        ms128    INTEGER (0..127),
        ms160    INTEGER (0..159),
        ms256    INTEGER (0..255),
        ms320    INTEGER (0..319),
        ms512    INTEGER (0..511),
        ms640    INTEGER (0..639),
        ms1024   INTEGER (0..1023),
        ms1280   INTEGER (0..1279),
        ms2048   INTEGER (0..2047),
        ms2560   INTEGER (0..2559),
        ms5120   INTEGER (0..5119),
        ms10240  INTEGER (0..10239)
    },
    shortDRX                          SEQUENCE {
        drx-ShortCycle                    ENUMERATED {
            ms2, ms3, ms4, ms5, ms6, ms7, ms8, ms10, ms14, ms16, ms20,
            ms30, ms32, ms35, ms40, ms64, ms80, ms128, ms160, ms256,
            ms320, ms512, ms640, spare9, ... },
        drx-ShortCycleTimer               INTEGER (1..16)
    }                                                          OPTIONAL,
    drx-SlotOffset                    INTEGER (0..31)    -- units of 1/32 ms
}

Listing 1. Abridged from TS 38.331. Note that the cycle and its offset are one field, that shortDRX is optional as a block, and that drx-SlotOffset is mandatory even when it is zero.

DCP-Config-r16 ::= SEQUENCE {
    ps-RNTI-r16                       RNTI-Value,
    ps-Offset-r16                     INTEGER (1..120),
    sizeDCI-2-6-r16                   INTEGER (1..maxDCI-2-6-Size-r16),
    ps-PositionDCI-2-6-r16            INTEGER (0..maxDCI-2-6-Size-1-r16)
                                                               OPTIONAL,
    ps-WakeUp-r16                     ENUMERATED {true}        OPTIONAL,
    ps-TransmitPeriodicL1-RSRP-r16    ENUMERATED {true}        OPTIONAL,
    ps-TransmitOtherPeriodicCSI-r16   ENUMERATED {true}        OPTIONAL,
    ...
}

Listing 2. DCP-Config, Rel-16, abridged from TS 38.331. The three optional true-only fields are all presence means enabled — absence is the aggressive setting in each case.

15. Failure Modes and What Each One Means

DRX has no failure indication. Nothing in the protocol reports that the UE and the gNB disagree about when the receiver is on, and no timer expires to tell you. Every failure mode below is diagnosed indirectly, from HARQ statistics, latency distributions or power measurements.

Table 10. DRX failure modes. Note the second column: eight of the ten are detected by nobody, which is the defining characteristic of this mechanism and the reason the checklist in §18 starts with recomputing the arithmetic.

16. Illustrative Message Traces

16.1 The configuration the UE is given

RRCReconfiguration
 criticalExtensions rrcReconfiguration
  secondaryCellGroup / masterCellGroup
   mac-CellGroupConfig
    drx-Config setup
     drx-onDurationTimer
      milliSeconds ................. ms8
     drx-InactivityTimer ........... ms40
     drx-HARQ-RTT-TimerDL .......... 56       -- symbols; 2.0 ms @ 30 kHz
     drx-HARQ-RTT-TimerUL .......... 56
     drx-RetransmissionTimerDL ..... sl16     -- slots;   8.0 ms @ 30 kHz
     drx-RetransmissionTimerUL ..... sl16
     drx-LongCycleStartOffset
      ms80 ......................... 27       -- cycle 80 ms, offset 27
     shortDRX
      drx-ShortCycle ............... ms20
      drx-ShortCycleTimer .......... 4        -- 4 x 20 = 80 ms residency
     drx-SlotOffset ................ 16       -- 16/32 = 0.5 ms
    schedulingRequestConfig ........ (see companion 10 BSR, PHR, SR)
    bsr-Config ..................... (idem)

-- derived by the UE, not signalled:
--   long-cycle occasions  : SFN = 2 mod 8, subframe 7, +0.5 ms  -> slot 15
--   short-cycle occasions : subframe 7 of every even SFN, +0.5 ms
--   floor duty cycle      : 8 / 80 = 10%

Listing 3. A drx-Config as it would appear decoded, with the arithmetic of §5 already applied. The derived lines are what a good MAC trace prints alongside the configuration.

16.2 An empty cycle, then a burst

-- C-RNTI 0x5C11 throughout, 30 kHz SCS, config as above

09:41:02.007  [MAC] DRX cycle occasion  SFN 82 sf 7  slot 1655
              cycle=long(80)  offset=27  slotOffset=16
              -> start drx-onDurationTimer (ms8 = 16 slots)
09:41:02.007  [MAC] ACTIVE TIME begin   reason=onDurationTimer
09:41:02.015  [MAC] drx-onDurationTimer expiry, no PDCCH decoded
09:41:02.015  [MAC] ACTIVE TIME end     -> sleep 72 ms

09:41:02.087  [MAC] DRX cycle occasion  SFN 90 sf 7
              -> start drx-onDurationTimer
09:41:02.087  [MAC] ACTIVE TIME begin   reason=onDurationTimer
09:41:02.090  [PHY] PDCCH DCI 1_1  C-RNTI 0x5C11  HARQ 2  NDI toggled
09:41:02.090  [MAC] new DL transmission -> start drx-InactivityTimer ms40
09:41:02.091  [PHY] PDSCH 1248 bytes, decoded OK -> ACK on PUCCH
09:41:02.091  [MAC] start drx-HARQ-RTT-TimerDL(HARQ 2) = 56 sym
09:41:02.093  [MAC] drx-HARQ-RTT-TimerDL(HARQ 2) expiry, TB decoded OK
              -> drx-RetransmissionTimerDL NOT started
09:41:02.095  [MAC] drx-onDurationTimer expiry
              -> ACTIVE TIME continues, reason=InactivityTimer
09:41:02.104  [PHY] PDCCH DCI 1_1  HARQ 3  NDI toggled
09:41:02.104  [MAC] new DL transmission -> RESTART drx-InactivityTimer ms40
              (28 ms of the previous run discarded)
09:41:02.144  [MAC] drx-InactivityTimer expiry
09:41:02.144  [MAC] shortDRX configured -> start drx-ShortCycleTimer (4)
              -> cycle=short(20)
09:41:02.144  [MAC] ACTIVE TIME end     -> sleep
09:41:02.147  [MAC] DRX cycle occasion  SFN 94 sf 7   cycle=short(20)
              -> start drx-onDurationTimer

Listing 4. One empty cycle and one cycle with traffic. The two lines worth reading twice are the InactivityTimer restart at .104 and the cycle switch at .144.

16.3 A retransmission with a sleep inside it

-- same UE; drx-InactivityTimer temporarily reconfigured to ms0 to make
-- the HARQ-driven wake-ups visible on their own

09:44:17.400  [MAC] DRX cycle occasion  SFN 174 sf 7
              -> start drx-onDurationTimer (ms4)
09:44:17.401  [PHY] PDCCH DCI 1_1  HARQ 5  NDI toggled  MCS 22
09:44:17.401  [MAC] drx-InactivityTimer = ms0 -> no extension
09:44:17.402  [PHY] PDSCH 2408 bytes  CRC FAIL
09:44:17.403  [PHY] PUCCH HARQ-ACK  HARQ 5 = NACK
09:44:17.403  [MAC] start drx-HARQ-RTT-TimerDL(HARQ 5) = 56 sym = 2.0 ms
09:44:17.404  [MAC] drx-onDurationTimer expiry
09:44:17.404  [MAC] ACTIVE TIME end
              -- HARQ-RTT timer is running but is NOT Active Time
              -> receiver OFF for 1.3 ms
09:44:17.405  [MAC] drx-HARQ-RTT-TimerDL(HARQ 5) expiry, TB NOT decoded
              -> start drx-RetransmissionTimerDL(HARQ 5) = sl16 = 8.0 ms
09:44:17.405  [MAC] ACTIVE TIME begin   reason=RetransmissionTimerDL
09:44:17.407  [PHY] PDCCH DCI 1_1  HARQ 5  NDI unchanged  -- retransmission
09:44:17.407  [MAC] stop drx-RetransmissionTimerDL(HARQ 5)
              -- retransmission grant: drx-InactivityTimer NOT restarted
09:44:17.408  [PHY] PDSCH combined with earlier attempt, decoded OK
09:44:17.410  [PHY] PUCCH HARQ-ACK  HARQ 5 = ACK
09:44:17.410  [MAC] start drx-HARQ-RTT-TimerDL(HARQ 5) = 2.0 ms
09:44:17.410  [MAC] ACTIVE TIME end     -> sleep to SFN 182 sf 7
09:44:17.412  [MAC] drx-HARQ-RTT-TimerDL(HARQ 5) expiry, TB decoded OK
              -> drx-RetransmissionTimerDL NOT started

Listing 5. The 1.3 ms of sleep at 17.404 is the whole reason drx-HARQ-RTT-TimerDL exists. Note also that Active Time ends at 17.410 even though a PDSCH was received two milliseconds earlier.

16.4 The DRX Command MAC CE

09:47:55.612  [PHY] PDCCH DCI 1_1  C-RNTI 0x5C11  HARQ 1  NDI toggled
09:47:55.613  [MAC-DL] MAC PDU, 34 octets
              subheader  R=0 F=0 LCID=1  L=32     -- DCCH SDU
                (RRC message, 32 octets)
              subheader  R=0 R=0 LCID=60          -- 0x3C
                DRX Command MAC CE                -- zero length
              subheader  R=0 R=0 LCID=63          -- padding to 34 octets
09:47:55.613  [MAC] DRX Command MAC CE received
              -> stop drx-onDurationTimer
              -> stop drx-InactivityTimer  (37 ms remaining, discarded)
              -> shortDRX configured: start drx-ShortCycleTimer (4 x ms20)
              -> cycle = short(20)
09:47:55.613  [MAC] ACTIVE TIME end

09:47:55.693  [MAC] drx-ShortCycleTimer expiry -> cycle = long(80)

-- alternative ending: the gNB skips the short-cycle stage
09:47:55.627  [MAC-DL] MAC PDU, 1 octet
              subheader  R=0 R=0 LCID=59          -- 0x3B
                Long DRX Command MAC CE           -- zero length
09:47:55.627  [MAC] Long DRX Command MAC CE received
              -> stop drx-ShortCycleTimer
              -> cycle = long(80)
              -- next onDuration at SFN = 2 mod 8, subframe 7

Listing 6. Both CEs on the wire. The Long DRX Command arrives as a single-octet MAC PDU, which is as small as a downlink transmission can usefully be.

16.5 A failure path: offset mismatch after reconfiguration

-- gNB believes offset 27; UE applied offset 7 (a stale configuration
-- retained after a reconfiguration the UE did not fully apply)

[gNB-MAC] 10:02:14.007  UE 0x5C11 onDuration expected  SFN 82 sf 7
[gNB-MAC] 10:02:14.009  DL data queued (1240 B) -> schedule DCI 1_1
[gNB-PHY] 10:02:14.010  PDSCH sent, HARQ 4, awaiting PUCCH k1=2
[gNB-PHY] 10:02:14.011  PUCCH occasion empty          -- HARQ 4 = DTX
[gNB-MAC] 10:02:14.012  retransmit HARQ 4 (adaptive)
[gNB-PHY] 10:02:14.014  PUCCH occasion empty          -- HARQ 4 = DTX
[gNB-MAC] 10:02:14.016  retransmit HARQ 4, RV 2
[gNB-PHY] 10:02:14.018  PUCCH occasion empty          -- HARQ 4 = DTX
[gNB-MAC] 10:02:14.020  HARQ 4 abandoned -> RLC will recover

[UE-MAC]  10:02:13.987  DRX cycle occasion  SFN 82 sf 7?  no
                        [(82 x 10) + 7] mod 80 = 27 ... offset in use = 7
                        27 != 7  -> not an occasion, stay asleep
[UE-MAC]  10:02:14.047  DRX cycle occasion  SFN 88 sf 7
                        [(88 x 10) + 7] mod 80 = 7 == offset  -> wake
                        -> start drx-onDurationTimer

-- signature: three DTX in a row on a FIRST transmission, then a clean
-- exchange exactly 20 ms later; repeating every 80 ms. Not a radio fault.

Listing 7. An offset mismatch, seen from both sides. Three DTX on a first transmission followed by a clean exchange one offset-difference later, repeating at the cycle period, is the fingerprint.

17. Release Deltas: Rel-15 to Rel-18

Table 11. DRX-relevant changes by release. Confirm feature presence against the UE capability exchange before assuming any of it is active — see the companion 26 UE Capability document.

18. Reading DRX in Logs: A Checklist

1. Recompute the cycle occasions from both sides' configuration. Take the SFN from the log, evaluate [(SFN x 10) + subframe] mod cycle, and compare against drx-StartOffset (§5). Do this before anything else; an offset or cycle mismatch explains symptoms that otherwise look like a radio fault.

2. Convert every timer into wall-clock time for the BWP actually in use. The HARQ RTT timers are symbols, the retransmission timers are slots. A configuration is a different mechanism at 30 kHz and at 120 kHz (§4).

3. Separate HARQ DTX from HARQ NACK. DTX means the UE was not listening and points at DRX; NACK means it was listening and points at the radio. This single distinction resolves most DRX investigations.

4. Establish which cycle is in use at the moment of interest. Long, short, or Active Time. drx-ShortCycleTimer expiry changes the wake-up spacing with no signalling at all, so infer it from the intervals, not from messages.

5. Check whether the PDCCH monitoring you are seeing outside onDuration is a retransmission timer. Match it against a HARQ process that NACKed one drx-HARQ-RTT-Timer earlier (§8). If it matches, it is correct behaviour.

6. Look for the DRX Command MAC CE. LCID 60 on DL-SCH, a single octet, easy to miss in a PDU dump. Its presence tells you the scheduler is actively managing Active Time; its absence tells you the whole drx-InactivityTimer is being spent every burst.

7. Measure the ratio of Active Time to scheduled slots. A UE awake for many multiples of the time it is actually being scheduled has drx-InactivityTimer set too long — that ratio is a more useful number than the configured duty cycle.

8. Before blaming DRX for a UE that stopped listening, rule out the other four Rel-16+ reasons: DCP said sleep, a dormant BWP, a sparse search space set group, or a PDCCH skipping instruction (§12, §13).

9. For latency complaints, compare the measured delay against (C - On)^2 / 2C. If the measured mean is close to the prediction, the configuration is working as designed and the fix is a shorter cycle, not debugging. If it is much worse, look at PDCCH load during onDuration.

10. Check the offset distribution across UEs in the cell. Identical drx-StartOffset values produce synchronised wake-ups and periodic CCE exhaustion that looks like a capacity problem (§15).

19. Glossary

drx-StartOffset

20. References

• 3GPP TS 38.321 — NR MAC protocol specification. Clause 5.7 (DRX: Active Time definition, cycle start condition, timer handling, HARQ RTT and retransmission timer rules, short/long cycle transitions), 5.4.4 (Scheduling Request, for the pending-SR contributor), 5.4.5 (BSR), 6.1.2 (MAC subheader formats), 6.1.3.3 / 6.1.3.4 (DRX Command and Long DRX Command MAC CEs), Table 6.2.1-1 (DL-SCH LCID values).
• 3GPP TS 38.331 — RRC protocol specification. DRX-Config, MAC-CellGroupConfig, DCP-Config, SearchSpace, BWP-DownlinkDedicated and the dormant BWP fields, PCCH-Config (for I-DRX), pei-Config.
• 3GPP TS 38.213 — Physical layer procedures for control. Clause 10.3 (monitoring DCI format 2_6 for DCP), clause 10.4 (search space set group switching), clause 10.1 (search space monitoring generally).
• 3GPP TS 38.212 — Multiplexing and channel coding. DCI format 2_6 contents, and the scheduling DCI fields carrying PDCCH skipping and SSSG indications.
• 3GPP TS 38.304 — UE procedures in Idle and Inactive. Paging Frame and Paging Occasion derivation, the I-DRX cycle, and the Rel-17 eDRX extension.
• 3GPP TS 38.300 — NR overall description. Clause 9.2.4 and the DRX overview text placing the mechanism in the RRC state model.
• 3GPP TS 38.133 — Requirements for support of radio resource management. Interruption and delay requirements the UE is allowed when waking and switching BWPs, which bound how aggressive a DRX profile can usefully be.

Companion documents in this set

• 02 Radio Frame Structure — SFN, subframes and slots; the numbering the cycle arithmetic of §5 operates on.
• 03 Random Access — ra-ContentionResolutionTimer, an Active Time contributor, and the CFRA case in the last Active Time row.
• 05 HARQ — the NDI semantics that decide whether a PDCCH restarts drx-InactivityTimer, and the process state the HARQ RTT timers key off.
• 07 MAC PDU and Control Elements — the general subheader format that §7 specialises for zero-length CEs.
• 08 Scheduling — search spaces, CORESETs and PDCCH monitoring occasions; what DRX switches off.
• 10 BSR, PHR, SR — the Scheduling Request whose pending state is an Active Time contributor.
• 12 Beam Failure Recovery — why ps-TransmitPeriodicL1-RSRP matters, and the CFRA that keeps the UE awake awaiting a response.
• 14 RRC States — which of C-DRX and I-DRX applies in each state.
• 16 RLM and RLF — what happens when a UE becomes unreachable because it is not listening.
• 19 Paging — the I-DRX column of the table in §10, in full.
• 21 Measurement Gaps and SMTC — the other periodic pattern the UE must obey, and its interaction with onDuration.
• 26 UE Capability — where DCP, SSSG switching, dormancy and eDRX support is declared.