5G NR MAC HARQ
HARQ is the MAC and PHY retransmission mechanism used to improve delivery reliability and resource efficiency. In NR, HARQ is one of the most important cross-layer topics for throughput, latency, BLER response, and practical log analysis.
This page focuses on the MAC-side view of HARQ. PHY provides the actual transmission, reception, and decoding outcome, but MAC tracks HARQ process state, retransmission context, and the scheduling-visible consequences of repeated ACK or NACK outcomes. Use it together with the PHY HARQ reference and the 5G NR MAC Overview page when investigating unstable throughput or radio-link behavior.
| Technology | 5G NR |
|---|---|
| Protocol area | MAC and PHY boundary |
| Main specification | 3GPP TS 38.321 |
| Related specifications | 3GPP TS 38.213 and 3GPP TS 38.214 |
| Release baseline | Release 18 |
| Key concepts | HARQ process state, ACK or NACK, retransmission, feedback timing, scheduler adaptation |
| Why it matters | HARQ directly shapes throughput, latency, delivered reliability, and scheduler efficiency |
| Best use | Throughput troubleshooting, decode-stability analysis, and cross-layer MAC-PHY reading |
Definition and purpose
HARQ in NR is the retransmission mechanism that allows the system to react quickly to unsuccessful transport-block delivery without relying only on higher-layer recovery. MAC tracks the HARQ process context, while PHY performs the actual transmission, reception, and decoding work.
For engineers, HARQ is not just a retransmission counter. It is a process-driven control loop that affects throughput, latency, radio-resource efficiency, and the practical behavior of both uplink and downlink traffic.
Where it fits
HARQ sits at the boundary between MAC and PHY. MAC tracks process state, scheduling-visible retransmission behavior, and related control interpretation, while PHY handles the actual signal transmission, decoding, and feedback generation or detection.
This is why HARQ analysis is always cross-layer. A MAC trace can show repeated retransmission behavior, but the root cause may be weak control reliability, aggressive transport settings, radio-quality variation, timing issues, or scheduler decisions.
HARQ workflow
Grant -> transmission -> decode outcome -> ACK or NACK -> process update -> retransmission or completion| HARQ stage | What to look for |
|---|---|
| Grant | Was the resource assignment reasonable for the traffic and radio conditions? |
| Initial transmission | Did the system pick an aggressive or conservative transport setting? |
| Feedback | Was ACK or NACK timing clean and correctly delivered? |
| Retransmission path | Did repeated retries improve reliability or just expose a deeper issue? |
Downlink and uplink HARQ views
| Direction | What usually matters most | Typical sign of trouble |
|---|---|---|
| Downlink HARQ | Scheduling quality, downlink decode success, feedback timing, and repeated retransmission demand | Repeated retransmissions with weak delivered throughput |
| Uplink HARQ | Grant use, uplink radio quality, timing alignment, and gNB-side decode success | Uplink retries grow while useful throughput stays low |
HARQ process behavior
At MAC level, HARQ should be read as tracked process state rather than as isolated failure events. Each active process represents a controlled sequence of transmission, acknowledgment outcome, and either completion or retransmission.
Stable HARQ behavior means the system is using radio resources efficiently even when some blocks need recovery. Unstable HARQ behavior means the same processes remain active too long, churn repeatedly, or consume resources that should have carried new data instead.
How HARQ reshapes scheduling behavior
Each retransmission attempt uses time and resources that could otherwise carry new data. That means HARQ directly changes scheduler efficiency, latency, and the amount of fresh traffic that can be served in the same time window.
This is why a link can look alive but still feel slow. HARQ churn turns good-looking headline connectivity into weak user throughput very quickly. In troubleshooting, HARQ often links poor user experience to a deeper combination of scheduler assumptions and PHY delivery conditions.
Why engineers care
- HARQ directly affects throughput efficiency and latency.
- HARQ churn is one of the clearest signs of unstable radio delivery.
- HARQ patterns often explain why apparently acceptable radio conditions still produce weak user experience.
- HARQ is one of the strongest links between MAC scheduling behavior and PHY decode quality.
Common HARQ failure patterns
| Observed pattern | Likely explanation | Next check |
|---|---|---|
| Retransmissions rise in bursts | Channel quality, interference, or scheduling assumptions are varying quickly | Check radio quality and MCS trends together with PHY HARQ context. |
| Retransmissions stay persistently high | The working point is too aggressive or the link is staying stressed | Check grant design, control reliability, and PHY decode quality. |
| Uplink seems active but useful throughput remains poor | HARQ retries are consuming resources without stable completion | Check uplink HARQ with Timing Advance and power context. |
Log-analysis notes
When reading logs, do not treat HARQ as a single KPI. Read it by direction, by process behavior, and by correlation with scheduling and PHY quality. A high retransmission count has different meaning in brief radio stress than in persistent scheduler failure.
A useful HARQ analysis usually moves outward from the retransmission symptom into grant behavior, control reliability, MCS or transport assumptions, radio quality, and adjacent MAC procedures such as Scheduling Request, Buffer Status Report, and Power Headroom Report when uplink performance is weak.
Troubleshooting
| Symptom | HARQ area to inspect | Why |
|---|---|---|
| Poor downlink throughput | Downlink retransmission pattern, feedback timing, and decode stability | Repeated downlink HARQ activity often explains low delivered throughput even when connectivity remains up. |
| Poor uplink throughput | Uplink HARQ retries, grant use, timing alignment, and power limitation | Uplink retries can consume resources without delivering stable completion. |
| High latency under load | Retransmission buildup and scheduler reuse of resources | HARQ consumes time and radio resources that would otherwise carry fresh data. |
| Good headline radio metrics but bad user experience | HARQ churn pattern over time | HARQ often exposes instability that is hidden by coarse summary metrics alone. |
| Intermittent performance collapse | Burst retransmission behavior and changing working point | Short HARQ bursts can indicate rapidly changing radio or control conditions. |
What to check when HARQ looks unhealthy
- Check retransmission counts and whether they are concentrated in a specific direction or condition.
- Check control reliability and whether grants are being interpreted correctly.
- Check radio quality and reference-signal conditions on the PHY side.
- Check whether MCS, layer use, or traffic timing assumptions are too aggressive for the real channel.
- Check adjacent MAC topics such as Scheduling Request, Buffer Status Report, and Power Headroom Report when the problem is mainly uplink-facing.
FAQ
What is 5G NR MAC HARQ?
It is the MAC-side retransmission control mechanism that works with PHY to improve delivery reliability through tracked HARQ processes, ACK or NACK feedback, and retransmission behavior.
What does MAC contribute to HARQ in 5G?
MAC tracks process handling, retransmission context, and scheduling-visible HARQ behavior around the PHY transmission and feedback loop.
Why can HARQ problems reduce throughput so much?
Because repeated retransmissions consume time and radio resources that could otherwise carry fresh data, which directly reduces efficiency and increases latency.
Is HARQ only a PHY topic?
No. HARQ sits at the MAC and PHY boundary, so useful analysis needs both views together.
Why should uplink and downlink HARQ be analyzed separately?
Because the failure patterns, scheduler implications, radio dependencies, and troubleshooting paths are different for uplink and downlink retransmission behavior.
Why is HARQ important for troubleshooting?
HARQ often explains poor throughput, high latency, unstable delivery, and weak user experience even when the system appears nominal at a high level.