HARQ (Async DL, Sync UL) in LTE 4G

Introduction

HARQ is the MAC-and-PHY retransmission engine that sits directly beneath the scheduler and directly above the turbo coder. It is specified in the MAC (TS 36.321) with its timing, channels and redundancy-version generation defined in the physical-layer specs (TS 36.213, TS 36.212, TS 36.211). Every scheduled transport block on PDSCH (downlink) or PUSCH (uplink) is carried by a HARQ process, so HARQ is running continuously the entire time a UE is in RRC_CONNECTED and has data flowing.

You meet HARQ from the moment RACH's Msg3 needs a retransmission, through every browsing burst, every VoLTE speech packet, and every handover. It is invisible when it works and it is the first thing to inspect when throughput collapses or latency spikes: a link that is stuck retransmitting, mis-toggling its NDI, or overflowing its soft buffer will show up as low MAC throughput long before the user sees a stall.

Because HARQ is a small, deterministic state machine — a per-process pairing of a MAC entity with a soft buffer, plus a fixed FDD timing rhythm — almost every HARQ fault localises to one identifiable thing: a wrong process id, an un-toggled or spuriously-toggled NDI, a mis-decoded ACK/NACK, an exhausted retransmission budget, or a soft buffer that is too small. Learning to read those five off a trace is the whole skill.

Why HARQ is needed

Concretely, LTE deliberately schedules at a modulation-and-coding scheme that targets about 10% first-transmission BLER. That aggression is what buys spectral efficiency — but it guarantees roughly one block in ten fails. Something has to recover those failures, and it has to do it fast: waiting for RLC ARQ (tens of milliseconds, a full outer-loop round trip) on every tenth block would wreck latency and throughput. HARQ closes that gap at L1/MAC in a few milliseconds, and it does so cheaply because it combines soft information rather than resending from scratch — a block that failed by a small margin needs only a small amount of extra parity to decode on the second attempt.

HARQ in one minute — stop-and-wait, eight ways

A single HARQ process is stop-and-wait: it sends one transport block (TB), then must wait for an ACK/NACK before it can send anything new. Waiting idle would waste the air interface, so LTE runs several processes in parallel — typically 8 HARQ processes in FDD per UE, in each direction. While process 0 waits for its feedback, processes 1–7 keep the pipe full. The number 8 is not arbitrary: it is exactly the round-trip time in subframes (send at n, feedback at n+4, retransmit at n+8), so eight processes are precisely enough to transmit continuously.

The whole mechanism lives at the boundary of two layers. The bookkeeping — which process owns which TB, whether a block is new or a retransmission, when to flush a soft buffer, how many attempts are allowed — belongs to the MAC layer (TS 36.321). The physical realisation — the fixed timing relations, the redundancy-version generation from the circular buffer, the ACK/NACK channels — belongs to the physical layer (TS 36.213, TS 36.212, TS 36.211). A HARQ "process" is really a pairing of a MAC HARQ entity state machine with a per-process soft buffer at the receiver where LLRs accumulate.

Two consequences fall out of the stop-and-wait design that trip people up. First, HARQ operates on transport blocks, per process, out of order: because eight processes run independently, TBs can finish decoding in a different order than they were sent, which is exactly why an in-order delivery layer (RLC) has to sit above it. Second, HARQ has a small but non-zero residual error floor: the single ACK/NACK bit can itself be misread, and a NACK-to-ACK error makes the transmitter move on while the receiver is still missing the block. That residual is what the RLC ARQ outer loop exists to clean up.

Soft combining — Chase vs Incremental Redundancy

LTE data uses a rate-1/3 turbo code. The turbo encoder produces one systematic stream and two parity streams; all three are written into a circular buffer after rate matching and sub-block interleaving. A retransmission simply starts reading from a different point in that buffer, so it carries different coded bits — mostly fresh parity. This is Incremental Redundancy (IR): each retransmission does not just add energy, it lowers the effective code rate (more parity = a stronger code). The receiver adds the LLRs of every attempt in its soft buffer before decoding, so the decoder sees a progressively lower-rate, stronger codeword with each attempt.

