5G HARQ - Hybrid Automatic Repeat Request in 5G NR
HARQ in 5G NR is the reliability loop that decides whether a transmission was decoded successfully or whether it needs another attempt. It connects scheduling, shared-channel decoding, feedback, and retransmission behavior across the PHY and MAC boundary.
For beginners, HARQ is the answer to a simple question: what happens if a block is not decoded correctly the first time? For experienced engineers, HARQ is where BLER, MCS choice, feedback timing, soft combining, and scheduler behavior start to shape real throughput and latency.
| Full name | Hybrid Automatic Repeat Request |
|---|---|
| Main specs | 3GPP TS 38.214, 38.213, 38.212, 38.321 |
| Main concepts | ACK/NACK, retransmission, soft combining, process timing, BLER, scheduler adaptation |
| Why it matters | HARQ turns radio decode uncertainty into a controlled retransmission loop, directly affecting throughput, latency, and reliability |
What HARQ means in simple terms
In practical terms, HARQ lets the network and UE recover from imperfect radio decoding without immediately dropping the data block. If the receiver can decode successfully, it sends or infers a positive outcome. If not, the transmission is repeated in a controlled way.
- HARQ is the fast retransmission loop used around scheduled data transmissions.
- It works with feedback such as ACK and NACK.
- It is tied closely to PDSCH, PUSCH, PDCCH, and PUCCH behavior.
- Engineers watch HARQ when analyzing throughput, latency, decode stability, and radio quality.
Technical summary
| Role | Fast reliability loop for scheduled radio transmissions |
|---|---|
| Main feedback | ACK/NACK outcome tied to decode success |
| Main dependencies | PDCCH scheduling, PDSCH/PUSCH quality, DMRS support, BLER behavior, timing and feedback transport |
| Main practical impact | Throughput, latency, retransmission count, scheduler adaptation, user experience under radio stress |
| Linked topics | PDSCH, PUSCH, PUCCH, DMRS, MCS, CQI, throughput, link adaptation |
How HARQ works in practice
Engineers should think of HARQ as a decode-result loop. A transport block is scheduled, sent, decoded, and then judged. If decode succeeds, the process can move forward. If decode fails, the system uses a retransmission path instead of abandoning the data immediately.
Scheduling starts the process
HARQ begins with a scheduled downlink or uplink transmission. In many normal cases, PDCCH tells the UE what resources to use or what downlink resources to expect.
Decode outcome matters more than raw resource count
Large resource allocation alone does not guarantee good performance. What matters is whether the receiver can decode the transport block under the actual radio conditions and reference-signal quality.
ACK and NACK drive the next step
A successful decode leads to an ACK path. A failed decode leads to a NACK path and therefore retransmission. This is where engineers start seeing HARQ counters, retransmission patterns, and BLER-related symptoms.
Retransmission is not a full reset
HARQ retransmissions are designed to improve the chance of successful decoding rather than simply repeating the same event without context. This is why repeated HARQ failure often points to a deeper radio-quality, scheduling, or configuration issue.
PDCCH -> PDSCH/PUSCH transmission -> decode result -> ACK or NACK -> retransmission / adaptation| HARQ step | What engineers should look for |
|---|---|
| Scheduling | Was the grant or allocation correct for the actual radio and traffic situation? |
| Initial transmission | Were MCS, layers, RBs, and DMRS assumptions reasonable? |
| Decode result | Did BLER, SINR, interference, or timing problems make decode unstable? |
| Feedback | Did ACK/NACK transport happen on time and on the expected control path? |
| Retransmission | Did the process recover normally, or is the system stuck in repeated failures? |
HARQ variants and practical behavior
Engineers usually do not talk about HARQ in terms of one single mode. They look at how the retransmission loop behaves in different radio and scheduling contexts.
| Variant | What engineers should know |
|---|---|
| Downlink HARQ | Centered on PDSCH decode outcome and uplink feedback toward the network |
| Uplink HARQ | Centered on PUSCH decode outcome at the gNB and the resulting retransmission behavior |
| ACK-dominant operation | Healthy radio conditions where most transport blocks complete without repeated retransmission |
| NACK-heavy operation | A stress pattern often linked to weak SINR, bad MCS choices, interference, or timing issues |
| Fast recovery case | One retransmission fixes the problem and performance remains stable |
| Persistent failure case | Repeated retransmissions point to a deeper issue that scheduler adaptation alone may not hide |
Where HARQ matters in real procedures
HARQ does not appear as a single stand-alone call-flow message. Instead, it is part of the transmission behavior that sits underneath many practical procedures once the UE is already exchanging scheduled traffic.
- It matters during normal downlink data delivery on PDSCH.
- It matters during uplink traffic delivery on PUSCH.
- It depends on control and grant behavior over PDCCH.
- It is closely tied to uplink control feedback over PUCCH.
- It affects throughput, latency, and user-perceived stability after initial access has completed.
Mini sequence flow
PDCCH grant
-> PDSCH / PUSCH transmission
-> receiver decode attempt
-> ACK / NACK outcome
-> scheduler continues or retransmitsReal-world engineering examples
A cell can show strong scheduling activity and still deliver poor usable throughput if HARQ retransmissions are too frequent. In field analysis, this often appears as an apparently active cell with disappointing user data performance.
Another common case is mismatch between radio conditions and MCS ambition. If the scheduler keeps selecting a transport profile that the channel cannot sustain, HARQ will keep trying to recover, but latency and spectral efficiency will suffer.
What to check in logs, KPIs, and traces
- HARQ ACK/NACK ratios and retransmission counters
- BLER behavior for downlink and uplink transport blocks
- MCS trends during the same time window
- Radio-quality context such as SINR, RSRP, and interference indications
- DMRS quality or decode-support conditions
- PDCCH grant timing and whether allocations make sense for the radio state
- PUCCH feedback behavior when downlink HARQ seems abnormal
- Whether retransmissions recover quickly or keep repeating without stabilizing
| Symptom | Likely engineering direction |
|---|---|
| High retransmission count | Check radio quality, MCS ambition, interference, and DMRS support |
| Good allocation but low throughput | Check whether HARQ is hiding repeated decode failure behind active scheduling |
| Unstable uplink latency | Check PUSCH decode quality, uplink power limits, and uplink HARQ recovery patterns |
| Frequent NACK bursts | Correlate with mobility, interference spikes, beam changes, and scheduler behavior |
Common mistakes engineers make with HARQ
- Treating HARQ as a pure MAC topic and ignoring the PHY conditions that trigger retransmission.
- Judging performance only by scheduled RBs instead of looking at decode success and retransmission cost.
- Ignoring DMRS and feedback quality when investigating repeated NACK behavior.
- Assuming more retransmissions always solve the problem rather than exposing a deeper radio issue.
Beginner takeaway
HARQ is the quick retry mechanism that helps 5G NR keep data delivery reliable when the radio link is not perfect. It sits behind many throughput and latency outcomes that engineers see in real networks.
Advanced engineer notes
- HARQ behavior should be read together with BLER, not as a standalone quality measure.
- Scheduler decisions, MCS policy, and radio conditions can create a stable or unstable HARQ regime.
- Repeated HARQ pressure often reveals problems in beam quality, interference, mobility state, or feedback timing.
- The practical engineering question is not “does HARQ exist,” but “what pattern of retransmission is the cell living in?”
FAQ
What is HARQ in 5G NR?
HARQ is the retransmission loop that decides whether a scheduled transport block was decoded correctly or should be sent again.
Why is HARQ important in 5G?
It protects reliability without forcing the system to use overly conservative transmission settings all the time.
Is HARQ only a PHY concept?
No. Engineers usually treat it as a PHY and MAC boundary topic because decode quality, control scheduling, and retransmission logic all matter together.
What causes too many HARQ retransmissions?
Common causes include low SINR, interference, aggressive MCS choice, poor reference-signal quality, and timing or feedback problems.
Use the decoder and related tools
HARQ is easiest to understand when you connect procedure traces with the radio behavior underneath them. Use the 3GPP Decoder to inspect related control and procedure messages, then move into the NR Throughput Calculator to connect retransmission pressure with real usable throughput.