LDPC and Polar Coding in 5G NR — The Complete 3GPP TS 38.212 Engineering Guide

Why channel coding is the heart of 5G NR

Every 5G slot you receive on your phone is a small miracle. The bit that came out of the gNB ran a 50 km gauntlet of fading, multipath, interference and quantisation noise — and yet your speed test still says 600 Mbps. The reason that miracle happens, slot after slot, is forward error correction. And the choice of error correction code is the single biggest physical‑layer decision a wireless standard makes. 4G picked Turbo for data and Tail‑Biting Convolutional Coding for control. 5G NR picked something different on both counts: LDPC for the data channels and Polar for the control channels.

That decision was made in November 2016 in 3GPP RAN1 #87 in Reno, after roughly six months of company submissions, simulations and political horse‑trading. The arguments were never about the abstract mathematical beauty of either family — they were about three engineering numbers: throughput per square millimetre of silicon, performance at very short blocks, and the cliff at very low BLER. LDPC won the data debate because of throughput. Polar won the control debate because of short‑block performance. Both winners are encoded into 3GPP TS 38.212, and that document is what every modem chip on Earth has implemented for the last seven years.

This article is a complete walk‑through of TS 38.212 Section 5.3 written for engineers who have to actually work with these codes — integrators tracing a CB segmentation issue, system designers picking an MCS table, students preparing for an interview, and L1 developers porting a decoder to a new SoC. Everything below is real spec text, not hand‑waving. Every base graph, every lifting size, every reliability index and every rate‑matching rule is exactly what 3GPP wrote, with the section numbers in brackets so you can verify it yourself.

The 5G NR coding map — who uses what

Before we open the LDPC bonnet, it helps to see the whole engine. NR defines exactly five families of channel codes, and each one is bound to a specific set of physical channels. There is no overlap and no fallback — once you know the channel, you know the code. The table below is a compressed view of TS 38.212 Section 5.3.

The first thing this table makes painfully clear is that 99% of the air‑interface bits, by volume, run through LDPC. Every byte of throughput, every megabit of video, every IP packet your application generates is LDPC‑coded. Polar's job is much smaller in volume but enormously more important in latency — if PDCCH fails, the entire slot is wasted, the UE has nothing to demodulate, and the operator's KPIs scream. This asymmetry of jobs is exactly why 3GPP needed two codes instead of one.

LDPC deep dive: base graphs BG1, BG2 and lifting

An LDPC code is fully described by a sparse parity‑check matrix H: every row is one parity equation, every column is one coded bit, and the codewords are exactly the binary vectors c that satisfy H·cT = 0. The "low‑density" name comes from the fact that almost all entries of H are zero — this sparseness is what makes belief‑propagation decoding tractable on real silicon. So far so good. The real engineering question, the one 3GPP had to answer in the spec, is: where does H come from?

NR uses a clever shortcut called quasi‑cyclic LDPC with lifting. Instead of storing one giant H, the standard stores a small base graph — an integer matrix where each entry tells you either "no edge here" or "an edge with shift value v". To get the real H at run‑time you take the base graph and replace every "no edge" with a Z×Z zero block, and every "shift v" with a Z×Z circulant identity matrix shifted by v columns. Z is called the lifting size. Choose Z and you choose the codeword length.

Two base graphs, two operating regions

NR ships with exactly two base graphs, and the encoder picks between them based on TBS and code rate. The split is engineered so that each base graph is best in its own region — BG1 is high‑rate, large‑block; BG2 is low‑rate, small‑block. The selection rule (TS 38.212 §7.2.2 / §6.2.2) is:

The numbers 292 and 3824 are not arbitrary; they came out of link‑level simulations comparing BG1 vs BG2 BLER curves at every code rate. BG2 is structurally superior at low rate because it has a smaller K_b (only 10 systematic columns, versus 22 for BG1) which means more parity bits per information bit and a much lower error floor at low SNR. BG1, by contrast, has 22 systematic columns and is far more efficient when the modulator wants very high‑rate codewords for 256QAM and 1024QAM transmissions.

Lifting size Z — the eight magic sets

