What actually changes in 6G channel coding when LDPC and Polar already provide the NR baseline? The main questions are decoder throughput, the operating range of a new LDPC base graph, and control payloads that do not fit the existing design comfortably. This page follows the RAN1 contributions and meeting outcomes through RAN1 #126bis, held on October 12–16, 2026.

The starting source set is the supplied TDoc search list, supplemented with company contributions from the meeting lists. The technical discussion uses selected agreement sections, evaluation descriptions, and proposals. A proposal or a reported simulation gain is identified as such; neither means that the design has been selected. The latest session record is R1-2607312, read together with R1-2608752.

• Executive Summary
• Mind Map
• Agreed Items
  • Earlier meetings - carried coding agreements
  • RAN1#126bis - agreements and recorded conclusion
• What is reused from NR, and why study an extension?
• How is the new LDPC base graph taking shape?
  • Why are row splitting and orthogonality still debated?
• When can BG3 be configured, and when is it selected?
• How should LDPC performance and complexity be compared?
  • Why separate maximum complexity from average complexity?
• Does 3–11-bit UCI need a different code?
  • Why do the reported gains point in different directions?
• What changes if DCI exceeds 140 bits?
• How should UCI above 1706 bits be segmented?
• How do HARQ and modulation affect the coding choice?
• Update Note
• Reference

Executive Summary

Following is the status of the main coding questions in the reviewed documents.

Mind Map

The coding questions divide into data-channel throughput, BG3 operating rules and three control-payload ranges. The branches keep those decisions separate, then connect them to decoder cost and the transmission chain. Follow a topic to check its conditions and agreement or proposal status.

Use + to expand a branch and select a topic for its description and section link. Drag the background or comment boxes with the left mouse button to pan. Hold the left mouse button and turn the wheel to zoom. Toolbar buttons and keyboard navigation are also available.

NOTE: Lines group related subjects; they do not specify an encoding or decoding sequence. Expand the final topics to read explanatory comments. An agreed framework, a candidate list and a conditional simulation gain have different meanings. The map follows this note's reviewed records through RAN1#126bis.

Agreed Items

The reviewed records contain explicit coding agreements as well as proposals and observations. The list below separates earlier decisions reproduced in the final summary from outcomes recorded in the #126bis session notes.

Earlier meetings - carried coding agreements

These entries retain the originating meeting given in the reviewed agreement passages. They establish coding families and a structural framework, while leaving the detailed graph and several operating rules open.

• RAN1#122bis coding families : use LDPC for data, including SIBs, and Polar for L1 control information above 11 bits, including PBCH. Reuse within the NR data-rate and control-payload ranges was a working assumption. The maximum Polar mother-code length was kept at 1024. R1-2508176.
• RAN1#124bis LDPC framework : use a maximum block size of 8448 bits, a single-edge graph with 44 information columns, maximum lifting size 192, and mother code rate approximately 2/3. These parameters narrow the study; they do not identify a final PCM.
• RAN1#125 core structure : B uses a weight-three first column with shift pattern [0, X, 0] or [X, 0, X], followed by a dual-diagonal structure. Row splitting and quasi-row orthogonality in D remain part of the study framework.
• RAN1#126 extension structure : E is lower triangular, with the identity-matrix option excluded. The bound on its columns with degree above one remains open.

The structural agreement history is reproduced in R1-2608752. The BG3 design section explains the remaining choices. The separate BG3 applicability section preserves the distinction between RAN plenary guidance, the reproduced RAN1 UL position, and per-TB selection proposals.

RAN1#126bis - agreements and recorded conclusion

The session notes explicitly label the large-UCI and large-DCI entries as agreements. Small UCI has a separate observation and conclusion, which schedule the next decision without selecting a replacement code.

