BCH-Polar级联：让极化码从理论走向工程的后悔药

简介：一套聚焦信道编码核心算法的MATLAB源码包，适合通信工程专业学生、编码算法初学者以及需要快速搭建仿真环境的工程师。资源以BCH码、极化码、汉明码、卷积码和循环码为主线，覆盖编码、译码、性能评估的完整学习链路，帮助读者理解伽罗华域纠错、信道极化、维特比回溯与香农极限等关键概念。包内含48个m脚本文件，压缩包大小仅34KB，文件均为可直接运行的MATLAB源码，既有各编码器主程序，也有码率、迭代次数、交织长度对误码性能影响的测试脚本，以及维特比译码、香农极限分析等配套模块。通过运行这些代码，可以直观对比不同信道编码方案的纠错能力与频谱效率，观察极化码在高信噪比下的性能优势，也能通过香农极限脚本判断当前编码方式距离理论下限的差距，适合用于课程实验、毕业设计或编码技术预研。目前已有373人学习下载，源码结构清晰、注释简要，便于按需修改参数或扩展新算法模块，能够在现有基础上快速生成自定义仿真实验。

1. 极化码理论最优，工程上却离不开 BCH 和 CRC 这瓶“后悔药”

做物理层的人大概都经历过这种场面：论文里极化码（Polar code）的性能曲线贴着香农限，仿佛信道编码的终点就是它；可真把极化码搬进自己的链路里，码长一短、码率一高，误码平台就告诉你什么叫理论与现实的落差。问题不在极化码的极化机制，而在于极化码本身不负责“修正自己选错的信息比特”——它需要外援。BCH 码和循环冗余校验（CRC），就是这么被拉回战场的。5G NR 里最终落地的也不是纯极化码，而是 CRC 辅助的极化码（CA-Polar），BCH 作为外码与极化码级联的方案同样活跃在深空通信和部分卫星链路线。这篇笔记就围绕“信道编码里的 BCH-Polar 级联”展开，讲清楚极化码为什么需要 BCH 和循环冗余帮忙，级联怎么搭、参数怎么定、仿真怎么跑、坑在哪。适合正在做 5G 物理层、卫星数传、或者想在水声/无人机图传链路里试极化码的工程师读，目标就一个：让你看完能动手搭出自己的级联验证平台。

2. 让极化码从理论走上工程：CA-Polar 与 BCH 级联到底解决什么

2.1 极化码的信道极化：为什么短码性能总是差一口气

极化码的核心思想是把 N 个独立信道通过递归的“信道合并 + 信道分裂”操作，变成 N 个极化程度不同的比特信道。一部分信道容量趋近 1（好信道），一部分趋近 0（坏信道）。发端把信息比特放在好信道上，坏信道放冻结比特（收发双方约定好的固定值），这就是极化码能逼近香农限的根源。

但极化有个物理约束：极化效应要到位，码长必须足够长。N=1024 时极化已经比较充分，N=256 时某些中等可靠信道还处在“半好半坏”的模糊区。工程场景下码长常常被帧结构和时延卡死，比如 5G NR 控制信道的极化码，码长从 32 到 1024 不等，短码场景非常多。短码极化不充分，直接后果是：即使选最好的 K 个信道放信息比特，仍然有部分比特信道错误概率远高于理论预期。这时候信息比特错了，极化码译码器（SC 或 SCL）未必纠得回来。

工程上的做法是引入外码。BCH 码作为外码，把极化码内码译码后的残余错误再纠正一层；CRC 则扮演“选码器”——SCL 译码器在多个候选路径里挑一条最像正确码字的路径，靠什么判断？靠 CRC 校验。路径列表里只有一条能通过 CRC 校验，就选它；如果多条通过，选路径度量最好的那条。这就是 CA-Polar（CRC-Aided Polar）名字的由来。所以极化码不是不要外码，而是短码工况下必须靠 BCH 或 CRC 这类“后悔药”来兜底。

2.2 BCH 码在级联里的定位：纠错、检错与早期终止

BCH 码是 1960 年提出的循环码家族成员，线性分组码出身，有严谨的代数学结构。它能做到一件事：对于任意正整数 m 和纠错能力 t，构造出码长 n=2^m-1、能纠正 t 个错误的 BCH 码。工程里常用的缩短 BCH 码，是把标准本原 BCH 码的信息位缩短得到的，以适应帧长需求。

