What is HARQ?
HARQ (Hybrid Automatic Repeat reQuest) is a mechanism in LTE that combines two older error-handling techniques - ARQ and FEC - to make data transmission both reliable and efficient. Think of it as a “smart retransmission” system: Instead of simply throwing away a bad packet and asking for a fresh copy, the receiver saves the corrupted packet and combines it with later retransmissions to piece together the correct data.
Building Block 1: ARQ
ARQ (Automatic Repeat reQuest) is the simpler, older technique. When the receiver gets a packet with errors, it sends a NACK (Negative Acknowledgment) back to the sender, which then resends the packet. If the packet is correct, the receiver sends an ACK (Acknowledgment). The key weakness of plain ARQ: the bad packet is discarded, so all the signal energy from the first (failed) transmission is wasted.
Building Block 2: FEC
FEC (Forward Error Correction) means the sender adds extra redundancy bits (like a “repair kit”) alongside the real data before sending. If the channel introduces some errors, the receiver can use those redundancy bits to correct them without asking for a retransmission. The downside: FEC adds overhead to every single packet, even when the channel is perfect.
How HARQ Combines Both
HARQ’s key innovation is soft combining - the receiver does NOT discard a failed packet. Instead, it stores that noisy packet in a buffer. When the retransmission arrives, it combines both copies mathematically, creating a stronger signal than either copy alone. This turns two weak receptions into one reliable decoding, which is far more efficient than starting fresh each time.
Two Types of HARQ Combining
Chase Combining (Type I)
In Chase Combining, every retransmission is an identical copy of the original packet. The receiver stores the first failed copy, waits for the retransmission, and applies Maximum Ratio Combining (MRC) to merge them. This effectively doubles the received energy for that packet, boosting the chance of successful decoding.
- Simple to implement.
- Does not send new information in retransmissions, so it is less spectrally efficient.
- Works best when channel quality is moderate and just a little more energy is needed.
Incremental Redundancy (Type II/III)
In Incremental Redundancy (IR), retransmissions do NOT repeat the same bits. Instead, a different subset of the coded bits (called a Redundancy Version, or RV) is sent each time. The receiver accumulates all received versions and tries to decode from the growing pool of information.
- Each retransmission carries new information, so the code rate effectively gets lower with each attempt.
- Much more spectrally efficient than Chase Combining, especially at high MCS (Modulation and Coding Schemes).
- Type II: each retransmission alone is NOT self-decodable; you need to combine all of them.
- Type III: each retransmission IS self-decodable on its own, providing extra robustness.
The sequence of Redundancy Versions in LTE follows the predefined order: RV = 0, 2, 3, 1.
HARQ Processes and the Stop-and-Wait Problem
A naive HARQ implementation would have the sender transmit a packet, then wait (Stop-and-Wait, or SAW) for an ACK or NACK before sending the next one. In LTE FDD, the Round Trip Time (RTT) is 8 ms - because the UE needs ~3 ms to process the received data, sends feedback 4 subframes (4 ms) later, and the eNodeB needs ~3 ms to process that feedback before acting. That 8 ms waiting gap would waste almost all transmission capacity.
The solution is to run 8 parallel HARQ processes simultaneously. Each process is an independent Stop-and-Wait channel numbered 0-7. While Process 0 is waiting for its ACK, Processes 1, 2, 3… are busy transmitting their own data. By the time you cycle back to Process 0, the ACK is already ready. This keeps the radio channel busy 100% of the time.
You can visualize this timing clearly in the diagram from Keysight’s documentation: https://helpfiles.keysight.com/csg/n7624/Content/RT/harq_level_mode.htm
The formula for determining the UL HARQ Process ID in LTE is:
Synchronous vs. Asynchronous HARQ
The behavior differs between the Uplink (UE to eNodeB) and Downlink (eNodeB to UE):
| Property | Uplink (UL) | Downlink (DL) |
|---|---|---|
| HARQ type | Synchronous | Asynchronous |
| Who knows the next process ID? | eNodeB can calculate it from subframe timing | eNodeB tells UE via PDCCH (DCI) |
| Re-transmission flexibility | Fixed timing, less overhead | Flexible scheduling, more overhead |
| Re-transmission type | Adaptive or Non-Adaptive | Adaptive only |
In Synchronous HARQ (Uplink), retransmissions happen at predictable, fixed time offsets, so the eNodeB already knows which process is coming in each subframe without being told. In Asynchronous HARQ (Downlink), the eNodeB can retransmit at any time and must include the HARQ Process ID and Redundancy Version (RV) in the PDCCH control message so the UE knows how to handle it.
Adaptive vs. Non-Adaptive Retransmission
Even within synchronous or asynchronous HARQ, there is a second dimension of flexibility:
- Adaptive retransmission: The sender can change the MCS, RV, and resource allocation for each retransmission. This allows adjusting to changed channel conditions but costs more signaling overhead.
- Non-adaptive retransmission: The retransmission reuses the exact same parameters as before. The UE triggers this automatically when it receives a NACK on PHICH (Physical HARQ Indicator Channel) without a new UL grant on PDCCH.
The New Data Indicator (NDI)
A critical 1-bit field called the NDI (New Data Indicator) is sent by the eNodeB in the PDCCH (Downlink Control Information, or DCI). Its rule is simple:
- If the NDI bit toggles (flips from 0 to 1, or 1 to 0) compared to the previous transmission for that HARQ process, it means new data is being sent - the UE should clear its buffer.
- If the NDI bit does not toggle, it means this is a retransmission - the UE should combine the new reception with its stored buffer.
This 1-bit mechanism elegantly separates new transmissions from retransmissions without any extra signaling.
Maximum Retransmissions
LTE limits HARQ retransmissions to a maximum of 4 transmissions per MAC PDU (1 initial + up to 3 retransmissions). If after 4 attempts the data still cannot be decoded, the MAC layer gives up and the responsibility for recovery falls to a higher layer - the RLC layer - which has its own ARQ mechanism. This two-layer design (HARQ at MAC + ARQ at RLC) provides both fast and robust error recovery.
Key Terms to Remember
- ACK/NACK: Positive/Negative Acknowledgment, the feedback signal telling the sender whether a packet was received correctly.
- HARQ Process: One independent Stop-and-Wait channel, numbered 0-7 in LTE FDD.
- Redundancy Version (RV): The version of coded bits sent in each transmission, following the sequence 0, 2, 3, 1.
- NDI: A toggle bit that distinguishes new data from retransmissions.
- Soft Combining: Storing and mathematically merging failed receptions with retransmissions to boost decoding probability.
- PDCCH: The physical channel that carries downlink control info including HARQ process ID, NDI, and RV.
- PHICH: The physical channel the eNodeB uses to send ACK/NACK to the UE for uplink transmissions.