首页 › deep-tech › HARQ：错包不扔，攒着合并

HARQ：错包不扔，攒着合并

一、从一个生活场景说起

假设你在嘈杂的食堂里听同学口述一串电话号码。第一次没听清，你会怎么做？

最朴素的办法是：把刚才听到的全忘掉，让同学再念一遍。这叫 ARQ——错了就重传，重传之前先把旧的全丢掉。

稍微聪明一点：你已经记下了"138…中间好像有个7"，于是让同学重念，把新听到的和模糊的印象叠加起来，第二次就拼对了。这其实就是 HARQ（Hybrid ARQ，混合自动重传请求） 的核心思想——错了不扔，把"软"印象攒起来合并。

这个"不扔"二字，看似微小，却是现代移动通信（HSPA、LTE、5G NR）能在恶劣无线环境下稳定传数据的"压舱石"。本文就带你从直觉到原理，把 HARQ 彻底讲透。

二、HARQ 的身世：FEC 和 ARQ 的"混血儿"

要理解 HARQ 为什么这样设计，先得认识它的两个"父辈"。

2.1 FEC（前向纠错）：提前备好"纠错零件"

FEC（Forward Error Correction）的思路是：发送端在数据里主动掺入冗余比特（比如校验位），接收端收完后自己算一算，直接把少量错误纠正，根本不用回头发请求。

优点：单向、低时延，不用等往返反馈。
缺点：冗余是"一刀切"的。如果信道突然很好，这些冗余比特就是浪费；如果信道突然很差，又可能纠不过来。

2.2 ARQ（自动重传请求）：错了就再来一遍

ARQ（Automatic Repeat reQuest）的思路相反：发了就发一个带检错码（如 CRC）的数据包，接收端发现错了，就回一个 NACK（否定确认），让发送端重传一个全新的副本。

优点：信道好时不浪费冗余，按需重传。
缺点：重传时把上一个错包直接扔掉，相当于"前功尽弃"；而且要等一整个往返（RTT）才能补救，时延大。

2.3 为什么非要"混合"？

把两者放在一起看就明白了：

维度	FEC（前向纠错）	ARQ（自动重传）	HARQ（混合）
是否重传	不重传，靠冗余自纠	重传全新副本	重传 + 保留并合并软信息
对错包的处理	直接解码	丢弃	缓存软比特，合并
时延	低	高（等 RTT）	中（快速重传）
对信道波动的适应	差（冗余固定）	中	好（自适应冗余）
协议层位置	PHY	RLC	MAC + PHY

HARQ 的精妙之处在于：它把 FEC 的"冗余"和 ARQ 的"重传"做成了同一件事的两面。第一次发送时就带上编码冗余；解码失败时，不扔掉软信息，而是请求重传，重传来的可能是完全相同的副本（Chase Combining），也可能是另一部分冗余（增量冗余 IR）。每一次重传都在为最终解码累积"燃料"，而不是从头开始。

用一句话概括：

ARQ 是"错了重来，旧的作废"；HARQ 是"错了不扔，旧的攒着，和新的一起算"。

三、HARQ 演进的三个"型号"

HARQ 并非一开始就这么聪明，它经历了 Type I → Type II → Type III 的演进，理解这条线，就能理解"软合并"是怎么一步步被发明的。

flowchart TD
    A["HARQ Type I<br/>(基本型)"]:::t1 -->|扩展| B["HARQ Type I + 合并<br/>(Chase Combining)"]:::t2
    B -->|进化| C["HARQ Type II<br/>(增量冗余 IR)"]:::t3
    C -->|改进| D["HARQ Type III<br/>(每份都自解码)"]:::t4
    A -.- E["错了就扔,重传相同包"]:::note
    B -.- F["错了不扔,重传相同包并叠加"]
    C -.- G["重传不同的冗余,码率逐步降低"]
    D -.- H["每一份单独也能解,更鲁棒"]
    classDef t1 fill:#fde2e4,stroke:#d90429,color:#333
    classDef t2 fill:#fff3b0,stroke:#f77f00,color:#333
    classDef t3 fill:#caffbf,stroke:#386641,color:#333
    classDef t4 fill:#bde0fe,stroke:#0077b6,color:#333
    classDef note fill:#f0f0f0,stroke:#999,stroke-dasharray: 4 4,color:#666