Once you have a base graph you still need to choose Z to make the actual codeword the right length. NR allows 51 distinct lifting sizes from 2 up to 384, organised into eight sets indexed by a parameter i_LS from 0 to 7. Each set is a geometric series: take an odd starting value a ∈ {2, 3, 5, 7, 9, 11, 13, 15} and multiply it by 2^j for j = 0, 1, 2, ... up to 384. So set 0 is {2, 4, 8, 16, 32, 64, 128, 256}, set 1 is {3, 6, 12, ..., 384}, set 2 is {5, 10, 20, ..., 320}, and so on.

Why eight sets and not just one big list? Because the integer shift values inside the base graph are different for each set — the spec actually stores eight different copies of the BG1 entries (one per set) in Tables 5.3.2‑2 and 5.3.2‑3, each tuned for the specific set so that the resulting parity‑check matrix has good girth and decoder convergence. This is the kind of detail you would never invent yourself; it took years of academic work and was contributed to 3GPP by groups including Qualcomm, Samsung, Huawei and Nokia.

The LDPC processing chain step by step

From the moment a transport block leaves higher layers until it lands on PUSCH/PDSCH resource elements, it goes through a fixed nine‑step pipeline. Every box in that pipeline is specified somewhere in TS 38.212 Section 6 (UL) or Section 7 (DL). Get any box wrong and the receiver gets garbage. Here is the whole chain, in order, with the section number and a short engineering note for each.

Step 1 — Transport block CRC attachment (5.2.1)

The MAC hands the PHY a transport block of size A bits. The PHY appends a CRC: CRC24A if A > 3824, otherwise the shorter CRC16. The polynomials are fixed in TS 38.212 §5.1.1. The CRC is computed over the systematic bits and appended — this is the only CRC the receiver uses to know whether the entire transport block decoded correctly.

Step 2 — Code block segmentation and CB CRC (5.2.2)

If the post‑CRC payload B is larger than the maximum code block size (8448 for BG1, 3840 for BG2), the encoder splits it into C equal‑sized code blocks of length K'. Each code block then receives its own 24‑bit CRC (CRC24B) so the decoder can later check each CB independently. If C = 1 (the whole TB fits in a single CB), no CB‑level CRC is added — the TB CRC is enough.

The segmentation is not arbitrary — the spec computes:

"Filler bits" (set to NULL, value 0 in the encoding but treated as known by the decoder) are inserted to bring the actual K up to K_b·Z — this is what allows a code block to use a quantised lifting size instead of an arbitrary length.

Step 3 — LDPC encoding (5.3.2)

For each code block the encoder runs c = G · m where G is implicitly defined by the lifted parity‑check matrix. In practice nobody computes G explicitly — you do back‑substitution on the H matrix. The first 2Z columns are punctured (not transmitted) but their contribution to parity is still computed. After encoding you have a mother codeword of length (Ncb,bg − 2) · Z = 66Z for BG1 or 50Z for BG2.

Step 4 — Rate matching (5.4.2)

This is where the magic happens. The encoder writes the mother codeword into a circular buffer of length N_cb (which is at most the mother length, but can be smaller if the soft buffer is limited). It then reads E bits out of the buffer starting at position k₀ — that starting offset is determined by the redundancy version. We will look at this in detail in the next chapter.

Step 5 — Per‑CB bit interleaver (5.4.2.2)

The E rate‑matched bits go through a row‑column interleaver of width Q_m (the modulation order, e.g. 6 for 64QAM). This interleaver is what gives NR LDPC its modulation‑diversity gain — bits with very different reliabilities end up on different positions of the QAM constellation.

Steps 6–9 — Concatenation, mux, scramble, modulate

All C code blocks are concatenated into one big bit stream. On PUSCH this stream is then optionally multiplexed with UCI bits (HARQ‑ACK, CSI, SR), then scrambled with a Gold sequence whose initial value is derived from RNTI and cell ID, then modulated and finally written to resource elements.

Rate matching and the four redundancy versions

