# HARQ原理：失败不是终点——混合自动重传与软合并的智慧 你有没有想过这样一个问题：无线信道那么不可靠，手机收到的数据隔三差五就是错的，网络是怎么做到让你刷视频几乎不卡顿的？答案不是“把信道修好”——衰落的物理规律改不了——而是**默认每一次传输都会失败，然后设计一套精巧的机制，让失败变得有价值**。这套机制就是HARQ（Hybrid Automatic Repeat Request，混合自动重传请求）。它是4G/5G物理层的"隐形功臣"，你感知不到它，但每一个下行数据包背后，它都在默默地做"三次握手甚至更多"。 本文面向有1-3年经验的工程师，从直觉到公式、从原理到现网调试，把HARQ讲透。 --- ## 一、从两个极端说起：ARQ太浪费，FEC太昂贵 要理解HARQ为什么是"混合"的，得先看它的两个"亲代"各自的缺陷。 ### 1. ARQ：确认式重传，简单但低效 ARQ（自动重传请求）是你最熟悉的模式——它就像网购的"签收-退货"流程： - 发送方发一个数据包，附带一段校验码（比如CRC）； - 接收方算一下CRC，对了就回"ACK"（确认），错了就回"NACK"（否认）； - 收到NACK，发送方就把**同一个包原样再发一遍**。 问题在哪？**重传的包和上次失败的包携带的信息量一模一样，上次解不出来的部分，这次还是那副面孔**。如果信道条件差，同一个包发十遍可能错十遍——你只是不断地重复“浪费”。用香农信息论的话说：重传没有带来任何**新信息**。 ### 2. FEC：前向纠错，可靠但"带宽税"太重 FEC（前向纠错）是另一个极端：发送前给数据加上大量冗余校验位（比如Turbo码、LDPC码，码率1/3意味着发送的比特数是原始数据的3倍），接收方即使收到一部分错误比特，也能靠这些冗余**自己算出正确答案**，完全不需要反馈。 问题是：**好日子也得交税**。信道好的时候，那些纠错位一个都用不上，却占了半个以上的信道容量。 Wikipedia上有个精辟的对比：普通ARQ只花几个百分点的容量做保护，而FEC动辄花掉一半以上容量做"保险"。 ### 3. 混血的智慧：按需付费 HARQ的核心思想就一句话：**把ARQ的反馈信道和FEC的纠错能力杂交，让冗余"按需发送"**。 - 信道好 → 一次成功，冗余位根本不用发全，吞吐量接近ARQ模式； - 信道差 → 接收方发NACK索要更多冗余，且**不丢弃失败的数据**，留着和重传合并解码，表现得像FEC一样坚韧。 ```mermaid flowchart LR subgraph 两个极端 A[纯ARQ
好信道:高效
差信道:反复失败] B[纯FEC
差信道:坚韧
好信道:带宽税重] end A --> C[HARQ
FEC + 反馈重传
冗余按需发送] B --> C C --> D[好信道 ≈ ARQ的吞吐
差信道 ≈ FEC的可靠性] ``` **这就是"Hybrid"的全部含义**：它不是某种新编码技术，而是一种“反馈驱动的、增量式的信道编码使用策略”。 --- ## 二、软合并：HARQ的灵魂——失败的数据不是垃圾，是拼图 HARQ最反直觉、也最精彩的设计在这里：**接收方解不出数据时，不扔，存进缓冲区（soft buffer），存的是解码前的软信息（每个比特的置信度），等重传来了拼在一起再解**。 为什么合并会有效？打个比方： > 你在嘈杂的酒吧里没听清朋友说的一句话。他没有原样重复第三遍，而是**换了种说法把同一个意思又说了一遍**，两句话对照着听，你大概率就把意思拼出来了。 工程上这叫**软合并（soft combining）**，有两大流派： ### 1. Chase合并（Chase 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)_{\text{单次}}$$ 以dB计，4次合并约带来 $10\lg 4 \approx 6\ \text{dB}$ 的等效增益（理想条件下）。 **局限**：你获得的是“同一份信息的多份拷贝”，信息量没有增加，只是更清晰了。 ### 2. 增量冗余（Incremental Redundancy，IR）：信息叠加 重传发送**同一数据块的另一部分编码比特**——第一次发系统位+部分校验位，重传发之前被打孔（puncturing）掉的那些校验位。每次重传，接收方手里的信息都**严格增加**。 直觉理解：第一次你拿到了拼图的“图案面”，重传给你的是“边角形状信息”——两批信息互补，越拼越完整。用互信息的语言说，IR译码成功条件是： $$\sum_{j=1}^{M} I(X; Y_j) \;\geq\; H(S)$$ 其中 $I(X;Y_j)$ 是第 $j$ 次传输贡献的互信息，$H(S)$ 是原始信息熵。**只要累积互信息跨过门槛，译码就成功**——哪怕每一次单独传输都解不出来。这是Chase合并做不到的：相同比特的重复传输，互信息收益是递减的（对数增长），而IR是近似线性累积。 ### 3. 哪个更好？ 早在HSDPA时代，Frenger、Parkvall、Dahlman等人的研究就表明：**增量冗余几乎总是优于Chase合并，代价是接收端需要更大的软缓冲区和更复杂的控制**（该结论发表于IEEE VTC 2001，被Wikipedia的HARQ词条引用）。所以现网LTE/5G默认走IR路线，Chase合并可以看作IR的一个退化特例（当循环缓冲区里选出的比特完全重合时，IR就变成了CC）。 ```mermaid flowchart TB subgraph CC["Chase合并：能量叠加"] A1["原始数据D
编码比特 {b1 b2 b3 b4}"] --> A2["重传：还是 {b1 b2 b3 b4}"] A2 --> A3["接收机：同一比特加权平均
置信度↑ 信息量不变"] end subgraph IR["增量冗余：信息叠加"] B1["编码器输出全部比特
{b1 b2 b3 b4 b5 b6 b7 b8}"] --> B2["第1次传输：打孔后发 {b1 b2 b5 b6}"] B2 --> B3["重传：发另一段 {b3 b4 b7 b8}"] B3 --> B4["接收机：软缓冲区拼接
信息量严格增加"] end ``` | 维度 | Chase合并 | 增量冗余（IR） | |---|---|---| | 重传内容 | 与首传完全相同 | 首传未发过的编码比特 | | 合并方式 | 最大比合并（MRC） | 软缓冲区比特拼装后联合译码 | | 每次重传的信息增量 | 无（只增能量） | 有（新增校验信息） | | 接收端复杂度 | 低 | 高（需软缓冲+打孔控制） | | 性能 | 有增益但有限 | 几乎总是更优（VTC 2001研究结论） | | 关系 | IR的退化特例（选到相同比特时） | LTE/NR现网默认方式 | --- ## 三、冗余版本（RV）：循环缓冲器上的“取数窗口” 增量冗余怎么实现“每次发不同比特”？关键器件叫**循环缓冲器（circular buffer）**，这是理解RV（Redundancy Version，冗余版本）的基础。 工作流程是这样的： 1. 数据块加CRC后，送入信道编码器（LTE用Turbo码，5G NR用LDPC码）——**编码器输出的是完整的、码率很低的比特流**（大量校验位）； 2. 这些比特按特定规则写进一个循环缓冲器； 3. 发送时，根据**RV值决定从缓冲器的哪个位置开始读**，读够本次传输需要的比特数为止； 4. 换一个RV，就换一个起点——自然就发送了不同的比特子集。 各次传输取出的比特窗口首尾相接、循环覆盖，最终把整个缓冲器“绕满”，就等于把编码器的全部输出发完了——**再往下发就没有新信息了，这就是最大重传次数的物理上限的来源之一**。 ```mermaid flowchart TB subgraph 编码与速率匹配 D["信息比特 + CRC"] --> E["LDPC/Turbo 编码器
输出低码率比特流（系统位+校验位）"] E --> CB["循环缓冲器
（比特按规则写入）"] end CB -->|"RV=0：从头取
系统位优先，可自解码"| T1["第1次传输"] CB -->|"RV=2：换起点
补校验位"| T2["第2次重传"] CB -->|"RV=3：取更深的校验区"| T3["第3次重传"] CB -->|"RV=1：最后一段"| T4["第4次重传"] T1 --> RX["接收端软缓冲区
按RV位置拼装比特"] T2 --> RX T3 --> RX T4 --> RX RX --> DEC["联合译码 → CRC校验"] ``` 几点工程上必须知道的细节（依据ShareTechnote对5G NR HARQ的整理）： - **RV值由调度DCI显式携带**（如DCI 1_1中的`rv_idx`字段），所以用空口抓包工具看每一次PDSCH/PUSCH，都能看到当次用的RV； - **典型RV序列是 0 → 2 → 3 → 1**：首次传输用RV0（包含系统位，保证单独可解码），后续重传依次取不同区段；现网也常见 0→0→0… 的重复（即Chase式重传）或调度器自定义序列； - RV的取值起点在物理层规范里以表格形式规定（对LDPC码，规范给出了4个RV在循环缓冲器中的起始位置比例）； - **RV0必须可自解码**：如果首传不含完整的系统位，信道好时反而无法一次成功，吞吐量就崩了。这是“冗余设计要向低时延低头”的典型案例。 --- ## 四、停等协议与多进程并行：为什么是8个、16个进程？ HARQ的操作模式是**停等（stop-and-wait）**：发一包 → 等ACK/NACK → 再决定发新包还是重传。停等的优点是协议极简、反馈关系清晰；缺点也致命——**干等反馈的时间里信道闲着，吞吐量全耗在等待上**。 解决办法朴素而有效：**开多个HARQ进程轮流干活**。进程0发完数据进入等待时，进程1立刻上新数据，进程2、进程3……接连填满信道。等进程0的ACK绕回来，信道正好又轮到它。这就是流水线思想：单个进程是停等的，整条流水线是全双工的。 ```text 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后释放
才能调度新数据 ``` 这个设计解释了几个你一定在参数表里见过的数字（来源：ShareTechnote 5G HARQ页）： - **LTE FDD固定8个HARQ进程**——8毫秒的往返时延（RTT）被8个进程精确填满，时序由规范表格写死； - **5G NR最多16个进程，且数量可由RRC配置**（`nrofHARQ-ProcessesForPDSCH`，可配2/4/6/8/10/12/16，不配置时默认8）——为什么NR要更多？因为NR的子载波间隔可变、时隙长度可变，一次传输的时长弹性很大，进程数需要跟着伸缩，才能保证“等待窗口”始终被填满； - **每个进程独立维护自己的软缓冲区**——这就是“软缓冲区大小”成为UE能力参数的原因：缓冲区越大，能支持的IR重传次数越多、码率可以越低。 一句话总结：**HARQ进程数 = 用空间（缓存+编号）换时间（等待反馈的空转）**。 --- ## 五、LTE与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在协议栈中的位置：快车道上的最后一道防线 理解HARQ还必须知道它“住在哪一层、和谁配合”——这决定了它和上层ARQ的分工。 ```mermaid flowchart TB subgraph 发送端gNB SDAP["SDAP/ PDCP / RLC"] --> MAC["MAC层
HARQ实体：进程管理、NDI、冗余版本"] MAC --> PHY["物理层
LDPC编码 → 循环缓冲 → RV取比特 → 调制"] end PHY -->|"空口传输(会出错)"| PHYUE["UE物理层
软缓冲区 + 合并 + 译码 + CRC"] PHYUE -->|"ACK/NACK (PUCCH/PUSCH)"| MAC2["gNB MAC：决定重传还是新传"] PHYUE -->|"数传成功才递交"| UPP["RLC层
HARQ搞不定时由RLC AM重传兜底"] ``` 分工逻辑非常清晰： - **HARQ（物理层/MAC层）**：毫秒级、高频次、允许少量失败。目标是把初始误块率控制在**10%左右**——注意，这不是质量差，而是链路自适应刻意选的甜点：MCS按“首传10%失败率”标定，失败的部分由HARQ以极低时延补回，整体吞吐量反而比保守的MCS更高； - **RLC AM重传（层2）**：HARQ用尽重传次数仍失败的包，或ACK/NACK本身丢失导致的“漏网之鱼”，由RLC的轮询+状态报告机制在更长的周期上兜底重传。RLC重传单位更大、周期更长，但保证最终可靠； - **PDCP/上层**：对可靠性已经无感知，只管加密、头压缩和按序递交。 这种“快慢双环”结构就是“为什么不能只用HARQ”和“为什么不能只用RLC重传”的统一答案：**可靠性要分层供给，时延和开销才能同时最小化**。 --- ## 七、现网实战：调试中你一定会遇到的HARQ问题 ### 1. 用QXDM/QCAT或空口抓包看什么？ 拿到一份NR空口日志，HARQ分析三板斧： - **锁定HARQ进程号**：在DCI（1_1/0_1等）中找到`harq_process`字段，**只跟踪同一个进程号的完整生命周期**（ShareTechnote特别强调：分析HARQ的第一步就是按进程号过滤日志）； - **看NDI翻转**：同一进程号下NDI从0→1表示新数据，NDI不变是重传。上行吞吐量异常时，第一件事就是查“NDI是不是长时间没翻转”——那意味着某个包一直在重传失败； - **看RV序列**：首传应为RV0。如果你看到首传就是RV2/RV3，要么是日志解析错位，要么是调度器配置问题——**RV0不可自解码会让好信道用户莫名其妙地低速**。 ### 2. 常见误解与陷阱 **误解一：“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分布”两张图叠着看，往往一眼定位。 --- ## 八、把原理串起来：一次完整的HARQ人生 最后用一条主线把全文串起来——**一个数据块的完整经历**： 1. PDCP/RLC递下来一个TB块，MAC给它绑一个HARQ进程号和NDI； 2. 物理层加CRC → LDPC编码 → 全部比特写入循环缓冲器； 3. DCI指定RV0，从缓冲器头部取出系统位+部分校验位，调制发送（第1次传输）； 4. UE译码：CRC通过 → 回ACK，数据上交，皆大欢喜（现网约90%的包到此结束）； 5. CRC失败 → 软比特**存入该进程的软缓冲区**，回NACK； 6. gNB收到NACK，NDI不翻转，调度RV2重传；UE把新收到的比特按RV位置拼进软缓冲区，**累积互信息+1**，联合译码； 7. 若仍失败，RV3、RV1依次接力；跨过 $\sum I_j \geq H(S)$ 门槛的那一刻，译码成功，回ACK； 8. 若全部用尽仍失败，缓冲区清空、进程释放，这个TB由**RLC AM**在更长的周期上重传兜底。 ```mermaid flowchart TB S["TB到达MAC
绑定进程号+NDI"] --> ENC["物理层：CRC→LDPC→循环缓冲器"] ENC --> T1["首传RV0(系统位)"] T1 --> D{"UE联合译码
CRC通过？"} D -->|是| ACK1["ACK → 递交上层
(约90%的包到此结束)"] D -->|否| BUF["软比特存入进程缓冲区
NACK → 累积互信息I₁"] BUF --> T2["重传RV2(新校验位)
I₁+I₂ 联合译码"] T2 --> D2{"CRC通过？"} D2 -->|是| ACK2["ACK → 递交上层"] D2 -->|否| T3["RV3 → RV1 依次接力
直至用尽重传次数"] T3 -->|成功| ACK3["ACK → 递交上层"] T3 -->|彻底失败| RLC["进程释放
交给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的置信度”）。正因存的是带幅度的模拟置信值，重传才能做加权合并与信息增量累积；如果只存硬判结果，软合并的绝大部分增益就没了。 --- ## 参考来源 2. [5G/NR - HARQ | ShareTechnote](https://www.sharetechnote.com/html/5G/5G_HARQ.html) — 5G NR HARQ工程细节：K1灵活时序、进程数配置（默认8/最大16）、RV与循环缓冲、上下行异步化、PUSCH无显式ACK/NACK，附Amarisoft空口日志实例 3. [Frenger, Parkvall, Dahlman: Performance comparison of HARQ with Chase combining and incremental redundancy for HSDPA (IEEE VTC 2001 Fall)](https://doi.org/10.1109/VTC.2001.956516) — 增量冗余几乎总是优于Chase合并的经典研究结论 4. Dahlman, Parkvall, Sköld等《3G Evolution: HSPA and LTE for Mobile Broadband》（第2版，第119-123页） — HARQ软合并与多进程设计的经典教材表述 --- > 本文由「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 等场景全覆盖。