5G控制信道Polar码仿真实战：从信道极化到SCL译码的完整链路调优

1. 为什么5G控制信道最终选了Polar码：信道极化不是玄学

先聊个有意思的背景。3GPP在2016年确定5G eMBB场景编码方案时，数据信道选了LDPC，控制信道选了Polar码。当时不少人觉得"Polar码是不是捡了控制信道的漏"，但真正做过仿真的人都知道，控制信道码长短、时延要求高、误报率要求极其苛刻，这个场景恰恰是Polar码的主场。Polar码的理论基础是Erdal Arikan在2008年提出的信道极化（Channel Polarization）现象，它是目前唯一被严格证明可以达到二进制输入对称离散无记忆信道容量的构造性编码方案。这句话听起来很学术，翻译成大白话就是：在理论上，Polar码有底气逼近香农极限，而且复杂度可控。

我在实际仿真里最大的感受是：Polar码牛不牛，一半靠编码构造，另一半完全靠译码算法。SC（Successive Cancellation，连续消除）译码在码长足够长时表现不错，但中等码长下错误平层偏高；而SCL（Successive Cancellation List，连续消除列表）引入路径列表之后，性能直接上一个台阶。这篇文章我把我自己搭的上行、下行链路仿真经验完整拆开讲，包括为什么上下行分开建模、SCL的列表管理怎么做、BLER曲线怎么解读、参数怎么调，以及最容易让新手翻车的几个细节。

先说清楚读者范围。这篇文章适合三类人：正在做通信物理层仿真课题的研究生、需要评估Polar码链路性能的工程师、以及对5G信道编码好奇想亲手跑通仿真的人。我会把原理部分压缩到够用的程度，重点放在仿真链路搭建和结果分析的方法论上，因为网上讲Polar码原理的文章很多，但"从零搭一条带SCL译码的完整链路并分析上下行性能差异"的实操型内容其实很少。

1.1 从Arikan的论文到3GPP标准落地

Arikan最初的构造基于巴氏参数（Bhattacharyya Parameter）选择冻结比特位置，后来的研究者陆续提出了密度进化（Density Evolution, DE）、高斯近似（Gaussian Approximation, GA）等更实用的可靠性度量方法。在5G标准落地时，Polar码的构造方案是：CRC（循环冗余校验）比特参与极化编码，信息比特位置按可靠度从高到低选取，冻结比特填充在不可靠位置。

这里有一个关键认知：Polar码的"性能"本质上是由比特信道的可靠性分化程度决定的。码长越长，极化越彻底，但控制信道不可能给你特别长的码，所以短块下的Polar码要靠CRC辅助做路径选择，这也就是CA-SCL（CRC-Aided SCL）成为5G控制信道主流方案的原因。

1.2 信道极化是怎么发生的：合并与分裂

信道极化的过程可以用一个简单例子理解。假设你有两个独立的二进制对称信道W，每个信道的错误概率都是p。把两个信道通过一个异或合并成一个等效的"双比特信道"，其中第一个比特经过"劣化"变成错误概率更高的信道W⁻，第二个比特经过"强化"变成错误概率更低的信道W⁺。递归做下去，N个独立信道会变成N个可靠性极不相同的比特信道，一部分信道容量趋近于1，一部分趋近于0。

仿真的第一步就是构造生成矩阵G_N，它满足G_N = B_N F^{⊗n}，其中F是2×2的极化核矩阵[[1,0],[1,1]]，B_N是比特反转排列矩阵，⊗n表示n次Kronecker积。这个矩阵决定了编码时的线性变换关系。我刚开始写代码时直接用了循环嵌套生成Kronecker积，码长到2048时速度还能接受，但再往上就明显吃力了，后来改成按递归结构生成，速度和内存都有改善。

1.3 可靠性排序：高斯近似用的就是你熟悉的LLR均值

仿真里最影响性能准确度的环节是信息位集合的选取。5G标准里不同码率有固定的可靠度序列（Q序列），但自己做仿真时未必能拿到标准序列的完整实现，所以通常用GA近似自己算。

GA近似的思路是：对每个比特信道，用高斯分布近似其对数似然比（LLR）的分布，通过迭代更新每个信道的均值和方差。初始时，全零码字在AWGN信道下的LLR均值为2/σ²（σ²是噪声方差），方差为4/σ²。迭代公式其实不复杂——对于长度N的极化码，每个极化阶段的均值和方差按以下规则更新：

• 合并节点（对应极化核的上支路）：μ⁻ = φ⁻¹(1 - (1-φ(μ₁))(1-φ(μ₂)))，这个计算较慢，实际工程中通常查表。
• 分裂节点（对应极化核的下支路）：μ⁺ = μ₁ + μ₂。