• Agreement: UCI above 1706 bits : study a maximum segment count S ≤ 6. The exact S remains for further study and must account for the maximum UCI payload. Other agendas must still confirm the need for payloads above the NR range.
• Agreement: DCI above 140 bits : down-select the maximum Polar mother-code length from 512 and 1024 at RAN1#127. Other agendas must still confirm the larger-payload requirement. This does not select 1024 at #126bis.
• Recorded conclusion: 3–11-bit UCI : conclude the study at RAN1#127 by determining whether NR RM has justifiable drawbacks. If it does, recommend a coding scheme from the candidates in the accompanying observation. The candidate list itself is not an adoption decision.

These outcomes are recorded in R1-2607312. They do not finalize the BG3 PCM, a large-UCI segmentation formula, or a small-UCI replacement. The technical sections retain the competing proposals so that their status remains visible.

What is reused from NR, and why study an extension?

The study starts from existing coding families. The question is whether their current constructions and processing chains can meet the new operating conditions at an acceptable cost for both UE and network.

At RAN1 #122bis, LDPC was selected for data, including SIBs. Polar was selected for L1 control information larger than 11 bits, including PBCH. Reusing NR LDPC within the NR data-rate range and NR Polar within the NR control-payload range was recorded as a working assumption. Extensions beyond those ranges were to be evaluated against performance and complexity. The maximum Polar mother-code length was kept at 1024. R1-2508176, R1-2608752.

The early data-channel study assumed a target peak rate twice the target in TR 38.913. That was a study assumption, rather than a claim that changing the code alone doubles radio throughput. Contributions subsequently examined iteration count, processing cycles, parallelism, and chip area. These are different constraints, even when two decoders achieve the same BLER.

The later RAN #110 requirements, reproduced in the joint contributions, specify 36 Gbps DL and 18 Gbps UL with 600 MHz aggregated bandwidth. These supersede the early twice-NR study assumption as the cited peak-rate requirements. A large group of companies also argues that chip area, energy use, and aggregate UL cell load motivate an extension. A later joint proposal from a large majority of companies explicitly argues against making beyond-NR data rate the only justification. These are motivations for broader applicability, not proof of a universal coding gain. R1-2601085, R1-2602882.

The control-channel discussion separates three cases: 3–11-bit UCI, DCI above 140 bits, and UCI above 1706 bits. At #123, there was no consensus on a motivation to enhance Polar coding for payloads within the NR range above 11 bits. Larger-payload studies remained conditional on requirements from other agenda items. The reviewed #126bis contributions still disagree on how much extra payload is necessary.

So the baseline does not settle every processing step. It establishes the comparison against which an extension needs justification. New BGs, new segmentation rules, and changes to CRC handling have different implementation consequences. Treating them as one general coding upgrade would hide the actual decisions.

• Keep the scope of each decision : a coding-family decision does not select a particular BG, PCM, interleaver, or segmentation rule.
• Keep the conditions : a beyond-NR payload study does not establish that the larger payload is required.

How is the new LDPC base graph taking shape?

BG3 is being developed around faster decoding at high data rates. The contributions therefore examine how a graph converges with limited iterations and how its rows can be processed by practical decoder hardware.

The design space narrowed over several meetings. At #124, the study included maximum block sizes of 8448 or 16896 bits, 22/33/44 information columns, and zero/one/two punctured columns before rate matching. By #124bis, the framework used a maximum block size of 8448, a single-edge BG with 44 information columns, maximum lifting size 192, and mother code rate approximately 2/3. The earlier alternatives should not be read as equally current choices. R1-2608752, historical agreements.

The encoder PCM is organized into A, B, C, D, and E. A covers information-bit columns, B covers core parity, and C is zero. D spans the information and core-parity columns. Figure 1 illustrates this agreed partition; it does not specify the individual entries or lifting shifts of a final PCM.

Figure 1. BG3 retains an explicit core and extension structure. The B and E choices affect implementation as well as decoding performance.

At #125, B was narrowed to a weight-three column followed by a dual-diagonal structure. The allowed shift pattern in that first column is [0, X, 0] or [X, 0, X]. The study also retained row splitting from the core and quasi-row orthogonality in D. No puncturing before rate matching was the starting point. At #126, E was selected as lower triangular, excluding the identity-matrix option. The bound I on columns of E with degree above one remained open.

Why are row splitting and orthogonality still debated?

