DRX — Discontinuous Reception in LTE 4G

Introduction

Connected-mode DRX is a MAC-layer duty cycle for PDCCH monitoring, defined in TS 36.321 and configured over RRC (TS 36.331). It applies while the UE is in RRC_CONNECTED with a live C-RNTI: instead of decoding the PDCCH every 1 ms subframe to catch a grant, the UE concentrates its monitoring into predictable windows and powers the receiver down in between.

You meet DRX on essentially every real data session. Web, messaging and video traffic is bursty, with long idle gaps, and DRX is what lets the UE sleep through those gaps without dropping the connection or blowing the latency budget. It is the single biggest lever on connected-mode battery life, and it is tuned constantly against the traffic mix — too aggressive and latency and throughput suffer; too timid and the battery drains.

Because the whole feature is a handful of deterministic timers running off the same SFN/subframe clock at both ends, DRX faults localise cleanly: a mis-set drx-InactivityTimer, an offset that puts the on-duration in the wrong subframe, a HARQ retransmission timer that never fires, or a measurement gap that collides with the on-duration. Reading those timer states off a trace — and knowing which ones count as Active Time — is the whole skill.

Why DRX is needed

Concretely, in RRC_CONNECTED the UE must in principle monitor the PDCCH every subframe to catch a DL assignment or UL grant addressed to its C-RNTI. At 1 ms per subframe that is a receiver running flat out, mostly to hear silence — a huge, needless drain given how bursty real traffic is. DRX cuts receiver-on time dramatically by breaking time into cycles with a short awake window and a long sleep opportunity, without tearing down the connection (which would cost a full re-setup) and without unbounded latency (the on-duration guarantees a periodic wake-up). The trick that makes it safe is that the eNB tracks the identical timer state and only ever schedules the UE while it is guaranteed awake.

What Connected-Mode DRX Is

In RRC_CONNECTED the UE must, in principle, monitor the PDCCH in every subframe to catch a DL assignment or UL grant addressed to its C-RNTI. At 1 ms per subframe that is a receiver running flat out, mostly to hear silence. DRX (defined in the MAC specification, TS 36.321) breaks time into cycles: a short awake window at the start of each cycle when the UE watches the PDCCH, followed by an opportunity for sleep when it may power the receiver down. As long as nothing is scheduled, the UE keeps sleeping between wake-ups.

DRX is configured entirely by RRC but executed entirely by MAC. The eNB decides the cycle lengths and timer durations based on the UE's traffic profile and its own scheduling policy, signals them once in an RRCConnectionReconfiguration, and from then on both ends run the same deterministic state machine off the same subframe clock. There is no per-subframe negotiation and no handshake to enter or leave a sleep window — the eNB simply knows, from the identical timer state it tracks for the UE, exactly which subframes the UE is guaranteed to be awake, and it only schedules the UE in those subframes. That shared, drift-free view of time is what makes DRX safe: the UE can sleep with confidence that it will never miss a grant, because the eNB will never send one while the UE is asleep.

Active Time — When the UE Actually Listens

Active Time is the umbrella concept and the single most important definition in the whole feature: it is the total time within a DRX cycle during which the UE is required to monitor the PDCCH. Everything else — every timer, every cycle, every MAC CE — exists only to grow or shrink the Active Time. Per TS 36.321 the UE is in Active Time whenever any of the following is true:

