<!-- title: 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 的演进，理解这条线，就能理解"软合并"是怎么一步步被发明的。

```mermaid
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=1}^{N} \text{LLR}_i
$$

信号相干叠加、噪声非相干叠加，结果就是**有效信噪比（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）+ 分集增益**。
- 形象比喻：第一次给你一道题的部分提示解不出，第二次再给你**新的、不同的提示**，而不是把旧提示再念一遍。

```mermaid
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……

```mermaid
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 是配合关系，不是重复。

```mermaid
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 的完整生命周期是这样的：

```mermaid
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 快速补救，整体容量最大。这正是"用可控的失败换取最大吞吐"的工程智慧。

---

## 参考来源

1. [5G HARQ机制详解：混合自动重传与软合并 — CSDN](https://blog.csdn.net/hhd1988/article/details/134385489) — 系统讲解 CC 与 IR 的区别与软合并流程。
2. [5G物理层 HARQ 软合并原理解析 — 知乎](https://zhuanlan.zhihu.com/p/718534563) — 从 PHY 角度解析软比特合并与 LLR 累积。
3. [混合自动重传请求 — 百度百科](https://baike.baidu.com/item/%E6%B7%B7%E5%90%88%E8%87%AA%E5%8A%A8%E9%87%8D%E4%BC%A0%E8%AF%B7%E6%B1%82/16911514) — HARQ 的 Type I/II/III 演进与基本定义。
4. [5G和LTE中的HARQ协议 — 博客园](https://www.cnblogs.com/sddai/p/10999950.html) — 同步/异步、自适应 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学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)