3. LDPC编码与速率匹配：WiFi6中的LDPC编码矩阵选择与打孔算法
各位同学，今天我们来聊聊WiFi6里一个绕不开的话题——LDPC编码。说实话，我刚接触LDPC的时候，看着那些校验矩阵和打孔规则，头都大了。但做多了你会发现，这东西其实有章可循。
WiFi6为什么选LDPC？说白了，就是因为它逼近香农极限。相比传统BCC（二进制卷积码），LDPC在高码率下能多出1-2dB的增益。嗯，这在信号弱的时候，可能就是能不能连上WiFi的区别。
3.1 LDPC编码矩阵的选择策略
WiFi6标准里定义了三种码率的LDPC矩阵：1/2、2/3、3/4和5/6。你可能要问，为什么是这几个码率？我个人的理解是，这是性能和复杂度的折中。
每种码率对应一个基矩阵（Base Graph），WiFi6用的是BG1和BG2两种基图。BG1适用于码长较长的情况（比如1944比特），BG2则用于短码（比如648比特）。
核心要点：实际项目中，我建议根据信道条件动态选择码率。信道好时用5/6，信道差时用1/2。别死脑筋一直用一种。
举个例子，假设你的接收端SNR是15dB，用5/6码率完全没问题。但如果SNR掉到5dB以下，赶紧切到1/2码率，不然误码率会飙升。
3.2 打孔算法详解
打孔（Puncturing）是速率匹配的关键。WiFi6的LDPC编码器输出的是系统位+校验位，但实际传输的比特数可能比编码后的比特数少。这时候就需要打孔——扔掉一部分校验位。
打孔的原则是什么？我总结了两条：
- 优先打掉校验位：系统位是信息位，打掉就丢信息了，所以尽量保留。
- 均匀打孔：别集中打掉某一块，否则解码器会"饿死"。
WiFi6的打孔算法其实挺巧妙的。它用了一个循环缓冲器（Circular Buffer），把编码后的比特按顺序写入，然后根据目标码率从缓冲器中读取。读的时候跳过一些位置，就实现了打孔。
避坑指南：我曾经在项目中犯过一个错误——打孔太密集，导致解码器迭代时收敛不了。后来发现，打孔后的校验节点度数分布要尽量均匀。这个经验值钱啊，兄弟们。
3.3 速率匹配的硬件实现
速率匹配在硬件上怎么实现？我给大家画个流程图：
你看这个流程，其实不复杂。编码器输出后，先存到循环缓冲器里。然后根据目标码率，决定读多少比特、跳过多少比特。
3.4 实际项目中的经验
我在做WiFi6芯片的时候，遇到过一个问题：打孔后的LDPC码性能比预期的差。排查了很久，发现是打孔位置和校验矩阵的结构冲突了。
具体来说，LDPC解码器依赖校验节点和变量节点之间的消息传递。如果打孔集中在某些校验节点上，这些节点就收不到足够的消息，解码就会失败。
警告：打孔时一定要考虑校验矩阵的列重分布。列重小的列（比如列重为1或2）尽量别打孔，否则解码器会"断粮"。
后来我总结了一套打孔优先级规则：
| 优先级 | 打孔位置 | 说明 |
|---|---|---|
| 1（优先打） | 列重≥3的校验位 | 这些节点连接多个校验方程，冗余度高 |
| 2 | 列重=2的校验位 | 有一定冗余，但打孔后影响中等 |
| 3（尽量不打） | 列重=1的校验位 | 打掉后对应校验方程直接失效 |
| 禁止打孔 | 系统位 | 打掉系统位等于丢信息 |
嗯，这个表格是我在实际项目中反复调试后总结出来的。你拿去用，基本不会出大问题。
3.5 小结
LDPC编码和速率匹配，说白了就是两件事：选对矩阵、打好孔。矩阵选错了，性能上不去；孔打错了，解码器罢工。
我个人建议，做WiFi6芯片的同学，一定要把校验矩阵的结构吃透。别只看标准文档，要动手仿真一下不同打孔方案的性能差异。我记得有一次，我为了验证一个打孔方案，跑了整整三天的仿真，最后发现一个参数设错了...那种感觉，嗯，你们懂的。
好了，这一章就到这里。记住，LDPC这东西，实践出真知。
公众号:蓝海资料掘金营，微信deep3321