• onDurationTimer is running — the scheduled wake-up at the start of the cycle;
• drx-InactivityTimer is running — the extension that keeps the UE awake while traffic flows;
• drx-RetransmissionTimer is running — the wake-up that watches for a downlink HARQ retransmission;
• mac-ContentionResolutionTimer is running — during random-access contention resolution;
• a Scheduling Request has been sent on PUCCH and is still pending;
• an uplink grant for a pending HARQ retransmission can occur and there is data in the corresponding HARQ buffer (a consequence of LTE's synchronous UL HARQ, where the retransmission instant is deterministic).

Whenever none of these holds, the UE is outside Active Time and may switch its receiver off. Notice the structure: the on-duration is the only guaranteed, periodic contributor — it fires every cycle no matter what the traffic is doing. All the others are reactive; they appear only because something is in flight. This split is the key to reading any DRX trace: the on-duration is the heartbeat, and the reactive timers are the UE staying awake because it has a reason to.

The DRX Cycle — On-Duration, Inactivity, Sleep

Every cycle begins at a fixed point defined by longDRX-CycleStartOffset, an IE that carries both the long cycle length (longDRX-Cycle, in subframes — sf10, sf20, sf32, up to sf2560) and the start offset (the subframe within the cycle where the on-duration begins). The UE knows a cycle is starting when the subframe number satisfies the standard modulo condition: [(SFN × 10) + subframe] mod longDRX-Cycle = drxStartOffset. At that instant it starts onDurationTimer and begins monitoring the PDCCH.

If, during the on-duration (or any later Active Time), the UE receives a PDCCH indicating a new transmission — a DL assignment or a UL grant, not a retransmission — it starts, or restarts, drx-InactivityTimer. Every further new-data PDCCH restarts it from the top. This is the mechanism that keeps the UE awake for the duration of an active session rather than chopping the session up at cycle boundaries: as long as data keeps arriving inside the inactivity window, the window keeps sliding forward and the UE never sleeps. When drx-InactivityTimer finally expires with no new grants, the burst is deemed over and the UE is free to sleep — either straight to the long cycle, or first to the short cycle if one is configured (described below).

So a typical cycle reads as three phases. First the on-duration: a mandatory, periodic wake-up during which the UE looks for any grant. Second, an optional inactivity extension: if a grant arrives, the UE stays awake and keeps extending as long as the traffic continues. Third, the sleep opportunity: once activity ends and every Active-Time condition is false, the receiver powers down until the next cycle's on-duration. The figure below traces exactly this.

Long Cycle vs Short Cycle

DRX can run with one or two cycle lengths. The long cycle (from longDRX-Cycle) is the baseline — sparse wake-ups for deep power saving during quiet periods. Optionally the network configures a short cycle (shortDRX-Cycle) used as a transitional state right after activity dies down. The short cycle must divide the long cycle evenly, so that short-cycle on-durations always line up with where a long-cycle on-duration would fall.

The logic runs off two events. When drx-InactivityTimer expires, or a DRX Command MAC CE is received, the UE checks whether a short cycle is configured. If it is, the UE switches to the short cycle and starts (or restarts) drxShortCycleTimer. It then runs the short, frequent cycle for that many consecutive short cycles. If no new data arrives before drxShortCycleTimer expires, the UE gives up on a quick resumption and falls back to the long cycle for deep sleep. If, on the other hand, data does arrive during the short-cycle phase, the inactivity timer restarts, the UE is fully awake again, and the ramp-down begins afresh once that burst ends. This gives a graceful, two-stage descent into sleep rather than an abrupt cliff.

HARQ Interaction — RTT and Retransmission Timer

Retransmissions complicate sleep. After a downlink transmission the UE knows a retransmission might come, but not immediately — the eNB needs time to receive and process the HARQ feedback and then schedule the retransmission. If the UE simply stayed awake watching for it, it would waste power monitoring subframes where a retransmission physically cannot appear yet. DRX solves this precisely with two timers working back to back: the HARQ RTT Timer plus drx-RetransmissionTimer.

After the UE receives a DL transmission on a HARQ process and sends its ACK/NACK, it starts the HARQ RTT Timer for that process. Unlike the configurable DRX timers, this one has a fixed value set by the specification (8 subframes for FDD downlink), because the HARQ round-trip timing is deterministic. During this RTT window a retransmission cannot yet arrive, so the UE is explicitly allowed to sleep — there is genuinely nothing to watch, and the RTT timer running is not part of Active Time. When the HARQ RTT Timer expires, the UE checks whether the data on that process was decoded correctly. If it was (an ACK), nothing more happens. If it was not (a NACK), the UE starts drx-RetransmissionTimer for that process and wakes to monitor the PDCCH for the retransmission grant. Because drx-RetransmissionTimer is part of Active Time, the UE reliably wakes exactly when a retransmission is plausible, and sleeps through the guaranteed-empty RTT gap that precedes it.

Note the direction difference. LTE uplink HARQ is synchronous: an uplink retransmission occurs at a fixed offset after the original, so its timing is already deterministic and needs no DRX retransmission timer — instead, the "UL grant for a pending HARQ retransmission may occur" condition in the Active-Time definition keeps the UE awake at the right instant. Downlink HARQ is asynchronous, so the eNB may schedule the retransmission at a flexible time, which is exactly why the downlink case needs the explicit HARQ RTT Timer plus drx-RetransmissionTimer pair to bound the wake-up window.

Reading DRX in the logs

DRX shows up in MAC traces as a running commentary of timer starts, stops and expiries, plus the current cycle (short vs long) and whether the subframe counts as Active Time. The fields to line up are the on-duration wake, what restarts drx-InactivityTimer, and the HARQ RTT→retransmission handoff.

Representative UE MAC DRX log — illustrative, values vary by vendor/build:

The DRX Timers at a Glance

The whole feature comes down to a handful of timers and two length parameters. The table pins down the role of each; keep the Active-Time definition from earlier in mind, since it is what ties them together.

Interactions — Measurement Gaps, SR and Scheduling

DRX does not run in isolation; it has to coexist with other MAC and physical-layer behaviours that also decide when the UE is or is not available on the PDCCH. Three interactions matter in practice.

Scheduling Request. When the UE has uplink data but no grant, it sends a Scheduling Request on PUCCH. A pending SR is one of the explicit conditions in the Active-Time definition: from the moment the UE sends an SR until it is resolved (a grant arrives or the SR procedure ends), the UE stays in Active Time and keeps monitoring the PDCCH. This is essential — the UE has asked to be scheduled, so it must be awake to receive the grant that answers its request. DRX therefore never causes the UE to sleep through the response to its own SR.

Measurement gaps. To measure other frequencies or inter-RAT neighbours, the UE is configured with measurement gaps during which it retunes its receiver away from the serving cell and cannot receive PDCCH at all. When a measurement gap overlaps an on-duration or any Active-Time subframe, the measurement gap takes precedence — the UE is off measuring and simply cannot monitor PDCCH there, and the eNB, which also knows the gap pattern, avoids scheduling in it. The timers themselves keep running on the same subframe clock; the UE just cannot act on Active Time during the gap. Both features are configured by RRC, so the network is responsible for choosing gap and DRX parameters that do not fight each other pathologically.

Scheduling. The whole point of the shared timer state is that the eNB scheduler restricts its grants for a DRX UE to that UE's Active Time. From the scheduler's view, DRX turns a continuously reachable UE into one reachable only in known windows, so it must batch downlink data to line up with on-durations (or keep the inactivity timer alive by scheduling within it). Aggressive DRX settings therefore constrain the scheduler and can reduce throughput for a given UE — another facet of the battery-versus-performance tradeoff.

Connected DRX Is Not Idle-Mode (Paging) DRX

Do not confuse connected-mode DRX with the DRX used in RRC_IDLE. That idle-mode DRX governs how often a camped UE wakes to check for paging — it is tied to paging occasions, the paging cycle broadcast in system information (defaultPagingCycle in SIB2, optionally overridden by a shorter UE-specific value supplied from NAS), and the UE's IMSI-derived paging frame and paging occasion. It is not driven by per-UE MAC timers at all, because in idle mode there is no RRC connection and no dedicated MAC configuration to hold them. Connected-mode DRX, this page's subject, is instead about not monitoring PDCCH between scheduled bursts while the RRC connection is up and the UE has a live C-RNTI. Same acronym, two entirely different mechanisms, driven by different configuration and serving different purposes.

Summary

Connected-mode DRX is a per-UE MAC duty cycle for PDCCH monitoring in RRC_CONNECTED: the UE wakes on a periodic on-duration, extends its wake window while data flows (drx-InactivityTimer), and sleeps otherwise. The one definition that unifies everything is Active Time — the logical OR of onDurationTimer, drx-InactivityTimer, drx-RetransmissionTimer, mac-ContentionResolutionTimer, a pending SR, and a possible synchronous UL retransmission grant. When all are false, the UE may power its receiver down.

To debug DRX, walk the timers in order: does the on-duration land where the modulo condition predicts (longDRX-Cycle/drxStartOffset)? Does only a new-Tx PDCCH restart the inactivity timer? Does the UE correctly sleep through the fixed HARQ RTT Timer and wake under drx-RetransmissionTimer for a DL retransmission? Does the short-cycle→long-cycle descent match drxShortCycleTimer? A grant that lands while the UE is asleep almost always traces to one of these, or to a measurement gap colliding with the on-duration.

The whole scheme is safe only because UE and eNB run the identical timer state off the same SFN/subframe clock — the eNB schedules the UE strictly inside its Active Time. Everything is a battery-versus-latency trade: bigger cycles and shorter inactivity save power but cost responsiveness, and the network tunes them to the traffic. And do not confuse it with idle-mode paging DRX, which is keyed to paging occasions from SIB2/NAS and addressed by P-RNTI.