A graph can reduce the arithmetic needed for convergence while adding dependencies between processing steps. The contributions examine both effects, because the number of graph edges does not fully describe hardware scheduling.

One proposal limits splitting to three rows and places off-diagonal E entries only in columns associated with split rows. Another favors enough splitting to improve density and orthogonality across code rates. A third cautions against double splitting because it adds decoding dependencies. These are competing design proposals, rather than settled restrictions. R1-2607058, R1-2608712, R1-2607556.

Implementation-oriented proposals also include full orthogonality between neighboring extension rows and conversion to a compact 22-column representation. The latter requires particular 2-by-2 patterns in the 44-column graph; it is not a property of every candidate BG3. R1-2607973, R1-2608414.

• The structural framework has narrowed : a detailed winning BG/PCM does not follow automatically from those agreements.
• Encoding cost matters too : lower-triangular E introduces parity dependencies that a decoding-edge count alone does not express.

When can BG3 be configured, and when is it selected?

A UE can support a set of base graphs without using BG3 for every transmission. The sources separate capability, network configuration of that set, and selection of one graph for a particular transport block.

The RAN #112 outcome, reproduced in the latest coding summary, defines DL applicability using an aggregate reference rate X and a per-carrier reference rate Y_n. The approximate thresholds are 12 Gbps for X and 6 Gbps for Y_n. These are configuration-based reference rates, not measured user throughput. The examples use NR overhead assumptions and explicitly allow updates for 6G overhead. R1-2608752, RAN #112 agreement.

The four cases below determine availability of the BG set. They do not supply the missing per-TB graph-selection thresholds.

The exact reference-rate calculation still attracts proposals. One contribution seeks a guard-band correction and use of the maximum configured BWP bandwidth. Another asks to confirm the preliminary 12/6-Gbps values without modification. Therefore, these thresholds should not be converted into a final RRC algorithm from the available contributions. R1-2607058, R1-2608338.

For UL, the recorded RAN1 #126 position supports mandatory BG3 capability with capability signaling, except for UEs whose maximum UL channel bandwidth is at most 20 MHz in every supported band. BG3 is optional for those UEs. The record leaves any additional exception to the RAN plenary. This is the RAN1 position reproduced in the reviewed source, rather than an independently verified final plenary capability definition.

Per-TB selection remains a separate discussion. One proposal uses coding rate above a threshold greater than 2/3 and TBS above a threshold at least 8448 bits. Another uses a fraction of the carrier's maximum schedulable TBS, with additional modulation and segmentation conditions. Neither should be substituted for an agreed selection rule. R1-2607058, R1-2607973.

• BG-set availability is not per-TB selection : keep those decisions separate when interpreting capability or throughput claims.

How should LDPC performance and complexity be compared?

A lower SNR at a chosen BLER is useful only when the comparison states its decoding cost. The RAN1 evaluation framework therefore couples reliability with complexity, while contributions also examine latency and area efficiency.

The #123 comparison uses computational complexity proportional to the required iteration count times the number of ones in the lifted PCM, divided by CB size. Equal iteration counts alone are insufficient when the matrices have different edge counts. The #124 framework compares SNR at equal computational complexity and complexity at equal BLER performance, using BG1 reference iteration limits of 5, 7, 10, and 15. Target CB BLER values include 10⁻² and 10⁻⁴. R1-2608752.

The decoder assumptions also matter. Layered BP and min-sum variants do not have identical implementation costs or performance. Decoding order, normalization or offset settings, stopping rules, and CB size must accompany the result. The original evaluation agreement explicitly treats its assumptions as simulation conditions, rather than specifications for the final graph.

Why separate maximum complexity from average complexity?

A decoder with early termination often stops before its iteration limit. Its worst-case processing budget and its average activity therefore answer different questions, particularly when fast convergence is the main objective of a candidate.

Contributions discuss both maximum and average complexity at a common SNR, and SNR at a common complexity. Reducing the maximum iteration budget can support throughput, while reducing average iterations can reduce activity. However, an aggressively small budget can also increase decoding failures and retransmissions. One contribution favors optimization over roughly 5–12 iterations for high-throughput operation, while another gives more attention to gains below ten iterations. These are evaluation priorities, not universal decoder settings. R1-2608722, R1-2608712.

