ARQ

Automatic Repeat Request

Protocol →
Introduced in R99 Also in: Services

ARQ is an error-control protocol that ensures reliable data transmission by detecting errors in received packets and automatically requesting retransmissions from the sender.

Category
Protocol
Introduced
R99
Where
Radio Access Network › NG-RAN (5G)
Also touches
1 segments
Specifications
29 specs
ARQ Description Purpose Related Classification Detected Changes Specifications

Description

Automatic Repeat Request (ARQ) is a fundamental error-control mechanism implemented at the data link layer (Layer 2) and transport layer (Layer 4) in 3GPP systems. It operates on the principle of error detection followed by retransmission requests when errors are detected. The protocol uses sequence numbers, acknowledgments (ACKs), negative acknowledgments (NACKs), and timers to manage the reliable delivery of data packets between peer entities. In 3GPP architectures, ARQ is typically implemented in the Radio Link Control (RLC) protocol for the control plane and user plane data, as well as in higher-layer protocols like TCP for end-to-end reliability.

The ARQ protocol operates through several key mechanisms. First, the transmitter segments data into Protocol Data Units (PDUs) and assigns each a unique sequence number. These PDUs are transmitted to the receiver, which performs error detection using Cyclic Redundancy Check (CRC) or similar methods. When the receiver successfully decodes a PDU, it sends a positive acknowledgment (ACK) back to the transmitter. If the receiver detects an error or notices missing sequence numbers, it sends a negative acknowledgment (NACK) or simply doesn't send an ACK, triggering the transmitter's retransmission timer. The transmitter maintains a retransmission buffer containing unacknowledged PDUs and retransmits them when NACKs are received or timers expire.

3GPP systems implement several ARQ variants with different operational characteristics. Stop-and-Wait ARQ requires the transmitter to wait for an acknowledgment before sending the next PDU, providing simplicity but poor utilization. Go-Back-N ARQ allows the transmitter to send multiple PDUs without waiting for acknowledgments but requires retransmission of all PDUs from the first erroneous one when an error occurs. Selective Repeat ARQ, the most efficient variant used in modern 3GPP systems, allows selective retransmission of only the erroneous or missing PDUs while continuing to transmit new PDUs. This approach maximizes throughput while maintaining reliability.

The ARQ protocol interacts closely with other error-control mechanisms in 3GPP systems. At the physical layer, Forward Error Correction (FEC) provides the first line of defense against transmission errors. When FEC fails to correct errors, ARQ provides the secondary recovery mechanism through retransmission. Hybrid ARQ (HARQ) combines both approaches, using FEC for error correction and ARQ for retransmission when FEC fails. In the RLC layer, ARQ operates in Acknowledged Mode (AM) to provide reliable data transfer, while Unacknowledged Mode (UM) and Transparent Mode (TM) provide lighter-weight alternatives for delay-sensitive applications.

ARQ parameters are carefully configured based on service requirements and channel conditions. Key parameters include the maximum number of retransmissions, retransmission timer values, window sizes for flow control, and PDU sizes. These parameters are optimized differently for control plane signaling (which requires high reliability) versus user plane data (which may tolerate some packet loss for delay-sensitive services). The protocol also includes mechanisms for reordering PDUs at the receiver, discarding stale PDUs, and handling protocol errors to ensure robust operation under varying network conditions.

Purpose & Motivation

ARQ was developed to address the fundamental challenge of reliable data transmission over inherently unreliable wireless channels. Wireless communication systems suffer from time-varying channel conditions, interference, fading, and noise that cause packet errors and losses. Without error control mechanisms, these impairments would render digital communication systems unusable for most applications. ARQ provides a systematic approach to detecting and recovering from transmission errors, enabling reliable communication over imperfect channels.

Before the widespread adoption of ARQ in digital wireless systems, analog communication systems relied on signal-to-noise ratio improvements and simple repetition techniques that were inefficient and provided limited reliability. Early digital systems used basic error detection without automatic recovery, requiring manual intervention or application-layer retransmissions. ARQ automated the error recovery process, significantly improving system efficiency and reliability while reducing latency compared to manual approaches. The protocol's automatic nature allows it to adapt to changing channel conditions without human intervention.

