Hybrid Automatic Repeat Request Acknowledgement

Description

HARQ-ACK (Hybrid Automatic Repeat Request Acknowledgement) is the control information generated by the physical layer of the receiver (User Equipment in the uplink, gNodeB in the downlink) in response to a HARQ transmission attempt. Its primary function is to inform the transmitter whether a specific transport block was successfully decoded (ACK - Acknowledgement) or not (NACK - Negative Acknowledgement). This single-bit or multi-bit feedback is the essential trigger for the HARQ protocol's retransmission mechanism. The generation of HARQ-ACK occurs after the receiver performs cyclic redundancy check (CRC) on the decoded transport block. A passed CRC results in an ACK, while a failed CRC results in a NACK.

The transmission of HARQ-ACK feedback is a meticulously defined physical layer procedure. In 5G NR, HARQ-ACK bits are multiplexed with other uplink control information (UCI) such as Scheduling Request (SR) and Channel State Information (CSI). This multiplexed control payload is then channel coded (e.g., using Reed-Muller or Polar codes for small payloads), modulated, and mapped to specific physical resources on the PUCCH (Physical Uplink Control Channel) or, in cases of concurrent uplink data, piggybacked onto the PUSCH (Physical Uplink Shared Channel). The timing relationship between the downlink data reception (on PDSCH) and the corresponding uplink HARQ-ACK transmission is defined by a parameter K1, which provides flexibility to accommodate different processing capabilities and latency requirements.

For carrier aggregation or multi-TRP (Transmission Reception Point) scenarios, HARQ-ACK feedback becomes a multi-bit codebook. The UE constructs this codebook based on the scheduling decisions (Downlink Control Information, DCI) it has received, ensuring the gNB can unambiguously associate each ACK/NACK bit with a specific transmitted transport block. The reliability of HARQ-ACK transmission is paramount, as a missed ACK could cause an unnecessary retransmission (wasting resources), while a missed NACK could lead to a lost packet. Therefore, the physical resources for PUCCH are designed for high reliability, often using low-order modulation and frequency diversity.

Purpose & Motivation

HARQ-ACK exists to close the loop of the HARQ protocol. Without explicit and timely feedback, the transmitter would not know whether to send new data or retransmit old data, rendering the HARQ mechanism inoperable. Its purpose is to provide a low-latency, reliable indicator of decoding status to enable efficient and adaptive retransmission management at the MAC layer. This solves the problem of the transmitter operating blindly, which would lead to either excessive redundancy (if it always retransmits) or high packet loss (if it never retransmits).

The design of HARQ-ACK mechanisms, especially from LTE to 5G NR, has been motivated by the need to support more complex deployments and stringent service requirements. In LTE, HARQ-ACK timing was largely synchronous. The move to fully asynchronous HARQ in NR required more sophisticated feedback signaling, as the timing of retransmissions is not predetermined. Furthermore, to support ultra-reliable low-latency communication (URLLC), the feedback latency (K1) must be extremely short, and the reliability of the HARQ-ACK signal itself must be very high. The multi-bit codebook design for carrier aggregation addresses the problem of efficiently providing feedback for multiple component carriers without a proportional increase in signaling overhead, which is crucial for exploiting wide bandwidths.

Key Features

• Conveys ACK (success) or NACK (failure) for a HARQ process
• Transmitted on PUCCH or multiplexed on PUSCH in the uplink
• Timing relative to data reception is configurable (parameter K1 in NR)
• Can be a single bit or part of a multi-bit codebook for carrier aggregation
• High-reliability transmission is crucial for system performance
• Integral part of the uplink control information (UCI) framework

Evolution Across Releases

Defining Specifications