A cycle-based proposal goes further: total decoding cycles depend on iterations multiplied by cycles per iteration. The latter includes dependencies and idle cycles between layers. Its area-efficiency model includes both logic and storage. This explains why a graph with fewer arithmetic operations does not automatically have the best throughput per chip area. R1-2607896.

The operating range is another source of disagreement. One evaluation finds relatively stable BG3 benefits above CBS 4224, but rate-dependent behavior below it. Other proposals seek wider CBS coverage or separate optimization and applicability regions. The proposed graph, rate, QAM order, CBS, and decoder must remain attached to every gain claim. R1-2607253, R1-2608722.

• Compare at a stated budget : equal iterations, equal edge-operation complexity, and equal decoder cycles are different comparisons.
• Do not rank candidates from isolated maxima : the documents use different operating points and implementation assumptions.

Does 3–11-bit UCI need a different code?

The small-UCI discussion contains two different motivations. Some contributions target rank deficiency after rate matching at high code rates. Others target coverage at low rates, where the NR length-32 mother code relies on repetition.

Both motivations need realistic scheduling conditions. The reuse position argues that a scheduler can avoid problematic high-rate combinations by providing slightly more coded bits. It also emphasizes the efficiency of FHT-based RM decoding. The enhancement position argues that even full-rank cases can benefit when the available coded length substantially exceeds 32. R1-2607058, R1-2607556, R1-2608722.

The #126bis observation organizes the candidates into five groups:

• S1: NR RM : retain the existing short-block construction.
• S2: enhanced RM with mother length up to 32 : adjust basis-sequence selection, encoding matrix, or interleaving before rate matching.
• S3: extended RM : use a longer mother code, such as 64 or 128, with NR RM as a base or nested component.
• S4: enhanced PC-Polar : adapt the Polar chain using candidate-specific pre-freezing, parity-check bits, and mother-length determination, without CRC in the listed constructions.
• S5: Golay-based code : retain this as another short-block candidate.

This is an observation identifying designs for study, rather than agreement to replace RM. The #126bis conclusion targets #127 for deciding whether NR RM has justifiable drawbacks and, if so, which listed coding scheme to recommend. R1-2607312.

Why do the reported gains point in different directions?

The candidates do not share a single construction or decoder. Results depend on information length K, transmitted coded length E, mother length, known bits, and the error event being measured.

For example, one PC-Polar evaluation reports about 0.7 dB gain over RM for an 8-bit payload with E = 256 in AWGN. Another set of enhanced constructions reports gains up to about 0.8 dB at 1% BLER for selected low-rate conditions. These results support investigating low-rate coverage; they do not establish a gain at every K/E combination. R1-2607253, R1-2608722.

Other evaluations find losses for particular PC-Polar extensions at short coded lengths. A separate concern is semi-static HARQ-ACK with known bits: the positions of the unknown information bits can affect performance. Missing the last DCI can also leave transmitter and receiver with different payload assumptions. RM nesting and the candidate Polar mapping then need comparison for BLER, NACK-to-ACK errors, and false alarms. R1-2608414, R1-2607556.

Hardware-reuse claims also disagree. Extended-RM proposals describe implementations that retain FHT processing with modest extra combining. PC-Polar proponents emphasize reuse of SCL processing, while other contributions identify changes in PC-bit generation, lookup information, or latency. Reusing a decoder family does not prove identical implementation cost. R1-2607973, R1-2607896, R1-2608712.

• Keep both motivations : avoiding high-rate ambiguity and improving low-rate coverage are separate tests.
• Keep the complete UCI case : known bits, missing DCI, detection method, and transmitter cost belong beside BLER.

What changes if DCI exceeds 140 bits?

Larger DCI creates a coding-chain question before it becomes a question about a longer Polar transform. The NR distributed-CRC interleaver and early-termination behavior must also be considered when extending the payload.