The single most important thing the rate matcher does is enable HARQ. When the first transmission fails, the receiver does not throw away the soft bits — it keeps them in a buffer. The retransmission then sends a different set of bits from the same mother codeword, and the decoder combines old and new soft information. Each "different starting point" is a redundancy version, and there are exactly four of them in NR. The starting offsets k₀ are listed in Table 5.4.2.1‑2 of TS 38.212.

The reason RV0 and RV2 are self‑decodable but RV1 and RV3 are not is purely a matter of where their starting offsets fall in the circular buffer. RV0 starts at the beginning of the systematic region, so it sends all the information bits and the receiver can decode standalone. RV3 starts deep in the parity region, so it sends only parity — on its own that is gibberish, but combined with RV0 it gives the decoder more linearly independent parity equations and lowers the residual BLER.

Polar codes from first principles

Polar codes were invented by Erdal Arïkan in 2008 in a paper titled "Channel polarization: A method for constructing capacity‑achieving codes". Of the dozens of code families competing for 5G control‑channel duty, polar was the only one with a mathematical proof that it asymptotically achieves the Shannon capacity of any binary‑input symmetric channel. That alone would not have won the 3GPP vote — what won the vote was that even at the very short block lengths used by PDCCH (typically N = 128 or 256 bits before puncturing), polar codes built with successive‑cancellation list decoding land within roughly 0.5 dB of the dispersion bound. Nothing else does.

The trick of polar coding is something called channel polarisation. Take two copies of a noisy binary channel W and combine them with a 2×2 transformation:

If you transmit x₁ and x₂ through the channel and try to decode u₁ first, then u₂ assuming u₁ is known, the surprising result is that the effective channel for u₁ is worse than W and the effective channel for u₂ is better. The information capacities are unequal — one bit channel has been polarised toward bad, the other toward good. Now recurse: take 2 of these blocks and combine them again. After log₂N stages you have N synthetic bit channels, and as N grows large each one is either nearly perfect (capacity = 1) or nearly useless (capacity = 0). The fraction of "perfect" channels equals exactly the channel capacity. That is the Shannon limit reached constructively.

The polar encoder is then trivially simple: send your information bits down the high‑capacity channels, set the low‑capacity channels to 0 (the famous "frozen bits"), and apply the recursive transform. The whole encoder is a single matrix multiplication x = u · GN where GN = G2⊗n is the n‑fold Kronecker product of G₂ with itself.

Mother code length and the n_max rule

NR uses two values of n_max:

• n_max = 9 (mother N up to 512) for downlink and uplink control. PDCCH, PUCCH UCI and the longer UCI on PUSCH all live here.
• n_max = 10 (mother N up to 1024) for the broadcast channel PBCH. PBCH carries the MIB (32 bits payload + 24 bits CRC + 8 bits added to give a total K = 64 bits) and uses N = 512 in practice.

The exact value of N for a given (K, E) pair is computed by a procedure in TS 38.212 §5.3.1: take the largest n such that 2ⁿ ≤ max(E, n_min), then check whether the resulting code rate K/N is too low — if so, drop n by one. The minimum mother size is N = 32 (n = 5).

The reliability sequence and frozen bits

Once the encoder knows N, it has to decide which bit positions inside u₀...u_N‑1 get information bits and which get frozen bits. In Arïkan's original paper this required computing the Bhattacharyya parameter or running density evolution for the actual channel, which in a real radio environment would be expensive and constantly changing. 3GPP solved this elegantly: there is a single, fixed, channel‑independent ordering of all 1024 bit channels from least to most reliable, written down as Table 5.3.1.2‑1 of TS 38.212. This is the reliability sequence.

The fact that this single ordering works across every operating SNR and every code rate is one of the small miracles of polar coding. It works because the polarisation transformation is much more dependent on the code structure than on the channel statistics — once the polarisation has happened, the relative ordering of bit channels is roughly stable. Tiny optimisations (PW for "polarisation weight") were proposed during 3GPP study, but in the end the standard committee picked one universal sequence and froze it forever. Every UE on Earth has those 1024 numbers in ROM.

Polar processing — CRC, sub‑block interleaver and rate matching

