5G NR Rate Matching and Interleaving
Rate matching and interleaving are the steps that turn encoded bits into the exact bit stream needed for the final NR transmission. They decide how many coded bits are taken, which part of the coded stream is selected, how retransmissions vary by redundancy version, and how the final bit order is prepared for modulation and mapping.
Read this page as the bridge between channel coding and the actual physical-channel bit stream. On the shared-data side it belongs with LDPC, MCS, and TBS and resource allocation. On the control side it belongs with Polar coding, PDCCH, PBCH, and selected PUCCH paths.
| Technology | 5G NR |
|---|---|
| Main spec | 3GPP TS 38.212 |
| Related specs | 3GPP TS 38.214 and TS 38.213 for scheduled length and retransmission context |
| Release | Release 18 |
| Main role | Adapt encoded bits to the actual transmission length and ordering required by each channel path |
| Main concepts | Circular-buffer reading, redundancy version, bit selection, puncturing, repetition, and interleaving |
| Why it matters | Rate matching decides which coded bits are actually sent, so it directly affects throughput, retransmission behavior, and decode robustness |
Contents
Overview
Rate matching sits after channel coding and before the final scrambling, modulation, and resource mapping stages. Its job is to make the coded output fit the transmission opportunity created by the scheduler or fixed channel structure.
- It selects the final coded-bit count needed by the channel.
- It can puncture or repeat coded bits depending on the length relationship.
- It works together with redundancy version so retransmissions do not always repeat the same coded region.
- It includes interleaving steps that prepare the final ordering for modulation and mapping.
Quick interpretation
| Role | Adapt encoded bits to the exact transmission length and ordering needed by the physical channel |
|---|---|
| Main actions | Bit selection, puncturing, repetition, interleaving, and redundancy-version-based shifting |
| Main data path | LDPC coded bits for PDSCH and PUSCH |
| Main control path | Polar-coded bits for PDCCH, PBCH, and selected PUCCH cases |
| Main reading point | If the expected coded length or retransmission behavior looks wrong, check rate matching before assuming the coding or transport size itself is wrong |
Processing model
Rate matching starts from the encoded block or blocks and ends with the exact coded-bit sequence passed toward scrambling and modulation.
encoded bits
-> circular buffer or equivalent coded-bit view
-> redundancy-version-dependent selection
-> puncturing or repetition as needed
-> interleaving
-> final coded length E| Stage | Purpose | Reading notes |
|---|---|---|
| Encoded-bit input | Start from LDPC or Polar-coded output | The upstream coding family changes the later rate-matching flow |
| Bit selection | Choose the coded-bit subset used for the current transmission | This is where the effective transmitted protection level becomes visible |
| Puncturing or repetition | Reduce or extend the selected coded output to the needed length | Puncturing removes some coded bits, while repetition reuses them when more bits are needed |
| Interleaving | Reorder coded bits for later modulation and mapping | The interleaving sequence differs between the LDPC and Polar paths |
| Final length | Produce the coded-bit count actually carried by the channel | This final length is usually read as E |
LDPC path
For LDPC-coded shared-data paths, rate matching is tied directly to code-block handling and retransmission behavior. Each code block is rate matched separately before the blocks are concatenated into the final transmission bit stream.
| LDPC area | Main reading point |
|---|---|
| Circular-buffer reading | The encoded code block is read through a circular-buffer model so different coded regions can be selected for different transmissions |
| Redundancy version shift | The selected starting point changes with the active redundancy version, which is why HARQ retransmissions can expose different coded bits |
| Bit interleaving | The selected coded bits are reordered for the later modulation order and mapping path |
| Per-code-block handling | Large transport blocks may create multiple code blocks, each with its own rate-matching step and later concatenation |
This is why LDPC rate matching is inseparable from MCS, TBS and resource allocation, and HARQ. If any of those are read incorrectly, the selected coded-bit length also looks wrong.
Polar path
The Polar-coded control and broadcast path uses its own ordering steps. The general idea is still the same: take the encoded output and adapt it to the transmission length, but the detailed path includes control-side interleaving behavior rather than the LDPC shared-data sequence.
| Polar area | Main reading point |
|---|---|
| Sub-block interleaving | Reorders the coded structure before the final bit-selection stage |
| Bit selection | Chooses the final coded-bit length needed by the control or broadcast channel |
| Coded-bit interleaving | Prepares the selected bits for control-channel modulation and mapping |
| Channel specificity | PDCCH, PBCH, and selected PUCCH cases reuse the same general family idea but with different later channel context |
A useful control-path rule is simple: if the issue is on PDCCH or PBCH, do not read it using shared-data LDPC assumptions. Use the Polar-coded path and its own interleaving sequence instead.
Redundancy versions
Redundancy version changes which coded-bit region is selected for transmission. This matters most on shared data, where retransmissions should not always send the same exact coded subset.
| Area | Why it matters |
|---|---|
| HARQ retransmission | A new redundancy version can expose coded bits that were not sent in the earlier attempt |
| Decode combination | Different RV values improve the chance that combined retransmissions reconstruct the original payload robustly |
| Trace reading | If repeated transmissions use the same RV unexpectedly, the retransmission behavior may be less effective than expected |
| Control signaling link | DCI and channel procedure context determine how the receiver should interpret the current RV and expected coded length |
Important formulas
These are the most useful reading formulas for rate matching and interleaving in daily NR work.
Final coded-bit length
E = final coded-bit length after rate matching E is the number of coded bits actually passed toward scrambling, modulation, and mapping for the
current transmission.
Target code rate from the MCS table
R = x / 1024 x is the code-rate field taken from the active
MCS table. This is one of the main inputs behind the coded-bit
length that rate matching needs to produce.
Approximate spectral-efficiency view
spectral efficiency ≈ Qm × R Qm is the modulation order. This is a useful reading rule when checking whether the resulting
coded length and selected MCS make sense for the observed channel behavior.
Shared-data length context
E depends on usable RE count, modulation order, number of layers, and transport contextThat is why rate matching cannot be read in isolation. It belongs with RE availability, DMRS overhead, transport size, and layer count on PDSCH or PUSCH.
Channel use
| Channel or path | Rate-matching role | Read it with |
|---|---|---|
| DL-SCH on PDSCH | Main shared-data LDPC rate-matching path | MCS, TBS, layers, DMRS overhead, and HARQ |
| UL-SCH on PUSCH | Main uplink shared-data LDPC rate-matching path | Power control, MCS, transform precoding, and HARQ |
| PDCCH | Polar-coded control bit selection and interleaving path | Polar coding, Search Space, CORESET, and DCI payload size |
| PBCH | Polar-coded broadcast bit-selection path | SSB, PBCH payload structure, and broadcast decoding context |
| Selected PUCCH UCI cases | Control-side rate matching before UCI transmission | UCI payload size, format, and the active coding family |
Troubleshooting
When the coded view does not match the expected transport or control behavior, start with rate matching before blaming the entire coding chain.
| Symptom | What to inspect first |
|---|---|
| Transport size and coded length do not match | Check TBS, usable RE count, modulation order, layers, and the final E assumption |
| Retransmissions do not improve decode behavior as expected | Check HARQ context, redundancy version sequence, and whether the retransmission actually selects a different coded region |
| PDSCH or PUSCH decode looks too optimistic for the radio conditions | Check MCS, target code rate, RE overhead, and whether puncturing pressure is too high for the channel state |
| PDCCH or PBCH decode is being read like shared data | Switch to the Polar-coded control path instead of the shared-data LDPC model |
| Repeated transmissions seem identical in traces | Check the recorded RV, DCI context, and whether the trace actually exposes the selected coded-bit region or only the higher-layer retransmission label |
References
- 3GPP TS 38.212 Release 18 - main NR specification for LDPC and Polar rate matching, interleaving, and coded-bit selection
- 3GPP TS 38.214 Release 18 - physical-layer data procedures providing transport-size, modulation, and layer context for shared-data coded length
- 3GPP TS 38.213 Release 18 - physical-layer control procedures and retransmission context used together with RV and channel procedure reading
FAQ
What is rate matching in 5G NR?
It is the step that adapts the coded output to the final transmission length by selecting, puncturing, repeating, and reordering coded bits before transmission.
Why is interleaving used together with rate matching?
Because the final coded-bit ordering needs to fit later modulation and mapping behavior. NR therefore combines coded-bit selection with path-specific interleaving.
What does redundancy version mean in NR?
It changes which coded-bit region is selected for the current transmission, especially in retransmission scenarios.
Do LDPC and Polar coding use the same rate-matching path?
No. The general goal is the same, but the detailed bit-ordering and interleaving sequence differs between the shared-data LDPC path and the control-side Polar-coded path.
Why is rate matching important for troubleshooting?
Because a mismatch in final coded length, RE assumptions, or RV handling can make the transport or control behavior look inconsistent even when the upstream coding family itself is correct.