The reviewed candidates include removing the distributed-CRC interleaver, extending or redefining it, applying it to a selected part of a larger sequence, and splitting DCI into code blocks. Other proposals introduce zero-embedding, PAC-based construction, known-bit checks, or changes to RNTI handling. These alternatives have different consequences for blind decoding and false alarms. They are not an agreed replacement chain. R1-2608752, R1-2607556.

At #126bis, the agreed next step is to choose between maximum mother-code lengths 512 and 1024 at #127. The need for DCI beyond 140 bits still requires confirmation from other agendas. A 1024 maximum is therefore a candidate, rather than the established 6G DCI setting. R1-2607312.

The performance evidence explains the attraction of 1024. One contribution reports gains up to approximately 0.45 dB at A = 200 and 1.1 dB at A = 300, compared with its 512 baseline. It proposes limiting the longer construction to large DCI at aggregation levels 8 and 16. Another contribution favors retaining 512 because of memory and latency concerns. R1-2608722, R1-2607896.

Segmentation is not uniformly better either. In one evaluation, a single block outperforms two blocks by up to about 1–2 dB when E ≤ 432. At E ≥ 864, the preferred choice changes with payload size. Therefore, a larger payload does not by itself determine the number of blocks. R1-2608414.

CRC coverage needs particular care when an existing interleaver is applied only to the final portion of a larger payload. One contribution questions how that partial use preserves the intended early-check relationships when CRC covers the full payload. Restricting CRC generation to the final portion would instead leave earlier information unprotected. This is a design objection requiring resolution, not a conclusion that every proposed partial-interleaver construction fails. R1-2608338.

• Check the whole blind-decoding task : BLER, false alarms, early termination, memory, and latency can favor different options.

How should UCI above 1706 bits be segmented?

The large-UCI study seeks additional capacity while retaining the Polar mother-code limit. More code blocks can reduce unfavorable rate matching, but every additional block brings CRC overhead and another encoding and decoding operation.

At #123, more than two segments was identified for further study. The #124 evaluation framework uses AWGN, QPSK as the baseline modulation, CRC-aided SCL with reported list size 8 or 16, and whole-UCI BLER targets of 10⁻² and 10⁻³. Each segment carries an 11-bit CRC; rate matching, channel interleaving, and concatenation follow NR in that framework. The tested rates range from 1/8 to 3/4. R1-2608752.

The number of segments cannot be chosen from payload length alone without checking the rate-matching consequences. Contributions compare repetition, shortening, and puncturing for different information lengths and coded lengths. A rule that helps a low-rate case may add unnecessary CRC or alter mother-length selection unfavorably elsewhere.

Several approaches remain proposals. One uses rate-dependent thresholds and integer comparisons to avoid division. Another seeks a compact closed-form approximation to a per-configuration optimum. A third separates low-rate payload-driven segmentation from a coded-length-driven rule at higher rates. The documents do not establish a single agreed formula. R1-2608712, R1-2608722, R1-2607556.

The latest recorded outcome is narrower than some incoming proposals: the maximum segment count S is constrained to S ≤ 6. Its exact value is still for further study and must account for the maximum UCI payload. The need to exceed 1706 bits also remains conditional. A proposal for eight segments should therefore be presented as an input to the discussion, not the #126bis outcome. R1-2607312.

Implementation comparisons should include buffering and latency, not only the best BLER point. The reviewed studies show diminishing returns from additional segmentation, but their preferred counts differ with payload and code rate. That is why the maximum count and the rule selecting the actual count are separate decisions.

• Six is a ceiling in the study : it does not mean every larger UCI uses six blocks.
• The payload requirement remains a dependency : coding studies do not independently decide how much UCI other procedures need.

How do HARQ and modulation affect the coding choice?

The supplied search list also contains joint coding and modulation contributions. For this page, the relevant question is how modulation, mapping, and retransmission change the comparison between coding candidates.