方差则按σ² = 2μ的关系简化处理。这样算完之后，把N个信道的μ值从大到小排序，选前K个作为信息位。这一步看起来简单，但实操时有个坑：GA近似的精度依赖信噪比设定，如果你在低信噪比环境下用高信噪比算出来的信息位集合，性能会明显下降。所以我在仿真时一般会按工作点附近的目标Eb/N0（比如2dB到3dB）来生成信息位集合，而不是随便取一个值算完就固定下来。

2. SCL译码到底多复杂：列表路径管理与度量排序的门道

SCL译码是SC译码的自然扩展：SC译码在每一层只保留一条幸存路径，而SCL保留L条（L是列表大小），最后从L条候选路径中选出最可靠的一条。这个改动看起来只是"多留了几条路"，但实际实现里涉及路径分裂、路径剪枝、度量计算、排序操作四个核心模块，每一步都有优化空间。

2.1 SC译码的局限：连续消除的串行纠错压力

SC译码的致命问题是决策的不可逆性。译码从第一个比特到第N个比特依次进行，每遇到一个信息比特就做一次硬判决，一旦决策错误，错误会沿着后续的所有比特传播——这和Turbo码或LDPC码的迭代译码思路完全不同。SC译码的错误传播导致它在中等码长下的错误平层比较明显，而控制信道恰恰是按"错误平层必须极低"来设计的，所以直接上SC是不行的。

从信息论角度看，SC译码是逐个比特做最大后验概率（MAP）判决，但没有利用未来比特的信息；而最优的MAP译码需要遍历所有可能的码字。SCL就是在性能和复杂度之间找了个中间点：保留L条最可能的路径，等效于做了"广度优先"的树搜索，L越大，越接近最优MAP译码。

2.2 路径分裂与剪枝：列表是怎么维护的

SCL译码的关键数据结构是一个大小为L的路径列表。每解码一个信息比特时，每个路径都可能分裂成两条（判决为0或1），所以瞬时路径数可能达到2L，此时需要按路径度量（Path Metric, PM）排序，只保留最小的L条。冻结比特不分裂，直接按已知值更新路径度量。

这里要特别注意：路径度量不是加法，而是"惩罚项"累加。标准的对数域PM定义为：当前比特LLR的符号方向与实际判决方向一致，则PM不变；不一致，则PM加上该比特LLR的绝对值。直观理解就是：你越背离信道给出的软信息，路径的累积惩罚就越大，PM越小表示路径越可靠。

2.3 PM度量的计算与排序实现

实现时最影响性能的是排序算法。朴素做法是每层对2L条路径做一次全排序，复杂度O(L log L)，列表大了之后非常拖速度。我实测N=1024、L=32时，排序操作大概占整个译码时间的40%以上。工程上的优化思路：

• 利用上一轮列表已经是排序完成的特性，新的2L条路径是由L条父路径各产生两条子路径，可以采用"局部插入排序"或"败者树"结构。
• 使用比特onic排序网络，在GPU实现中特别有效。
• 对PM值做定点量化，降低比较开销。

我的经验是：如果只是做链路性能评估，用MATLAB的sort函数完全够用，重点在于把路径分裂和剪枝的逻辑写对，而不是过度优化排序。等你要做实时性评估时再考虑C/C++或GPU优化。

此外，CA-SCL引入CRC校验来选择最终路径。具体做法是：译码结束后，从L条候选路径中按PM从小到大依次检查CRC是否通过，选第一个通过的路径输出。如果所有路径都失败，就选PM最小的路径输出。这种"CRC辅助选路"机制对整个性能提升非常显著——表面上是多加了一组CRC比特，实际上是利用CRC的检错能力把错误路径剔除掉了。我下面会专门用一节讲CRC长度对性能的影响。

3. 上下行链路仿真的建模差异：基站侧和终端侧谁更难

很多第一次做Polar码链路仿真的人会把上下行混在一起，直接用同一个模型改改信噪比。这种做法不是不行，但会丢失现实中关键差异。上行链路的典型特征是：发射端是手机，功率受限；接收端是基站，有更好的接收处理能力和更大规模天线。下行链路则反过来，基站发射功率大，但终端的接收处理能力相对有限。这些物理差异在仿真里反映为：SNR定义不同、功控模型不同、天线增益和接收噪声系数不同。

3.1 信噪比的定义差异

上行和下行仿真中，我习惯于区分两种信噪比口径：

• Eb/N0（每比特能量与噪声功率谱密度之比），用于纯编码性能比较，传输速率不同的方案用它做对齐最公平。
• 接收SNR或SINR（信干噪比），用于链路预算评估，因为接收信号的实际强度取决于发射功率、路损、收发天线增益和噪声带宽。

编解码性能分析用Eb/N0，系统级评估用SNR。两者换算关系是：SNR = Eb/N0 × (编码前比特数/符号数)。也就是说，调制阶数和编码码率直接影响SNR和Eb/N0之间的换算关系。我做链路仿真时一般给两套结果：Eb/N0下的BLER曲线用于和文献对比，SNR下的吞吐量曲线用于直观评估实际覆盖。

