HARQ (Hybrid Automatic Repeat reQuest) Interview Prep
HARQ interview prep — soft combining, Chase vs Incremental Redundancy, LTE/5G NR HARQ timing, and the new IEEE 802.11bn (Wi-Fi 8) PHY HARQ.
Quick answer
HARQ (Hybrid Automatic Repeat reQuest) is a reliability mechanism that combines forward error correction (FEC) with retransmission.
Wireless and modem interviews use HARQ questions as a fast filter for whether a candidate understands the feedback loop between channel quality, scheduler decisions, and retransmission policy.
Editorial review
Written by
CompoundLearn editorial team
Wireless / RF / hardware engineering
Reviewed by
CompoundLearn editorial team
Wireless / RF / hardware engineering
Last reviewed
Built from curated topic maps, editorial validation, and subject-matter review so the page stays aligned with the interview intent and the current content pipeline.
What it is
HARQ (Hybrid Automatic Repeat reQuest) is a reliability mechanism that combines forward error correction (FEC) with retransmission. When a frame fails the CRC check, the receiver does not discard it — instead, it retains the soft demodulator output (log-likelihood ratios, or LLRs) in a buffer. When a retransmission arrives, the receiver merges the new LLRs with the stored ones and decodes the combined codeword, which has a lower effective code rate and stronger error correction than either attempt alone. The mechanism is fundamental in LTE and 5G NR cellular systems and is being introduced to Wi-Fi at the physical layer for the first time in the draft IEEE 802.11bn (Wi-Fi 8), still an active project rather than a finalized amendment. The two main HARQ flavors are Chase combining (HARQ-CC), where every retransmission sends the same coded bits and the receiver combines LLRs to lower the noise floor, and Incremental Redundancy (HARQ-IR), where each retransmission sends new parity bits from a low-rate mother code punctured at different positions. IR is more spectrally efficient because every retransmission carries new information, but it requires a larger receiver buffer and tighter mother-code design. 5G NR HARQ uses Redundancy Versions (RVs 0/1/2/3) to signal which puncturing pattern is being sent — that is IR in practice. IEEE 802.11bn PHY HARQ is expected to follow the same chase-combining-or-IR design pattern, adapted to the local Wi-Fi channel-coherence interval. The timing relationship matters as much as the combining algorithm. 5G NR uses k1 (DL HARQ feedback gap) and k2 (UL HARQ timing) parameters to control the round-trip between an initial transmission and its retransmission. URLLC slices with sub-millisecond latency budgets configure aggressive k1 / k2 values so a single HARQ retransmission still fits within budget — without that tightness, URLLC would have to use very conservative MCS values to hit reliability targets without HARQ. Wi-Fi 8 PHY HARQ targets a much shorter local RTT than cellular, so the per-retransmission combining gain is more predictable. Case study: an LTE eNB scheduling a UE with marginal SNR. The first transmission uses an MCS targeting 10 percent BLER. The receiver fails to decode, stores the LLRs, sends a NACK. The eNB schedules a retransmission with RV=2 (a different puncturing pattern of the same mother code). The receiver combines the RV=0 and RV=2 LLR buffers, decodes the merged codeword, and sends an ACK. The end-to-end BLER falls to under 1 percent at the cost of one extra slot of latency and a small spectral-efficiency penalty. That tradeoff — reliability for latency and a bit of spectrum — is the central HARQ engineering decision in every cellular and Wi-Fi 8 deployment.
Why interviewers ask
Wireless and modem interviews use HARQ questions as a fast filter for whether a candidate understands the feedback loop between channel quality, scheduler decisions, and retransmission policy. A strong answer goes past "HARQ retries failed packets" and explains that HARQ retains soft information across attempts, that Chase combining and Incremental Redundancy are different tradeoffs on the same retransmission framework, and that the round-trip timing constrains how aggressive the initial MCS can be. Three signals matter most. First, can the candidate distinguish HARQ from simple ARQ? The defining property of HARQ is soft combining — candidates who describe HARQ as "retransmit the failed packet" are describing ARQ and missing the entire engineering content. Second, can they reason about the IR vs CC tradeoff and the buffer cost of IR? Third, can they connect HARQ to the broader system: link adaptation (how MCS choice interacts with retransmission probability), latency budgets (why URLLC needs aggressive HARQ timing), and now the draft Wi-Fi 8 PHY HARQ (a new surface where prior Wi-Fi relied on MAC-layer ARQ alone). Roles where these questions matter most include modem firmware engineers, RF systems engineers, baseband DSP engineers, and Wi-Fi access-point firmware engineers now that the draft IEEE 802.11bn is introducing PHY HARQ. HARQ shows up directly in modem logs (NACK rate, average retransmission count per HARQ process), in scheduler decisions (which HARQ process to schedule next), and in throughput measurements (the gap between peak rate and effective rate is often a HARQ retransmission story). A candidate who can read a NACK log and explain why the scheduler is using a particular MCS-and-HARQ-timing combination is doing the kind of analysis the role expects.
Common mistakes
The most common mistake is conflating HARQ with simple ARQ. Simple ARQ throws away the failed packet and starts over; HARQ retains the soft demodulator output and combines it with retransmissions. A candidate who skips this distinction has missed the entire engineering content of the topic. A second common mistake is treating HARQ as free reliability. Every retransmission costs airtime and adds latency; the scheduler must balance how many HARQ retransmissions to allow against the latency budget for the traffic. URLLC slices configure aggressive k1 / k2 timing to allow one HARQ retransmission within a sub-millisecond budget — without that tightness, HARQ would push traffic past the latency requirement. A third gap is conflating Incremental Redundancy with Chase combining. Chase combining retransmits the same bits and combines LLRs to lower the noise floor; Incremental Redundancy sends new parity bits and combines codewords to lower the effective code rate. IR is more spectrally efficient but requires more receiver buffer and a tighter mother-code design. Real systems pick one or the other based on memory budget and codec design. A fourth gap is assuming HARQ is a cellular-only mechanism. Until recently this was largely true — Wi-Fi relied on MAC-layer RTS/CTS retransmission with no soft combining. The draft IEEE 802.11bn (Wi-Fi 8) proposes to change this by introducing PHY HARQ to Wi-Fi for the first time. Candidates who only know cellular HARQ are caught flat by Wi-Fi 8 questions. A fifth mistake is overstating PHY HARQ's role in Wi-Fi 8. PHY HARQ does NOT replace MAC-layer mechanisms like RTS/CTS — they operate at different layers and address different problems. RTS/CTS reserves the medium; HARQ improves combining gain on failed frames. The two are layered and complementary. A sixth gap is forgetting cross-link HARQ in Wi-Fi 7 MLO. In a Multi-Link Device, a retransmission can arrive on a different link than the original, with the receiver combining soft information across links. This is a high-value reliability mechanism but is often missed by candidates who only know single-link HARQ — for the MLO context, see /topics/multi-link-operation-deep-dive.
HARQ variants and where they appear
| HARQ flavor | How it combines | Buffer cost | Primary use |
|---|---|---|---|
| Chase Combining (HARQ-CC) | Same coded bits retransmitted; receiver merges LLRs in the same buffer | Lower — single buffer per process | Simpler systems, baseline LTE configurations |
| Incremental Redundancy (HARQ-IR) | New parity bits from punctured mother code; receiver merges codewords | Higher — buffer holds combined codeword growing across attempts | 5G NR (Redundancy Versions 0/1/2/3); spectral efficiency priority |
| Cross-link HARQ (Wi-Fi 7 MLO) | Retransmission on a different MLO link than original; receiver combines soft info across links | Higher — coordination across affiliated links | IEEE 802.11be Multi-Link Operation; reliability without single-link retry latency |
| PHY HARQ (Wi-Fi 8) | Soft-combining of LLRs across PHY-level retransmissions; chase or IR variants | New buffer per HARQ process at Wi-Fi receivers | Draft IEEE 802.11bn; first Wi-Fi generation proposed to add PHY-layer HARQ |
Sample interview questions
- A receiver fails to decode the first RV=0 transmission of an LTE PDSCH and sends a NACK. The retransmission then arrives with Redundancy Version 2 (RV=2). What is the receiver supposed to do with the new bits?
- A. Discard the stored RV=0 buffer and decode the RV=2 attempt independently, since each RV is a self-contained codeword that can be decoded standalone.
- B. Forward the RV=2 attempt to the MAC layer and let the MAC ARQ scheduler decide whether to combine it with the failed RV=0; the PHY does not combine across HARQ attempts.
- C. Combine the new RV=2 LLRs with the stored RV=0 LLRs as Incremental Redundancy — the merged codeword has a lower effective code rate than either attempt alone, raising the chance of decoding success. ✓
- D. Re-encode the RV=2 bits using the RV=0 codeword as a key, then decode the XORed result with the original FEC code.
Option C is correct. LTE HARQ uses Incremental Redundancy: each Redundancy Version (RV 0/1/2/3) sends a different puncturing pattern of the low-rate mother turbo code. The receiver retains the soft demodulator outputs (LLRs) from the failed RV=0 attempt and merges them with the new RV=2 LLRs in the buffer. The combined codeword has lower effective code rate and stronger error correction than either attempt independently — the IR gain that distinguishes HARQ from simple ARQ. Option A is wrong because, although RV=2 may sometimes be decodable on its own, individual RVs are not designed as self-contained codewords; RV=2 carries a different puncturing pattern, so decoding it standalone gives a weaker result than soft-combining it with the stored RV=0 LLRs. Option B is wrong because HARQ combining happens at the PHY layer, not at the MAC. The MAC layer sees the result of the HARQ decode (success or failure). Option D is wrong because HARQ does not XOR bits across attempts; the combining is soft-information merging in the LLR domain, not a bitwise operation.
- A wireless engineer claims "IEEE 802.11bn (Wi-Fi 8) PHY HARQ — a draft/proposed feature — replaces RTS/CTS once enabled, so the channel-reservation handshake is no longer needed." How would you correct this?
- A. The statement is correct — PHY HARQ replaces channel reservation entirely in Wi-Fi 8 deployments.
- B. PHY HARQ replaces RTS/CTS only in 6 GHz operation; in 2.4 and 5 GHz, RTS/CTS continues to operate alongside HARQ.
- C. PHY HARQ is a security mechanism; it does not interact with RTS/CTS at all.
- D. PHY HARQ is a retransmission scheme that improves combining gain on failed frames; it does not replace channel reservation. RTS/CTS and other medium-access mechanisms continue to operate. HARQ adds a physical-layer capability on top of the existing Wi-Fi PHY/MAC. ✓
Option D is correct. The proposed/draft 802.11bn (Wi-Fi 8) PHY HARQ adds a physical-layer retransmission mechanism (soft combining of LLRs across attempts) on top of the existing Wi-Fi PHY/MAC stack. RTS/CTS continues to operate as the medium reservation handshake — they solve different problems. HARQ converts retry energy into coding gain; RTS/CTS reserves the channel against hidden-node collisions. The two mechanisms are layered and complementary, not substitutable. Option A is wrong because HARQ and RTS/CTS operate at different layers and address different problems; one does not replace the other. Option B is wrong because the HARQ vs RTS/CTS relationship is not band-dependent; both operate across all bands Wi-Fi 8 targets. Option C is wrong because PHY HARQ is a reliability mechanism, not a security mechanism.
- In a 5G NR URLLC slice with a 1-millisecond end-to-end latency budget, why does the network configure aggressive k1 / k2 HARQ timing values?
- A. Aggressive k1 / k2 values disable HARQ entirely; URLLC slices rely exclusively on FEC redundancy without any retransmission.
- B. Shorter k1 (the DL PDSCH-to-HARQ-ACK feedback gap) tightens the downlink HARQ loop, and shorter k2 (the UL-grant-to-PUSCH gap) tightens the uplink HARQ loop; tightening whichever loop the URLLC flow uses lets a single HARQ retransmission fit within the 1-millisecond budget when UE processing and scheduling allow, letting the link use a higher initial BLER target without breaching the latency requirement. ✓
- C. k1 and k2 are unrelated to HARQ timing; they control the modulation order applied to initial transmissions only.
- D. Shorter k1 / k2 reduces transmit power consumption; the URLLC use case is dominated by battery life rather than latency.
Option B is correct. In 5G NR, k1 is the gap (in slots) between a downlink PDSCH transmission and its HARQ-ACK feedback on the uplink (per TS 38.213); k2 is the gap between an uplink grant on PDCCH and the corresponding PUSCH transmission (per TS 38.214). Shorter k1 tightens the downlink HARQ loop (PDSCH → ACK/NACK → DL retransmission) and shorter k2 tightens the uplink HARQ loop (grant → PUSCH → retransmission); a DL URLLC flow is bounded by k1, a UL URLLC flow by k2, and tightening the relevant loop lets even a failed initial transmission complete its retransmission within a 1-millisecond URLLC budget — provided UE processing time and scheduling constraints permit. This lets the scheduler use a higher initial BLER target (e.g., 10 percent) while still meeting reliability targets via one HARQ retransmission; without aggressive HARQ timing, URLLC would need a much lower initial BLER (and lower MCS), wasting spectral efficiency. Option A is wrong because URLLC slices use HARQ aggressively; they do not disable it. Aggressive timing is the mechanism that makes HARQ usable within a tight latency budget. Option C is wrong because k1 / k2 are HARQ-related scheduling-timing parameters, not modulation-order controls. Option D is wrong because URLLC is latency-driven, not battery-driven (eMTC/NB-IoT are the battery-driven slices).
- IEEE 802.11be (Wi-Fi 7) standardized Multi-Link Operation, and proposed/discussed cross-link HARQ combining builds on top of it. Conceptually, what advantage would cross-link HARQ combining offer over single-link retransmission?
- A. Cross-link HARQ doubles the peak throughput because the receiver combines two parallel transmissions simultaneously.
- B. Cross-link HARQ is a regulatory requirement for 6 GHz operation under AFC.
- C. A retransmission can arrive on a different MLO link than the original, so combining gain is captured without paying the latency of waiting for the original-link channel to recover — valuable when the original link is congested or interference-impaired. ✓
- D. Cross-link HARQ replaces all single-link HARQ in Wi-Fi 7; MLO devices cannot use single-link retransmission.
Option C is correct. Note first that PHY-layer HARQ (and cross-link HARQ combining specifically) was a candidate feature discussed during 802.11be development but did NOT make the final Wi-Fi 7 (802.11be-2024) standard; it is best described as a proposed MLO reliability mechanism, with PHY HARQ now being explored for the draft 802.11bn (Wi-Fi 8). Conceptually, in an MLO device with affiliated links on multiple bands (typically 2.4 / 5 / 6 GHz), a failed transmission on one link could be retransmitted on a different link, with the receiver combining the soft information from both attempts. The latency advantage is concrete: if the original 5 GHz link is congested, waiting for it to clear would add hundreds of microseconds of jitter; sending the retransmission on the 6 GHz link instead would avoid that wait while still capturing combining gain. For broader MLO mechanism context, see /topics/multi-link-operation-deep-dive. Option A is wrong because cross-link HARQ would not double throughput; it improves reliability and reduces tail latency for retransmitted frames. Throughput aggregation across links is a different MLO feature. Option B is wrong because cross-link HARQ is a reliability mechanism, not a regulatory requirement; AFC governs 6 GHz Standard Power outdoor operation, unrelated to HARQ. Option D is wrong because an MLO device would retain single-link HARQ as well; cross-link would be an additional mode, not a replacement.
Frequently asked questions
- What is HARQ and how does it differ from simple ARQ?
- HARQ (Hybrid Automatic Repeat reQuest) combines forward error correction (FEC) with retransmission. When a frame fails CRC, the receiver stores the soft demodulator output (log-likelihood ratios, or LLRs) instead of discarding it. On retransmission, the receiver combines the new LLRs with the stored ones and decodes the merged codeword — recovering the frame at a lower effective SNR than either attempt would need alone. Simple ARQ throws away the failed frame and starts over; HARQ converts retry energy into coding gain via soft combining. The mechanism is fundamental in LTE and 5G NR and is being introduced to Wi-Fi at the PHY layer in the draft IEEE 802.11bn (Wi-Fi 8), which is still an active project rather than a finalized amendment.
- What is the difference between Chase combining and Incremental Redundancy?
- Chase combining (HARQ-CC) retransmits the same coded bits on every attempt; the receiver combines LLRs across retransmissions to lower the effective noise floor. Incremental Redundancy (HARQ-IR) sends new parity bits on each retransmission — typically from a low-rate mother code punctured at different positions — so the effective code rate falls with each attempt, raising error-correction strength. IR is more spectrally efficient than CC because every retransmission delivers new information, but it requires a larger receiver buffer and tighter mother-code design. 5G NR HARQ uses Redundancy Versions (RVs 0/1/2/3) to signal which puncturing pattern is being sent — that is IR in practice.
- How does HARQ timing interact with round-trip latency?
- HARQ depends on a tight feedback loop: receiver decodes, sends ACK or NACK, transmitter retransmits. If the round-trip time is long relative to the channel coherence time, the retransmission arrives on a different channel realization than the original — soft combining still works, but the per-transmission gain is harder to predict. 5G NR uses a configurable HARQ timing relationship (k1 for DL HARQ, k2 for UL HARQ) so the network can shorten the feedback gap for URLLC slices. IEEE 802.11bn (Wi-Fi 8) PHY HARQ targets the local Wi-Fi RTT, which is much shorter than cellular, so the combining gain per retransmission is more predictable. Long-haul satellite links use stop-and-wait HARQ sparingly because the RTT can stretch into hundreds of milliseconds.
- How does HARQ interact with MCS and link adaptation?
- The MCS chosen for a transmission sets the BLER target — typically 10 percent on the first transmission for LTE/NR, so that one retransmission brings the effective BLER under 1 percent. HARQ and link adaptation are joint design decisions: a more aggressive MCS gives higher peak throughput but raises retransmission probability, while a conservative MCS lowers retries at the cost of peak rate. The scheduler watches the HARQ statistics (NACK rate, average retransmission count) and steers the outer link adaptation loop accordingly. In Wi-Fi 8, PHY HARQ adds a new degree of freedom — the rate-matching outer loop can now assume the receiver retains soft information across attempts, which changes the optimal MCS choice in marginal-SNR regimes versus prior Wi-Fi generations that relied on MAC-layer ARQ alone.
- What is the difference between PHY HARQ in IEEE 802.11bn and MAC-layer ARQ in earlier Wi-Fi?
- Pre-802.11bn Wi-Fi relied on MAC-layer mechanisms: a failed frame triggered an RTS/CTS retransmission, the original payload was discarded, and the receiver decoded the new attempt independently. IEEE 802.11bn (Wi-Fi 8) introduces a physical-layer HARQ-like retransmission scheme where the receiver retains soft demodulator outputs from a failed frame and combines them with the LLRs from a retransmission — the same chase-combining or incremental-redundancy gain that LTE and 5G NR have exploited for years. The Wi-Fi 8 implementation must coexist with the MAC-layer reservation framework (RTS/CTS still operates) and operates over the local channel coherence interval, which is much shorter than cellular RTT. For deeper Wi-Fi 8 mechanism context, see /topics/wifi-8-80211bn-ultra-high-reliability.
- What common HARQ interview questions reveal candidates who only know the buzzword?
- The fastest filter is asking what soft combining actually combines. Candidates who say "HARQ stores the failed packet and retries" are describing simple ARQ; candidates who name log-likelihood ratios and explain that the receiver merges per-bit soft values are showing the right mental model. A second filter is the IR vs CC tradeoff — strong candidates know that Incremental Redundancy is more spectrally efficient but requires more receiver buffer and tighter mother-code design. A third filter is the latency-vs-reliability tradeoff: each retransmission improves the chance of decoding but adds round-trip delay, and HARQ is not free in latency-sensitive applications. A fourth filter is the multi-link angle — in IEEE 802.11be (Wi-Fi 7) MLO, cross-link HARQ combining where retransmissions arrive on a different link than the original is a high-value claim area, since it improves reliability without single-link retry latency.
- How does HARQ relate to OFDMA scheduling and resource units?
- HARQ retransmissions in 5G NR and IEEE 802.11bn are scheduled into the same resource grid as initial transmissions, so the scheduler decides how to allocate retransmission energy alongside new traffic. A retransmission of a failed OFDMA frame may be allocated more bandwidth (larger resource unit) than the original to maximize combining gain, or scheduled into a different subcarrier set to exploit frequency diversity. For OFDMA scheduling depth, see /topics/ofdma-resource-units-explained. The scheduler tradeoff is complex: spending RUs on retransmissions reduces airtime for new users, but failing to retransmit aggressively pushes traffic into longer tail-latency outcomes that the scheduler is trying to avoid.
- Which NR physical channels carry HARQ feedback and data?
- HARQ-ACK feedback is UCI (Uplink Control Information) carried on PUCCH when no concurrent PUSCH is scheduled, or multiplexed onto PUSCH when a PUSCH transmission overlaps in the same slot (the default UCI-on-PUSCH behavior). The DCI carried on PDCCH addressed to the UE's C-RNTI announces HARQ process ID, redundancy version, and new-data-indicator for each PDSCH or PUSCH transmission. See /topics/nr-physical-channels for the full PDCCH/PDSCH/PUCCH/PUSCH layer, DCI formats, and UCI multiplexing rules.
Related topics
Essential AI-Native Skills for HARQ (Hybrid Automatic Repeat reQuest)
Modern engineering work increasingly uses AI tools for design and code review, debugging, documentation, test and testbench generation, and workflow automation. The goal is not to let AI replace engineering judgment — it is to move faster while keeping verification discipline.
- Use AI to explain unfamiliar code, logs, waveforms, datasheets, or test failures.
- Break large problems into small, reviewable steps you can verify independently.
- Ask AI for hypotheses, then validate them against tests, measurements, simulations, or lab data.
- Version-control your analysis scripts, testbenches, and configs — keep changes small and reviewable.
- Document your assumptions, design tradeoffs, and debugging decisions.
- Verify AI output before trusting it: run the checks that fit the domain — unit tests, linters, simulations, or bench/lab measurements.
- Review AI output for correctness, edge cases, and real-world consequences.
HARQ (Hybrid Automatic Repeat reQuest) — coming to the question bank
The adaptive practice engine is already live for core wireless, RF, and ML systems. HARQ (Hybrid Automatic Repeat reQuest) isn't covered in the question bank yet — get notified when it's added.