极化码速率匹配全解析：打孔、缩短与QUP准均匀打孔

做物理层信道编解码的人对E这个字母应该都有点条件反射——它代表一次传输实际占用的编码比特数。极化码母码长度永远是 2 的幂可实际调度的E几乎不会恰好等于N。这个落差怎么填就是信号编码技术里常说的速率匹配问题也是缩短、打孔、QUP准均匀打孔这些术语集中出现的地方。我最早接触这批概念是在调 5G 控制信道译码器的时候发现同样一组极化码参数换一种速率匹配方式误块率曲线能差出零点几个 dB。当时第一反应是算法写错了后来才意识到从N个编码比特里挑出E个送出去这个挑的动作本身就有大学问而且和极化码的信道极化结构深度绑定。这篇就顺着这个思路把这几个概念彻底捋清楚。1. 为什么极化码也逃不过速率匹配这一关1.1 极化码的母码长度为什么永远是 2 的幂要理解速率匹配为什么绕不开得先回到极化码的出生方式。Arikan 提出的极化编码本质是把多个独立信道通过递归的合并-分裂操作变成一组容量各不相同的虚拟信道。这个递归结构决定了编码矩阵是F⊗n的 Kronecker 幂母码码长只能取N 2^n。这和 Turbo 码、LDPC 码还不一样。LDPC 的码长可以按校验矩阵的列数灵活设计成 648、1296、1944 这类非 2 的幂Turbo 码支持一大串内部交织长度。极化码想做到任意长度也可以但代价是破坏递归极化结构构造信息位集合时得重新算信道可靠性工程上非常难受。所以 5G NR 里干脆把极化码母码长度限定为{32, 64, 128, 256, 512, 1024}这一串 2 的幂值。问题接着就来了物理层调度的资源块数是动态的调制阶数也是动态的算出来的传输比特数E几乎不可能正好落在上面这串数值上。你总不能为了用极化码逼着调度器把资源凑成恰好能编码的尺寸。所以必须有一个机制把固定长度的母码输出修剪成任意长度的传输序列。1.2 5G NR 场景里 E 值的真实波动拿 PUCCH 和 PUSCH 控制信息举例。上行控制信息 UCI 经过极化编码后映射到物理资源上的比特数由占用的符号数、频域资源块数、调制阶数共同决定。哪怕信息比特数K固定E也会随资源分配在很大范围内跳变。我实际调试中遇到过这样的情况同一份编码输出某次调度算出来E 96另一次算出来E 118。这里 96 和 118 都小于母码长度 128但如果用不同的删减策略译码端填回去的置信度分布就完全不一样。速率匹配做得好不好直接决定了多出来的那二十几个比特是均匀损失的性能还是集中损失的灾难。所以极化码的速率匹配本质上就是解决一个问题已知N个编码比特x[0], x[1], ..., x[N-1]如何选出一个大小为E的子集发送让接收端在删掉N-E个比特的情况下依然能正确译码。思路无非两条路径打孔Puncturing和缩短Shortening而 QUP 则是把打孔这件事做到更精细的一种方案。2. 打孔与缩短同样少发几个比特本质却完全相反2.1 打孔被剪掉的位置在接收端是薛定谔的比特打孔的机制最直观编码完成后把选中的位置直接从发送序列里删除不占用物理资源。接收端拿到E个软比特后要先做解速率匹配把这E个比特放回N长的数组里。那N-E个缺失位置怎么办标准做法是填 0即对数似然比 LLR 为 0表示该比特等概率为 0 或 1完全未知。这里有一个必须理解的点打孔位置虽然是未知的但它在译码过程中依然会参与运算。极化码的译码是置信传播或连续消除这类基于因子图的迭代/递归过程每个编码比特节点都牵着若干信息位节点的可靠性账本。LLR 0 意味着这个节点不贡献任何倾向性但它在因子图里的连接关系还在因此会让与之关联的信息位译码置信度下降。这意味着打孔本质上是用降低某些子信道等效信道质量为代价换取传输长度的灵活性。打孔位置选得越集中被牵连的信息位就越集中如果恰好牵连到几个重要信息位误块率会立刻恶化。2.2 缩短先钉死在 0 再剪接收端已知答案缩短的思路和打孔完全不同。它不是编码之后剪掉未知比特而是编码之前就把某些位置确定为冻结比特并置 0编码之后再把 0 比特剪掉。操作细节是这样的假设要把母码从N缩短到E需要缩短N-E个位置。发送端先构造一个长N的信息向量u其中数字位放在信息位集合A上冻结位放在补集A^c上。在N-E个缩短位置上不仅把它设为冻结位而且明确填 0。编码完成后这些位置因为冻结且输入为 0输出的编码比特必然也是 0注意极化码的生成矩阵是线性变换于是把 0 比特删掉即可。接收端更舒服已知这些位置就是 0解速率匹配时直接给这些位置填一个很大的正 LLR比如 100表示我不仅知道它存在还知道它一定是 0。这种先验信息非但不会降低性能反而能帮助译码器排除干扰。从这里能看出缩短的效率为什么优于打孔打孔引入的是不确定性缩短引入的是确定性。缩短本质上是我通过冻结操作白赚了一个已知位置唯一代价是它消耗了冻结位集合的配额。2.3 为什么缩短优先、打孔兜底既然缩短性能更好为什么不全用缩短因为缩短位置的候选集合受冻结位集合限制。信息位集合A的大小是K冻结位集合大小是N-K。你最多只能缩短N-K个位置而且还要保证缩短之后留下的编码结构依然合理。实际中的典型场景是K比较大、E又比较小。比如K 80, N 256, E 100需要缩短 156 个位置但冻结位只有 176 个逻辑上可行可还要预留一些位置做 CRC 校验、极化权重微调所以纯缩短方案往往不现实。更常见的情况是N比E大很多缩短数量超过可用冻结位数量或者缩短位置落在可靠性分布的关键区域导致信息位被迫迁走这时就打孔兜底。工程上还有一个更细的约束缩短位置必须精确落在冻结位集合内。如果随便指定某个索引做缩短而这个索引恰好是信息位发送端把 0 填进去等于丢掉一个信息比特接收端还浑然不知译码必崩。这是新手最容易踩的坑后面我专门展开。3. QUP准均匀打孔让被剪掉的位置均匀散开3.1 朴素打孔的坏味道先看打孔最直接的实现随便选N-E个位置比如直接取前N-E个索引丢掉。这样做有什么问题极化码的递归结构可以看作一棵深度为n的二叉树。根节点对应整个码字左子树对应前半段编码比特右子树对应后半段编码比特。信道极化的本质就是在这棵树上做分裂每次分裂都把可靠性往两个方向推。如果打孔位置全部集中在左子树的一片连续区域相当于这棵树的某个局部被整体挖掉那这些位置对应的高层节点在因子图上会形成一块置信度空洞。举个例子N 64, E 48如果打孔位置选0~15那第 0 到第 15 个编码比特对应的所有叶子节点全部缺失。这些叶子在极化树的前四层分裂中形成的中间节点几乎全部受到影响。译码时这一大片区域的子信道等效容量趋近于零信息位只要稍微往这个区域靠一点性能就雪崩。更糟糕的是这种集中打孔还会破坏信息位选择的可靠性排序。本来通过密度演进或极化权重算好的可靠性序列是在所有信道都存在的假设下算的。打孔之后被打孔位置对应的子信道可靠性应该被降级重算如果沿用旧序列等于用错误的前提做选择。3.2 QUP 的构造逻辑QUPQuasi-Uniform Puncturing准均匀打孔就是为了解决集中打孔的毛病提出来的。它的核心思想是让打孔位置尽量均匀地分布在整棵极化树上使得损失的置信度被摊薄到尽可能多的分支里而不是集中在某几个关键节点上。工程上常用一种基于比特反转置换的构造方式我直接给可运行的思路import math def bit_reverse(x, n_bits): y 0 for i in range(n_bits): if (x i) 1: y | 1 (n_bits - 1 - i) return y def qup_puncturing_positions(n, e): 生成准均匀打孔位置。 n: 母码码长 (2 的幂) e: 传输比特数 返回: 长度为 n-e 的打孔索引数组 n_bits int(math.log2(n)) n_punc n - e # 对 0..n-1 做比特反转排序取后面 n_punc 个作为打孔位置 order sorted(range(n), keylambda i: bit_reverse(i, n_bits)) return order[-n_punc:]这段代码的思路是把0到N-1的索引按比特反转后的值排序。比特反转本质上是在极化树的不同层级之间做对称置换让排序结果天然具备递归均匀性。取排序序列的连续一段作为打孔集合这些位置在原始序里就会散落在低半区、高半区以及各自的四分之一区内。我实测过N 256, E 160的情况QUP 打孔位置在 0~255 上的分布接近等差数列和随机抖动的结合而不是挤在开头。要注意这是 QUP 思想的工程化表达。严格版本的 QUP 在原始文献里采用递归扩张算法先建立打孔一半的最优骨架再逐级补位但最终效果和我上面这段代码体现的均匀化思想是一致的。3.3 QUP 的性能特性与适用边界QUP 相对朴素连续打孔的性能增益主要体现在中等打孔率区间。打孔率很低时比如N 256, E 240只打 16 个孔无论怎么选位置损失都有限差距只有零点零几 dB在工程上有无 QUP 无所谓。打孔率很高时比如E N/2可用编码比特不足一半信息位已经被压缩得很厉害均匀与否的差距会被强信道纠错能力掩盖一部分。真正能看出差距的是中间地带打孔比例在 25% 到 50% 之间时QUP 比连续打孔通常好 0.2 到 0.5 dB。我自己的仿真习惯是把 QUP 作为打孔方案的默认选项因为它的计算复杂度极低一次比特反转排序完全可以用查表的方式预生成运行时只是取一段索引。相比优化信息位集合的收益QUP 这个优化几乎是白捡的。4. 删余到底是什么一个容易混淆的术语澄清4.1 删余、打孔、缩短的词典级辨析很多中文资料里删余和打孔混着用标题里也把打孔、删余并列了这里花一小节说清楚。从编码理论的一般定义看删余puncturing 的常见译名是一个大类概念从编码器输出序列中删去若干符号以适配目标速率。打孔是删余的最直接实现——发送端删、接收端未知。缩短从广义上看也是一种删删掉了部分输出比特但它不是删余的典型子集因为缩短的比特在编码前就被固定为 0接收端是已知的信息论意义上它没有引入删除信道。更准确地说打孔和缩短是达到速率匹配这一目的的两种并列手段删余是打孔的中文别称。下面这个表我整理给团队新人用这里直接放出来术语英文发送端操作接收端先验性能代价约束条件打孔Puncturing编码后删除指定比特LLR0完全未知有损需重新设计信息位无硬性约束选位要均匀缩短Shortening编码前冻结并置 0编码后删除LLR∞已知为 0基本无损缩短位必须是冻结位删余Puncturing/删除同打孔同打孔同打孔同打孔4.2 工程代码里常见的注释陷阱看开源实现或者芯片参考代码时经常看到delete,omit,puncture三个词交替出现。新手容易以为它们是三个不同功能实际上大多数情况下指的都是打孔。真正需要警惕的是代码里出现shorten时往往伴随一套完全不同的冻结位处理流程。我之前接过一个移植自 MATLAB 的极化码模块函数名叫puncturing_pattern但看它的注释又写 shortening-based rate matching。点进去发现它打孔前先对输入向量做了置零冻结然后删掉对应编码输出。这东西到底是打孔还是缩短判断标准只有一个接收端对删掉位置的 LLR 填 0 还是填无穷大。填 0 就是打孔填无穷大就是缩短。至于发送端代码长什么样都只是实现细节。4.3 为什么标准文档里很少出现删余而多用打孔/缩短3GPP 标准文本和学术论文里几乎只用 puncture 和 shortening 两个词中文社区里删余更多是从老编码理论教材继承下来的习惯。老教材讲卷积码、RS 码时删余卷积码指的就是通过周期性删除校验输出来提高码率当时没有缩短这种精细区分。到极化码时代术语体系逐渐收敛到打孔/缩短的二元划分。所以我建议读论文时看到删余就默认理解成打孔看到缩短才单独区别对待。5. 从论文到 5G 标准QUP 为什么没有进 NR以及它现在还在哪用5.1 5G NR 最终选择的比特选择方案如果搜 5G NR 的极化码速率匹配会发现协议里根本不出现 QUP 这个名词也没有显式的打孔集合或缩短集合概念。3GPP RAN1 在讨论极化码速率匹配时对比过各种方案包括基于缩短的方案、基于打孔的方案和 QUP最终收口到一种和 LTE Turbo 码风格很像的循环缓冲比特选择circular buffer based bit selection。流程大致是编码输出先经过一个子块交织器做位序重排写入一个循环缓冲区然后按照信噪比和码率需求从某个起始位置开始连续取E个比特。如果缓冲区不够长就循环取。这种方案的高明之处在于它用一个统一的取比特规则自动把低码率时的行为表现为类似缩短、高码率时的行为表现为类似打孔收发两端只需要维护一张交织表和一个起始位置硬件实现非常干净。那 QUP 被淘汰了吗严格说不是被淘汰而是被这个更通用的框架吸收了。循环缓冲里的交织表如果设计得当取出的比特集本身就接近均匀分布。QUP 的均匀化思想并没有过时。5.2 QUP 的当代价值与适用场景虽然 NR 标准没用 QUP 这个名字但在几个场合它依然是实用的第一学术对比的基准方案。发表极化码速率匹配相关论文时QUP 几乎是默认的 baseline因为它构造简单、结果可复现。你想验证自己的新方案是否有效先跟 QUP 比比赢了再跟标准方案比这个路径最清晰。第二特殊码长适配。有些专用通信系统不采用标准 NR 参数集而是自己定义N和E。这时候不想实现完整的循环缓冲交织器直接用预生成的 QUP 位置表几行代码就能搞定。我在一个窄带卫星控制的仿真项目里就是这么干的N 512, E从 180 到 480 变化一张 512 长的顺序表配合比特反转排序全部打孔位置一次性算完运行期零额外开销。第三协作通信和增量冗余。比如 HARQ 重传时第一次传E1个比特第二次传E2个新比特。用 QUP 生成的两组打孔位置天然互补性强可以避免重传和初传的比特大量重叠。这一点是我实际测试哈工大链路时发现的同样的重传增益QUP 的均匀分布让合并后的有效码率更平滑。5.3 如果你要上手推荐怎么搭试验我的建议是先用一个极简的 BPSK-AWGN 仿真平台验证不要一上来就上 5G 的完整收发链路。参数选择如下母码长度N 256信息位K 40CRC 长度为 8采用 CA-SCL 译码列表大小L 8E取三组(a)E 224打孔率低(b)E 160打孔率中等(c)E 96打孔率高三种速率匹配方式连续打孔、QUP、缩短缩短仅在冻结位够用时对比。跑出来的典型结论是E 224时三种方案差距很小E 160时 QUP 比连续打孔约有 0.3 dB 增益缩短若可用则比 QUP 再好一点E 96时所有方案都开始快速恶化QUP 的优势依然存在但不那么明显。这种结论能帮你建立直觉以后看协议里的速率匹配参数时就有底了。6. 实测观察与踩坑心得6.1 打孔位置对信息位选择的蝴蝶效应我踩过最诡异的坑是换了一套打孔位置表后误码率不降反升查了两天才发现问题出在信息位集合上。极化码的信息位集合A是基于所有N个子信道都存在假设下的可靠性排序选出来的。打孔之后被打孔位置对应的子信道等于被强制降级为容量为 0 的信道整个可靠性排序都被打乱了。如果按旧的排序选信息位很可能选到一些实际上已经被打孔拖垮的信道。正确做法是先构造打孔集合把打孔位置排除出候选信息位或者用密度演进法在打孔后的信道集合上重新算可靠性。5G NR 标准里提供的Q序列表在设计时就考虑了这个因素所以用标准参数没问题。但自定义参数的系统一定要把这个重算流程写进链路构建步骤而不是只改速率匹配函数。6.2 缩短位置必须落在冻结位并且要和 CRC 对表缩短最隐蔽的坑是在 CRC 辅助极化码里。CRC 比特在编码前会插入信息位序列因此 CRC 位本身也被当作信息参与极化编码。如果你做一个缩短方案缩短位置没有经过 CRC 位校验——缩短位置要求冻结CRC 位要求作为信息参与运算两者天然冲突。一旦缩短位置和 CRC 位重叠发送端会把 CRC 比特置 0 发送接收端 CRC 校验必挂。解决方法是缩短位置直接限定在纯冻结区域或者在做 CRC 插入之前先确定缩短集合把缩短位置排除在信息位和 CRC 位之外。这个顺序问题我在代码里吃过亏之前把缩短处理放在 CRC 插入之后位置表对不上第一轮仿真结果惨不忍睹。6.3 接收端 LLR 填充的细节比发送端更重要很多实现把重心放在发送端怎么删比特但真正决定性能的是接收端怎么填缺失位置的 LLR。打孔位置填 0缩短位置填大正值这个原则清楚但填的时候要考虑有限精度的影响。定点实现时缩短位置的 LLR 如果填100在 8-bit 量化下饱和到最大值问题不大。但如果打孔位置填 0 时没有把状态位处理好某些译码器会把 0 当成已删除的无效节点直接剪断导致因子图结构不一致性能反而比填 0 更差。我建议无论浮点定点都保持数组长度恒为N缺失位置用标准化的 LLR 占位不要试图在内存里把数组缩短否则索引映射的调试能让人崩溃。硬件上还有个习惯是提前把打孔位置表固化在 ROM 里。用 QUP 时位置表长N每个条目 1 个 bit 标记是否打孔也就是N/8字节N 1024时只有 128 字节非常小。相比运行时不断调用比特反转函数查表更省逻辑资源也更方便做时序约束。6.4 一个实用的自检方法如果你想快速确认自己的速率匹配实现是否正确有一个简单粗暴的自检在无噪声条件下跑一次收尾到头的仿真。发送端编码、打孔/缩短、接收端填 LLR、译码全过程如果正确译码输出必须和发送信息完全一致。只要速率匹配任意一个位置映射有误无噪声环境下立刻暴露而且错误比特数通常远大于单比特差错的量级一眼就能看出来。做完无噪声自检再加一个高信噪比点比如 8 dB验证误块率趋近于零然后逐步降低信噪比扫曲线。链路没调通之前别急着对比方案优劣先把0 dB 下方案 A 比方案 B 好 0.3 dB这种结论压到链路全通之后再说。就我个人经验极化码速率匹配这块的复杂度不在编码矩阵也不在译码器而在于所有删减动作和可靠性排序之间的耦合关系。打孔、缩短、QUP 这些名字听起来像是简单的位置选择问题实际上每一个都在和极化结构做博弈。理解了打孔是引入未知、缩短是注入已知、QUP 是让未知尽量均匀这个三角关系再看任何协议里的速率匹配实现思路都会清晰很多。