3.2 发射功率与天线配置

下行仿真中，基站发射功率通常是43dBm（20W）左右，终端接收噪声系数7~9dB，基站天线增益可以有几十dBi的波束赋形增益。上行仿真中，手机最大发射功率一般是23dBm（约0.2W），基站接收机噪声系数2~3dB，终端天线增益通常只有0dBi。这个不对称意味着同样是1dB的链路损耗变化，上行覆盖范围的变化更敏感。

我的做法是：上下行链路用相同的信道编码器和译码器，但信道模型和信噪比映射关系分开配置。具体参数可以按需求灵活设置：下行用基站侧发射功率43dBm、接收端（终端）噪声系数7dB、天线增益0dBi；上行用终端发射功率23dBm、接收端（基站）噪声系数3dB、天线增益25dBi。这样跑出来的BLER曲线虽然形状类似，但落到实际覆盖距离时，上下行的性能差异会非常直观。

3.3 信道模型的选择：AWGN、Rayleigh和TDL模型

纯AWGN信道只适合验证译码算法的理论性能，不适合评估真实链路。工程上常用两种：

• 平衰落Rayleigh信道：每条路径经历独立的复高斯衰落，反映无频率选择性衰落场景，适合CDL/TDL模型之前的快速验证。
• 5G标准TDL模型（如TDL-A、TDL-C）：带时延扩展和功率分布，需要配合OFDM做频域均衡，仿真复杂度高一个量级。

我第一版仿真只在AWGN下验证了SCL和CA-SCL性能，曲线非常漂亮。但后来加上Rayleigh衰落信道后，问题立刻暴露：信息位集合在衰落信道下是否还可靠？答案是"需要重新计算"。GA近似中LLR均值依赖信道状态，衰落信道下信道状态随时间变化，最简单的处理是用信道状态信息的统计平均来重新生成信息位集合，或者直接采用5G标准中基于可靠度序列的固定方案。这一节后面我会再细说。

4. 从BLER曲线看性能：蒙特卡洛仿真的参数配比与结果解读

仿真链路的关键模块包括：Polar编码、调制映射、信道加噪、解调软信息计算、SCL/CA-SCL译码、BER/BLER统计。我用的工具链是MATLAB为主，部分耗时模块用C MEX加速。下面按模块拆解，并把关键参数配比讲清楚。

4.1 仿真代码架构：从编码到译码的主循环设计

主循环的伪代码逻辑如下：

for each EbN0_dB in EbN0_set: for each block in num_blocks: u_info = randi([0 1], K, 1) u = polar_encode(u_info, info_pos, frozen_pos) % 信息位+冻结位 x_mod = modulate(u, mod_order) % BPSK/QPSK/16QAM... y = awgn_channel(x_mod, snr_lin) llr = demodulate(y, snr_lin, mod_order, noise_var) est_u = scl_decode(llr, N, K, L, crc_poly, info_pos, frozen_pos) count_block_errors += ~isequal(u_info(1:K), est_u(1:K)) count_bit_errors += sum(xor(u_info(1:K), est_u(1:K))) BLER = count_block_errors / num_blocks BER = count_bit_errors / (num_blocks * K)

有几个细节要提醒：

• 每次仿真各个信噪比点独立统计块数。BLER目标越低，需要的块数越多，否则置信区间太宽，曲线抖动严重。我的经验是目标BLER=1e-2时至少统计200个错误块，目标1e-3时至少统计100个错误块，这样才能让曲线末端稳定。
• 调制阶数不同，LLR计算方式不同。BPSK/QPSK的LLR可以直接写解析式，16QAM/64QAM用Max-Log MAP近似计算，核心是计算每个符号到星座点的最小欧氏距离。
• 随机数种子要固定，否则每次跑的结果都略有差异，不利于对比调参。我通常按"信噪比点+列表大小+CRC长度"组合设置种子。

4.2 参数配置表：N、K、L、CRC怎么选

我常用的几组参数如下：

举例来说，N=1024、R=1/2（K=512）、L=8时，BPSK调制，AWGN信道下CA-SCL译码（CRC-8）的BLER=1e-2对应Eb/N0大约在1.6dB到1.9dB区间；换成L=32，大约能再省0.3dB左右。具体数值需要以你的实现为准，但趋势是稳定的：L增大、CRC变长都带来增益，只是增益在递减。

4.3 BLER曲线的解读：增益到底花在了哪