在级联结构里，BCH 通常做外码，放在极化码之前（发端维）。极化码译码输出一串比特，先经过 BCH 译码器纠正残余错误，再交给上层。为什么不用 LDPC 或 Turbo 做外码？因为 BCH 的译码延迟极低、实现简单（移位寄存器就能搞定编码），且纠突发错误之外的随机错误能力与极化码残错分布匹配良好。极化码经过 SC 译码后的错误往往是随机分布的少量比特错误，正是 BCH 最擅长处理的场景。

BCH 还有一个被低估的作用：检错和译码提前终止。级联链路里，如果 BCH 译码失败（错误个数超出 t），说明这一帧已经救不回来，接收端可以直接发起重传请求，不必等整帧数据全部译完。这在高吞吐链路里能省下可观的无效计算。另一个作用是“避免错误扩散”——BCH 译码失败时能明确上报译码失败，而不是像卷积码那样默默输出错误比特。

注：极化码做内码、BCH 做外码的级联结构，本质是把“概率译码”和“代数译码”两种思路叠在一起。前者擅长逼近容量，后者擅长清理残余错误。两者各自干自己最擅长的事。

2.3 循环冗余在级联里另一个身份：CRC 不只是校验

热词里反复出现“循环冗余检查”和“err:23 数据错误（循环冗余检查）”，大家熟悉的场景是解压文件时报错。但在信道编码语境下，循环冗余和极化码组合成了 CA-Polar 方案：发端在 K 个信息比特后面附加 L 位 CRC，一并做极化码编码；收端 SCL 译码器维护 L 条候选译码路径，最后用 CRC 从多条候选中选出正确路径。这个“用 CRC 选路径”的动作，让极化码在短码下的性能直接提升了一个量级。

5G NR 的上下行控制信道用的就是 CA-Polar：下行 DCI 用 24 位 CRC，上行 UCI 根据 payload 大小选 11 位或 6 位 CRC。这解释了为什么热词里“极化码”和“循环冗余”频繁绑定出现——在 5G 标准语境下它俩是一套组合，不是两个独立的编码方案。BCH 和循环冗余同时出现在级联链路里也不冲突：BCH 做外码做前向纠错，CRC 做路径选择/检错。把两者分开理解，级联结构就一目了然。

3. 在 5G NR 参数下搭 BCH-Polar 级联：码率、CRC 长度与信道配置

3.1 5G NR 的极化码参数：从 K 到 E 的一张表

工程实现级联，第一步是把参数定清楚。5G NR 里极化码的输入输出定义如下：K 是信息比特长度（包含 CRC），E 是速率匹配后的输出比特长度，N 是母码长度（必须是 2 的幂）。上行控制信息 UCI 和下行控制信息 DCI 的极化码配置不完全相同，但核心流程一致。

自己做 BCH 级联实验时，不需要完全照抄 5G 参数，但建议把 CRC 长度和极化码母码长度对齐到近似的量级，这样仿真结果能和 3GPP 公开曲线做横向对比。我一般用 K=56、CRC=8、BCH(127,113,2) 缩短到适配 K=64，E 从 128 到 512 扫几组，覆盖码率从 1/2 到 1/8。

3.2 用 Python 把极化码构造和 BCH 外码粘成一个验证链路

明确的极化码构造方法很多，最容易理解的是密度进化（DE）和高斯近似（GA）。工程仿真里常用高斯近似构造，因为运算量小、精度够。下面给一个最小可跑的链路：BCH 编码 → 极化码编码 → AWGN 信道 → SC 译码 → BCH 译码。

import numpy as np from math import log2 def bch_encode(info_bits, gx): """BCH编码：信息位左移n-k位后对生成多项式做模2除法，余数作为校验位""" n_k = len(gx) - 1 msg = np.array(info_bits + [0]*n_k, dtype=int) # 模2除法，等效于循环移位寄存器 for i in range(len(info_bits)): if msg[i] == 1: for j in range(len(gx)): msg[i+j] ^= gx[j] return msg[:len(info_bits)] + msg[len(info_bits):] def polar_encode(u, n): """极化码编码：u * G_n, G_n = G_2 的克罗内克幂""" g2 = np.array([[1,0],[1,1]]) gn = np.array([1]) for _ in range(int(log2(n))): gn = np.kron(g2, gn) # 克罗内克积逐级扩展 return (u @ gn) % 2 # 例：BCH(15,7,2) 生成多项式 gx = x^8 + x^7 + x^6 + x^4 + 1 gx = [1,1,1,0,1,0,0,0,1] info = np.random.randint(0,2,7) bch_codeword = bch_encode(list(info), gx) print("BCH codeword:", bch_codeword)