Type I（最古老）：错包直接丢，重传一模一样的包。这其实就是"带 FEC 的 ARQ"，还没真正利用合并。
Type I + 软合并（即 Chase Combining）：错包不丢，把软比特存起来，重传相同副本后叠加信噪比。
Type II（增量冗余 IR）：重传的是不同的冗余比特，每重传一次，等效码率下降一档，相当于"动态加深"纠错能力。
Type III（部分 IR / 完全自解码）：每一份重传单独都能解出来（含系统位），即使前面某份丢了也不影响。LTE/5G 实际用的多属于这一族。

记住这条演进线的核心驱动力：从"丢错包"到"攒软信息"，从"重复劳动"到"增量贡献"。

四、最关键的发明：软比特与软合并

要真正理解 HARQ，必须跨过一道坎——软比特（soft bit / LLR）。

4.1 硬判决 vs 软判决

普通 ARQ 里，接收端对每个比特做"非黑即白"的判断：这个比特是 0 还是 1？这叫硬判决。一旦判错，这个"0"或"1"就钉死了。

但物理层解码器（如 Turbo/LDPC/Polar 译码器）真正想吃进去的，不是"0/1"，而是这个比特是 0 还是 1 的"把握有多大"——也就是对数似然比 LLR（Log-Likelihood Ratio），一个实数（可为负，可为正，绝对值越大越确定）。

$$ \text{LLR}(b) = \ln \frac{P(b=0 \mid y)}{P(b=1 \mid y)} $$

这个 LLR 就是"软比特"。它保留了比硬判决多得多的信息：不仅告诉你倾向哪个值，还告诉你有多确信。

4.2 软合并的精髓

HARQ 的精髓在于：解码失败时，不把这些软比特扔掉，而是缓存起来。重传来时，把新的软比特和缓存里的软比特逐位相加（或加权合并），再喂给译码器。

为什么相加有效？因为两次接收的噪声大致是独立的，信号是相关（相同）的：

