你有没有想过这样一个问题：无线信道那么不可靠，手机收到的数据隔三差五就是错的，网络是怎么做到让你刷视频几乎不卡顿的？答案不是“把信道修好”——衰落的物理规律改不了——而是默认每一次传输都会失败，然后设计一套精巧的机制，让失败变得有价值。这套机制就是HARQ（Hybrid Automatic Repeat Request，混合自动重传请求）。它是4G/5G物理层的"隐形功臣"，你感知不到它，但每一个下行数据包背后，它都在默默地做"三次握手甚至更多"。
本文面向有1-3年经验的工程师，从直觉到公式、从原理到现网调试，把HARQ讲透。
要理解HARQ为什么是"混合"的，得先看它的两个"亲代"各自的缺陷。
ARQ（自动重传请求）是你最熟悉的模式——它就像网购的"签收-退货"流程：
问题在哪？重传的包和上次失败的包携带的信息量一模一样，上次解不出来的部分，这次还是那副面孔。如果信道条件差，同一个包发十遍可能错十遍——你只是不断地重复“浪费”。用香农信息论的话说：重传没有带来任何新信息。
FEC（前向纠错）是另一个极端：发送前给数据加上大量冗余校验位（比如Turbo码、LDPC码，码率1/3意味着发送的比特数是原始数据的3倍），接收方即使收到一部分错误比特，也能靠这些冗余自己算出正确答案，完全不需要反馈。
问题是：好日子也得交税。信道好的时候，那些纠错位一个都用不上，却占了半个以上的信道容量。 Wikipedia上有个精辟的对比：普通ARQ只花几个百分点的容量做保护，而FEC动辄花掉一半以上容量做"保险"。
HARQ的核心思想就一句话：把ARQ的反馈信道和FEC的纠错能力杂交，让冗余"按需发送"。
flowchart LR
subgraph 两个极端
A[纯ARQ<br/>好信道:高效<br/>差信道:反复失败]
B[纯FEC<br/>差信道:坚韧<br/>好信道:带宽税重]
end
A --> C[HARQ<br/>FEC + 反馈重传<br/>冗余按需发送]
B --> C
C --> D[好信道 ≈ ARQ的吞吐<br/>差信道 ≈ FEC的可靠性]
这就是"Hybrid"的全部含义：它不是某种新编码技术，而是一种“反馈驱动的、增量式的信道编码使用策略”。
HARQ最反直觉、也最精彩的设计在这里：接收方解不出数据时，不扔，存进缓冲区（soft buffer），存的是解码前的软信息（每个比特的置信度），等重传来了拼在一起再解。
为什么合并会有效？打个比方：
你在嘈杂的酒吧里没听清朋友说的一句话。他没有原样重复第三遍，而是换了种说法把同一个意思又说了一遍，两句话对照着听，你大概率就把意思拼出来了。
工程上这叫软合并（soft combining），有两大流派：
重传发送完全相同的编码比特。接收方把两次收到的同一比特做最大比合并（MRC）——信噪比高的分量权重大、低的权重小，加权平均后解码。
直觉理解：一个比特第一次收到的“软值”是+0.6（偏向1但不太确定），重传收到的是+0.8，合并后是+1.4——置信度变强了。本质上，Chase合并相当于对每个比特注入了更多能量，等效于提高 $E_b/N_0$。Wikipedia的表述很到位：可以把每次重传看作“额外的重复编码”，通过增加接收能量来对抗噪声。
$M$ 次相同传输理想合并后，等效信噪比近似提高 $M$ 倍：
$$\left(\frac{E_b}{N_0}\right){\text{eff}} \approx M \cdot \left(\frac{E_b}{N_0}\right)$$}
以dB计，4次合并约带来 $10\lg 4 \approx 6\ \text{dB}$ 的等效增益（理想条件下）。
局限：你获得的是“同一份信息的多份拷贝”，信息量没有增加，只是更清晰了。
重传发送同一数据块的另一部分编码比特——第一次发系统位+部分校验位，重传发之前被打孔（puncturing）掉的那些校验位。每次重传，接收方手里的信息都严格增加。
直觉理解：第一次你拿到了拼图的“图案面”，重传给你的是“边角形状信息”——两批信息互补，越拼越完整。用互信息的语言说，IR译码成功条件是：
$$\sum_{j=1}^{M} I(X; Y_j) \;\geq\; H(S)$$
其中 $I(X;Y_j)$ 是第 $j$ 次传输贡献的互信息，$H(S)$ 是原始信息熵。只要累积互信息跨过门槛，译码就成功——哪怕每一次单独传输都解不出来。这是Chase合并做不到的：相同比特的重复传输，互信息收益是递减的（对数增长），而IR是近似线性累积。
早在HSDPA时代，Frenger、Parkvall、Dahlman等人的研究就表明：增量冗余几乎总是优于Chase合并，代价是接收端需要更大的软缓冲区和更复杂的控制（该结论发表于IEEE VTC 2001，被Wikipedia的HARQ词条引用）。所以现网LTE/5G默认走IR路线，Chase合并可以看作IR的一个退化特例（当循环缓冲区里选出的比特完全重合时，IR就变成了CC）。
flowchart TB
subgraph CC["Chase合并：能量叠加"]
A1["原始数据D<br/>编码比特 {b1 b2 b3 b4}"] --> A2["重传：还是 {b1 b2 b3 b4}"]
A2 --> A3["接收机：同一比特加权平均<br/>置信度↑ 信息量不变"]
end
subgraph IR["增量冗余：信息叠加"]
B1["编码器输出全部比特<br/>{b1 b2 b3 b4 b5 b6 b7 b8}"] --> B2["第1次传输：打孔后发 {b1 b2 b5 b6}"]
B2 --> B3["重传：发另一段 {b3 b4 b7 b8}"]
B3 --> B4["接收机：软缓冲区拼接<br/>信息量严格增加"]
end
| 维度 | Chase合并 | 增量冗余（IR） |
|---|---|---|
| 重传内容 | 与首传完全相同 | 首传未发过的编码比特 |
| 合并方式 | 最大比合并（MRC） | 软缓冲区比特拼装后联合译码 |
| 每次重传的信息增量 | 无（只增能量） | 有（新增校验信息） |
| 接收端复杂度 | 低 | 高（需软缓冲+打孔控制） |
| 性能 | 有增益但有限 | 几乎总是更优（VTC 2001研究结论） |
| 关系 | IR的退化特例（选到相同比特时） | LTE/NR现网默认方式 |
增量冗余怎么实现“每次发不同比特”？关键器件叫循环缓冲器（circular buffer），这是理解RV（Redundancy Version，冗余版本）的基础。
工作流程是这样的：
各次传输取出的比特窗口首尾相接、循环覆盖，最终把整个缓冲器“绕满”，就等于把编码器的全部输出发完了——再往下发就没有新信息了，这就是最大重传次数的物理上限的来源之一。
flowchart TB
subgraph 编码与速率匹配
D["信息比特 + CRC"] --> E["LDPC/Turbo 编码器<br/>输出低码率比特流（系统位+校验位）"]
E --> CB["循环缓冲器<br/>（比特按规则写入）"]
end
CB -->|"RV=0：从头取<br/>系统位优先，可自解码"| T1["第1次传输"]
CB -->|"RV=2：换起点<br/>补校验位"| T2["第2次重传"]
CB -->|"RV=3：取更深的校验区"| T3["第3次重传"]
CB -->|"RV=1：最后一段"| T4["第4次重传"]
T1 --> RX["接收端软缓冲区<br/>按RV位置拼装比特"]
T2 --> RX
T3 --> RX
T4 --> RX
RX --> DEC["联合译码 → CRC校验"]
几点工程上必须知道的细节（依据ShareTechnote对5G NR HARQ的整理）：
rv_idx字段），所以用空口抓包工具看每一次PDSCH/PUSCH，都能看到当次用的RV；HARQ的操作模式是停等（stop-and-wait）：发一包 → 等ACK/NACK → 再决定发新包还是重传。停等的优点是协议极简、反馈关系清晰；缺点也致命——干等反馈的时间里信道闲着，吞吐量全耗在等待上。
解决办法朴素而有效：开多个HARQ进程轮流干活。进程0发完数据进入等待时，进程1立刻上新数据，进程2、进程3……接连填满信道。等进程0的ACK绕回来，信道正好又轮到它。这就是流水线思想：单个进程是停等的，整条流水线是全双工的。
sequenceDiagram
participant UE as UE接收机
participant N1 as 进程0
participant N2 as 进程1
participant N3 as 进程2
Note over UE,N3: 以8个子帧往返时延(RTT)为例的流水线
T1: 进程0 发送数据块A
T2: 进程1 发送数据块B
T3: 进程2 发送数据块C
UE-->>N1: A的NACK (RTT后返回)
T4: 进程0 重传A(rv2)，进程1发D…
UE->>UE: 缓冲区中A的软信息 + 重传A → 联合译码成功
UE-->>N1: A的ACK
Note over N1: 进程0收到ACK后释放<br/>才能调度新数据
这个设计解释了几个你一定在参数表里见过的数字（来源：ShareTechnote 5G HARQ页）：
nrofHARQ-ProcessesForPDSCH，可配2/4/6/8/10/12/16，不配置时默认8）——为什么NR要更多？因为NR的子载波间隔可变、时隙长度可变，一次传输的时长弹性很大，进程数需要跟着伸缩，才能保证“等待窗口”始终被填满；一句话总结：HARQ进程数 = 用空间（缓存+编号）换时间（等待反馈的空转）。
HARQ的基本框架从HSDPA一路继承到5G NR，但NR针对灵活参数集做了大量“解固定化”改造。下表是工程视角的对比（依据ShareTechnote整理）：
| 特性 | LTE | 5G NR |
|---|---|---|
| 下行HARQ | 异步 | 异步（不变） |
| 上行HARQ | 同步（固定时序重传） | 异步（上下行均异步） |
| 进程号指示 | 仅下行DCI带HARQ进程号 | 上/下行DCI（0_0/0_1/1_0/1_1）都带进程号字段 |
| 数据→ACK时延 | FDD固定4ms（k=4），TDD查固定表 | 完全灵活：RRC配候选表（dl-DataToUL-ACK），DCI逐次指定K1值 |
| K1最大值 | 由TDD配置决定 | 可配到15个时隙 |
| 进程数 | FDD固定8个 | RRC可配，2~16个，默认8 |
| 上行PUSCH反馈 | 显式PHICH carries ACK/NACK | 无显式ACK/NACK：UE看gNB是否发NDI翻转的重传调度来判断成败 |
两个改动最值得展开：
① 上行同步→异步。 LTE上行用同步HARQ，重传时刻是死的（第n子帧失败，就在n+4重传），好处是调度器省心，坏处是无法避让TDD的上下行配比冲突，也无法根据信道变化重选资源。NR全面异步后，gNB对每一次重传的时域/频域/RV/MCS都有完全自由——代价是DCI必须显式携带HARQ进程号，否则接收端无法知道这次传输该拼到哪个缓冲区里。
② 上行反馈从“显式”变“隐式”。 NR取消了PHICH，PUSCH传完后gNB不回ACK/NACK。UE的判断逻辑是：如果收到针对同一HARQ进程的新数据调度（NDI翻转），说明gNB已成功解码；如果收到NDI不变的调度，那就是重传指令。这是典型的“用一条信令顺便捎带另一层含义”的极简设计。
理解HARQ还必须知道它“住在哪一层、和谁配合”——这决定了它和上层ARQ的分工。
flowchart TB
subgraph 发送端gNB
SDAP["SDAP/ PDCP / RLC"] --> MAC["MAC层<br/>HARQ实体：进程管理、NDI、冗余版本"]
MAC --> PHY["物理层<br/>LDPC编码 → 循环缓冲 → RV取比特 → 调制"]
end
PHY -->|"空口传输(会出错)"| PHYUE["UE物理层<br/>软缓冲区 + 合并 + 译码 + CRC"]
PHYUE -->|"ACK/NACK (PUCCH/PUSCH)"| MAC2["gNB MAC：决定重传还是新传"]
PHYUE -->|"数传成功才递交"| UPP["RLC层<br/>HARQ搞不定时由RLC AM重传兜底"]
分工逻辑非常清晰：
这种“快慢双环”结构就是“为什么不能只用HARQ”和“为什么不能只用RLC重传”的统一答案：可靠性要分层供给，时延和开销才能同时最小化。
拿到一份NR空口日志，HARQ分析三板斧：
harq_process字段，只跟踪同一个进程号的完整生命周期（ShareTechnote特别强调：分析HARQ的第一步就是按进程号过滤日志）；误解一：“HARQ重传率高 = 网络有问题。” 不对。链路自适应本来就按首传BLER≈10%做目标，正常网络里每10个包就有1个要走重传，这是特性不是故障。真正的故障信号是：IBLER（初传误块率）远超目标值，或者重传也连续失败、最终触发RLC重传甚至RLC复位。
误解二：“重传次数越多吞吐量越高。” 有限度。软缓冲区是按最大重传次数规划的，重传次数配置过大：①占用缓存导致支持的并行用户变少；②一个包反复占用HARQ进程，进程耗尽后新数据全部排队，时延雪崩。现网典型配置是数据业务2~4次重传。
误解三：“ACK/NACK丢了，数据就丢了。” 不会。UE发NACK但gNB没收到（NACK误判为ACK的极端情况除外），gNB会在若干轮之后通过DRX对齐的调度或RLC轮询发现空洞，走RLC层恢复。HARQ的定位从来不是“保证送达”，而是“低成本快速抢救大部分失败”。
调试陷阱：TDD配比与K1不匹配。 NR的K1（数据到ACK的时隙间隔）由RRC给候选表、DCI逐次指定。如果K1指向的时隙被配成了下行（DDD D U配比下K1=1可能落不到上行时隙），HARQ反馈无处安放——表现为下行吞吐量上不去、调度器大量回退。改TDD配比时，dl-DataToUL-ACK表必须同步审查。
调试陷阱：MCS虚高引发重传风暴。 CQI上报偏高（干扰突增、邻区污染）→ 调度器给出过高的MCS → 首传BLER飙升 → 重传挤占进程 → 时延放大、RLC层开始报警。排障时把“IBLER”和“MCS分布”两张图叠着看，往往一眼定位。
最后用一条主线把全文串起来——一个数据块的完整经历：
flowchart TB
S["TB到达MAC<br/>绑定进程号+NDI"] --> ENC["物理层：CRC→LDPC→循环缓冲器"]
ENC --> T1["首传RV0(系统位)"]
T1 --> D{"UE联合译码<br/>CRC通过？"}
D -->|是| ACK1["ACK → 递交上层<br/>(约90%的包到此结束)"]
D -->|否| BUF["软比特存入进程缓冲区<br/>NACK → 累积互信息I₁"]
BUF --> T2["重传RV2(新校验位)<br/>I₁+I₂ 联合译码"]
T2 --> D2{"CRC通过？"}
D2 -->|是| ACK2["ACK → 递交上层"]
D2 -->|否| T3["RV3 → RV1 依次接力<br/>直至用尽重传次数"]
T3 -->|成功| ACK3["ACK → 递交上层"]
T3 -->|彻底失败| RLC["进程释放<br/>交给RLC AM兜底重传"]
HARQ的设计哲学可以浓缩成三句话：反馈驱动冗余，按需付费；失败不丢弃，软信息是资产；快环尽力、慢环保底，可靠性分层供给。下次在日志里看到一串rv_idx=0,2,3,1的接力，你看到的就不再是枯燥的字段，而是一场“用信息增量换译码成功”的精密抢救。
Q1：HARQ重传和RLC重传到底有什么区别？ A：三个维度不同。①位置：HARQ在物理层/MAC层，RLC AM在层2上部；②粒度与周期：HARQ以毫秒级时延抢救单个TB，RLC以更长周期重传更大块；③可靠性语义：HARQ允许最终失败（尽力而为的快环），RLC AM保证最终送达（慢环兜底）。两层都失败才会表现为业务断流。
Q2：Chase合并和增量冗余，现网到底用哪个？ A：现网LTE/NR的速率匹配+循环缓冲机制天然支持IR，典型RV序列0→2→3→1就是IR；但调度器也常发RV0重复重传（等效Chase）。研究结论（VTC 2001）是IR几乎总是更优，代价是软缓冲和实现复杂度，终端能力越强越倾向纯IR。
Q3：为什么5G NR上行PUSCH没有显式的ACK/NACK？ A：设计取舍。NR取消了PHICH，用“NDI是否翻转”隐式携带成败信息：收到NDI翻转的新传调度=上行成功；收到NDI不变的重传调度=需要重传。省掉一条独立控制信道，代价是UE对成败的确认有一拍延迟。
Q4：HARQ进程数是不是配得越多越好？ A：不是。进程数只需覆盖“一个往返时延内能发多少次传输”——多了白白占软缓冲和进程管理开销，少了流水线出现空泡。NR把上限放到16并允许RRC配置（默认8），本质上是为了适配不同子载波间隔/时隙结构下的RTT弹性，而不是鼓励配满。
Q5：HARQ软缓冲区里存的到底是什么？ A：不是解码后的比特，而是解码前的软信息——每个编码比特的对数似然比（LLR，即“这个比特是1还是0的置信度”）。正因存的是带幅度的模拟置信值，重传才能做加权合并与信息增量累积；如果只存硬判结果，软合并的绝大部分增益就没了。
本文由「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 等场景全覆盖。