你网购了一件瓷器，开箱发现碎了一角。你会怎么做？把整箱扔掉，让仓库再从头发一件一模一样的——大多数人不会这么干，而是把碎片留着拍照留证，等商家补发。补发的箱子里，可能是同样的一件（ chances 是碎同一个角），也可能干脆是几块补片和说明书，跟你的碎片正好拼成一个整体。
第二种的效率明显更高：你已经拿到的那部分没有浪费。无线通信里的 HARQ（Hybrid Automatic Repeat reQuest，混合自动重传请求），干的就是这件事：传错了不白传，接收失败的信息留下来，跟重传拼起来一起译码。它是空口可靠性设计中最精巧的一环，也是网优日常盯着的那几个 KPI（ACK 率、重传率）背后的原理。
这篇文章回答一个核心问题：HARQ 为什么要设计成这样？它和普通重传差在哪、软合并为什么必须留在物理层做、为什么要有 8 个“进程”在轮转、5G 又为什么把它改成了异步。
先回顾背景。信号穿过无线信道，一定会出错，第一道防线是信道编码（前向纠错，FEC）：发送端按规则多塞一些校验比特，接收端译码器像走迷宫一样把错的比特“掰”回来。上一轮聊过的 LDPC/Polar 码，就是这条防线的主力。
但 FEC 有个天生的矛盾：码率越低（冗余越多）越可靠，可频谱效率就越低。如果你为了对抗最差的信道条件，把一半的空口资源都拿去发冗余，那在信道好的时候（大多数时候），这些冗余纯属浪费。
于是有了第二道防线：ARQ（自动重传请求）。接收端发现数据不对就要求重发。朴素的想法是——平时用高码率跑，错了再说，把冗余从“常备军”改成“预备役”。
但朴素 ARQ 有两个致命伤：
第一，判决器太粗糙。接收端只能给出“对/错”的二值答案，错的帧整个扔掉重传。你花真金白银发出去的一整帧软信息，只换来一个“错误”的判决就进了垃圾桶——信息论意义上，这是巨大的浪费。
第二，反馈环路的层级太慢。如果重传交给 TCP 在端到端做，一个来回要跨越整个互联网，几十上百毫秒起步，无线链路稍差一点 TCP 窗口就崩了。语音和实时业务根本等不起。
HARQ 的设计思路，一句话就能说清：把 FEC 和 ARQ 焊在一起，把重传下沉到物理层/MAC 层，而且失败的接收结果不清空、留着跟重传合并。 FEC 管“大概率对”，HARQ 管“小概率错了的补救”，两层配合，初传就能用高码率把频谱效率拉满。
flowchart TD
A["发送端 编码器吐出低码率母码"] --> B["按RV选窗口 发出一段"]
B --> C["无线信道 有衰落有干扰"]
C --> D["接收端 存进软缓冲区"]
D --> E{"CRC校验通过吗"}
E -->|通过| F["回ACK 清空缓冲区"]
E -->|失败| G["回NACK 保留软信息"]
G --> H["发端换窗口 补发新比特"]
H --> D
F --> I["合并结果上交高层"]
HARQ 的整个流程由一个不起眼的角色驱动：CRC（循环冗余校验）。
发送端在每个传输块（TB）后面附上按多项式运算算出的校验比特；接收端用同样的规则验一遍，除得尽就“过”，除不尽就“错”。它不能纠错，只能检错——但这恰恰是重传系统需要的：一个无条件可信的判决器。
还有一个容易忽略的细节：大块数据会被切分成多个码块（CB），每个码块各自带 CRC。为什么要切？因为译码器是流水线化的硬件，一次喂进几万个比特不现实，切成千比特级的码块才能并行译码；更重要的是，每个码块独立判决后，只有错的码块才需要参与重传合并，对的码块不必陪绑。在 5G 里这个思路更进一步，可以把相邻的码块编成组（CBG），按组重传——比整块重传省流量，比逐码块重传省信令。
CRC 的另一个隐性贡献是提前终止：某个码块校验通过，它的译码器立刻停机省电；全块通过，一次传输就结束。这是仿真和实测里“HARQ 平均传输次数通常略大于 1”的物理来源。
这是 HARQ 灵魂所在。理解它只需要一个直觉：译码器吃的不是比特，是“信心程度”。
接收机对每个比特的判断，量化成一个叫 LLR（对数似然比） 的数。先别怕公式，它的含义极其直观：
$$LLR = \ln\frac{P(b=+1 \mid y)}{P(b=-1 \mid y)} = \frac{2y}{\sigma^2}$$
信道差，LLR 就小（都很犹豫）；信道好，LLR 就大（都很笃定）。译码失败的帧，并不是“全错的帧”，而往往是一堆犹豫的比特里恰好有几个错得离谱。
传统 ARQ 的做法是把这帧全扔了。软合并（soft combining）的做法是：把这份犹豫的记录留在软缓冲区里，等重传到达后，逐位把两次的 LLR 加起来：
$$LLR_{合并} = LLR_1 + LLR_2$$
直觉上，两次独立观察同一比特，证据是可以累加的：第一次微弱地偏向 1（+0.8），第二次也偏向 1（+1.6），合并后（+2.4）你就有底气了。更妙的是，如果第一次偏向 1、第二次偏向 0，加起来接近零——等于错误被对方的证据稀释了。
用信噪比的语言说，对两次独立的等功率接收做 LLR 相加，等效于：
$$SNR_{等效} = SNR_1 + SNR_2$$
两次信噪比相同时，等效信噪比翻倍，折算成 dB 就是 +3 dB。相当于你没花一分钱发射功率，白捡了 3 个 dB 的链路预算——在衰落环境里，3 dB 可能就是“不可用”和“可用”的差别。这就是软合并被称为时间分集的原因：同一个比特在两个时刻各衰落了一次，合并后把衰落“平均”掉了。
flowchart TD
A["同一比特 第一次接收"] --> B["LLR等于正0.8 弱判1"]
C["同一比特 第二次接收"] --> D["LLR等于正1.6 中等判1"]
B --> E["逐位对齐 相加"]
D --> E
E --> F["合并LLR等于正2.4"]
F --> G["等效信噪比翻倍"]
G --> H["译码走出迷宫"]
为什么这件事必须留在物理层做？因为只有物理层的解调器手里有原始的 LLR 软信息。数据一旦在 MAC 层以上变成“对的/错的”硬比特，犹豫程度这个信息就永久丢失了——上层重传只能整包重来，一分软信息都榨不出来。这就是“HARQ 下沉到物理层/MAC 层”的技术原因，不是标准制定者拍脑袋，而是软信息只在最底层存在。
软合并确定了“留着拼”的总方针，接下来的分歧是：重传到底发什么？
最直接的做法由 Chase 在上世纪提出：每次重传都与初传完全相同，接收端逐位叠 LLR 即可。上面推导的 +3 dB 就是它的典型收益。
它的优点是实现简单、接收端缓存压力小；缺点也明显——重传提供的证据和初传完全重复，你只是反复确认同一批比特，信噪比堆上去了，但码率没有变，冗余的“花样”没有增加。
IR 的思路换了个角度。既然编码器本来就能生成一个低码率的母码（比如码率 1/3，一比特信息配两比特校验），那为什么每次只发其中一段？
把母码想象成一整卷电影胶片，初传只放映其中一段窗口，重传放映另一段窗口——新窗口里是初传没发过的校验比特。接收端把所有到手的片段拼起来，相当于：
$$R^{(k)} = \frac{K}{N_1 + N_2 + \cdots + N_k}$$
其中 K 是信息比特数，$N_i$ 是第 i 次发送的比特数。每重传一次，等效码率就下降一档——你等于在“动态地、按需地”降低码率。信道差就多传几段，信道好就一段收工。这比一开始就按最差信道预留一半冗余的方案，频谱效率高得多。
那个“窗口起点”就是 RV（冗余版本，Redundancy Version）。工程上常用的推进顺序是 0 → 2 → 3 → 1。为什么第二跳跳过 1 直奔 2？因为在常用码率下，RV1 的窗口起点离 RV0 太近，重发的内容和初传大量重叠，新证据不多；RV2 的起点更远，能带来互补性最强的新校验比特。这个顺序是工程经验的结晶，不是随意的编号轮换。
| 维度 | Chase 合并 | 增量冗余 IR |
|---|---|---|
| 重传内容 | 与初传完全相同的比特 | 同一母码的不同窗口（新校验位） |
| 合并方式 | LLR 逐位叠加 | LLR 按位置对齐拼接再叠加 |
| 等效效果 | 能量累积，等效 SNR 提升 | 能量累积 + 等效码率逐次下降 |
| 接收端缓存 | 小，只需保存合并结果 | 大，需保存多次不同的软信息 |
| 高信噪比区吞吐 | 天花板较低 | 明显更优 |
| 复杂度 | 低 | 高 |
现代系统（LTE 起）两者都用：重传时由调度器在 DCI 里指示 RV，站在 IR 的框架里跑，Chase 合并相当于“每次都选同一个窗口”的特例。环境越差、重传越多，IR “每次都给新证据”的优势越明显。
HARQ 的反馈机制骨子里是停等协议（Stop-and-Wait）：发一帧，停下来，等 ACK/NACK，收到反馈再决定新传还是重传。
为什么不用连续发送？因为反馈必须及时且确定——接收端缓冲区有限，发端必须精确知道“现在该操作第几帧”。停等协议把状态机做到最简，一个进程只需要记住一份数据一份软信息。
但纯停等有个致命问题：等待反馈的时间全是空窗。LTE FDD 里这个空窗有多长？推一遍时间线：
flowchart TD
A["子帧n PDSCH到达手机"] --> B["手机译码 耗时约几毫秒"]
B --> C["子帧n+4 回ACK或NACK"]
C --> D["基站读反馈 决定新传或重传"]
D --> E["子帧n+8 进程才能复用"]
E --> F["8毫秒一轮 铺满8个进程"]
子帧 n 发数据，固定在 n+4 收反馈，处理完最早 n+8 才能轮到这个进程干下一票——一个进程一圈就是 8 毫秒。如果只有一个进程，链路每传 1 毫秒就要歇 7 毫秒，频谱效率惨不忍睹。
解法是流水线：并排摆 8 个进程轮班。进程 0 在等反馈的时候，进程 1、2、3……依次上阵。8 毫秒的空窗正好被 8 个进程填满，每个子帧都有活干，每个进程的停等逻辑又保持极简。这就是 LTE FDD 固定 8 个 HARQ 进程的由来——不是选出来的“合理值”，是 n+4 定时推导出来的必然值。TDD 因为上下行配比不同，反馈时延不固定，进程数随配置在 7 到 15 之间浮动。
| 维度 | LTE | 5G NR |
|---|---|---|
| 进程数 | FDD 固定 8，TDD 随配比 7~15 | DCI 里 4 比特进程号，最多 16 |
| 同步性 | 下行自适应；上行同步（重传时刻固定） | 上下行均可异步自适应 |
| 反馈承载 | PHICH 物理信道，格式隐式 | 无 PHICH，PUCCH/PUSCH 上显式反馈 |
| 重传定时 | 固定 n+4 / n+8 骨架 | K0/K1 按时隙可配，随调度灵活伸缩 |
| 重传粒度 | 传输块整块 | 传输块，或更细的 CBG 组 |
| RV 推进惯例 | 0→2→3→1 | 沿用 0→2→3→1 |
多进程的时序直觉看这张图——注意任意时刻只有一个进程在“等判决”，其余进程都在干活或排队：
sequenceDiagram
participant T as 发送侧
participant R as 接收侧
Note over T,R: 进程0在等反馈 进程1顶上
T->>R: 进程0 初传RV0
T->>R: 进程1 初传RV0
R-->>T: 进程0 反馈NACK
T->>R: 进程2 初传RV0
R-->>T: 进程1 反馈ACK
T->>R: 进程0 重传RV2
R-->>T: 进程0 反馈ACK
5G 把 LTE 这套骨架拆掉了三处，每一处都有明确的动机。
第一，从同步走向异步。LTE 的重传时刻写死在帧结构里，好处是简单，坏处是僵化——5G 的空口面对从 0.125 ms 到 2 ms 的多种时隙结构、波束赋形带来的调度自由，固定时刻根本塞不进去。于是 NR 把三个定时全部参数化：K0（调度指令到数据的间隔）、K1（数据到反馈的间隔）、K2（调度指令到上行数据的间隔），按需配置，调度器获得完全的灵活性。代价是控制面变复杂——手机必须老老实实解析 DCI 才知道下一次交互在什么时候、哪个进程上。
第二，进程号扩到 16。子载波间隔大了，时隙短了，但处理时延不会同比缩短，一轮“发-收-判-重传”占用的时隙数相对变多，需要更多进程填流水线。4 比特进程号给出 16 个槽位，留足余量。
第三，取消 PHICH，反馈全部显式化。LTE 的下行 HARQ 反馈走专用的 PHICH 信道，格式是隐式的（靠加扰区分 ACK/NACK 语义），省信令但难扩展；NR 干脆取消它，所有 HARQ-ACK 都在 PUCCH/PUSCH 上显式发送，还能把多个进程的反馈复用进一个码本——时隙越长、调度越密，这种“攒一批发快递回执”的方式越省开销。同理，针对大传输块的 CBG 按组重传、针对重复传输的进程号复用，都是同一个设计哲学：把重传的粒度和时机做成调度器的旋钮，而不是帧结构的死规矩。
原理讲完，说工程师真正会用到的部分。
HARQ 重传率是最灵敏的空口“体温计”。初传 BLER 的设计目标通常是 10% 附近——这是刻意的：信道质量指示（CQI）就是按“初传 BLER≈10%”反推选择的。初传留 10% 的失败率，意味着系统工作在“码率-可靠性”曲线最陡峭的区段，频谱效率被榨到极限，剩下的错误交给 HARQ 软合并低成本兜底。所以看到 DL HARQ 重传率在几个百分点到 10% 出头，多数时候是系统在正常工作，不是故障；真正的病灶信号是重传率突跳（常见于上行干扰抬升、弱覆盖、模三/波束干扰）和残余 BLER（重传几次都救不回来、最后被上层判死的比例）升高。
调试时最容易踩的三个坑：
上行方向还有一个经典现象：LTE 上行是同步 HARQ，重传时刻写死为 n+8，基站在 PHICH 上回一个 ACK 的同时其实兼任了“新数据的上行授权”，所以上行重传异常经常和调度授权问题纠缠在一起，看日志时要分清“这一笔是重传还是新传”。
最后把视野拉高。空口到互联网，其实有三层重传在同时工作，它们不是冗余设计，而是各管一段：
| 层级 | HARQ（MAC 层） | RLC AM（链路层） | TCP（端到端） |
|---|---|---|---|
| 纠错对象 | 译码失败的码块，毫秒级 | 穿透 HARQ 的残余错包，几十毫秒 | 端到端丢包，秒级 |
| 反馈节奏 | 每 slot/子帧反馈一次 | 状态报告 | 累积/选择性确认 |
| 重传方式 | 软信息合并，不算“重传”意义上的重来 | 整包重传 | 整段重传 |
| 设计目标 | 快、低时延、省功率 | 补 HARQ 的长尾 | 跨越全网兜底 |
分工的逻辑很清楚：越靠近物理层，信息越丰富、反馈越快，但覆盖范围越小。HARQ 用软合并把 99% 的错误消灭在几毫秒内；RLC AM 收拾极少数穿透的“漏网之鱼”；TCP 只对真正的端到端异常负责。越往下越便宜，越往上越昂贵——错误要在最便宜的那一层被解决，这是整个移动通信可靠性体系的总设计原则。
Q: HARQ 重传率高，是不是说明网络有问题？ A: 不一定。初传 BLER 目标本来就在 10% 附近，几个百分点的 HARQ 重传率是设计内的正常工况，且软合并几乎不损失吞吐。要看的是两个异常信号：重传率突跳（暗示干扰或弱场突现）和残余 BLER 升高（软合并都救不回来）。平稳的高重传率只消耗一点资源，斜率突变才是病灶。
Q: HARQ 和 RLC 都会重传，为什么建两套？ A: 因为时间尺度和信息类型不同。HARQ 在毫秒级用软信息合并，快且便宜，但缓冲区小、重传次数有限；RLC 在几十毫秒级用完整数据包重传，慢但可靠，负责收拾 HARQ 次数用尽仍失败的残余错误。一套管速度，一套管兜底，缺谁都会把压力推给更贵的 TCP。
Q: 初传为什么不直接做到零差错，非要留 10% 的错误？ A: 把初传 BLER 从 10% 压到 1%，付出的代价是大幅降低码率——每个好信道里的用户都要陪着最差用户一起降速。而 HARQ 的软合并恰好擅长低成本处理这 10%：重传一两次就能救回。系统按“初传求快、重传求稳”分工，总频谱效率远高于“初传求稳”。
Q: 5G 为什么放弃 LTE 那套固定时序，改成异步 HARQ？ A: LTE 的固定 n+4 时序和固定帧结构绑死，在 5G 的多子载波间隔、灵活时隙、波束赋形调度下无法适配。把 K1 等 定时做成可配置参数后，调度器能按业务（大带宽求吞吐、URLLC 求极低时延）自由安排反馈时机。异步不是技术炫技，是把死规矩换成旋钮的必然选择。
Q: 软合并为什么不能放到 TCP 层去做？ A: 软信息（LLR）只存在于物理层解调器里，数据一旦上到高层就只剩“对/错”的硬比特，犹豫程度这个最宝贵的信息已经丢失。TCP 重传只能整包重来，之前收到的部分毫无价值；HARQ 重传却能与历史残留叠加出 +3 dB 级的等效增益。位置决定能力，这就是重传必须下沉到最底层的原因。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。