The encoder pipeline for a polar codeword on PDCCH looks like the LDPC chain but smaller and with one signature trick — the distributed CRC. The full chain is:

Distributed CRC and the early‑termination trick

For PDCCH the CRC is CRC24C, scrambled with the RNTI of the addressee. The classical thing to do would be to append all 24 CRC bits to the end of the information block and then run the polar encoder. NR does something cleverer: it interleaves the CRC bits into the information bits using the deterministic pattern in Table 5.3.1.1‑1, so that some CRC bits sit at the front, some in the middle and some at the end. That is what "distributed CRC" means.

Why bother? Because of the receiver. A UE in CONNECTED mode has to do PDCCH blind decoding several times every slot — checking every aggregation level, every CCE candidate, every search space. Each blind decode runs an SCL decoder of list size 8. With distributed CRC, the decoder can compute partial CRC checks during the SCL traversal: as soon as one path's partial CRC mismatches it can be killed early, freeing up list slots for promising paths. The result is a 30–60% reduction in average decoding cycles for PDCCH compared to a tail‑CRC scheme. Multiplied across hundreds of blind decodes per slot per UE, that is real silicon power savings.

Sub‑block interleaver — 32 blocks, fixed pattern

After polar encoding the codeword is broken into 32 equal‑size sub‑blocks (each of size N/32 bits) and these sub‑blocks are reordered by a fixed permutation P given in Table 5.4.1.1‑1 of TS 38.212. The permutation looks random but is in fact engineered so that puncturing or shortening from the front of the buffer drops the least useful bits first.

Rate matching — three modes

After the sub‑block interleaver, the encoder writes the codeword into a circular buffer and reads E bits out. Depending on (E, N, K) one of three modes is used:

The 7/16 threshold is not a typo — it really is 7 over 16. It comes out of an analytical comparison of how shortening and puncturing affect the polarisation: at high code rate, shortening hurts the wrong bit channels and puncturing is better; at low code rate, the opposite is true.

PDCCH‑only channel interleaver

After rate matching, only PDCCH applies one more permutation: a triangular interleaver that scatters bits across QPSK symbols and across CCEs so that any single‑CCE collision with another DCI causes only graceful degradation rather than a catastrophic loss. PUCCH and PUSCH UCI skip this step.

Decoding — BP/min‑sum, SC, SCL and CA‑SCL

3GPP only specifies the encoder. The decoder is an implementation choice, but in practice every commercial chip uses the same family of algorithms because nothing else gives the right performance/silicon trade‑off. Here is the short version.

LDPC decoding — layered min‑sum

LDPC decoders run belief propagation on the bipartite graph of H: variable nodes (one per coded bit) exchange log‑likelihood ratio (LLR) messages with check nodes (one per parity equation). After enough iterations the variable‑node beliefs converge and you read out the decoded bits. In hardware, exact BP is too expensive because it needs the tanh function at every check node, so production decoders use the min‑sum approximation:

Real chips run a "layered" version where rows of H are processed sequentially — this halves the number of iterations needed for the same BLER. Typical implementations on smartphone modems use 8 to 15 iterations and reach BLER 10^‑3 within roughly 1 dB of the dispersion bound. The throughput is enormous: a 7nm modem can sustain 4 Gbps of LDPC decoding in well under 100 mW.

Polar decoding — SC, SCL, CA‑SCL

Polar codes have a different decoder family. The simplest is successive cancellation (SC): walk the binary tree of bit channels left to right, and at each information bit position pick the locally most likely value given everything decoded so far. SC is fast (O(N log N) operations) but its BLER is mediocre at the short blocks NR uses.

The breakthrough that made polar practical for 5G is successive cancellation list (SCL) decoding, due to Tal and Vardy. Instead of picking one path through the tree, SCL maintains a list of L candidate paths (typical L = 8 for NR). At each information bit it doubles the list (one fork for each of 0 and 1) and then prunes back to the L most likely. After decoding the last information bit it picks the surviving path with the highest path metric.