这段代码里两个函数分属两级：bch_encode用生成多项式逐位异或求余，得到校验位；polar_encode通过克罗内克积构造生成矩阵G_n，再把输入向量乘上去。注意polar_encode的矩阵构造是“每迭代一次矩阵翻倍”，这里我用的是与 3GPP 一致的生成矩阵定义，不是文献里常见的另一种排序，两者差在比特顺序，仿真时按同一套顺序收发即可。

3.3 批量扫参数：用 shell 脚本跑 for 循环拿误码曲线

一次仿真只能拿一个点，误码曲线需要批量跑。我习惯把 Python 仿真写成一个可接受命令行参数的脚本，然后用 shell 的 for 循环批量提交。

#!/bin/bash # 批量扫 Eb/N0 参数：从 1dB 到 5dB，步进 0.5dB for ebn0 in 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0; do python3 polar_bch_link.py --ebn0 ${ebn0} --n 256 --k 56 \ --crc_len 8 --sc_list 4 --frames 5000 >> results.log done # 结果追加写入 results.log，之后用 grep 抽出各行 grep "EB/N0" results.log | awk '{print $2, $4, $6}' > ber_curve.dat

脚本逻辑是：外层 for 循环变量ebn0逐点传给 Python 链路，链路每次跑 5000 帧统计误码率，输出按行追加到results.log。最后用grep和awk把需要的列抽出来，画图用。5000 帧在码率 1/2、N=256 时，SC 译码大概跑几分钟一个点，整条曲线半小时内能出。如果想跑 SCL 列表宽度 8，把--sc_list 4改成--sc_list 8，时间约翻倍，性能在高 SNR 区大约能再挤 0.2~0.3dB。

提示：批量仿真最容易出的问题是帧数不一致导致曲线抖动。固定帧数，不要用“跑到 N 个错误就停”的早期终止，除非你评估的指标本身需要这种终止条件。

4. 复现 CA-Polar 的最小实现：生成矩阵、速率匹配与 LLR 计算

4.1 极化码生成矩阵构造：从 N=8 开始手推

很多第一次接触极化码的人直接跳到 N=1024，结果生成矩阵写成什么样、比特顺序怎么排，全凭复制粘贴。出问题后根本没法定位。我的建议是先从 N=8 手推，把矩阵结构看明白再上大码长。

# 用递推方式构造 G_N，并从高斯近似得到信道可靠性排序 def polar_gen_matrix(n): fn = np.array([1]) for _ in range(int(log2(n))): fn = np.kron(np.array([[1,0],[1,1]]), fn) return fn % 2 N = 8 G8 = polar_gen_matrix(N) print("G_8:\n", G8) # 用简单的高斯近似计算每个比特信道的可靠性 def gaussian_approx(llr_mean, n): """输入初始llr均值，返回n个比特信道的可靠性估计""" z = np.array([llr_mean]*n) for _ in range(int(log2(n))): # 合并层：较好信道取 2*phi_inv(1-(1-phi(z1))*(1-phi(z2))) # 简化起见，用文献常见近似 phi(z) = exp(0.0564*z^2 - 0.4856*z) pass # 完整实现需要phi函数

代码里G_8矩阵的行代表比特信道，从上到下可靠性递增（经过比特置换后）。实际工程中用的可靠性排序表可以用密度进化离线算好存成静态表，运行时查表，不现场算。这样实现简单且和标准方案一致。手工算可靠性时用高斯近似公式逐个递推，注意公式里phi(z)的近似表达式在低 LLR 区误差较大，做定量仿真时建议用查表或离线密度进化。

4.2 速率匹配与比特选择：E 小于 N 时的打孔与重复

极化码编码永远输出 N 个比特，但物理信道分配的 RE 数未必等于 N。E < N 时要从 N 里挑 E 个发出去，这就是速率匹配。5G NR 里用的是基于可靠性的速率匹配：优先发送可靠信道上的编码比特，低可靠位置被打孔（不发送）。这个选择直接影响性能——如果打孔打到了高可靠位置，等效于把好信道丢了，误码率立刻恶化。

