LDPC Codes in Wireless (Wi-Fi 6+ / 5G NR / DVB-S2) Interview Prep
LDPC codes in wireless interview prep — Tanner graphs, belief propagation, min-sum decoding, 5G NR base-graph + lifting, Wi-Fi 6+ adoption, vs Polar codes.
Quick answer
LDPC (Low-Density Parity-Check) codes are a family of forward-error-correction codes defined by a sparse parity-check matrix H and decoded iteratively on a Tanner graph using belief propagation.
LDPC questions appear in wireless and modem interviews because the topic sits at the intersection of information theory, decoder algorithm design, and modem hardware architecture.
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.
Key points
- LDPC = a sparse parity-check matrix H decoded iteratively on a Tanner graph (variable nodes ↔ check nodes exchanging LLRs); the sparsity keeps each iteration linear in block length.
- QC-LDPC replaces each base-graph entry with a Z×Z circulant permutation matrix, so the same decoder hardware processes Z bits per cycle and spans many block sizes by changing the lifting size Z.
- Min-sum approximates sum-product (min+sign instead of tanh), cutting decoder gates/power ~50% for ~0.1–0.5 dB BER loss; layered scheduling roughly halves the iteration count vs flooding.
- 5G NR splits coding: LDPC for data (PDSCH/PUSCH), Polar for control (PDCCH/PBCH). BG1 (info ≤8448 bits, rate 1/3–8/9) for large blocks above ~3824 bits at rate >1/4; BG2 (info ≤3840 bits, rate 1/5–2/3) for smaller/coverage-limited blocks; 51 lifting sizes Z = 2–384.
- Wi-Fi: LDPC is optional from 802.11n (block lengths 648/1296/1944 bits) but effectively mandatory at the top MCS — HE-MCS 10/11 (1024-QAM, Wi-Fi 6) and EHT-MCS 12/13 (4096-QAM, Wi-Fi 7).
- Throughput drove the data-channel switch: parallel QC-LDPC decoders exceed 20 Gbps vs ~150 Mbps for serial turbo MAP; modern LDPC sits within ~0.5 dB of Shannon at practical block lengths.
- Turbo is not universally inferior — at very low code rates (<1/3) and short blocks it can match LDPC; the 3GPP choice reflects high-rate, large-block eMBB dominance, not a blanket claim.
What it is
LDPC (Low-Density Parity-Check) codes are a family of forward-error-correction codes defined by a sparse parity-check matrix H and decoded iteratively on a Tanner graph using belief propagation. Originally proposed by Gallager in 1962 and rediscovered in the late 1990s, LDPC has become the data-channel code of choice for modern wireless standards because the decoder is highly parallelizable, the code-rate structure is flexible via base-graph plus lifting, and the asymptotic performance approaches the Shannon limit at moderate-to-large block sizes. The Tanner graph is a bipartite graph with variable nodes (one per coded bit) on one side and check nodes (one per parity-check equation) on the other; edges connect bits to the checks that involve them. Belief-propagation decoding iterates messages between the two sides: each variable node sends log-likelihood-ratio (LLR) estimates of its bit value to connected check nodes; each check node combines incoming LLRs (using a tanh-style update that enforces the parity constraint) and sends back refined LLRs; the variable nodes update again, and so on. After 10-50 iterations (typical for shipping systems), the decoder hard-decides each bit from its accumulated LLR. The sparsity of H keeps each iteration linear in code length, which is what makes LDPC tractable at multi-Gbps. The 5G NR data channel (PDSCH / PUSCH) uses LDPC with two base graphs and 51 lifting sizes (Z = 2 to 384): BG1 (information blocks up to 8448 bits, code rates 1/3–8/9) carries large transport blocks above ~3824 bits at rates above 1/4, while BG2 (up to 3840 bits, rates 1/5–2/3) covers smaller, coverage-limited blocks. The actual parity-check matrix is built by replacing each base-graph entry with a Z-by-Z circulant permutation matrix — a structured "lifted" construction that lets the same decoder hardware handle many block sizes by changing Z. Rate matching uses circular-buffer puncturing: the encoder produces a long codeword from the lowest rate, then the rate-matcher selects a contiguous range of bits to transmit. Different Redundancy Versions (RVs 0/1/2/3) for HARQ Incremental Redundancy choose different starting points in the buffer — see /topics/harq for the HARQ context. IEEE 802.11 introduced LDPC as an optional code in 802.11n (2009) — with three block lengths (648, 1296, 1944 bits) at rates 1/2, 2/3, 3/4, and 5/6 — made it commonly enabled in 802.11ac (2013), and now relies on it heavily in 802.11ax (Wi-Fi 6), 802.11be (Wi-Fi 7), and 802.11bn (Wi-Fi 8). LDPC becomes effectively mandatory at the highest MCS — HE-MCS 10/11 (1024-QAM) in Wi-Fi 6 and EHT-MCS 12/13 (4096-QAM) in Wi-Fi 7 — because the legacy Binary Convolutional Code cannot deliver the required BER at the tight per-symbol Euclidean distance of those constellations. Case study: a Wi-Fi 7 chipset targeting 4096-QAM downlinks at multi-Gbps throughput. The LDPC decoder runs normalized min-sum (a hardware-friendly approximation of full sum-product) with aggressive early termination — stopping iterations as soon as the parity checks are all satisfied. The decoder area and power can be a significant fraction of the modem baseband (see /topics/soc-design-engineer-signals), and the iteration-count vs throughput vs BER trade-off is a central architectural decision.
Why interviewers ask
LDPC questions appear in wireless and modem interviews because the topic sits at the intersection of information theory, decoder algorithm design, and modem hardware architecture. A strong candidate can sketch the Tanner graph, explain belief propagation as LLR message-passing, name min-sum as the hardware-friendly approximation, and place LDPC correctly against Polar codes for the control-versus-data split in 5G NR. Three signals matter most. First, can the candidate explain belief propagation at the right level of abstraction — variable nodes and check nodes exchanging LLR messages, the tanh-style check-node update, iterative refinement until convergence — without dropping into hand-waving? Second, can the candidate articulate the implementation trade-offs: full sum-product gives the best BER but is expensive in gates; min-sum simplifies the hardware at a 0.2-0.5 dB cost; normalized min-sum recovers most of that loss. Third, can the candidate place LDPC correctly in the standards landscape: 5G NR LDPC for data + Polar for control, Wi-Fi 6+ default LDPC for everything except legacy compatibility, the role of LDPC in supporting high-order MCS like 4096-QAM where BCC cannot deliver the required BER. Hiring teams use LDPC questions to test whether a candidate has the algorithmic vocabulary to discuss the modem baseband as a system — not just at the level of "the decoder corrects errors." Roles where these questions matter most include baseband DSP engineers, modem firmware engineers, ASIC engineers designing LDPC blocks, and Wi-Fi / cellular system engineers (see /practice/wireless-engineer) planning chipsets with specific throughput-and-power budgets.
Common mistakes
The most common mistake is calling LDPC "iterative decoding" without naming the bipartite Tanner-graph structure or the LLR message-passing algorithm. The defining property of LDPC is the sparse parity-check matrix and the resulting low-complexity belief-propagation decoder; "iterative" is true but does not capture the engineering content. A second common mistake is confusing LDPC with turbo codes. Turbo codes (Berrou-Glavieux 1993) use two convolutional encoders separated by an interleaver and decode via the BCJR algorithm; LDPC codes use a sparse parity-check matrix and decode via belief propagation on the Tanner graph. Both are capacity-approaching but the algorithms and the parallelism characteristics differ substantially. 5G NR moved from turbo (LTE) to LDPC for the data channel precisely because LDPC parallelizes better for multi-Gbps targets. A third gap is missing the LDPC vs Polar split in 5G NR (see /topics/nr-channel-coding). Candidates who say "5G uses LDPC" miss that Polar codes carry control channels (PDCCH / PUCCH) while LDPC carries data channels (PDSCH / PUSCH). The split exists because Polar performs better at short block sizes (control messages are tens to a few hundred bits) and LDPC scales better at moderate-to-large block sizes (data payloads are 1000-8000 bits). A fourth gap is over-claiming about min-sum. Min-sum is an approximation of sum-product, not an equivalent — it costs 0.2-0.5 dB BER. Normalized or offset min-sum recovers most of that, but no min-sum variant matches full sum-product exactly. Real decoders pick the operating point based on hardware budget and BER targets. A fifth gap is forgetting the rate-matching and HARQ-IR connection. 5G NR LDPC rate matching uses a circular buffer; different Redundancy Versions for HARQ-IR start at different offsets in the buffer, so each retransmission delivers new parity bits. This is the mechanism that makes HARQ-IR more spectrally efficient than Chase combining. Candidates who treat LDPC and HARQ as independent topics miss the integration.
LDPC vs turbo vs Polar — code-family comparison
| Code family | Decoding algorithm | Best block-size regime | Where used |
|---|---|---|---|
| LDPC (Low-Density Parity-Check) | Belief propagation on Tanner graph (sum-product or min-sum) | Moderate to large (1000-8000 bits) | 5G NR data (PDSCH/PUSCH), Wi-Fi 6/6E/7/8, DVB-S2, 802.16 |
| Turbo | BCJR per constituent + iterative exchange via interleaver | Moderate (1000-6000 bits) | LTE data, 3G HSPA, deep-space (CCSDS); replaced by LDPC in 5G NR |
| Polar | Successive-cancellation list (SCL) decoding | Short (tens to hundreds of bits) | 5G NR control (PDCCH/PUCCH); first capacity-achieving family for finite block lengths |
| BCC (Binary Convolutional Code) | Viterbi decoder | Short to moderate | Wi-Fi 802.11a/g legacy mandatory; backward-compat in newer Wi-Fi |
Sample interview questions
- Why does 5G NR use LDPC codes for the data channel but Polar codes for control channels?
- A. LDPC is the only code that can support 4096-QAM modulation, and Polar is the only code that can support QPSK; the choice is forced by the modulation order assigned to each channel.
- B. LDPC decoders parallelize well and perform near-optimally at the moderate-to-large block sizes typical of data payloads (1000-8000 bits); Polar codes excel at the short block sizes of control messages (tens to a few hundred bits) where successive-cancellation list decoding is efficient. Each code is matched to the block-size regime it operates in. ✓
- C. Polar codes are deprecated in 5G NR Rel-17 and replaced by LDPC for both control and data; the original control-channel Polar choice was reverted.
- D. LDPC requires turbo decoding hardware that 5G UEs lack; Polar codes are the only capacity-approaching option compatible with the receiver power budget.
Option B is correct. LDPC decoders scale to multi-Gbps throughput via highly parallel message-passing hardware and perform near-optimally at the moderate-to-large block sizes (around 1000-8000 bits) where data-channel payloads live. Polar codes (Arikan 2008) are provably capacity-achieving in the asymptotic limit and perform extremely well at the short block sizes (tens to a few hundred bits) where control-channel messages live, with simpler successive-cancellation list decoding for those sizes. 5G NR assigns LDPC to the data transport channels (DL-SCH / UL-SCH on PDSCH/PUSCH) and Polar to the larger control messages — DCI on PDCCH, the PBCH payload, and UCI above ~11 bits — to match each code to its native operating regime. (Very small UCI of 1-11 bits actually uses block coding — repetition/simplex/Reed-Muller — rather than Polar, so "Polar for all control" is a simplification.) Option A is wrong because modulation order is independent of code choice; LDPC and Polar both support a range of constellations. Option C is wrong because Polar codes remain in 5G NR Rel-17 and continue to be used for control channels. Option D is wrong because LDPC does not use turbo-decoder hardware — turbo and LDPC are different code families with different decoder architectures.
- A baseband engineer is comparing full sum-product LDPC decoding against min-sum decoding for a Wi-Fi 7 chipset. What is the dominant practical trade-off?
- A. Min-sum is mathematically identical to full sum-product and incurs no performance loss; the choice is purely about coding style.
- B. Min-sum doubles the decoder latency because it requires twice the iteration count; full sum-product is the right choice for multi-Gbps Wi-Fi.
- C. Min-sum is incompatible with the Tanner graph structure of LDPC codes; it applies only to convolutional decoders.
- D. Min-sum simplifies the check-node update from a tanh-style nonlinearity to a min-and-sign operation, shrinking gate count and power significantly at a cost of roughly 0.2-0.5 dB BER performance versus full sum-product. Normalized or offset min-sum recovers most of that loss with a small scaling factor. ✓
Option D is correct. The check-node update in sum-product decoding involves a tanh and an atanh, which are expensive in hardware. Min-sum replaces the tanh-style update with the minimum-magnitude rule across incoming LLRs combined with the product-of-signs — much cheaper to implement. The price is roughly 0.2-0.5 dB BER loss in shipping configurations. Normalized min-sum (multiply the min-sum result by a small constant like 0.75) or offset min-sum (subtract a small offset) recovers most of the loss while keeping the hardware simple. Wi-Fi-class and cellular LDPC decoders commonly use normalized or offset min-sum variants with aggressive early termination. Option A is wrong because min-sum is an approximation of sum-product with a measurable BER difference. Option B is wrong because min-sum is a simpler per-iteration update; it does not require more iterations. Option C is wrong because min-sum is specifically the LDPC check-node update simplification, derived from the Tanner-graph structure of LDPC.
- In 5G NR LDPC, what does the "lifting size" Z parameter control, and why is the base-graph + lifting structure useful?
- A. Z is the size of the circulant permutation matrix that replaces each entry of the base graph H_base; the resulting parity-check matrix has size proportional to Z, which lets the same decoder hardware handle a range of block sizes by changing Z without reloading the decoder. ✓
- B. Z is the modulation order assigned to the LDPC code, independent of the parity-check matrix structure.
- C. Z is the number of HARQ retransmission attempts allowed before the codeword is discarded.
- D. Z is the puncturing pattern selector for rate matching, with each Z value corresponding to a different Redundancy Version.
Option A is correct. 5G NR defines two base graphs (BG1 for larger payloads, BG2 for smaller payloads) and supports a range of lifting sizes Z. The actual parity-check matrix used by the encoder and decoder is built by replacing each entry in the base graph with a Z-by-Z circulant permutation matrix — a "lifted" construction. The decoder hardware processes blocks of size Z in parallel, and by changing the Z parameter the same decoder handles a wide range of block sizes without reloading code-construction tables. This structured-LDPC design is key to making 5G NR LDPC implementable at multi-Gbps throughput across many payload sizes. Option B is wrong because Z is unrelated to modulation order; LDPC and modulation are independent layers. Option C is wrong because Z is a code-construction parameter, not a HARQ retransmission limit. Option D is wrong because rate matching and Redundancy Versions select bits from the LDPC circular buffer; Z is the lifting size of the parity-check matrix itself.
Frequently asked questions
- What are LDPC codes and why did they replace turbo codes in modern wireless standards?
- LDPC (Low-Density Parity-Check) codes are forward-error-correction codes defined by a sparse parity-check matrix H, decoded iteratively on a Tanner graph using belief propagation (also called sum-product or message-passing decoding). They were rediscovered in the late 1990s after Gallager originally proposed them in 1962. Modern wireless standards moved from turbo codes to LDPC for the data channel because LDPC decoders are highly parallelizable (good for hardware throughput at multi-Gbps rates), have a more flexible code-rate structure via base-graph plus lifting, and tend to have a lower error floor at moderate-to-high SNR. 5G NR uses LDPC for the user data channel and Polar codes for control; IEEE 802.11 has used LDPC since 802.11n (as an optional code) and 802.11ac (commonly enabled), with continued use in 802.11ax / be / bn.
- How does belief-propagation (sum-product) decoding work on an LDPC Tanner graph?
- The Tanner graph is a bipartite graph with variable nodes (one per coded bit) on one side and check nodes (one per parity-check equation) on the other; edges connect bits to the checks that involve them. Decoding iterates messages between the two sides: each variable node sends log-likelihood-ratio (LLR) estimates of its bit value to connected check nodes; each check node combines incoming LLRs (using a tanh-style update that enforces the parity constraint) and sends back refined LLRs; the variable nodes update again, and so on. After enough iterations (typically 10-50 for shipped systems) the decoder hard-decides each bit from its accumulated LLR. The "sparse" property of the H matrix keeps each iteration linear in code length, which is what makes LDPC tractable at multi-Gbps. Approximations like min-sum decoding trade a small dB performance loss for simpler hardware.
- What is the 5G NR LDPC structure — base graphs, lifting, and rate matching?
- 5G NR defines two base graphs (BG1 for larger payloads, BG2 for smaller payloads) and supports a range of lifting sizes Z. The actual parity-check matrix used at encoding is built by replacing each entry in the base graph with a Z-by-Z circulant permutation matrix — a structured "lifted" construction that lets the same decoder hardware handle many block sizes with only the lifting size changing. Rate matching uses circular-buffer puncturing: the encoder produces a long codeword from the lowest rate, then the rate-matcher selects a contiguous range of bits to transmit. Different Redundancy Versions (RVs 0/1/2/3) for HARQ Incremental Redundancy choose different starting points in the buffer, which is why HARQ-IR with 5G NR LDPC delivers additional coding gain on each retransmission. See /topics/harq for the HARQ context.
- Why does Wi-Fi use LDPC instead of convolutional / BCC codes for modern rates?
- Wi-Fi has two coding options. Binary Convolutional Code (BCC) is the legacy mandatory code carried since 802.11a/g — simple Viterbi decoder, low complexity, but the error-correction performance degrades at high MCS and high code rate. LDPC is the optional-then-recommended code introduced in 802.11n and used heavily in 802.11ac, 802.11ax, 802.11be, and 802.11bn. For high-order MCS like 4096-QAM in 802.11be, LDPC is effectively mandatory because BCC cannot deliver the required BER at the per-symbol Euclidean distance — the gap between LDPC and BCC widens dramatically at high modulation orders. Wi-Fi 7 / 8 chipsets ship LDPC as the default coding path; BCC remains in the standard for backward compatibility with legacy clients.
- How do LDPC codes compare to Polar codes — and why does 5G NR use both?
- LDPC and Polar are both modern capacity-approaching codes but they sit at different operating points. LDPC decoders are highly parallelizable, scale well to multi-Gbps throughput, and perform well at moderate block sizes (1000-8000 bits) where data-channel payloads live. Polar codes (Arikan 2008) are provably capacity-achieving in the asymptotic limit, perform extremely well at short block sizes (tens to a few hundred bits) where control-channel messages live, and have simpler successive-cancellation list decoding for those sizes. 5G NR uses LDPC for the user data channel (PDSCH / PUSCH) and Polar codes for the control channels (PDCCH / PUCCH), reflecting this short-vs-long-block trade-off. IEEE 802.11 has only adopted LDPC for the data path — control fields in 802.11 use simpler block codes or repetition, not Polar.
- What sample LDPC interview questions catch candidates who only know the buzzword?
- The fastest filter is asking what a Tanner graph is and how messages propagate between variable and check nodes. Candidates who say "LDPC uses iterative decoding" without naming the bipartite-graph structure, the LLR exchange, or the tanh-style check-node update have memorized the term but not the algorithm. A second filter is asking why LDPC outperforms BCC at high MCS — strong answers cite the Euclidean-distance argument for high-order constellations and explain that BCC was a 1990s-era design point that does not scale. A third filter is the base-graph + lifting structure for 5G NR — candidates who can explain that the same decoder hardware handles many block sizes by changing the lifting parameter Z (without reloading the decoder) are demonstrating implementation-level understanding. A fourth is the LDPC vs Polar split in NR — control versus data — which tests whether the candidate understands the short-vs-long block trade-off.
- What hardware considerations dominate LDPC decoder design at multi-Gbps rates?
- Throughput depends on the iteration count and the parallelism of message updates. Hardware decoders trade three things: number of parallel message-passing units (more parallelism → higher throughput, larger silicon area), number of iterations per codeword (more iterations → better BER, lower throughput, more power), and decoder algorithm (full sum-product → best BER, larger gates; min-sum or normalized min-sum → smaller gates, ~0.2-0.5 dB performance loss). Early-termination logic stops iterations when the parity checks are all satisfied, freeing throughput for the next codeword. Wi-Fi 7 / 8 chipsets routinely run LDPC at multi-Gbps with min-sum approximations and aggressive early termination. The decoder area and power can be significant fractions of the modem baseband.
Related topics
Pillar
Siblings
Practice
Essential AI-Native Skills for LDPC Codes in Wireless (Wi-Fi 6+ / 5G NR / DVB-S2)
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.
LDPC Codes in Wireless (Wi-Fi 6+ / 5G NR / DVB-S2) — coming to the question bank
The adaptive practice engine is already live for core wireless, RF, and ML systems. LDPC Codes in Wireless (Wi-Fi 6+ / 5G NR / DVB-S2) isn't covered in the question bank yet — get notified when it's added.