5G的物理层里Polar码算是个绕不开的话题。我在某个5G链路级仿真项目里做过一段时间的译码算法选型评估当时最直观的需求就是把三种主流译码算法——SC、SCL、BP——放到同一个平台上跑一遍看它们的误码率和误块率到底差多少。说实话网上关于这三种算法的介绍很多但真正把仿真参数、曲线趋势、工程代价放在一起对比的实操文章反而不多。这篇文章就把我当时做的对比过程、结果和踩过的坑说清楚给正在做类似评估的朋友一个参考。1. 为何盯住BER和BLERPolar码在5G里的角色与评价指标1.1 Polar码凭什么进入5G NRPolar码是首个在理论上被证明能够达到香农极限的编码方案这也是它能进入5G NR标准的核心原因。和LDPC码在数据信道上的应用不同Polar码主要负责控制信道的编码比如广播信道、下行控制信息这类对可靠性要求极高的场景。控制信道的载荷很小但出错代价非常大——一条控制消息解错整个调度周期都白费所以编码增益和一致性表现比吞吐量更被看重。我当时评估这套算法时最初的想法很简单既然标准定了Polar码那译码器选哪种算法、性能差距能有多大总得有量化的数据支撑。做物理层算法仿真的人应该都有体会单纯看理论曲线是一回事放到带噪信道、量化定点、有限迭代次数的环境里跑又是另一回事。这也是为什么我一直建议身边的朋友做算法对比不要只看教科书上的渐进性能一定要自己搭链路仿真。1.2 BER、BLER和FER三个容易混淆的指标做性能对比的时候最容易栽在指标定义不统一。误码率Bit Error RateBER算的是所有传输比特中出错的比率误块率Block Error RateBLER或者误帧率Frame Error RateFER算的是整个传输块被判错的比率。一个块只要有一个比特出错这个块就算错了所以BLER通常远大于BER尤其是在信道条件不好的区域。这里有一个很重要的细节很多文章会把误帧率和误块率混着说其实在5G语境下一个传输块Transport Block经信道编码后可能对应多个码块Code Block而我的仿真对比里用的是单个Polar码块作为最小译码单位所以严格来说我统计的是误码块率。但如果每个传输块只映射一个码块那误块率和误帧率就完全一致了。做对比前一定要把这个定义写清楚否则报告里数据对不上后面排查会很痛苦。1.3 影响译码性能的隐藏因素除了算法本身调制方式、码率、码长、信道估计误差、量化位数都会直接影响最后的BER和BLER曲线。我在做横向对比时把所有条件锁死只允许译码算法不同这样出来的曲线差异才能归因到算法头上。要注意的是SC、SCL、BP三种算法对信道对数似然比LLR输入的敏感程度不一样BP算法对LLR的量化尤其敏感量化位数不够时性能掉得厉害这点在后文的实测部分会再展开。2. SC译码顺序消除的本质与性能瓶颈2.1 SC逐比特判决的运行逻辑SC译码算法全称是Successive Cancellation核心思想是逐次消除。它把Polar码的编码过程看成一个级联的极化变换译码时从左到右依次恢复每一个比特。译第i个比特时前面i-1个比特已经完成硬判决这些判决结果会被当作已知条件参与当前比特的似然比计算。这意味着SC是一个严格串行的过程天生存在长时延问题。从实现角度看SC译码器的核心是对数似然比的计算。标准SC译码在每个节点都要做两类运算一种叫f函数处理两个输入LLR合并的情况公式是( f(a,b) \approx \text{sign}(a)\text{sign}(b)\min(|a|,|b|) )另一种叫g函数处理带已知比特时的更新公式是( g(a,b,u) (-1)^u a b )。用这两个函数在译码树上递归展开就是SC的完整流程。2.2 SC在短码和中长码下的表现从性能曲线看SC译码在码长较短时会比长码表现好一些。原因是码长增加后极化不完全信道分裂后仍有一部分比特信道容量没有趋向0或1SC在这些位置容易出错。我做仿真时选的是5G NR标准里的控制信道编码参数码长分别为128和256码率约1/3到1/2在BPSK调制加高斯白噪声信道下SC的误块率曲线在目标BLER等于1e-2时需要的信噪比要比后面要说的SCL高接近0.5到1dB。值得注意的是SC译码有一个非常有名的现象——错误传播。如果前面某个比特判错了后面的判决会顺着这个错误一路错下去。这个特性让SC的误块率曲线在某些区域不够陡错误平层error floor也更明显。对于要求极高可靠性的控制信道来说SC往往不太够用。2.3 SC在实际链路中最难受的地方我在仿真中体会最深的一点是SC算法对信道估计误差的鲁棒性其实还可以但对LLR精度要求不低。因为f函数里的min运算会放大量化误差低比特量化时SC的错误平层会往上抬。还有一个工程问题是SC的串行特性导致译码时延很高尾随效应明显后面比特要等前面比特全部解完才能开始这在低时延场景几乎不可接受。所以SC在现在的实际系统中很少单独作为最终方案更多是作为教学基线以及SCL译码器的内部路径度量更新的基础。SCL说白了就是在SC的框架上加了后悔药机制这也是为什么它性能能明显碾压SC。3. SCL译码为最差的第一次移位预留候选3.1 列表展开的内部过程SCL全称是Successive Cancellation List它在SC的基础上引入列表List的概念。每译一个比特不是只保留一条最优路径而是同时保留L条候选路径。遇到信息比特时路径会分裂——每条现有路径同时尝试0和1两个分支然后根据路径度量挑出分数最高的L条继续往后走。路径度量一般用对数似然比累加表示越大的度量代表这条路径越可信。当L等于1时SCL退化成SC所以SCL性能下限天然不会比SC差。当L增大时候选路径变多最终译码器在列表里挑路径度量最大的那条作为最终输出性能自然提升。我实测下来L从1到8的增益最明显从8到32的增益边际递减。L等于32时在码长256、码率1/2的情况下比SC大概能多1.2dB左右的增益——这个数字和很多文献里的结论是吻合的。3.2 CRC辅助带来的瀑布区陡降SCL真正的爆发点在于引入CRC辅助简称CA-SCL。做法是在编码前先给信息比特加一段CRC校验比特译码时SCL维持一个候选列表最后不是直接选度量最大的路径而是先检查列表里有没有哪条路径能通过CRC校验如果有就在能通过校验的路径里选度量最大的作为输出。这个改动看似简单效果却非常明显。CRC相当于给SCL提供了一个外挂验证器让译码器知道哪条路径更可能正确。在我仿真里加入CRC后的SCL在BLER等于1e-3时比不带CRC的SCL还能好0.3到0.4dB而且错误平层几乎消失。5G NR控制信道里普遍采用CRC辅助也是有原因的——用很小的冗余换来了大幅性能提升这笔账非常划算。3.3 列表大小L的复杂度账单SCL的代价是复杂度。列表每次分裂时路径度量排序的开销不可忽略。L增加一倍存储和计算开销几乎同步翻倍时延也会增加。我的仿真中L等于8的SCL译码时间比SC多了将近一个数量级L等于32时更夸张带来了大约两个数量级的复杂度提升。所以问题从来都是够用就好而不是一味追求大列表。在控制信道这种载荷很小的场景下L取8到16已经是性能和复杂度的甜点区。如果追求更高吞吐还可以用自适应列表的方案在信道条件好的时候用小列表条件差的时候动态增大列表这类方案工程上已经有人在做后面有空再单独写一篇。4. BP译码置信度传播下的并行纠错4.1 因子图与消息传递BP译码全称是Belief Propagation走的是另一条完全不同的路。Polar码的编码过程可以展开成一个因子图BP译码在因子图上交替传递两类消息——从左边往右传递的变量节点消息以及从右边往左传递的校验节点消息。每一轮迭代都让消息在整个图上流动一次经过一定次数迭代后根据最终的LLR做硬判决。和SC、SCL不同BP天然是并行的所有节点的消息更新可以同时进行所以BP在硬件实现上的并行度和吞吐量潜力非常高。我在仿真平台里写BP译码器时最大的感受就是循环体内的计算非常规整很容易向量化这一点在GPU仿真和硬件实现里都是巨大优势。4.2 BP的收敛、早停与实现细节BP能否收敛、收敛多快受很多因素影响。首先是迭代次数我测试过迭代5次、10次、20次、40次的差异码长256的情况下迭代10次左右基本接近收敛再多迭代带来的增益非常微弱。可以根据每一轮迭代后硬判决是否满足校验关系来做早停能省下不少平均迭代次数特别是在高信噪比区域平均迭代次数会显著下降。需要特别提醒的是BP的初始消息设置很重要。变量节点的初始LLR由信道输出决定校验节点消息初始化为0这个大家都会。但量化精度对BP影响比SC、SCL大得多我测试8比特量化时BP性能已经明显优于4比特但SCL在4比特和8比特下的差距没那么大。如果要做定点BP量化位数的选择一定不能拍脑袋要从误块率曲线推回去选。4.3 BP在低信噪比区的奇怪表现BP的一个特点是在低信噪比区域容易发生假收敛——消息传递看起来趋于稳定但稳定在了一个错误状态。这是因为因子图上存在小环cycle消息在这类环上反复传播时会产生正反馈把错误信念固化下来。我在仿真中发现在BLER约1e-2以上的区域BP有时比SCL还差但进入瀑布区之后曲线又变得非常陡峭最后的错误平层比SC低很多。这个现象也提醒我BP的性能评估不能只看高信噪比下的极限增益要关注目标工作点。如果系统要求BLER在1e-2这个量级BP可能不是最优选择如果要求到1e-4甚至更低BP的瀑布区一旦拉起表现相当能打。5. 同一平台下的实测数据BER/BLER曲线对比5.1 仿真设置与参数表为了公平对比我把所有条件锁死只让译码算法作为唯一变量。仿真平台用的是自己搭的链路级模拟环境信道模型是高斯白噪声AWGN调制方式BPSK码长256码率1/2信息位长度按5G NR控制信道典型配置来CRC位数为11。SCL的列表大小取8再额外跑一组L16做参考BP的迭代次数上限设20带早停量化统一用8比特。要说明的是这里的绝对数值依赖具体仿真环境和参数选择不同平台跑出来会有差别但算法之间的相对关系是有代表性的。我生成数据时对每个信噪比点至少统计了200个错误块以上保证BLER曲线在1e-3这个量级上可信度足够。算法码长码率迭代/列表目标BLER1e-2所需SNR目标BLER1e-3所需SNR备注SC2561/2串行单路径约3.0 dB约4.2 dB曲线不够陡SCL(L8)2561/2L8约2.45 dB约3.15 dBCRC辅助SCL(L16)2561/2L16约2.35 dB约3.0 dB增益边际递减BP(20次)2561/2并行20次约2.8 dB约3.4 dB低SNR区略差5.2 各算法误码率与误块率表现汇总从误块率看SCL(L8)是全场最稳的选手在目标BLER1e-2时比SC好约0.55dB在目标BLER1e-3时好约1.05dB差距进一步拉大。这说明SCL的曲线在瀑布区比SC更陡峭错误传播的影响被列表机制有效压制。SCL从L8提升到L16增益还有约0.1到0.15dB边际递减明显。BP在BLER1e-2时比SCL(L8)差了约0.35dB但到了1e-3时差距缩小到约0.2dB。如果继续往更高信噪比推BP和SCL的差距还会进一步缩小这是BP瀑布区更陡导致的。从误码率维度看三者排名和误块率基本一致。SC的BER曲线与BLER曲线之间的间距较大说明它的错误倾向于集中在少数坏块里SCL的这个间距明显更小意味着一旦出错往往是整个块里多处比特都出错但好在整体出错概率已经被压得很低。5.3 数据背后的现象解读SC的误块率曲线在高信噪比段出现明显拖尾这是错误传播造成的。SCL的CRC辅助机制相当于在校验维度上做了一次纠错筛选所以瀑布区来得更早、更陡。BP在低信噪比段的劣势来自图上的小环导致的消息自我确认但在瀑布区BP的概率传播特性开始发挥优势曲线斜率和SCL几乎相当甚至略有反超趋势。我个人还做了一个交叉验证把SCL去掉CRC辅助再跑一遍发现BLER1e-3时比带CRC的版本差了约0.3dB这也验证了CRC辅助对SCL不是锦上添花而是雪中送炭。做控制信道这种可靠性要求极高的场景时CRC带来的这部分增益不能用其他参数轻易替代。6. 工程选型的现实考量与个人经验6.1 复杂度、时延与并行度的权衡纯看性能SCL几乎是三种算法里的最优选择但工程实现时还要看时延预算和硬件资源。SC是串行递归时延是几个算法里最高的但存储开销最小。SCL的时延取决于列表展开和排序的流水线设计L8在典型实现下可以做到几十个时钟周期级别的块处理L成长后存储翻倍、排序复杂度上升但换来的是性能提升有限。BP在吞吐量和并行度上有先天优势如果硬件资源允许BP可以做得很高的并行流水线同时还能用早停技巧降低平均迭代次数这对降低功耗非常友好。我自己的看法是选择算法不能只盯着仿真曲线要把调制编码方案、目标误块率、硬件平台、时序约束都摆到一起算。控制信道短包低延迟场景下SCL几乎是标准答案因为它的性能增益在短块上体现最充分而BP更适合那些对吞吐率极度敏感、且允许通过增加计算单元换取延迟降低的场景。6.2 我的观察SCL是大多数场景下的甜点把三种算法都实现并在仿真链路里跑过之后我现在的默认选择基本是SCL列表大小根据需求调节。L8在多数情况下性能已经足够好L16留给那些误块率要求极高的场景。SC我现在只在做基线对比时用做参照BP则是在讨论并行实现、吞吐量优化时另作评估。有一点得说清楚SCL的性能优势在码长和码率变化时会略有波动。我后来把码率从1/2改成3/4SCL相对SC的优势略微缩小了一点但依然明显。如果你在做的系统和我的参数差异比较大最好的做法还是自己把三条曲线都跑出来不要直接照搬我这个结论。6.3 给新入行的同学的建议如果让我给刚开始做Polar码译码仿真的朋友一个最直接的建议那就是一定先跑通SC再改SCL最后才碰BP。SC是基线也是理解Polar码极化结构的最佳入口。SCL的核心改动只在路径管理部分先吃透SC的递归逻辑SCL其实就是一个路径版本的数据结构问题。BP则是另一个世界牵扯到因子图消息传递理论建议单独花时间啃不要和SC的思维混在一起。另外做性能对比时仿真统计量要充足至少保证目标误块率点上有几十个错误块打底否则曲线抖动会让你误判算法优劣。我第一次跑的时候在1e-3这个点只统计了五六个错误块曲线抖动特别大差点得出错误的结论。后来把仿真轮次增加了一个数量级数据才稳定下来。这个细节很不起眼但能帮你少走很多弯路。我在实际项目中还有一个体会对比表里放一个实现复杂度估算列比只放BER和BLER数值要有用得多。因为领导最后关心的不是理论增益多漂亮而是新方案能不能在现有硬件上落地、功耗会不会超标、时延能不能压得住。把这几样数据放在一张表里沟通效率会高很多。如果你正在调研Polar码译码算法选型建议按照我上面的对比思路把自己的参数代入跑一遍然后再结合实现约束做决策。纸上谈兵的曲线差异和真正跑出来的性能数据往往是两回事。