def rate_match(coded_bits, reliability_order, E): """按可靠性从高到低选E个编码比特发送""" # reliability_order: 按可靠性降序排列的索引数组 # 5G NR标准做法是交织后按位置发送，这里简化为直接选 selected_idx = sorted(range(len(coded_bits)), key=lambda i: reliability_order[i], reverse=True) return coded_bits[selected_idx[:E]]

这个函数做的事情很简单但关键：发送端选择的 E 个比特，在接收端译码时对应位置的 LLR 才有值，其余位置 LLR 置 0（相当于该信道完全不可靠）。SC/SCL 译码器会把 0 LLR 当作等概率信息处理，配合冻结比特的先验知识照样能译。注意标准里的速率匹配还有交织器，交织的主要目的是把打孔位置尽量打散，避免连续丢比特。

4.3 译码端 LLR：BCH 硬判决之前为什么要先软信息

SC 译码器内部全部在 LLR 域工作，最后一步才做硬判决。如果直接对接收信号先硬判决再送进译码器，约等于把软信息全扔了，性能损失 2dB 以上。

def bpsk_llr(received, noise_var): """BPSK调制下计算对数似然比 L = 2*y/σ^2""" return 2.0 * received / noise_var # 假设接收符号 y = (+1/-1) + n, n ~ N(0, noise_var) y = np.array([1.2, -0.7, 0.3, -1.5]) sigma2 = 0.8 llr = bpsk_llr(y, sigma2) print("LLR:", llr) # 硬判决: LLR > 0 -> bit=0, LLR < 0 -> bit=1（与映射有关）

LLR 的计算公式在上面的代码里，噪声方差从信道估计那里拿。注意如果调制不是 BPSK，比如 QPSK 每个符号携带两个比特，需要把符号 LLR 拆成比特级软信息再送进译码器。BCH 译码器工作在硬判决域，所以极化码译码器输出硬比特塞给 BCH 之前，中间不需要保留软信息。这也是级联设计的巧妙之处：内码用软译码尽量把比特判对，外码用代数手段清理残错，两级各吃各的饭。

5. 极化码+BCH 联调的避坑指南：我从误码平台里捞回来的五个教训

5.1 发端 CRC 算进去了，收端却把 CRC 比特当信息比特，误码率直接失控

现象：仿真曲线在高 SNR 区出现平台，误码率降到 1e-3 后不再下降。

原因：SCL 译码器路径选择依赖 CRC 校验，如果收端把 CRC 位当作普通信息位参与译码路径度量计算，CRC 就失去了“选路径”的功能，路径选错后错误会直接传到上层。本质是收发两端对“哪些位是 CRC、哪些位是信息”的约定不一致。

解决：在仿真代码里把 K 拆成 K_info + L_crc 两段，收发两端用同一个掩码区分。这条看起来简单，但我至少见到三个项目在这里翻过车。排查方法是打印收发两端的信息位索引，逐一比对。

5.2 BCH 译码器纠错越界：t=2 却把 3 个错当 2 个纠，剩余误码不降反升

现象：加上 BCH 外码后，误码率在中低 SNR 区反而比不加还差。

原因：BCH 译码器在错误个数超过 t 时，如果仍然强行纠错，会把错误的校验子映射到一个错误的“校正子”，等于把更多比特改错。这种现象叫“误纠”（miscorrection）。它比不纠更危险，因为外码把好比特改坏了。

解决：BCH 译码器必须做好“拒绝”逻辑——当校验子计算出的错误位置数超过 t 时，直接放弃这一帧纠错，保持原始比特不动并上报译码失败。在级联方案里，此时可以让上层的 CRC 决定是否重传。

注意：BCH 的误纠概率随着 t 和码长增大而上升，自己实现译码器时最容易漏掉的就是这个分支。开源的 Berlekamp-Massey 算法大多实现了该逻辑，但用错版本或裁剪过度时容易丢。建议单独写测试向量验证误纠分支。

5.3 速率匹配打孔位置影响极化权重，盲目打孔丢掉高可靠信道

现象：N=512、E=256 时，打孔率 50%，仿真误码率比理论上限差 1.5dB 以上。

原因：速率匹配如果直接删末尾 256 个比特，但末尾恰好包含多个高可靠比特信道的编码输出，等效于发端把好信道丢了。标准里的速率匹配顺序是经过精心设计的，自己随意打孔会破坏极化码最核心的“好信道优先”原则。

解决：打孔位置必须依据可靠性排序表倒序选择——优先打掉可靠性最低的比特位置。或者直接用 5G NR 标准定义的速率匹配顺序，它对每个 (N, E) 组合都预先算好了打孔/重复位置，直接查表。