$$ \text{LLR}{\text{comb}} = \sum_i $$}^{N} \text{LLR

信号相干叠加、噪声非相干叠加，结果就是有效信噪比（SNR）被抬高了。对于 Chase Combining，N 次相同传输后：

$$ \gamma_{\text{comb}} = \sum_{i=1}^{N} \gamma_i \;\approx\; N \cdot \bar{\gamma} $$

这就是"攒着合并"在数学上的体现——每一次重传都在为信噪比添砖加瓦，而不是从零开始。

五、两种合并方式：CC vs IR，到底差在哪

软合并具体怎么"合"，分两条技术路线。

5.1 Chase Combining（追赶合并 / CC）

重传时发送与初次传输完全相同的编码比特（同一个冗余版本 RV）。接收端把多次的软比特叠加，纯粹靠提高 SNR 来纠错。

本质增益：分集增益（diversity gain）——对抗衰落。
形象比喻：同一张模糊照片多拍几张叠在一起，越叠越清晰。

5.2 Incremental Redundancy（增量冗余 / IR）

重传时发送不同的冗余版本（RV1、RV2、RV3…）。母码率较低（冗余很足），每次只发一部分，每重传一次就往译码器里喂入新的校验比特，等效码率越来越低，纠错能力越来越强。

本质增益：编码增益（coding gain）+ 分集增益。
形象比喻：第一次给你一道题的部分提示解不出，第二次再给你新的、不同的提示，而不是把旧提示再念一遍。

flowchart LR
    subgraph CC["Chase Combining 追赶合并"]
        direction TB
        C1["发送 RV0<br/>(码率 R)"] --> C2["重传 RV0<br/>(相同)"] --> C3["重传 RV0<br/>(相同)"]
        C4["合并方式: 软比特相加<br/>SNR 累积↑<br/>码率不变"]
        C1 -.- C4
    end
    subgraph IR["Incremental Redundancy 增量冗余"]
        direction TB
        I1["发送 RV0<br/>(码率 R)"] --> I2["重传 RV1<br/>(新冗余)"] --> I3["重传 RV2<br/>(新冗余)"]
        I4["合并方式: 累积校验位<br/>等效码率↓<br/>纠错能力↑↑"]
        I1 -.- I4
    end

5.3 一张对比表说清差异

对比项	Chase Combining（CC）	Incremental Redundancy（IR）
重传内容	与初传完全相同的编码比特	不同的冗余版本
工作层面	软比特叠加（提升 SNR）	码率下降（增加校验信息）
主要增益	分集增益	编码增益 + 分集增益
等效码率	不变	随重传次数降低
接收缓冲	小（只需存软比特）	较大（需存未译出的码块）
低 SNR 性能	一般	更优
实现复杂度	低	较高
5G/LTE 中地位	作为 IR 的特例存在	主流方式（5G NR 数据信道主打）

一个关键的工程认知：在 5G NR 中，CC 其实是 IR 的一个特例——当多次重传恰好用了同一个 RV 时，IR 就退化成了 CC。NR 定义了 RV0、RV1、RV2、RV3 四个冗余版本，调度器按需挑选。

5.4 IR 为什么更聪明：码率在动态下降

假设母码码率是 1/3（每 1 个信息比特编成 3 个编码比特），但初传为了高吞吐只发其中一部分，等效码率可能是 2/3。重传时：

$$ R_{\text{eff}}(k) = \frac{K}{N_1 + N_2 + \cdots + N_k} $$

其中 $K$ 是信息比特数，$N_i$ 是第 $i$ 次传输发的编码比特数。每多一次 IR 重传，分母增大，等效码率 $R_{\text{eff}}$ 持续下降——相当于信道编码"自动加厚"。这就是 IR 的"编码增益"来源。

六、停等协议 + 多进程：怎么做到"重传不堵车"

光有合并还不够，还得解决"重传占着信道、其他数据干等"的问题。

6.1 单进程停等的尴尬

HARQ 底层用的是最简单的停等协议（Stop-and-Wait, SW-ARQ）：发一个包，停下来等 ACK/NACK，收到了再发下一个。

问题显而易见：等反馈的这一段时间，信道完全空转。无线链路一个往返（RTT）动辄几毫秒，对追求峰值速率的系统是巨大浪费。

6.2 多进程并行：流水线化解空等

解决办法很工程化：开多条独立的 HARQ"流水线"（HARQ Process），交替占用信道。进程 A 在等反馈时，信道用来发进程 B、进程 C……

sequenceDiagram
    participant UE as 手机(UE)
    participant gNB as 基站(gNB)
    Note over UE,gNB: 多个 HARQ 进程交替发送,填满空等时间
    UE->>gNB: 进程0: TB(RV0)
    Note right of gNB: 解码中...
    UE->>gNB: 进程1: TB(RV0)  (进程0还在等反馈)
    UE->>gNB: 进程2: TB(RV0)
    gNB-->>UE: 进程0: NACK
    UE->>gNB: 进程0: TB(RV1)  (重传,IR新冗余)
    gNB-->>UE: 进程1: ACK
    gNB-->>UE: 进程0: ACK  (合并后解码成功!)
    Note over UE,gNB: 看似停等,实则流水线满负荷

每个进程都有自己独立的软缓冲区，互不干扰。进程数越多，越能把"等反馈"的空隙填满，吞吐越高，但缓冲和复杂度也越大。

系统	典型 HARQ 进程数	备注
LTE FDD 下行	最多 8	同步 HARQ
LTE TDD	依上下行配比，4~15	受时隙结构约束
5G NR	最多 16	与子载波间隔、K1 时序相关

6.3 同步 vs 异步、自适应 vs 非自适应

HARQ 重传的"触发方式"还有两个维度：

同步 / 异步：同步 HARQ 中，重传发生在固定的子帧/时隙（不用额外通知进程号）；异步 HARQ 中，重传时刻灵活，需要 DCI 显式指示进程号。5G NR 上下行都用异步 HARQ，灵活性最高。
自适应 / 非自适应：自适应指重传时可以改变 MCS、频域资源；非自适应则沿用初传配置。NR 支持自适应，能针对信道变化动态调整重传参数。

七、HARQ 在协议栈里的"工位"

HARQ 不是孤立存在的，它在协议栈里有明确的"工位"，而且和上层的 ARQ 是配合关系，不是重复。

flowchart TB
    subgraph Stack["协议栈与差错控制分工"]
        direction TB
        SDAP["SDAP: QoS 流映射"]
        PDCP["PDCP: 加密/完整性保护/重排序"]
        RLC["RLC 层 —— ARQ<br/>分段重传,按序交付,保证最终无误"]:::layer
        MAC["MAC 层 —— HARQ 控制器<br/>进程管理,反馈调度"]:::hl
        PHY["PHY 层 —— 软合并执行<br/>LLR 缓存,IR/CC 合并,译码"]:::hl
        SDAP --> PDCP --> RLC --> MAC --> PHY
    end
    classDef layer fill:#fde2e4,stroke:#d90429,color:#333
    classDef hl fill:#caffbf,stroke:#386641,color:#333

记住三层分工的一句话：

MAC 层"管" HARQ（进程、调度、重传判决），PHY 层"做" HARQ（软比特缓存与合并译码），RLC 层的 ARQ 是最后的"兜底"。

HARQ（MAC/PHY）：快速、软合并、目标是把绝大部分错误在几毫秒内就地解决。
RLC AM 的 ARQ：慢一些、按段重传、目标是保证零差错——当 HARQ 把某进程重传到最大次数仍失败时，把这个"硬伤"扔给 RLC，由 RLC 在更高层重传该分段。

两者是接力关系：HARQ 是"第一道快修"，RLC ARQ 是"最后的质检"。这也是为什么 NR 控制面用 RLC AM（要可靠），而某些对时延敏感的场景会讨论"是否还需要 RLC 重传"。

八、RV 版本与"四段式"循环

5G NR 数据信道定义了四个冗余版本 RV0~RV3，对应母码打孔/速率匹配后的不同比特子集。一个典型的循环是：

传输次序	冗余版本	作用
初传	RV0	通常含完整系统位，自解码能力最强
第 1 次重传	RV2	补充冗余，IR 累积
第 2 次重传	RV3	继续累积校验位
第 3 次重传	RV1	把剩余冗余补齐

注意：NR 没有强制规定 RV 的固定循环顺序，调度器可以灵活选择，但 RV0 一般用于初传以保证首次就有强自解码能力。

每多一次 IR 重传，译码器拿到的校验信息越多，等效码率越低，越接近母码的强纠错能力——这就是"动态加深冗余"。

九、现网调试：工程师哪里会用到 HARQ 知识

理论讲完，落到现网，HARQ 是网优和研发天天打交道的东西。

9.1 初始 BLER 为什么定在 10% 左右

这是一个反直觉但极其重要的设计点：系统并不会追求"第一次就 100% 传对"。

如果要把初始误块率（BLER）压到 0%，就得用非常保守的 MCS（低阶调制 + 强编码），信道稍微好一点就浪费了大量容量。仿真和理论都表明：初始 BLER 目标定在 10% 左右时，长期吞吐率最高。

$$ \text{吞吐} \;\propto\; \frac{\text{每次传输的比特数} \times (1 - \text{BLER})}{\text{平均传输次数}} $$

少量初次失败没关系——HARQ 会用 1~2 次重传快速补救，整体反而更高效。外环链路自适应（OLLA） 就是根据实际 BLER 反馈，动态微调 MCS，把初始 BLER 维持在目标值附近。

9.2 调试时的几个黄金指标

重传率 / HARQ NACK 比例：长期偏高 → 链路质量差、MCS 偏激进、存在干扰或覆盖空洞。
平均重传次数：正常系统大多 1.x 次；接近或达到最大次数 → 接近掉话/丢包边缘。
HARQ 失败上抛 RLC 的次数：升高说明 PHY 层已经"抢救不回来"，需要关注覆盖或干扰根因。
HARQ 进程占用率：进程数耗尽会限制调度，反映在小速率受限。

9.3 常见误解与陷阱

误解一："重传说明网络很差。" 不完全对。一定比例的重传（~10%）是有意设计的，是链路自适应的一部分，恰恰说明系统在高效利用信道。
误解二："HARQ 和 ARQ 是一回事。" 不是。HARQ 在 MAC/PHY，软合并、毫秒级快修；RLC ARQ 在更高层，分段重传、保证最终零差错。两者接力。
陷阱一：忽视软缓冲区大小。 IR 性能依赖 UE 的 HARQ 软缓冲能力（maxRate 等参数）。缓冲不够时，部分码块无法缓存合并，重传增益打折，表现为高阶调制下重传仍频繁失败。
陷阱二：把同步/异步搞混。 调试 5G 时，重传不依赖固定时序，必须靠 DCI 里的 HARQ Process Number 和 NDI（新数据指示）来判断"这是新数据还是重传"。NDI 翻转=新数据，NDI 不变=重传，这是抓包分析时最基本也最容易看错的字段。
陷阱三：以为重传一定能救回来。 当信道跌得太狠，再多重传也无济于事，此时应关注是否触发切换、是否该降 MCS，而不是盯着 HARQ 计数。

十、一张图总览 HARQ 全流程

把前面的概念串起来，HARQ 的完整生命周期是这样的：

flowchart TD
    Start(["新数据块到达"]) --> Enc["信道编码+速率匹配<br/>选定 RV0"]
    Enc --> Send["发送给接收端"]
    Send --> Rx["接收,计算 LLR 软比特"]
    Rx --> Dec{"译码+CRC 校验<br/>成功?"}
    Dec -->|成功| ACK["回 ACK"]
    ACK --> Next(["清缓冲,发下一块"])
    Dec -->|失败| Cache["缓存软比特<br/>不丢弃!"]
    Cache --> NACK["回 NACK"]
    NACK --> RT{"选择重传策略"}
    RT -->|相同 RV| CC["Chase Combining<br/>软比特叠加,SNR↑"]
    RT -->|新 RV| IR["Incremental Redundancy<br/>累积校验位,码率↓"]
    CC --> Merge["与新软比特合并"]
    IR --> Merge
    Merge --> Dec2{"合并后译码<br/>成功?"}
    Dec2 -->|成功| ACK2(["回 ACK,完成"])
    Dec2 -->|失败,未达上限| NACK
    Dec2 -->|失败,达最大次数| RLC(["上抛 RLC ARQ 兜底"])

常见问题

Q1：HARQ 的"软合并"和 MIMO 里的"最大比合并"是一回事吗？ A：思想相通（都是信号相干叠加、噪声非相干叠加来抬升 SNR），但场景不同。MIMO 合并的是同一时刻多根天线收到的空间副本；HARQ 合并的是不同时刻收到的同一数据块的时间副本。Chase Combining 用的正是类似 MRC 的加权叠加。

Q2：既然 IR 比 CC 好，为什么还要保留 CC？ A：一是简单——缓冲需求小、实现成本低，适合资源受限场景；二是灵活——当信道瞬时很好、偶发一次错误时，重传相同副本（退化为 CC）就够了，没必要发新冗余。更重要的是，在 5G NR 的统一框架里，CC 本就是 IR 的特例，调度器选同一个 RV 即可，无需两套机制。

Q3：HARQ 进程数越多越好吗？ A：不一定。进程多能更好填满"等反馈"的空隙、提升吞吐，但每个进程都要独立的软缓冲，UE 缓冲能力是有限的。NR 最多 16 个进程是综合时延、吞吐和 UE 复杂度后的折中。进程数还和子载波间隔、K1 反馈时序强相关。

Q4：HARQ 失败了会怎样？数据会丢吗？ A：不会丢。HARQ 是第一道快修，达到最大重传次数仍失败时，该数据块会上抛给 RLC 层的 ARQ 机制（AM 模式下）兜底重传，RLC 再失败还有 PDCP。这种"层层兜底"的设计保证了无线传输最终的无差错交付，代价是时延增加。

Q5：为什么说初始 BLER 设成 10% 是"最优"，而不是越低越好？ A：因为吞吐是"单次携带比特数 × 成功率 ÷ 平均传输次数"的平衡。把 BLER 压到 0% 需要极保守的 MCS，单次携带的比特大幅减少，反而拖累整体吞吐；容忍 ~10% 的初始失败、用 1~2 次 HARQ 快速补救，整体容量最大。这正是"用可控的失败换取最大吞吐"的工程智慧。

参考来源

5G HARQ机制详解：混合自动重传与软合并 — CSDN — 系统讲解 CC 与 IR 的区别与软合并流程。
5G物理层 HARQ 软合并原理解析 — 知乎 — 从 PHY 角度解析软比特合并与 LLR 累积。
混合自动重传请求 — 百度百科 — HARQ 的 Type I/II/III 演进与基本定义。
5G和LTE中的HARQ协议 — 博客园 — 同步/异步、自适应 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 等场景全覆盖。

51学通信知识星球海报-扫码加入