HARQ in LTE: How Radio Retransmission Actually Extracts Value From Every Failed Attempt

Originally published on 4GNation — republished here as part of the Telco & Beyond Engineering Archive.

The radio retransmission mechanism in LTE is called Hybrid Automatic Repeat Request (HARQ). HARQ allows erroneous blocks to be retransmitted quickly between the eNodeB and the UE, avoiding the much longer retransmission delay that would otherwise happen at the TCP layer. HARQ is one of those mechanisms that quietly does an enormous amount of work to keep an LTE link efficient — without it, every dropped block would mean a full TCP-layer retransmission, with all the latency that implies. This piece captures the core idea in a way I still find useful when explaining radio efficiency to non-RF audiences, and goes deeper into the mechanics than the original short version did.

Why HARQ exists: the problem with retransmitting at the wrong layer

TCP already has retransmission built in — that’s not new. The problem is timing. A TCP retransmission depends on round-trip acknowledgment across the entire network path, often tens to hundreds of milliseconds. On a radio interface where blocks are transmitted every 1ms, waiting for a TCP-layer retransmission to catch a single corrupted block would be catastrophically slow relative to the air interface’s own tempo. HARQ solves this by handling retransmission at the layer closest to the actual radio errors — fast enough to keep pace with the radio link itself, rather than the much slower path a TCP retransmission has to travel.

Where HARQ actually lives: two ARQ layers, not one

It’s worth being precise here because LTE actually runs retransmission logic at two different layers, and conflating them is a common source of confusion:

• HARQ at the MAC layer — fast, physical-layer-aware retransmission, working in tight timing loops directly tied to the radio interface. This is what the rest of this piece focuses on.
• RLC ARQ at the Radio Link Control layer — a slower, more traditional ARQ mechanism sitting above HARQ, acting as a safety net for cases HARQ doesn’t fully resolve (e.g., after HARQ’s maximum retransmission attempts are exhausted).

HARQ is deliberately designed to resolve most errors quickly, with RLC ARQ catching the rare cases that slip through — a two-tier system rather than relying on a single retransmission mechanism to do everything.

The ACK/NACK feedback loop

The HARQ process runs in both the eNodeB and the UE, based on ACK/NACK messages carried over PUCCH (Physical Uplink Control Channel) or PUSCH (Physical Uplink Shared Channel, when the UE already has an uplink grant). After receiving a downlink transmission, the UE attempts to decode it and reports back:

• ACK — block decoded successfully, no retransmission needed
• NACK — decoding failed, retransmission requested

This feedback is tightly time-bound. In FDD LTE, the standard round-trip timing is 8ms — the UE must respond with ACK/NACK exactly 4ms after receiving the transmission, and if a retransmission is needed, it arrives 4ms after that NACK. This fixed timing is what allows up to 8 parallel HARQ processes to run simultaneously without waiting idle for feedback on any single one — while process 1 is waiting for its ACK/NACK, processes 2 through 8 are already transmitting their own blocks.

How a typical HARQ implementation actually works

A typical hard-HARQ implementation follows this sequence:

1. It reserves the same resource blocks and MCS (Modulation and Coding Scheme) used in the initial transmission, keeping the retransmission consistent with the original attempt’s radio conditions assumptions.
2. It reuses information from previous transmissions of the same block to increase the probability of successful decoding — this is the “soft combining” that makes HARQ fundamentally different from a naive repeat-the-whole-thing retransmission.
3. If a data block isn’t received correctly, soft values are stored so they can be reused after retransmission, rather than being discarded. The receiver doesn’t throw away a failed attempt — it keeps the partial information extracted from it.
4. On retransmission, a different puncturing scheme is used, so the retransmitted bits don’t carry exactly the same information as the first attempt. This is the mechanism that makes HARQ genuinely clever rather than just “try again”: each retransmission sends different redundancy information about the same data, not a duplicate of what already failed to decode.
5. If the puncturing schemes across transmissions are disjoint, the number of coded bits transmitted after the second attempt effectively doubles — meaning the coding rate is halved. After a third transmission, the coding rate is divided by three, and so on. Each retransmission increases the probability of successful decoding.

Chase Combining vs. Incremental Redundancy — the two flavors of soft combining

The description above — different puncturing per retransmission — describes Incremental Redundancy (IR), the more sophisticated of two soft-combining approaches LTE supports:

• Chase Combining (CC) — the simpler approach: every retransmission sends an identical copy of the original coded bits. The receiver combines multiple identical copies to improve the effective signal-to-noise ratio, similar to averaging multiple noisy measurements of the same signal. Simple to implement, but doesn’t add new coding information.
• Incremental Redundancy (IR) — the approach described in the puncturing-scheme mechanism above: each retransmission carries different redundancy bits, effectively lowering the overall coding rate with each attempt and giving the decoder genuinely new information to work with, not just a repeated signal to average against noise.

IR generally outperforms CC because it doesn’t just fight noise — it actively strengthens the error-correcting code itself with each attempt, which is why most practical LTE deployments favor IR-based HARQ over simple Chase Combining.

Why this matters beyond the RF team

It’s a good example of engineering pragmatism: rather than treating every failed block as a full loss, the network extracts maximum value from every transmission attempt, incrementally improving the odds of success rather than starting over each time. That principle — don’t discard failed work, extract partial value and build on it — shows up constantly outside of radio engineering too, from how retry logic should be designed in distributed software systems to how enterprise processes should treat a failed first attempt at anything. HARQ isn’t just a clever radio trick; it’s a genuinely reusable design pattern.

The engineer’s takeaway

If you’re debugging throughput issues on an LTE link and see a high proportion of NACKs relative to ACKs, that’s not automatically a crisis — HARQ is specifically designed to make several retransmission attempts productive rather than wasted. What’s worth investigating is whether blocks are eventually succeeding within HARQ’s retry budget (typically configured for a handful of attempts) or falling through to RLC ARQ regularly, since the latter signals the radio conditions are bad enough that HARQ’s incremental redundancy isn’t closing the gap — a genuinely different problem than normal HARQ operation.

HARQ isn’t the only link-adaptation lever worth checking either — see Rank Indication for how MIMO layer feedback shapes what the scheduler even attempts to send in the first place.

Email address:

Leave this field empty if you're human: