HARQ in 5G NR: Soft Combining, Process IDs, and Flexible Timing

Plain ARQ throws away failed transmissions. That's the intuition worth starting from, because it's exactly what HARQ refuses to do — and everything else follows.

A transport block arrives corrupted. Classic ARQ discards it, sends a NACK, and waits for a fresh copy. But that corrupted block wasn't worthless — it contained most of the information, just not enough to decode. HARQ (Hybrid ARQ) keeps it in a soft buffer and combines it with the retransmission.

The "hybrid" is FEC plus retransmission working together rather than as separate layers. The gain is substantial and it compounds: two failed transmissions that individually couldn't be decoded frequently decode successfully when combined.

---

Why soft combining wins

Consider a transmission received at an effective SNR just below the decoding threshold. Plain ARQ discards it and the retransmission arrives at roughly the same SNR — likely failing again, and again, until the channel happens to improve.

HARQ combines the energy from both attempts. Two identical transmissions combined give roughly a 3 dB gain, which is often exactly the margin that was missing.

This is why HARQ makes aggressive link adaptation viable. The scheduler can target roughly 10% first-transmission block error rate rather than 0.1%, because failures are cheap to recover. Higher target BLER means higher MCS, which means higher average throughput. HARQ isn't a safety net bolted on — it's what lets the scheduler run the link hot.

---

Two ways to combine

Chase combining

The retransmission is an identical copy of the original coded block. The receiver combines them symbol by symbol, which is effectively maximum ratio combining across time.

Simple, and the soft buffer only needs to hold one block's worth of data. But every retransmission gives diminishing returns — you're only adding energy, never new information.

Incremental redundancy

The retransmission carries different coded bits from the same mother code — a different redundancy version.

Now each retransmission genuinely lowers the effective code rate. The first transmission might be at rate 0.9; after two retransmissions the receiver is effectively decoding at rate 0.3 — a fundamentally easier problem, not just a higher-SNR version of the same one.

NR defines four redundancy versions, RV0 through RV3, with RV0 self-decodable (it contains the systematic bits) and the others carrying additional parity. IR outperforms chase combining substantially, at the cost of a larger soft buffer.

In practice NR uses IR. Chase combining is best understood as the degenerate case where the scheduler happens to resend RV0.

---

HARQ processes

Here's the problem processes solve. If the transmitter sent a block and then waited for the ACK before sending anything else, the link would sit idle for the entire round-trip time. At NR timescales that's most of the available capacity wasted.

Instead, multiple HARQ processes run in parallel. Each is an independent stop-and-wait instance with its own soft buffer and state.

While process 0 waits for its acknowledgement, processes 1 through 15 transmit. The link stays continuously busy. NR supports up to 16 HARQ processes per carrier per direction — double LTE's eight, because NR's shorter slots mean more transmissions fit inside one round trip.

Each transmission carries its process ID in the DCI, so the receiver knows which soft buffer to combine into. Each process holds a New Data Indicator (toggled for fresh data), the redundancy version, and the soft buffer contents.

One consequence worth knowing: HARQ delivers out of order. Process 3 may complete after two retransmissions while process 4 succeeded first time. Reordering is RLC's job, not MAC's — which is precisely why RLC AM exists above a layer that already does retransmission.

---

Timing: where NR really differs

LTE fixed HARQ timing. In FDD, a downlink transmission in subframe n got its acknowledgement in subframe n+4. Always. You could set your watch by it.

NR made timing dynamically signalled per transmission, through two parameters carried in the scheduling DCI.

K1 — downlink feedback timing

K1 is the offset in slots from the PDSCH reception to the slot carrying its HARQ feedback on PUCCH.

The gNB picks K1 per transmission. A latency-critical service gets a small K1 — potentially placing the acknowledgement in the same slot as the data, if the TDD pattern has uplink symbols available. A device with limited processing capability gets a larger one.

K2 — uplink scheduling timing

K2 is the offset from the uplink grant on PDCCH to the PUSCH transmission it schedules. Same principle in the other direction.

Why this matters

Flexible timing enables self-contained slots — data and its acknowledgement within one slot. Combined with mini-slots and wide subcarrier spacing, the HARQ round trip collapses from LTE's fixed ~4 ms to well under a millisecond.

The constraint is UE processing capability. NR defines processing time capabilities (N1 for downlink, N2 for uplink) that bound how small K1 and K2 can legitimately be. Capability 2 devices support aggressive timing; Capability 1 devices don't. The scheduler must respect what the UE actually reported — this is a common source of interoperability problems in the field.

---

The soft buffer is the real constraint

Soft combining sounds free until you account for memory. The receiver has to store the demodulated soft values — LLRs — for every transport block awaiting retransmission, at several bits of precision per coded bit. For a high-category UE running carrier aggregation, that is tens of megabits of dedicated on-chip memory.

3GPP handles this by defining a total soft buffer size per UE category and requiring the UE to partition it across HARQ processes. The consequence is that a UE with many configured processes has less memory per process, and at high code rates it may be unable to store the full block.

This is where limited buffer rate matching (LBRM) comes in. Rather than letting the buffer overflow unpredictably, the specification restricts the range of coded bits that may be transmitted so the receiver can always store what it needs. The transmitter and receiver agree on the limit in advance, so the combining is deterministic.

For an implementer this is one of the more consequential constraints in the design. Soft buffer memory is expensive silicon, it scales with peak throughput, and it is a large part of why device categories exist at all.

Why redundancy versions are ordered the way they are

The four redundancy versions are not evenly spaced around the circular buffer. RV0 starts at the systematic bits and is self-decodable. RV2 is also positioned to be close to self-decodable. RV1 and RV3 are parity-heavy and rely on combining with an earlier transmission.

That asymmetry is deliberate. A scheduler that expects the retransmission to be received in isolation — after a long gap, or on a different beam — sends RV0 or RV2. A scheduler confident the receiver still holds the earlier soft values sends RV1 or RV3 and buys more incremental coding gain per retransmission.

The common sequence 0, 2, 3, 1 is a compromise: self-decodable early, maximum incremental gain later.

---

HARQ and URLLC

HARQ helps URLLC, but the relationship has a hard limit worth being precise about.

Each retransmission costs a round trip. A URLLC target of 1 ms user-plane latency at 99.999% reliability doesn't leave room for many attempts — often one retransmission, sometimes none at all.

So URLLC uses HARQ differently:

Conservative link adaptation. Target BLER drops to around 0.001% instead of 10%, so the first transmission usually succeeds. This costs spectral efficiency — deliberately.

Blind repetition. Rather than waiting for feedback, send K repetitions unconditionally. Latency becomes deterministic because there's no feedback loop, at the cost of resources spent on repetitions that may not have been needed.

PDCP duplication. Send the same packet over two independent paths — two carriers or two cells via dual connectivity. This is diversity, not retransmission, and it's the mechanism that gets you the last nines.

The general rule: HARQ optimises average throughput; URLLC needs bounded worst-case latency. Those are different objectives, and the URLLC configuration sacrifices the former for the latter.

---

When HARQ makes things worse

HARQ is not free, and there are regimes where the right answer is to use less of it.

Latency-bound traffic. Every retransmission costs a round trip. For a flow with a 1 ms budget, even one retransmission may blow the deadline, which is why URLLC leans on conservative MCS and repetition rather than relying on HARQ to clean up afterwards.

Head-of-line blocking. HARQ operates per process, and processes complete out of order. RLC acknowledged mode restores ordering above it, which means a single block stuck in retransmission holds up everything behind it in the reordering window. A poor channel does not merely slow one block — it stalls delivery of blocks that already arrived correctly.

Non-terrestrial networks. With a GEO satellite the round trip is over 500 ms. Waiting for feedback before reusing a process would idle the link almost entirely, so NTN permits HARQ feedback to be disabled per process, falling back to blind repetition and RLC-level recovery. This is the clearest case of the mechanism being switched off because its assumptions no longer hold.

Broadcast and multicast. With many receivers there is no single feedback path to act on. Multicast either does without HARQ or uses a NACK-only scheme.

Reading HARQ statistics

Two numbers matter when assessing a link, and they are frequently confused.

BLER after the first transmission — the target the outer loop drives, conventionally 10% for eMBB. A first-transmission BLER far below target means the scheduler is being too cautious and leaving throughput unclaimed. Far above means it is over-reaching.

Residual BLER after all retransmissions — what actually reaches RLC, typically below 0.1%. If residual BLER is elevated, HARQ is exhausting its retransmission budget and the problem is coverage or interference, not link adaptation.

A link showing 10% initial and 0.01% residual is working exactly as designed. A link showing 40% initial and 1% residual is being scheduled far beyond what the channel supports.

---

Where HARQ sits

HARQ lives in MAC, and NR has a second retransmission mechanism in RLC AM above it. That seems redundant until you see the division of labour.

HARQ is fast — a round trip in the sub-millisecond range — with lightweight 1-bit feedback, but its feedback channel is itself error-prone. A NACK misread as an ACK loses the block silently.

RLC ARQ is slower, with detailed status reports, and it catches exactly those residual failures. HARQ handles the common case at high speed; RLC catches what leaks through. Roughly: HARQ targets ~10⁻¹ to 10⁻² residual error, RLC drives it to ~10⁻⁵ or better.

Interaction with the scheduler

HARQ feedback also feeds link adaptation. A stream of ACKs suggests the MCS is too conservative and the scheduler pushes it up; repeated NACKs pull it back down.

This is a closed loop running continuously per UE. HARQ statistics are one of the most useful signals available for diagnosing radio problems in a live network — a cell with an abnormal retransmission profile is telling you something specific about interference or coverage.

---

LTE to NR at a glance

CBG-based retransmission is worth flagging. NR can retransmit only the failed code block groups within a transport block rather than the whole thing. On large transport blocks — think 100 MHz carriers with high-order MIMO — this saves meaningful resources when only part of the block was corrupted.

---

The mental model

HARQ = FEC + retransmission + soft combining. Failed transmissions are kept, not discarded.

Incremental redundancy lowers the effective code rate with each attempt. Chase combining only adds energy.

Up to 16 parallel processes keep the link busy across the round-trip delay.

K1 and K2 are signalled per transmission — that flexibility is NR's real HARQ innovation.

HARQ enables aggressive link adaptation. ~10% target BLER is a feature, not a fault.

MAC HARQ is fast and imperfect; RLC ARQ catches the residue. Both exist deliberately.

---

Further reading

• 3GPP TS 38.321 — MAC protocol specification, HARQ operation
• 3GPP TS 38.212 — Multiplexing and channel coding, redundancy versions
• 3GPP TS 38.213 — Physical layer procedures for control, K1/K2 and HARQ codebooks
• 3GPP TS 38.214 — Physical layer procedures for data, UE processing time capabilities