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
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (139 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 15, corrections and clarifications were introduced for the HARQ-ACK function, specifically addressing the **dynamic HARQ codebook** determination and its associated transmission procedures. This included fixes to the Type-1 HARQ-ACK codebook pseudo-code and clarifications on the timeline condition for multiplexing two HARQ-ACK information bits in one slot. Furthermore, the release detailed the rules for HARQ-ACK transmission alongside other UCI types like CSI and SR on PUCCH formats 2, 3, and 4, including their multiplexing and rate matching.
- Clarification on UL_SUL indicator field and SRS request field TS 38.212CR0013
- Removal of CSI request in RAR grant TS 38.213CR0012
- Correction to dynamic HARQ codebook in NR TS 38.213CR0014
- Correction to last PUCCH resource set configuration TS 38.213CR0019
- CR on the determination of the minimum number of PRBs for PUCCH transmission TS 38.213CR0036
- Correction on the timeline condition of multiplexing two HARQ-ACK information in one slot TS 38.213CR0043
+ 6 more changes
In Release 16, key enhancements for HARQ-ACK included the introduction of a Type-3 HARQ-ACK codebook for reporting without a scheduled PDSCH and clarifications for HARQ-ACK priority determination, particularly for SCell dormancy indication. The release also defined procedures for handling overlapping PUCCH/PUSCH transmissions with repetitions and different priorities, and refined the HARQ-ACK processing timeline for specific DCI formats. Furthermore, corrections were made to codebook construction for secondary PUCCH groups and to multiplexing timelines to resolve ambiguities.
- Correction on HARQ-ACK codebook RRC parameter TS 38.212CR0069
- Correction for PUCCH repetition transmission TS 38.213CR0120
- CR to 38.213 on HARQ-ACK processing timeline for DCI format 1_1 with Scell dormancy indication without scheduling PDSCH TS 38.213CR0135
- Correction of NRU HARQ procedure in the presence of SPS PDSCH TS 38.213CR0163
- 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
+ 41 more changes
In Release 17, key enhancements to the HARQ-ACK function included enabling configurable multiple HARQ-ACK codebooks for multicast and corrections for codebook generation when spatial or time bundling is configured. The release also introduced specific handling for HARQ-ACK feedback in new scenarios like Non-Terrestrial Networks (NTN) and for multicast PDSCH scheduled by DCI format 4_1. Furthermore, it provided clarifications and corrections for PUCCH resource determination, particularly for multiplexing dynamic multicast and SPS unicast HARQ-ACK, and for operations during PUCCH cell switching.
- CR on DCI size for Rel-17 NTN HARQ in 38.212 TS 38.212CR0116
- Correction to support up to 32 HARQ process numbers for FR2-2 TS 38.212CR0126
- 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
- CR on the clarification of PUCCH resource determination in 38.213 TS 38.213CR0339
- CR on the description about HARQ-feedbackEnablingforSPSactive in 38.213 TS 38.213CR0340
+ 48 more 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 enhancement, alongside numerous corrections and clarifications for Type-2 HARQ-ACK codebooks and multiplexing procedures, aimed to improve reliability and efficiency for uplink control signaling. The release also included maintenance and corrections for other features like network-controlled repeaters, which interacted with the overall control channel framework.
- Introduction of Rel-18 network controlled repeaters TS 38.212CR0150
- Introduction of Network Controlled Repeaters TS 38.213CR0506
- 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
- Corrections on Rel-18 network controlled repeaters in 38.212 TS 38.212CR0174
- Maintenance of Network Controlled Repeaters TS 38.213CR0577
- Maintenance of Network Controlled Repeaters TS 38.213CR0607
+ 19 more changes
In Release 19, a key enhancement for the HARQ-ACK function was the introduction of support for 32 HARQ process numbers, expanding the previous limit. This change, detailed in the CR titled "Introduction of 32 HARQ process numbers in Rel-19 [TN32HARQ]", increases scheduling flexibility and data throughput. The existing procedures for multiplexing HARQ-ACK with other UCI types like CSI or SR on PUCCH or PUSCH remain applicable alongside this new capability.
- Introduction of 32 HARQ process numbers in Rel-19 [TN32HARQ] TS 38.212CR0222
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.
| Specification | Title | Release |
|---|---|---|
| TS 38.212 vj10 | NR Multiplexing and Channel Coding | Rel-19 |
| TS 38.213 vj10 | NR Physical Layer Control Procedures | Rel-19 |