HARQ-ACK

Hybrid Automatic Repeat Request Acknowledgement

Physical Layer →
Introduced in Rel-15

HARQ-ACK is the feedback signal sent by a receiver to indicate the success or failure of a decoded transport block, triggering retransmissions to impact link reliability, latency, and throughput.

Category
Physical Layer
Introduced
Rel-15
Where
Radio Access Network › NG-RAN (5G)
Specifications
2 specs
HARQ-ACK Description Purpose Related Classification Detected Changes Specifications

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.

Classification

Part ofUCI
Related approachesPUCCHDCI

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

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

Rel-15 5 changes

In Release 15, the HARQ-ACK function introduced support for multiplexing with new uplink control information types like CG-UCI, UTO-UCI, and UEIRI on a PUSCH, as defined by specific configuration parameters. It also added detailed procedures for generating HARQ-ACK bit sequences when transmitted alongside multi-part CSI or SR on a PUCCH. Furthermore, the release specified mechanisms for handling HARQ-ACK with different priority indexes when the *uci-MuxWithDiffPrio* parameter is configured.

  • Correction on the timeline condition of multiplexing two HARQ-ACK information in one slot TS 38.213CR0043
  • CR on Type-1 HARQ-ACK codebook determination TS 38.213CR0044
  • CR to 38.213 fix to HARQ-ACK Type-1 codebook pseudo-code TS 38.213CR0053
  • Correction on HARQ-ACK transmission with BWP change TS 38.213CR0064
  • Correction on time gap definition for HARQ-ACK transmission TS 38.213CR0067
Rel-16 31 changes

In Release 16, enhancements to HARQ-ACK included refinements to codebook construction and processing timelines, such as corrections for Type-1, Type-2, and Type-3 HARQ-ACK codebooks. The release also introduced specific handling for new scenarios like PDSCH repetition with different subcarrier spacings in downlink and uplink, and clarified procedures for HARQ-ACK multiplexing with other uplink control information like CG-UCI on a PUSCH. Furthermore, support was defined for separate HARQ-ACK feedback in multi-TRP transmissions and for HARQ-ACK priority determination related to SCell dormancy indication.

  • Correction on HARQ-ACK codebook RRC parameter TS 38.212CR0069
  • CR to 38.213 on HARQ-ACK processing timeline for DCI format 1_1 with Scell dormancy indication without scheduling PDSCH TS 38.213CR0135
  • 38.213 CR Correction on HARQ-ACK codebook for secondary PUCCH group TS 38.213CR0167
  • Correction on Type2 HARQ-ACK codebook construction TS 38.213CR0168
  • Type-1 HARQ-ACK for PDSCH repetition with different SCSs in DL and UL TS 38.213CR0180
  • Correction of Type-3 HARQ-ACK codebook generation for a PDSCH with one transport block for a configuration with a maximum number of two TBs TS 38.213CR0187

+ 25 more changes

Rel-17 37 changes

In Release 17, key enhancements for HARQ-ACK focused on supporting multicast transmissions and refining codebook procedures. This included new mechanisms for configuring multiple HARQ-ACK codebooks for multicast, aligning DCI sizes for these codebooks, and defining PUCCH resource determination for multiplexing dynamic multicast and SPS unicast HARQ-ACK. The release also introduced corrections and clarifications for codebook generation during cell switching, enhanced Type-3 codebooks, and HARQ-ACK multiplexing on PUSCH, particularly for scenarios involving intra-UE multiplexing and different priority indices.

  • CR on number of HARQ-ACK codebooks configurable for multicast TS 38.212CR0129
  • CR on aligning DCI sizes when configuring two HARQ-ACK codebooks for multicast TS 38.212CR0135
  • Correction for HARQ-ACK codebook generation for PUCCH cell switching and UL BWP switching TS 38.213CR0347
  • CR on the Type-2 HARQ-ACK codebook TS 38.213CR0375
  • Correction on enhanced Type 3 HARQ-ACK codebook and HARQ-ACK re-transmission triggering TS 38.213CR0379
  • CR on multiplexing for SPS HARQ-ACK TS 38.213CR0381

+ 31 more changes

Rel-18 15 changes

In Release 18, a key new feature for HARQ-ACK was the introduction of multiplexing HARQ-ACK in a PUSCH with repetitions, specifically for acknowledgements associated with downlink assignments received after the uplink grant for that PUSCH. This release also included corrections and clarifications for the Type-2 HARQ-ACK codebook, particularly concerning multi-cell scheduling, multi-slot scheduling, and interactions with Configured Grant PUSCH (CG-PUSCH). Additionally, enhancements were made to the multiplexing procedures of HARQ-ACK with other uplink control information types like UTO-UCI and UEIRI on a PUSCH.

  • Introduction of multiplexing in a PUSCH with repetitions HARQ-ACK associated with DL assignments received after an UL grant for the PUSCH [HARQ-ACK MUX on PUSCH] TS 38.213CR0568
  • Correction on Type-2 HARQ-ACK codebook and DL BWP change TS 38.213CR0632
  • Correction on multiplexing HARQ-ACK in a PUSCH transmission TS 38.213CR0636
  • Correction on HARQ-ACK multiplexing on a PUSCH repetition [HARQ-ACK MUX on PUSCH] TS 38.213CR0646
  • Correction on HARQ-ACK skipping for Rel-18 multi-cell scheduling TS 38.213CR0673
  • Correction on the rate matching when HARQ-ACK multiplexed with CG-PUSCH TS 38.212CR0158

+ 9 more changes

Explore further

Broader topics and technologies where HARQ-ACK plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 38.212 vj10 NR Multiplexing and Channel Coding Rel-19
TS 38.213 vj10 NR Physical Layer Control Procedures Rel-19
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.