The four starting points into the circular buffer are the Redundancy Versions, signalled by a 2-bit Redundancy version field in the DCI. RV0 starts at the systematic (information) bits, so it is self-decodable — a lucky first attempt can decode on its own. RV1 and RV2 sit deep in the parity region and are not self-decodable; RV3 starts near the end of the buffer and wraps around, so it re-includes systematic bits and is also self-decodable. The first transmission almost always uses RV0; a common IR retransmission order is {0, 2, 3, 1}. If the scheduler always sends RV0, IR degenerates into Chase Combining (identical bits every time, pure energy accumulation, also called soft combining with maximal-ratio combining).

Why does the choice between Chase and IR matter in practice? IR gives a larger combining gain because it keeps lowering the code rate, so it wins when the channel is stable enough that the network can plan the RV sequence. Chase is simpler and is what you effectively get when the soft buffer is limited: the UE reports a soft buffer size capability, and if the buffer cannot hold the full rate-1/3 mother codeword, the transmitter is limited in how much incremental parity it can usefully send — the limited-buffer rate matching (LBRM) that constrains high-order MIMO/CA UEs. Either way, the receiver combines soft LLRs, never hard bits, which is the whole point: a block that fails at 0 dB margin on attempt one may decode after attempt two even though neither attempt alone would.

Downlink HARQ — asynchronous and adaptive

On the downlink, the eNB has full freedom over when and how to retransmit. Every PDSCH is scheduled by a DCI on the PDCCH, and that DCI carries three fields that make HARQ explicit:

• HARQ process number (3 bits → 8 processes in FDD) — tells the UE which soft buffer this TB belongs to. Because the process is named explicitly, a retransmission can arrive in any later subframe. That is what "asynchronous" means.
• NDI (New Data Indicator, 1 bit) — toggled relative to the last use of this process means new data (flush and decode fresh); not toggled means this is a retransmission of the same TB (soft-combine into the existing buffer).
• Redundancy version (2 bits) — which RV / starting point to use for this attempt.

Because the eNB can change the resource allocation, MCS and RV on every retransmission, downlink HARQ is also "adaptive" — there is no non-adaptive mode on the downlink at all, since every PDSCH requires a fresh PDCCH assignment anyway. The eNB will typically move a retransmission to a better allocation, drop the MCS a notch, or pick a self-decodable RV if it suspects the first attempt was completely lost. With spatial multiplexing (two codewords), each codeword carries its own NDI and RV but the two share the single HARQ process number, so a 2-codeword transmission occupies one process with two soft buffers.

The scheduling DCI for a normal DL assignment (DCI format 1/1A/2-family, per transmission mode) has its CRC scrambled with the UE's C-RNTI and is found in the UE-specific search space on the PDCCH; the fallback DCI format 1A is also monitored in the common search space. The UE reports the result as a 1-bit HARQ-ACK on PUCCH (using PUCCH format 1a/1b) or piggybacked on PUSCH if it happens to be transmitting data in that subframe. In FDD the timing is fixed: feedback for a PDSCH received in subframe n is sent 4 ms later, in subframe n+4 (TS 36.213). The earliest the eNB will retransmit is n+8, which is why 8 processes fill the FDD downlink. Note the asymmetry: even though the eNB is free to retransmit at any subframe (asynchronous), the UE's feedback timing is still fixed at n+4 — asynchronicity is about the data, not the ACK.

Uplink HARQ — synchronous

The uplink is the opposite in almost every way, and this is the classic LTE-versus-NR difference (NR made both directions asynchronous and adaptive, and dropped the PHICH entirely). LTE uplink HARQ is synchronous: retransmissions for a given process happen at a fixed, known timing, so the process number never needs to be signalled — it is implied by the subframe. In FDD the round-trip is 8 ms: the UE transmits PUSCH in subframe n, receives feedback in n+4, and retransmits (if needed) in n+8. Because the mapping from subframe to process is fixed and periodic, both ends compute the same process index with no signalling.

