第1章：信道编码——LDPC与Polar码的实战解读
各位同学，咱们今天聊聊5G里最硬核的两个编码方案：LDPC和Polar码。说实话，我刚入行那会儿，看到这两个名字就觉得头大。但干久了你会发现，它们其实就是通信系统里的"纠错双雄"。
5G为什么选它们？说白了，就是要在有限带宽里传更多数据，还得保证不出错。我参与过几个基站项目，深刻体会到：编码选不对，后面全白费。
1.1 LDPC编码：老将新传
LDPC码，全称低密度奇偶校验码。名字听着唬人，其实核心就一句话：用稀疏矩阵做校验。什么叫稀疏？就是矩阵里大部分是0，只有少数几个1。
我在项目中遇到过一个问题：刚开始用随机生成的校验矩阵，结果解码死活不收敛。后来才发现，矩阵的"环"结构没处理好。嗯，这里要注意——LDPC最怕短环，尤其是4环。
核心要点：LDPC编码的关键在于校验矩阵H的构造。5G标准里用的是QC-LDPC（准循环LDPC），好处是便于硬件实现。
来看一个简单的编码示例：
// 伪代码：LDPC编码核心步骤
1. 生成校验矩阵 H (m×n)
2. 通过高斯消元得到生成矩阵 G
3. 编码：c = u × G
// u: 信息比特 (1×k)
// c: 码字 (1×n)
4. 输出码字 c你想想看，实际工程中谁会真去算高斯消元？太慢了。5G基站里用的是分层迭代编码，说白了就是一块一块地算，流水线处理。
| 参数 | LDPC (5G NR) |
|---|---|
| 码率范围 | 1/3 ~ 8/9 |
| 最大码长 | 8448 bits |
| 基图类型 | BG1 (大码块) / BG2 (小码块) |
| 解码算法 | BP (置信传播) / 最小和算法 |
我的经验：做LDPC解码器时，最小和算法比BP算法快3-5倍，但误码率会差0.2dB左右。怎么选？看你的应用场景。基站侧我建议用BP，终端侧用最小和。
1.2 Polar码：新秀崛起
Polar码是土耳其教授Erdal Arikan在2008年提出的。说实话，我第一次看论文时觉得这玩意儿太数学了——信道极化，听着就玄乎。
但实际做下来，Polar码的思路其实很朴素：把信道分成"好信道"和"坏信道"。好的传数据，坏的传固定比特。就这么简单。
为什么会这样？因为信道极化定理告诉我们：当码长趋于无穷时，信道容量要么是1，要么是0。嗯，这就是Polar码的理论基础。
核心要点：Polar码的编码就是做一次"克罗内克积"变换。5G里用的是CRC辅助的Polar码，解码用SCL（串行抵消列表）算法。
编码实现其实很规整：
// 伪代码：Polar码编码
1. 确定信息位集合 A (好信道)
2. 构造编码向量 u:
u[A] = 信息比特
u[A^c] = 冻结比特 (通常为0)
3. 编码: x = u × G_N
// G_N = F ⊗ n, F = [1 0; 1 1]
4. 输出码字 x我曾经踩过一个坑：SCL解码时列表长度L设得太大，结果延迟飙到毫秒级。后来发现L=8就够用了，再大收益微乎其微。
避坑指南：Polar码对信噪比估计很敏感。我曾经因为SNR估计偏差0.5dB，导致解码性能直接崩了。建议用自适应方案，别用固定值。
1.3 速率匹配：把码字塞进资源块
编码完了，码字长度不一定刚好匹配物理资源。怎么办？速率匹配上场了。
说白了就是三步：打孔、缩短、重复。5G里用的是循环缓冲速率匹配（CBRM），我参与的第一个基站项目就是调这个模块。
- 打孔：删掉一些比特，适合高码率场景
- 缩短：把码字截短，适合低码率场景
- 重复：复制一些比特，适合极低码率场景
我记得有一次，客户反馈吞吐量上不去。查了半天，发现是速率匹配的比特选择算法没对齐——嗯，这种问题最坑人，因为代码逻辑看起来完全正确。
1.4 HARQ：错了就重传
HARQ，混合自动重传请求。名字长，但逻辑简单：第一次传错了，第二次传冗余信息，帮你把错纠回来。
5G里用的是增量冗余HARQ。什么意思？每次重传不传相同数据，而是传新的校验比特。这样接收端可以合并多次传输的信息，解码成功率更高。
| HARQ类型 | 特点 | 5G应用 |
|---|---|---|
| Type I | 重传相同数据 | 基本不用 |
| Type II (IR) | 重传冗余版本 | 5G核心方案 |
| Type III | 部分冗余 | 辅助方案 |
实战建议：HARQ的RTT（往返时间）很关键。5G要求小于1ms。我见过有人把HARQ缓冲设得太大，结果延迟超标。记住：缓冲深度和延迟是死对头。
好了，这一章的内容就到这里。LDPC和Polar码各有千秋，速率匹配和HARQ是工程落地的关键。下一章咱们聊聊调制和MIMO，那又是另一片天地。
有什么问题，欢迎交流。我的经验是：编码这东西，纸上谈兵容易，真到调板子的时候就见真章了。