Now combine SCL with the CRC: the decoder picks the surviving path that also passes the CRC check. This is CRC‑aided SCL (CA‑SCL), and it is what 5G actually uses. The 24‑bit CRC effectively acts as 24 extra parity equations applied across the list, dramatically reducing the chance of selecting an incorrect surviving path. CA‑SCL with L = 8 reaches within 0.5 dB of the dispersion bound for K up to a few hundred bits — the regime PDCCH operates in.

Side‑by‑side — when each code wins

Putting it all together, the engineering case for splitting 5G into LDPC and Polar comes down to three numbers per code family.

Two end‑to‑end worked examples

Example 1 — LDPC for a 12 000‑bit transport block at code rate 0.5

Example 2 — Polar encoding a 40‑bit DCI for PDCCH at AL=4

Frequently asked questions

Why didn't 3GPP just keep Turbo codes from LTE?

Turbo codes were considered seriously and have a deep, mature implementation base from LTE and HSPA. Three things killed them for 5G data: (1) the iterative MAP decoder is fundamentally hard to parallelise beyond 8–16 sub‑blocks, which limits Gbps throughput; (2) Turbo has a visible error floor around BLER 10^‑4–10^‑5 that requires careful interleaver design to push down; (3) LDPC's IR‑HARQ scheme with rate‑compatible parity check matrices is structurally cleaner than Turbo's puncturing patterns. For control, Turbo is even worse: at K = 40–100 bits it underperforms both polar and convolutional codes.

Is the polar reliability sequence really frequency‑independent?

For all practical purposes, yes. The sequence in Table 5.3.1.2‑1 was constructed for the binary‑input AWGN channel at a "design SNR" but Monte‑Carlo studies show that the relative bit‑channel ordering is essentially preserved across the entire range of SNRs and modulation orders that NR uses. There is no need for the UE or gNB to recompute the sequence for every (channel, modulation, code rate) tuple — one fixed table works.

What is the longest possible polar codeword in NR?

N = 1024, used only for PBCH (which carries the MIB). All other polar uses cap at N = 512. The 1024‑long mother codeword is then heavily punctured down to the actual PBCH transmission size (864 channel bits in the standard SS/PBCH block layout).

What is the longest possible LDPC code block in NR?

K = 8448 information bits (BG1 with Z = 384). Beyond that, the transport block is segmented into multiple code blocks. The maximum number of code blocks per transport block in NR is governed by the maximum supported transport block size, which for the highest UE category reaches roughly 1.6 Mbits.

How does BLER compare between LDPC and Polar at the same K?

At K below 200 bits, polar with CA‑SCL beats LDPC by 0.5–1.5 dB. Between K = 200 and 500 the two are roughly tied. Above K = 1000, LDPC has a clear advantage (about 0.2–0.5 dB) because its code construction has more structural diversity. This is exactly the partition that 3GPP encoded into the channel assignment.

Why does PUSCH UCI use so many code families?

UCI on PUSCH is special because the number of bits varies enormously: a UE might send 1 HARQ‑ACK bit one slot, 11 CSI bits the next, 200 CSI bits the slot after. Using one code for all of these would either over‑engineer the small cases (Polar with K = 1 is wasteful) or under‑perform the large cases (Reed–Muller at K = 200 is hopeless). So the spec defines a graceful staircase: 1 bit → repetition; 2 bits → simplex; 3–11 bits → Reed–Muller (32, K); 12–1706 bits → polar. Each step uses the smallest, fastest code that can do the job.

Where can I read the spec myself?

The free, authoritative source is the 3GPP portal: https://www.3gpp.org/ftp/Specs/archive/38_series/38.212/. Always download the latest released version (currently v18.7.0 as of Release 18). Section 5.3 is the channel coding chapter. It is dense but readable, and once you have read this article it will look much friendlier.

Channel coding is the unglamorous, invisible workhorse of 5G NR. Nothing about it shows up in the marketing slides — nobody tweets about base graphs or reliability sequences. But every Gbps of throughput, every successful PDCCH decode, every initial cell access starts with the bits going through one of the two pipelines you just learned. The next time someone asks you why 5G works, you have a real answer: because Arïkan and Gallager did the maths, and 3GPP picked the right code for the right job.