One discussion concerns redundancy versions and bit-to-symbol mapping. Two contributions propose studying reversed modulation-bit mapping on retransmission for BG3 and for BG1 with limited-buffer rate matching. The aim is to change which coded bits experience the more reliable modulation-bit positions across transmissions. The detailed BG3 redundancy-version design still depends on the final graph and PCM. R1-2607973, R1-2608414.

Other proposals examine inter-CB coding or interleaving to reduce concentrated errors within a large TB. The competing reuse position asks to preserve the NR CRC, segmentation, interleaving, bit-selection, and concatenation procedures, with only changes justified by the agreed extension. These are distinct positions on processing-chain complexity. Neither a new outer code nor a new inter-CB interleaver is established by the reviewed meeting outcome. R1-2608752, R1-2608338.

The modulation summary compares different QAM-order/code-rate pairs at the same spectral efficiency. Its reported preference can reverse between AWGN and fading, between low and high MIMO rank, or between receiver types. Layer imbalance may favor higher modulation order with more coding redundancy; strong inter-layer interference can favor the opposite combination under the evaluated receivers. R1-2608658, AMC evaluation discussion.

This matters to BG3 because its optimization range includes high code rates. A gain measured with one fixed MCS does not settle the gain after link adaptation chooses a different modulation/rate pair. The same comparison should identify receiver, channel, codeword-to-layer mapping, and whether practical link adaptation is included. A modulation gain should not be relabeled as an intrinsic gain of the code.

• Evaluate the transmission chain : coding, mapping, and HARQ interact, even when the BG is unchanged.
• Keep proposal status visible : processing-chain enhancements remain distinct from the recorded BG3 structural decisions.

Update Note

• 2026-10-20 - Added Agreed Items and its contents links, separating earlier coding agreements from the RAN1#126bis agreements and recorded small-UCI conclusion.
• 2026-10-20 - Added NR baseline, BG3 design, BG3 applicability, LDPC evaluation, small UCI, large DCI, large UCI, and coding-chain and modulation discussions from the supplied RAN1 #122–#126bis TDoc set and supplementary company contributions, with outcomes checked against the #126bis session notes and final coding summary.

Reference

• R1-2607312 (RAN1#126bis) : Session Notes of AI 10.3.1 (Channel Coding) (Ad-Hoc Chair (Ericsson))
• R1-2608752 (RAN1#126bis) : FL summary#7 for 6G channel coding (Moderator (ZTE))
• R1-2508176 (RAN1#122bis) : Final FL summary for 6G channel coding (Moderator (ZTE, Apple))
• R1-2607058 (RAN1#126bis) : On remaining aspects of channel coding in 6GR (Nokia)
• R1-2608712 (RAN1#126bis) : Channel coding for 6GR air interface (Huawei, HiSilicon)
• R1-2607556 (RAN1#126bis) : Discussion on channel coding for 6GR (Samsung)
• R1-2607973 (RAN1#126bis) : Channel coding for 6GR (Ericsson)
• R1-2608414 (RAN1#126bis) : Channel coding for 6GR (Qualcomm Incorporated)
• R1-2608338 (RAN1#126bis) : Discussion on 6GR channel coding (NTT DOCOMO INC.)
• R1-2608722 (RAN1#126bis) : Consideration of 6GR channel coding (Apple)
• R1-2607896 (RAN1#126bis) : Channel coding for 6GR air interface (MediaTek Inc.)
• R1-2607253 (RAN1#126bis) : Discussion on 6G channel coding (OPPO)
• R1-2608658 (RAN1#126bis) : FL summary #4 on modulation, joint channel coding and modulation (Moderator (Qualcomm Incorporated))
• R1-2601085 (RAN1#124) : Views on 6GR LDPC code (Verizon, CMCC, China Telecom, China Unicom, Samsung, ZTE, Sanechips, Apple, Qualcomm, MediaTek, Meta)
• R1-2602882 (RAN1#124bis) : Views on LDPC Channel Coding Extension for 6GR (Verizon, T-Mobile USA, CMCC, China Telecom, China Unicom, CSCN, KT Corp., Samsung, ZTE, CATT, Sanechips, Apple, Qualcomm, MediaTek, Meta, Shanghai Jiao Tong University)