Description
Hybrid Automatic Repeat Request (H-ARQ) is a fundamental error control mechanism used in the data link layer (Layer 2) of 3GPP radio access technologies, including LTE and NR. It is termed 'hybrid' because it merges two classical techniques: Forward Error Correction (FEC) and Automatic Repeat Request (ARQ). The primary goal is to achieve highly reliable data transmission over the inherently unreliable and time-varying wireless channel while maintaining good spectral efficiency.
H-ARQ operates on a per-transport-block basis. When a transmitter (e.g., a gNB in the downlink or a UE in the uplink) sends a data packet, it includes redundant FEC bits (channel coding, like Turbo codes in LTE or LDPC/Polar codes in NR). The receiver attempts to decode the packet. If the decoding fails (detected via a Cyclic Redundancy Check - CRC), the receiver does not discard the corrupted soft-bit information (the analog values representing the received signal). Instead, it stores this 'soft' information in a buffer called the H-ARQ buffer and sends a Negative Acknowledgement (NACK) back to the transmitter via the feedback channel (e.g., on the Physical Uplink Control Channel - PUCCH).
Upon receiving a NACK, the transmitter performs a retransmission. Crucially, H-ARQ employs different 'redundancy versions' (RVs). The retransmission may not be an identical copy of the original packet. It may contain a different set of parity bits (FEC redundancy) from the same mother code. The receiver then performs 'soft combining', where it combines the new set of soft bits from the retransmission with the stored soft bits from the previous failed attempt(s). This combined signal has a higher effective Signal-to-Noise Ratio (SNR), increasing the probability of successful decoding. This process of retransmission and soft combining continues until the packet is successfully decoded (leading to an ACK) or a maximum number of retransmissions is reached, at which point higher-layer ARQ (RLC layer) may take over.
3GPP systems implement multiple parallel H-ARQ processes (e.g., up to 8 in LTE, 16 in NR) to maintain continuous data flow. While one process is waiting for feedback/retransmission, others can be used to send new data, hiding the round-trip time latency. The management of these processes, including scheduling retransmissions and assigning new data indicators (NDI), is handled by the Medium Access Control (MAC) layer. H-ARQ is a primary reason for the high reliability and efficiency of modern cellular systems, as it allows the system to operate at higher block error rates initially, knowing that most errors can be efficiently corrected through rapid retransmissions.
Purpose & Motivation
H-ARQ was developed to overcome the severe limitations of using pure ARQ or pure FEC alone on wireless channels. Pure ARQ, which simply retransmits packets upon error, becomes highly inefficient under poor channel conditions due to frequent retransmissions and associated delays. Pure FEC, which adds substantial redundancy to every transmission to correct errors, wastes bandwidth when the channel is good and may still fail when the channel is very bad.
The hybrid approach was motivated by the need for a more adaptive and efficient error control scheme. By combining a moderate level of FEC with a fast retransmission mechanism, H-ARQ allows the system to operate closer to the channel capacity. The initial transmission uses just enough FEC to correct the most common errors. For the less frequent, deeper fades or interference events that cause a decoding failure, the incremental redundancy provided by retransmissions (with soft combining) acts as additional, on-demand FEC. This 'chase combining' or 'incremental redundancy' strategy dramatically improves performance.
Its creation was essential for supporting high-data-rate services in 3G (HSDPA introduced H-ARQ) and became a cornerstone for 4G LTE and 5G NR. It solves the critical problem of unreliable radio links by providing a fast, physical-layer-centric recovery mechanism that minimizes latency and maximizes throughput. This is especially vital for low-latency applications and for maintaining high spectral efficiency, which is a key economic driver for mobile network operators. H-ARQ effectively makes the wireless link appear more reliable and efficient to the higher protocol layers.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (2 CRs across 2 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-8, normative work from Rel-17.
In Release 17, the H-ARQ function was not a primary focus of the specified changes. The provided grounding context and CR titles do not contain any specific technical details, procedures, or capabilities related to new introductions for Hybrid Automatic Repeat Request in this release. The documented changes primarily concern other areas such as media session handling, codec adaptation, and SDP negotiation.
- Change Request on ITT4RT features TS 26.114CR0519
In Release 18, a specific enhancement for H-ARQ-related feedback mechanisms was introduced concerning the RTCP-APP signaling. The release defined the use of an "RTCP-APP Redundancy Request for Processing Information (PI)" to carry adaptation requests, particularly for scenarios where in-band codec mode requests (CMR) are disabled. This provided an alternative, out-of-band control channel for functions like mode adaptation in EVS codec operation during a session.
- RTCP-APP Redundancy Request for Processing Information (PI) TS 26.114CR0566
Explore further
Broader topics and technologies where H-ARQ plays a role.
Defining Specifications
3GPP specifications that define or reference H-ARQ, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 26.114 vj10 | IMS Multimedia Telephony Media Handling | Rel-19 |
| TR 26.914 vj00 | Multimedia Telephony over IP Optimization | Rel-19 |
| TR 26.937 vj00 | 3GPP PSS Characterization | Rel-19 |