5.4 先硬判决再进 BCH：软判决拒绝次数比想象中高，块错误率抬高 0.3dB

现象：BCH 外码感觉没起作用，纠错成功次数很少，块错误率曲线比参考值差 0.3~0.5dB。

原因：级联链路设计里，内码译码出的软信息没有传递给外码。BCH 是代数译码器，只吃硬比特，但内码 SC 译码输出的 LLR 置信度信息其实是可用的——比如 LLR 绝对值很小的比特，它的硬判决可能是错的。如果有软信息，可以先按 LLR 排序，尝试翻转低置信度的几个比特后再做 BCH 校验，这种“软判决辅助 BCH”能降低 BCH 的译码失败率。

解决：工程里常见做法是内码译码后输出 LLR 和硬比特，BCH 译码失败时，把 LLR 绝对值最小的 5~10 个比特逐一翻转重试。实现成本低，块错误率通常能再降 0.2~0.3dB。

5.5 冻结比特集没有按可靠性排序，仿真结果比标称差 1dB 还找不到原因

现象：中低信噪比区域误码率尚可，高信噪比区域比参考曲线差 1dB 左右，且 BCH 外码几乎完全无效。

原因：冻结比特的选择依赖可靠性排序表。如果用的是自算的高斯近似结果，中高可靠信道排序错误率较高；而排序错误恰好发生在中等可靠信道区域——也就是高 SNR 时仍会出错的区域。我遇到过一次是因为用错了排序表的比特顺序（自然序 vs. 比特逆序），整张表错了一半位置。

解决：直接用 3GPP TS 38.212 里给出的 N 最大为 1024 的可靠性排序表，先跑通再考虑替换。自算排序表只用于验证理解，不要用于正式仿真。还有一点：冻结比特的值必须收发双方一致，通常全 0，但某些实现里会用已知伪随机序列填充以避免全 0 码字带来的 DC 分量问题。

6. 把级联链路推进到实现级：浮点转定点、迭代与标准差异验证

6.1 浮点仿真转定点：量化噪声比信道噪声更早到

误码率仿真通过后，下一步一定是定点化。极化码的 SC/SCL 译码器内部全是 LLR 加减比较，定点化相对友好。我一般先把 LLR 量化为 Q6.2（6 位整数位、2 位小数位），观察误码率曲线是否损失超过 0.1dB，然后逐步缩位。关键是 LLR 饱和处理——BPSK 解调出来的 LLR 极端情况下可能很大，不做饱和直接截断，等效于给每个比特叠加随机噪声。

def quantize_llr(llr, int_bits, frac_bits): """定点化LLR：饱和截断""" max_val = 2**(int_bits-1) - 1.0/2**frac_bits llr = np.clip(llr, -max_val, max_val) scale = 2**frac_bits return np.round(llr * scale) / scale

量化测试要配合固定随机种子，保证同一批噪声样本在浮点和定点下都跑过，逐比特比对译码输出，首次出现不一致的位置就是量化误差最早溢出的位置。

6.2 和标准参考结果对拍：比误码率更重要的是码字对不对

完成级联链路后，最后一步是验证“发端码字是否正确”。很多团队只盯误码率曲线，结果曲线看着没问题，但发端的码字排列和标准不一致，导致与别家设备对接时全部失败。我习惯做一个独立的码字级验证：构造一组固定输入比特，经过自己的编码器得到码字，再和参考实现（如 MATLAB 5G Toolbox 或开源库）的码字逐比特比对，不一致就逐级排查。

# 码字级对拍脚本，输入相同比特序列，输出逐比特比对结果 python3 code_compare.py --ref_codeword ref.bin --my_codeword my.bin # 期望输出：Bit mismatch count: 0

对码字通过后再跑误码率曲线，此时曲线才有意义。我养成的习惯是：每次改参数都跑一遍码字对拍，防止新改动引入比特顺序错误。这个习惯救过我至少两次，其中一次是把信息位和冻结位的顺序搞反了，误码率几乎没变，但对接直接失败。

最后说一句经验：级联方案的工程落地，难点从来不在某个编码器的数学推导，而在收发两侧的比特级约定——CRC 放哪、打孔按什么序、冻结比特用什么填充、BCH 失败后是纠是弃。把这些边界条件定死并写成自动化验证脚本，误码率曲线自然就对了。希望帮到你。

本文还有配套的精品资源，点击获取