Why 5G NR Replaced Turbo Codes with LDPC and Polar

When 3GPP began designing the 5G NR physical layer in 2016, one of the loudest fights inside RAN1 was over channel coding. LTE used Turbo codes for data and tail-biting Convolutional codes for control. They worked. They had a decade of optimization. They were familiar. So why throw them out?

The answer turned out to be three letters: URLLC — Ultra-Reliable Low-Latency Communications. To hit 1 ms one-way latency at 99.999% reliability, the channel coder had to decode in well under 100 microseconds. Turbo could not.

The Latency Problem with Turbo

Turbo decoding is built around an iterative loop between two component decoders connected through an interleaver. Each iteration, decoder A runs, hands its soft outputs through the interleaver to decoder B, B runs, hands back through the de-interleaver, and the cycle repeats. Five to eight iterations are typical.

The killer is that this loop is inherently serial. A given iteration cannot start until the previous one finishes. You cannot parallelize across iterations. You cannot pipeline either, because the soft information from iteration N is used to refine iteration N+1.

By contrast, LDPC's belief-propagation decoder is structurally parallel. Every variable node updates its messages simultaneously, then every check node updates its messages simultaneously. With sufficient hardware, one full iteration of a 1024-variable-node LDPC decoder can run in a single clock cycle — versus thousands of cycles for Turbo's serial loop.

This isn't a theoretical edge. 5G NR's chosen base graph BG1 with lifting size Z = 384 means an effective parity-check matrix of ~26,000 columns × ~17,000 rows. A modern hardware decoder runs all the variable-node updates in parallel across the lifted Z-block, completes 25-50 iterations in under 50 microseconds, and delivers decoded bits ready for HARQ acknowledgment within the same slot.

The Error Floor Problem

Turbo codes have a well-known "error floor" at high SNR. Below a certain BLER (typically 10⁻⁵ to 10⁻⁶), the rate of improvement with additional SNR slows dramatically and eventually plateaus. This is fine for eMBB throughput-optimized links, but URLLC needs 10⁻⁵ residual error after HARQ — and you don't want to depend on retransmission to get there.

LDPC, especially the quasi-cyclic LDPC codes 3GPP picked, has no such floor in the operational range. The waterfall region keeps falling. With 25-50 belief-propagation iterations and good base-graph design, BLER 10⁻⁹ is achievable at the same Eb/N0 where Turbo would still be at 10⁻⁵.

Why Polar for Control

Control channels (PDCCH, PBCH) carry small payloads — DCI is typically 30-80 bits. Turbo and LDPC are both designed for large block sizes; they don't shine at small. Polar codes do.

Polar codes, invented by Erdal Arıkan in 2009, are the first practical capacity-achieving codes for the binary symmetric channel. At small block sizes (say, 64 to 1024 bits), they deliver near-Shannon-bound performance with a deterministic encoder and a tractable decoder (typically successive cancellation list decoding with a CRC-aided early-termination tweak).

3GPP picked Polar specifically for control because:

• Small-block efficiency — Polar shines at sub-1024-bit payloads.
• Deterministic structure — no random interleaver; the encoder is just a recursive Hadamard-style transform plus a freezing-set lookup. Hardware-friendly.
• List decoding — SCL (Successive Cancellation List) decoders run multiple decoding hypotheses in parallel and pick the one whose CRC verifies. Robust against typical control-channel block errors.

The Real Cost: Hardware Re-Design

Of course, no spec change is free. UE chipsets and gNB DUs both had to be redesigned. LDPC decoders are area-hungry — a parallel decoder with 384× lifting needs hundreds of thousands of XOR gates. Polar list decoders need stack memory proportional to the list size.

But the trade-off was correct. The hardware area cost is paid once at silicon design time. The latency benefit is paid every microsecond, every slot, every UE, forever.

What This Means in Practice

For a working RF or RAN engineer:

1. You will see different KPIs in NR vs LTE — sub-ms HARQ round-trips, lower BLER targets, higher achievable spectral efficiency at high SNR.
2. UE decoder failures look different — LDPC failures are less correlated with SINR than Turbo's were; they're often driven by hardware iteration limits (UE decided to stop iterating early to save battery).
3. Hybrid IR works better — different RVs of LDPC code blocks combine more constructively than Turbo's puncturing patterns did.
4. Control-channel reliability is decoupled from data — Polar PDCCH can be reliable even when LDPC PDSCH is failing, which simplifies link adaptation.

And for an RF engineer doing log analysis: when you see PDSCH BLER spike, it's almost certainly a propagation/scheduler issue. When you see PDCCH miss-detection spike, it's typically a CORESET configuration or beam-tracking issue. The two failure modes used to be coupled in LTE; in NR they're not.

What's Next?

Rel-19 is already drafting next-generation candidates. Some teams are pushing for "neural-net" channel codes that learn from received samples. Others want sparse-graph codes optimized for AI/ML PHY workloads. The pattern from Rel-15's LDPC/Polar move applies again: standardize what scales in hardware, even if it costs years of optimization on the existing approach.

If you're building a serious career in 5G PHY engineering, understanding LDPC encoding and Polar list-decoding is now the price of entry. The full course walks through both end-to-end with cinematic visualizations of the parity-check matrix, the Tanner graph, and the SCL decoder tree.