The feedback itself does not come on a shared control channel like the downlink. It arrives as a single ACK/NACK bit on the PHICH (Physical HARQ Indicator Channel), whose resource is derived implicitly from the lowest PRB index of the PUSCH allocation plus the DMRS cyclic shift used on that PUSCH — no explicit addressing needed, and MU-MIMO UEs sharing PRBs are separated by their different cyclic shifts. On a NACK, the default is a non-adaptive retransmission: the UE resends on the same resources with the next RV in the sequence, with no new grant required. The eNB can override this with an adaptive retransmission by sending a fresh DCI format 0 (with NDI not toggled), whose CRC is scrambled with the C-RNTI and which the UE finds in its UE-specific search space, moving the retransmission to new resources, a new MCS, or a new RV. So uplink HARQ is synchronous in timing, but the retransmission can be either non-adaptive (PHICH-driven, same resources) or adaptive (DCI-driven, new resources).

There is one subtlety worth memorising: the PDCCH (adaptive grant) overrides the PHICH. If the UE receives both a PHICH and a DCI 0 for the same process in the same subframe, it obeys the DCI. This lets the eNB retune a retransmission even after having sent an ACK/NACK. The uplink also uses measurement-gap and TTI-bundling exceptions: in TTI bundling (used for VoLTE coverage), a set of four consecutive subframes carrying different RVs of the same TB is treated as one bundle with a single HARQ feedback, extending coverage without waiting a full RTT between attempts.

The 8-process FDD timeline

Both directions run on the same 8 ms rhythm — n for the transmission, n+4 for the feedback, n+8 for the retransmission — but they signal it very differently. The downlink names the process in the DCI (asynchronous); the uplink lets the fixed timing name the process for it (synchronous) and carries the ACK/NACK on the PHICH. The table below lays out the exact FDD timing relations that produce the number 8.

Read the uplink row carefully: the 8 ms RTT is measured PUSCH-to-PUSCH (transmit at n, PHICH at n+4, retransmit at n+8), while the grant-to-PUSCH delay is a separate 4 ms. That PUSCH-to-PUSCH round trip of 8 subframes is exactly why 8 HARQ processes saturate the FDD uplink and downlink.

The maximum number of retransmissions is not infinite. On the downlink it is effectively bounded by the eNB scheduler policy (there is no hard spec cap on DL attempts — the eNB simply stops and lets RLC take over). On the uplink it is governed by the MAC parameter maxHARQ-Tx (in ul-SCH-Config), typically set to 4 or 5; once a process has been transmitted maxHARQ-Tx times without success, the MAC flushes the buffer, declares the TB failed, and the block is left for RLC ARQ to recover.

Reading HARQ in the logs

HARQ shows up in MAC/PHY traces as a per-process sequence: a first transmission with a toggled NDI and RV0, an ACK/NACK a few subframes later, and — on a NACK — a retransmission on the same process with an un-toggled NDI and the next RV. The two things to line up are the process id (same across an attempt chain) and the NDI (toggles only on genuinely new data).

Representative eNB/UE MAC-PHY log — illustrative, values vary by vendor/build:

TDD HARQ — timing, bundling, and multiplexing

Everything above assumed FDD, where uplink and downlink each have a subframe every millisecond and the clean n+4/n+8 relations hold. TDD breaks that symmetry: in a given radio frame some subframes are downlink, some uplink, and one or two are special (with the DwPTS/GP/UpPTS structure). The number of HARQ processes and the feedback timing therefore depend on the UL/DL configuration (configurations 0–6, TS 36.213), not on a fixed constant.

The core problem in TDD is that several downlink subframes may need to report their HARQ-ACK in a single uplink subframe (because there are fewer UL subframes than DL). LTE solves this with two techniques, chosen by RRC (tdd-AckNackFeedbackMode):