有一个常见误区是：把SCL的增益简单归结为"译码算法更强"。从仿真结果看，L从1（即SC）增加到8时，BLER曲线在1e-2附近大约能带来0.5~0.8dB增益；L从8增加到32，增益不到0.3dB；L超过32之后基本进入平台期。这说明SCL的增益主要来自路径分集和选择——SC一条路走到底，一旦方向错就回不来；SCL保留8条路径时大部分错误决策已经能被纠正，再增加路径的边际收益就不明显了。

还有CA-SCL带来的深邃曲线下滑——CRC强制校验路径合法性的能力是关键。具体看，同样L=16，带CRC-8的CA-SCL比纯SCL在BLER=1e-3处的增益可以多0.3~0.5dB，而且有效消灭了错误平层。原因在于：SCL选出的是PM最小的路径，PM最小并不代表译码正确；CRC把"码字合法性"作为硬约束后，错判概率大幅下降。

5. 仿真调优经验：列表长度、CRC长度和信道模型的选择

这一节是我个人踩坑最多的地方。很多问题不是原理不懂，而是参数组合选得不对，导致仿真结果要么不收敛，要么和理论对不上。

5.1 列表长度L的取舍与排序瓶颈

L的选取原则是：在目标BLER达到之前尽量增大L，在目标BLER满足之后再考虑减L降复杂度。如果只是对比算法性能，L=32完全够用；如果要模拟实际控制信道，L=8或16更接近工程可实现的范围。

L变大之后最直接的问题是译码时间线性增长，排序开销甚至超线性增长。我在N=2048、L=32、跑10万块时，纯MATLAB实现要跑两个多小时；换用C MEX加速译码核心后压缩到二十分钟以内。如果你的目标是批量扫参数，建议把译码函数做成C MEX或Python/Cython混合实现，纯脚本语言做大规模蒙特卡洛仿真会很痛苦。

5.2 CRC长度和分段CRC的微妙影响

CRC长度不是越长越好。CRC越长，信息位中被CRC占用的比特越多，等效码率下降；但CRC的检错能力更强，路径筛选更可靠。折中下来，N=512时CRC-8比较合适，N=1024时CRC-16更好。我做了一组对比仿真，结果很有意思：

可以看到CRC-16确实更好，但代价是K少了8比特的有效载荷。实际系统设计时要考虑有效吞吐率，不是无脑上长CRC。另外，5G标准里有一种分段CRC的思路——把信息比特分段，每段各加CRC，逐段做校验，这样不但能加速路径剪枝，还能降低错误传播。我在仿真中试过将总长度16的CRC拆成两段各8，放在前后两段信息上，发现BLER无明显恶化，但早期剪枝效果提升了约15%的译码速度。

5.3 信道模型扩展：从AWGN到TDL-C的演进

如果你只是做Polar码性能和SCL算法对比，AWGN信道足够。但如果你需要评估真实链路的上下行性能，TDL-C这类多径信道是少不了的。TDL-C有典型的时延扩展，频率选择性衰落明显，要配合OFDM做子载波级处理才能正确解调。

我发现一个意外的情况：基于GA近似在AWGN下最优选出的信息位集合，在TDL-C信道下并不是最优的。TDL-C下信道的瞬时SNR波动大，固定信息位集合有时会把信息放在深度衰落的子载波对应的比特信道上，导致错误平层。传统做法有两种：

1. 对每帧做动态资源分配（要求信道估计可靠，实际下行可以靠导频实现）。
2. 使用更保守的信息位集合——把可靠度排名略低但更稳的位子也纳入信息位选择。

不过，如果只是评估SCL算法的上下行性能对比，我建议第一版仿真还是用AWGN加平衰落Rayleigh，先把算法行为摸清楚，再上TDL-C。否则你很难分清性能损失到底是编码/译码带来的，还是信道均衡和OFDM同步带来的。

5.4 浮点转定点：一个容易被忽视的性能陷阱

Polar码译码的LLR在硬件实现里一般用定点数表示，位数不够会直接影响性能。仿真时如果全用浮点，没问题；但想做工程可行性评估时，建议加一步定点仿真。我试过把LLR量化成6比特和8比特，发现8比特和浮点几乎无差异，6比特在低信噪比下会有约0.1dB的损失。这个数据可以给做硬件实现的同学一个初始参考。

另外，PM值的更新公式在定点实现时要注意溢出。路径度量累加的是LLR绝对值的和，N=1024时动态范围可能到上百，用Q8格式要小心。建议所有定点仿真在浮点基线稳定后再做，不要一开始就混着搞，否则出了问题很难定位是算法问题还是量化问题。

最后说一个我实际工作中经常用来快速验证SCL实现正确性的方法：把L设为1，此时SCL退化为SC译码，把译码结果和标准的SC译码实现做逐比特对比。如果两者完全一致，说明你的列表管理框架没写错；如果出现不一致，大概率是路径分裂时冻结比特处理或者PM更新逻辑有bug。这个小技巧帮我省了非常多调试时间，建议你上手时先做这一步验证。