Introduction
HARQ (Hybrid Automatic Repeat Request) technique is the reason behind reliable and efficient transmission of data in traditional terrestrial 5G NR. The gNB sends a data packet on the downlink. The UE decodes it, checks the CRC, and sends back either an ACK or NACK on PUCCH within 4 milliseconds. If it’s a NACK, the gNB retransmits before the user even notice. This tight, fast HARQ loop is the backbone of NR reliability, running 16 parallel processes to keep the pipeline full.
In NTN, the round-trip time for a LEO-600 transparent payload is 10–36 ms. For GEO, it’s 480–560 ms. The gNB sends a packet, and then keeps waiting the ACK. By the time the feedback arrives, normal terrestrial HARQ would have cycled through its processes many times over. With only 16 HARQ processes, each one stalls and sits idle, unable to be reused, waiting for feedback that’s stuck in transit at the speed of light. This is called HARQ stalling problem, and it forced 3GPP to fundamentally rethink and redesign retransmissions process for NTN.
Standard HARQ Process
In 5G NR HARQ is an asynchronous, adaptive protocol combining forward error correction (FEC) with retransmission. It works as follows
- gNodeB transmits a transport block (TB) in downlink on PDSCH in slot n
- UE decodes PDSCH and checks CRC
- UE sends ACK/NACK in uplink on PUCCH in slot n + K (where K is typically 4 at 15 kHz SCS)
- If NACK, gNB retransmits (same or different redundancy version) after processing delay
- UE does soft combining the original and retransmitted data using Chase combining or Incremental Redundancy (IR), dramatically improving decoding probability
The total HARQ round-trip time (RTT) in terrestrial NR:
- T_HARQ = K + δ_processing ≈ 4 + 3 = 7 slots ≈ 7 ms (at 15 kHz SCS)
With 16 HARQ processes operating in parallel, the gNodeB can keep all 16 processes busy within this 7 ms window:
- N_processes,needed = ceil(T_HARQ / T_slot) = ceil(7 ms / 1 ms) = 7
Since 7 < 16, there’s enough headroom. Each process gets reused approximately every 7 ms, and the system never stalls.
HARQ Processes Requirement Analysis in NTN
Let’s calculate how many HARQ processes are required to avoid stalling in NTN:
- No. of Required HARQ Processes ID= [Time (HARQ,NTN) / Time (slot)]
Where Time (HARQ,NTN) includes the NTN round-trip delay:
- Time (HARQ,NTN) = Time (RTT,NTN) + (K + Delta Processing)
| Scenario | NTN RTT | K + Delta Processing | Total HARQ RTT | Processes Needed | Available (NR) | Deficit |
|---|---|---|---|---|---|---|
| Terrestrial | ~0 ms | 7 ms | 7 ms | 7 | 16 | None |
| LEO-600 (min) | 8 ms | 7 ms | 15 ms | 15 | 16 | ~OK |
| LEO-600 (max) | 26 ms | 7 ms | 33 ms | 33 | 16 | 17 short |
| LEO-600 (Typ.) | 18 ms | 7 ms | 25 ms | 25 | 16 | 9 short |
| LEO-1200 (typ.) | 30 ms | 7 ms | 37 ms | 37 | 16 | 21 short |
| GEO (transparent) | 540 ms | 7 ms | 547 ms | 547 | 16 | 531 short |
The above results highlight a clear capacity gap for HARQ process. Typical LEO-600 operation requires 25 HARQ processes, exceeding the 16 processes supported by NR. GEO operation would require 547 processes, roughly 34 times the available capacity.
HARQ Processes Stall Impacts in NTN
When all 16 HARQ processes are in use waiting for feedback, the gNodeB has no free process ID to use for new transmissions. This can results in:
- Throughput drops dramatically because the gNodeB sits idle despite having data to send
- Latency spikes as new data must wait until a process is freed
- Radio resource waste because DL/UL resources go unused during stall periods
The HARQ utilization efficiency shows the severity:
- Efficiency (η) = min(1, No. of available HARQ Process/ No. of needed HARQ Process) × 100%
| Scenario | No. Processes Needed | No. Processes Available | HARQ Utilization Efficiency (η) |
|---|---|---|---|
| Terrestrial | 7 | 16 | min (1, 7/16) = 100% |
| LEO-600 (min) | 15 | 16 | min (1, 15/16) = 100% |
| LEO-600 (typ.) | 25 | 16 | min (1, 25/16) = 64% |
| LEO-600 (max) | 33 | 16 | min (1, 33/16) = 48% |
| LEO-1200 (typ.) | 37 | 16 | min (1, 37/16) = 43% |
| GEO | 547 | 16 | min (1, 547/16) = 2.9% |
3GPP Proposals for HARQ Adaptation to NTN
3GPP provided following proposals for HARQ mechanism adaptation to support NTN requirement.
- Disabled HARQ Feedback
- Extended HARQ Processes
- RLC ARQ as the Reliability Backstop
- HARQ-ACK Bundling and Deferral in release 18
- Adaptive HARQ in release 19
Case1: Disabled HARQ Feedback
For GEO and high-delay LEO cases, 3GPP has introduced the option to disable HARQ feedback completely. The gNodeB transmits data without expecting any ACK/NACK and data reliability is managed by upper layers.
In this case of implementation, gNodeB sends PDSCH with HARQ feedback disabled indicated in DCI. UE decodes but does not send ACK/NACK. HARQ process is immediately freed for reuse. If decoding fails, the RLC layer specifically RLC AM — Acknowledged Mode detects the missing PDU and requests retransmission.
Disabling HARQ avoids the stalling problem entirely, but with following trades-offs
- More conservative MCS: we must target lower BLER (1%) on first transmission since there’s no fast retransmission
- Higher retransmission latency: RLC retransmissions take a full RTT (~540 ms for GEO)
- No soft combining gain: We may lose 2–3 dB of coding gain
Case:2 Extended HARQ Processes
For LEO NTN, where RTTs are large enough to cause stalling but small enough that HARQ feedback is still valuable, 3GPP allows increasing the number of HARQ processes (proc) beyond 16. In Release 17, the maximum number of HARQ processes for NTN was extended to 32.
| Scenario | No. Proc Needed | No. Proc Aval Rel.17 | HARQ Utilization Efficiency (η) |
|---|---|---|---|
| LEO-600 (typ.) | 25 | 32 | min (1, 25/32) = 100% |
| LEO-600 (max) | 33 | 32 | min (1, 33/32) = 97% |
| LEO-1200 (typ.) | 37 | 32 | min (1, 37/32) = 86% |
For LEO-600, 32 processes significantly solved the stalling problem. The gNodeB can keep transmitting continuously with only minor stalling at maximum delays in case of LEO-600 and LEO-1200.
Increasing the HARQ Processes is not just a number, it has significate impact on buffer memory uses. More no. of HARQ processes means, more buffer memory requirement. Each process requires a soft buffer to store received bits for combining. Hence 32 processes requires 2× the buffer memory compared to 16. For gNodeB prospective, the scheduler needs track more in-use processes and a larger e.g. 5-bit HARQ process ID field in DCI is must to signal 32 processes instead of 4-bit enough to signal 16 processes.
RLC ARQ as the Reliability Backstop
Whether HARQ is enabled or disabled, RLC AM (Acknowledged Mode) serves as the reliability backstop for NTN. RLC operates above HARQ in the protocol stack and provides following.
- Sequence number tracking: Detects missing PDUs regardless of HARQ outcome
- Status reporting: UE sends RLC STATUS PDUs indicating which PDUs were received and which are missing
- Retransmission: gNB retransmits missing RLC PDUs
In terrestrial NR, RLC retransmission is rare, HARQ able to capture ~99% of errors. In NTN, RLC plays a much more prominent role.
| Scenario | HARQ Mode | RLC Retransmission Rate | RLC Retransmission Delay |
|---|---|---|---|
| Terrestrial | Enabled (16 proc.) | < 0.1% | ~7 ms |
| LEO NTN | Enabled (32 proc.) | ~1–2% | ~18–36 ms |
| GEO NTN | Disabled | ~1–5% | 540–1080 ms |
HARQ-ACK Bundling and Deferral
3GPP release 18 introduced another refinements to reduce HARQ feedback overhead using following two techniques
- HARQ-ACK bundling: Multiple HARQ-ACK bits bundled into a single feedback occasion, reducing PUCCH overhead
- HARQ-ACK deferral: UE can defer feedback to a later slot, better aligning with NTN scheduling patterns
- One-shot feedback: All pending HARQ-ACK bits transmitted in one occasion after a configurable delay
Adaptive HARQ in Release 19
3GPP release 19 studies included following techniques to support adaptive HARQ.
- Dynamic HARQ enable/disable: Switching HARQ on/off based on current channel conditions and RTT
- Proactive retransmission: gNB retransmits without waiting for NACK, based on predicted BLER. This is very useful when RTT is long but channel quality is known to be poor.
- Multi-connectivity HARQ: Splitting HARQ across terrestrial and NTN links for reliability diversity
Conclusion
HARQ is a key technique that makes terrestrial 5G NR highly reliable, but the long propagation delays of Non-Terrestrial Networks fundamentally challenge its traditional design. As RTT increases from a few milliseconds in terrestrial networks to 10s or even 100s of milliseconds in NTN, the standard 16 HARQ processes become insufficient, leading to process stalling, reduced throughput, and higher latency.
To address this, 3GPP has introduced NTN-specific enhancements such as extending HARQ processes to 32, HARQ-ACK bundling and deferral, and even disabling HARQ feedback for GEO scenarios while relying on RLC retransmissions. These adaptations ensure that 5G can efficiently operate over satellite links, balancing reliability, latency, and resource utilization as NTN becomes an integral part of future global connectivity.
Related Posts
- NTN RACH Procedure Impacts – NTN RACH
- System Information 19 – SIB19 For 5g Satellite NTN
- 5G NTN Quality of Service – 5G NTN QoS
- Handover in Non-Terrestrial Networks
- Conditional handover (CHO)