• ACK/NACK bundling — the UE logically ANDs the results of all the DL subframes in the association set into a single ACK/NACK. One NACK anywhere makes the whole bundle a NACK, forcing retransmission of everything. It is cheap on uplink control resources but wasteful when only one of several TBs failed.
• ACK/NACK multiplexing — the UE reports up to a few separate ACK/NACK bits (using PUCCH format 1b with channel selection), so it can NACK just the block that failed. It is more precise but limited to a small number of DL subframes.

The set of downlink subframes whose feedback lands in a given uplink subframe is the downlink association set K, tabulated per UL/DL configuration in TS 36.213. Because these windows can span several subframes and are asymmetric, the DCI in TDD carries an extra field, the DAI (Downlink Assignment Index), which counts the assignments in the current window so the UE can detect a missed PDCCH and size its ACK/NACK codebook correctly. Uplink HARQ timing in TDD is likewise config-dependent: the PHICH and any adaptive grant follow per-configuration timing tables rather than the flat FDD n+4. The takeaway for interviews: FDD HARQ is the simple 8-process, n+4/n+8 model; TDD trades that simplicity for flexibility, with a variable process count and bundling/multiplexing to squeeze many DL acknowledgements into fewer UL subframes.

Downlink vs uplink, and HARQ vs RLC ARQ

The table below is the summary an interviewer wants. Note that the shared machinery — turbo coding, circular buffer, RVs, NDI, soft combining, 8 FDD processes — is identical in both directions; only the timing model and the feedback channel differ.

HARQ is not the only retransmission layer. Above it sits RLC ARQ (in RLC Acknowledged Mode, AM). Think of them as a two-loop system. HARQ is the fast inner loop — it runs every few milliseconds at L1/MAC and clears the vast majority of errors quickly, but it has a small residual error floor because the feedback bit itself can be mis-decoded (a NACK misread as an ACK, so the transmitter moves on while the receiver is still missing the block). RLC ARQ is the slower outer loop — it works on RLC STATUS PDU reports over longer timescales and catches the rare blocks HARQ lets through, and it also restores in-order delivery that the parallel HARQ processes disturb. Using both gives you HARQ's speed with ARQ's guaranteed delivery.

One more distinction worth stating cleanly: HARQ retransmits the same coded transport block with different redundancy and combines the attempts, so each retransmission is cheaper (it only needs to close a small gap). RLC ARQ retransmits an entire RLC PDU from scratch with no combining — it is a full resend. That is why the design pushes almost all recovery onto HARQ and leaves RLC to mop up the last fraction of a percent.

Summary

HARQ is LTE's fast inner-loop recovery: schedule aggressively at ~10% BLER, then soft-combine cheap L1 retransmissions until the CRC passes. The single fact to anchor everything is the direction asymmetry — downlink HARQ is asynchronous and adaptive (process id, NDI and RV all signalled in the DCI, retx any later subframe, feedback as HARQ-ACK on PUCCH), while uplink HARQ is synchronous (retx at a fixed n+8, process implied by timing, ACK/NACK on the PHICH, non-adaptive by default but adaptive via a fresh DCI 0).

To root-cause a HARQ problem, walk the same three checks every time: the process id (constant across an attempt chain), the NDI (toggles only on new data), and the ACK/NACK (with its n+4 timing and, on the uplink, its implicit PHICH resource). Add the RV sequence (IR vs Chase), the MCS trend, and the attempt count against maxHARQ-Tx, and almost any stall — a flushed buffer, a mis-read NACK, an exhausted budget, an LBRM soft-buffer shortage — falls out of the trace.

Finally, remember HARQ never works alone: it clears ~99% of errors in a few milliseconds and leaves a thin residual for the RLC ARQ outer loop (TS 36.322) to mop up and to restore in-order delivery. Speed from HARQ, guaranteed delivery from ARQ.