1. FEC与重传机制概述
前向纠错（FEC）原理
前向纠错，简称FEC，说白了就是在发送数据时就带上冗余信息。接收端拿到这些冗余码字，就能自己把错修回来，用不着麻烦发送方再重发一次。
我最早接触FEC，是在一条卫星链路上调一个视频传输项目。当时延时特别大，重传一遍来回要半秒多，画面直接卡死。后来切了FEC，虽然带宽多了20%左右，但画面总算能看了。打那之后，我对FEC的印象就一个字——快。不管重传多好的机制，总归有来回时间，FEC不来回，一次到位。
FEC的核心思路很简单：给原始数据增加校验码。比如最经典的Reed-Solomon（RS）码，它的参数写成 RS(n, k)：
k是原始数据块的长度n是编码后带冗余的总长度- 冗余度就是
(n – k)个符号
举个例子，你发送100字节的数据，用RS(120, 100)，每100字节额外带20字节的纠错码。如果信道里丢了一些字节，接收端能用这20个冗余把它补回来。具体能纠多少错？一般可以纠正 (n – k)/2 个错误。注意是“错误”不是“丢失”，丢失的算擦除，能纠更多。这里不展开数学细节，你只要记住一句话：FEC用带宽换时间。
| 参数 | 含义 | 典型值 |
|---|---|---|
| n | 编码后总符号数 | 120 |
| k | 原始符号数 | 100 |
| t | 可纠错符号数（错误） | 10 |
| 冗余率 | (n−k)/n | 16.7% |
自动重传请求（ARQ）基础
ARQ就完全是另一条路——不纠错，只检错，错了就喊发射方重新发。典型的流程是：接收方收到数据包，算个CRC，如果校验通过回ACK，不通过回NAK或者什么都不回（超时重发）。
最常见的三种ARQ机制：
- 停等ARQ（Stop-and-Wait）：发一个包，等ACK，到了再发下一个。简单，但利用率低。我当年做低速物联网模组时用过，9600波特率下一个包几十毫秒，等得起。但换成千兆以太网你试试看，效率会低到离谱。
- 回退N步ARQ（Go-Back-N）：连续发一堆包，一旦某一个丢了或错了，发送方从那个包开始全部重传。窗口长度固定，适合信道比较稳定的场景。我记得有一回优化一个地面微波链路，用了Go-Back-N窗口32，误码率一上来就“雪崩”——一个包错，后面31个白传了。
- 选择性重传ARQ（Selective Repeat）：只重传出错的包，其他包缓存起来乱序重组。效率最高，但实现也最复杂。我现在做的无线视频传输项目就用的Selective Repeat，接收侧要维护一个大重排缓冲区，处理乱序到达的包。
三种方式的对比我经常拿来做调试手册的入门参考：
| 类型 | 重传粒度 | 接收缓存需求 | 效率（高误码） | 实现复杂度 |
|---|---|---|---|---|
| 停等ARQ | 单包 | 无 | 极低 | 简单 |
| 回退N步 | 整窗口 | 无（丢弃乱序包） | 低 | 中等 |
| 选择性重传 | 单包 | 有（重排序） | 高 | 复杂 |
混合自动重传请求（HARQ）简介
看到这里你可能在想：FEC快但浪费带宽，ARQ节省带宽但牺牲延时。能不能两个合起来用？当然可以。这就是HARQ。
HARQ的思路：第一次发数据包时，带上一部分FEC冗余。如果接收端解码成功，直接回ACK；如果解码失败，但不至于完全找不到北，接收端会缓存这次失败的软信息（比如LLR对数似然比），然后请求发送端重发增补冗余。发送端再发一些额外的校验比特，接收端把新老信息合并起来再尝试解码。这样大大提高了成功率。
HARQ分两种主流方案：
- 类型I HARQ（纯重传+简单合并）：每次重传都是相同的数据和冗余，接收端做分集合并（Chase Combining）。简单，但增益有限。
- 类型II HARQ（增量冗余 HARQ / IR-HARQ）：重传的不是整个包，而是新的冗余比特。每次重传都增加纠错能力。我倾向于用IR-HARQ，码率自适应，效率明显更高。
嗯，这里要注意：IR-HARQ虽然好，但要求接收端能灵活调整软缓冲区大小。我在调试4G LTE基站的HARQ流程时，曾因为软缓存区配置不匹配，导致重传合并后CRC依然失败，反复重传了4次才成功——后来重新算了最大软比特数和HARQ进程数才压下来。
下面这张图把FEC、ARQ、HARQ的关系串到一起，你看一眼就能明白它们各自的位置：
HARQ的关键设计参数包括：
- 最大重传次数：太多会堆积延时，太少则浪费纠错潜力。LTE里一般是4次，NR灵活到最多几十次。
- 冗余版本（RV）：增量冗余里每次重传用不同的打孔模式。我习惯搞一个RV序列表，第一版给满码率，后面逐渐降低。别忘了同步接收端的软合并状态机，否则合并全是乱序。
- HARQ进程数：流水线里同时存在多个未完成的HARQ事务。太少导致发送端等响应而空闲，太多则占用大量内存。5G NR最多16个进程，我调试时发现10个左右就能喂饱100MHz带宽。
核心思想：三种机制不是互斥的。现代通信系统——比如4G/5G、Wi-Fi 6、卫星DVB-S2X——都把FEC作为底码，再在MAC层叠一层ARQ或HARQ。你的调试工具必须能同时观测这两层的状态：物理层的CRC错误、解码迭代次数、软比特范围；MAC层的重传计数、RTT、缓冲区水位。缺一个信息，误码定位就像瞎猫捉耗子。
写到这里我想起一个真实的案例：调试某国产卫星通信网关时，发现FEC纠错一直正常，ARQ却反复超时。一开始以为FEC部分没问题，后面一查才发现接收端会错误地把解码成功的包当成失败，导致双重重传。最后问题出在——软比特量化位数被协议栈误配成4位，SNR估计偏差超过3dB，判决定门直接崩溃。所以说，别以为FEC修好了就万事大吉：上层重传日志和底层解码统计必须联合分析。