ARQ solves several critical problems in wireless communication systems. First, it ensures data integrity by detecting and correcting transmission errors that would otherwise corrupt the received information. Second, it provides reliability guarantees for applications that cannot tolerate data loss, such as file transfers, signaling messages, and critical control information. Third, it enables efficient use of the wireless spectrum by avoiding unnecessary retransmissions through selective acknowledgment mechanisms. Finally, ARQ works in conjunction with other error-control techniques to provide a layered defense against channel impairments, allowing system designers to balance reliability, latency, and throughput according to application requirements.

Classification

Part ofRLC
Specific typesHARQH-ARQPANREJRLP

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (45 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-15 9 changes

In Release 15, the ARQ-related enhancements specifically introduced an additional UE capability regarding HARQ-ACK multiplexing on the PUSCH. This release also included a correction to the field description for HARQ-ACK delay targeted for Rel-14 MTC devices and provided clarifications for the operation of asynchronous HARQ in conjunction with LTE mobility enhancements.

  • Clarification on UE Capability Request Filtering TS 36.331CR3826
  • Corrections to mpdcch-UL-HARQ-ACK-FeedbackConfig TS 36.331CR3840
  • Handling Cell Reselection during SI Request TS 38.331CR0202
  • CR on SI request procedure in TS38.331 TS 38.331CR0246
  • Clarifications to SIBs requiring request procedure TS 38.331CR0600
  • Clarification on UE Capability Request Filtering TS 38.331CR0805

+ 3 more changes

Rel-16 15 changes

In Release 16, the ARQ/HARQ function saw specific refinements including clarifications on HARQ process sharing for Configured Grants (CGs) and corrections to HARQ-ACK codebook and spatial bundling configurations, particularly for the secondary PUCCH group. The release also introduced corrections to the value ranges for specific sidelink configuration parameters and addressed HARQ feedback configurations for both LTE-MTC (eMTC) and NR operation in EN-DC.

  • Introduction of RLOS support indicator and RLOS request indicator TS 36.331CR4049
  • Correction of on the IP address requesting in EN-DC TS 36.331CR4419
  • Correction on HARQ ACK spatial bundling configurations for secondary PUCCH group TS 38.331CR1993
  • Clarification on HARQ process sharing for CGs TS 38.331CR2055
  • Correction on HARQ ACK/NACK feedback configuration TS 38.331CR2181
  • Correction on value range of sl-ConfigIndexCG and sl-HARQ-ProcID-offset TS 38.331CR2315

+ 9 more changes

Rel-17 9 changes

In Release 17, specific enhancements and corrections were made to HARQ procedures, including a correction for the configuration of the Enhanced Type 3 HARQ-ACK codebook for a PUCCH group and a clarification on Type1 HARQ-ACK codebook generation. The release also introduced the rule to start the drx-HARQ-RTT-TimerUL after the last repetition and addressed HARQ-ACK multiplexing on PUSCH when a PUCCH is absent.

  • Change Request on ITT4RT features TS 26.114CR0519
  • Start drx-HARQ-RTT-TimerUL after last repetition [ulHARQ_RTT_Timer] TS 38.331CR3479
  • Corrections to on-demand SI request TS 38.331CR3786
  • RRC Configuration for Positioning Measurement Gap Activation/Deactivation Request MAC CE TS 38.331CR3891
  • Corrections to on-demand SI request TS 38.331CR4050
  • Correction to RRC for 71GHz on scheduling and HARQ configuration for FR2-2 TS 38.331CR4144

+ 3 more changes

Rel-18 10 changes

In Release 18, enhancements to ARQ/HARQ functions included the introduction of RRC parameters for HARQ-ACK multiplexing on the PUSCH and the support for PTM retransmission reception for multicast services when HARQ feedback is disabled. These changes were accompanied by updates to UE capabilities to support the new HARQ multiplexing feature. Additionally, the release introduced support for network-controlled repeaters, which interact with ARQ-related procedures through new RRC parameters and corrections.

  • Introduction of Network Controlled Repeaters in RRC spec TS 38.331CR4162
  • PTM retransmission reception for multicast DRX with HARQ feedback disabled [PTM_ReTx_Mcast_HARQ_Disb] TS 38.331CR4504
  • Introduction of RRC parameters for HARQ multiplexing [HARQ-ACK MUX on PUSCH] TS 38.331CR4597
  • Corrections and Updates to UE capabilities for Rel-18 WIs, including TEI18 [HARQ-ACK MUX on PUSCH] TS 38.331CR4638
  • Downlink positioning support and posSIB request for L2 UE-to-network remote UE [PosL2RemoteUE] TS 38.331CR4066
  • RTCP-APP Redundancy Request for Processing Information (PI) TS 26.114CR0566

+ 4 more changes

Rel-19 2 changes

In Release 19, the key enhancement for ARQ functions was the introduction of 32 HARQ processes for the TN (Terrestrial Network). This change, specified by the CR titled "Introduction of 32 HARQ processes to TN [TN32HARQ]," increases the number of simultaneous Hybrid ARQ processes available, which is a core part of the Automatic Repeat Request mechanism for error correction.

  • Introduction of control parameters for on-demand posSIB request [OdPosSIB_Req] TS 38.331CR5406
  • Introduction of 32 HARQ processes to TN [TN32HARQ] TS 38.331CR5410

Explore further

Broader topics and technologies where ARQ plays a role.

Defining Specifications

3GPP specifications that define or reference ARQ, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TR 21.905 vj00 3GPP Technical Terms and Definitions Rel-19
TS 23.146 vj00 3G Facsimile Group 3 Technical Realization Rel-19
TS 25.201 vj00 UTRA Physical Layer General Description Rel-19
TS 25.212 vj00 UTRA FDD Layer 1 Multiplexing & Channel Coding Rel-19
TS 25.222 vj00 UTRA TDD Multiplexing & Channel Coding Rel-19
TS 25.301 vj00 UE-UTRAN Radio Interface Protocol Architecture Rel-19
TS 25.302 vj00 UTRA Physical Layer Services Rel-19
TS 25.321 vj00 MAC Protocol Specification for UTRAN Rel-19
TS 25.322 vj00 RLC Protocol Specification Rel-19
TR 25.912 vj00 Evolved UTRA and UTRAN Technical Report Rel-19
TS 26.114 vj10 IMS Multimedia Telephony Media Handling Rel-19
TS 26.804 vj10 5G Media Streaming Extensions Study Rel-19
TR 26.805 vh01 Study on Media Production over 5G NPN Systems Rel-17
TR 26.914 vj00 Multimedia Telephony over IP Optimization Rel-19
TR 26.937 vj00 3GPP PSS Characterization Rel-19
TS 36.133 vj20 E-UTRA RRM Requirements Rel-19
TS 36.300 vj00 E-UTRAN Radio Interface Protocol Architecture Overview Rel-19
TS 36.302 vj00 E-UTRA Physical Layer Services Rel-19
TS 36.322 vj00 E-UTRA Radio Link Control Protocol Specification Rel-19
TS 36.331 vj00 LTE RRC Protocol Specification Rel-19
TS 36.938 v900 E-UTRAN to 3GPP2/Mobile WiMAX Mobility Rel-9
TS 38.202 vj00 5G NR Physical Layer Services Rel-19
TS 38.322 vj00 NR Radio Link Control (RLC) Protocol Rel-19
TS 38.331 vj00 NR Radio Resource Control (RRC) Protocol Specification Rel-19
TS 38.811 vf40 Study on NR Support for Non-Terrestrial Networks Rel-15
TS 43.051 vj00 GERAN Stage 2 Service Description Rel-19
TS 43.064 vj00 GPRS Radio Interface Lower-Layer Functions Rel-19
TS 44.060 vj00 GERAN RLC/MAC Protocol Specification Rel-19
TS 44.160 vg00 GERAN Iu Mode RLC/MAC Protocol Specification Rel-16