# 别扔草稿：HARQ软合并原理 ## 一、从听写课说起：解错了，然后呢？ 先讲一个每个人都经历过的场景。小学听写课，老师念一个长句子，你只听清了七成，剩下的靠猜。这时候你有两种选择：要么硬着头皮把猜的写上去，错了就错了；要么把没听清的位置做个记号，等老师念第二遍时，重点对齐记号处，把两遍听到的内容拼起来——第二遍念的如果是完整重复，你把两遍重叠的部分互相印证；如果第二遍干脆念的是“答案的另一半”，那拼起来就是完整的答案。 无线接收机每天都在做这道听写题。空气里的信号被噪声、衰落、干扰反复揉搓，解码器拿到的是一份伤痕累累的数据。**第一次解码失败了，这份伤痕累累的数据该怎么办？** 绝大多数协议（包括我们熟悉的TCP）的答案是：扔掉，让对方重发一份，重新再来。这个思路在有线世界完全合理——光纤里的误码率低到可以忽略，重发一次的代价就是时间。但无线世界不一样：**空口每个比特都来之不易，是能量、频谱、调度机会堆出来的，扔掉等于把已经付出的射频能量直接倒进垃圾桶。** 于是无线系统做了一个很“抠门”的设计：**解码失败的数据不扔，留着，跟重传的那一份合并起来一起解**。这套机制叫混合自动重传请求（HARQ，Hybrid ARQ）。"Hybrid"这个词指的就是它混合了两种东西：前向纠错（FEC，编码抗错）和重传（ARQ，错了再来）。而它的灵魂，全在接收机那个“不扔”的动作上。 本文要回答三个问题：为什么留着旧数据有用（软合并的数学直觉）、重传时发什么（增量冗余与冗余版本）、以及为什么网络能一边等确认一边不停工（多进程流水线）。 ## 二、为什么不扔：硬判决扔掉了最值钱的东西 要理解软合并，得先看清“扔掉”这个动作到底扔掉了什么。 接收机收到一个调制符号，比如一个16QAM星座点，落在星座图上某个位置。这个位置和标准点之间有个偏移——偏移是噪声造成的。接下来接收机要判断：这个符号代表哪几个比特？ **硬判决**的做法是“就近拍板”：看它离哪个标准点最近，直接判定为那个点，输出0和1。判断完，原始的位置信息就地销毁。 问题来了。假设某个比特被硬判成了0，但它的信号点其实落在0和1两个标准点的正中间——这不是一个“0”，这是一个“吵架中”的0。硬判决把这份犹豫全部抹掉，只留下一个斩钉截铁的0。如果重传的数据再来一遍，还是这个位置还是这个纠结，硬判决还是输出同一个0——**两份信息叠加，你得到的还是同一个错误，没有任何新东西。** **软判决**的做法完全不同：不急着拍板，先把每个比特的“证据强度”记下来。这个证据强度有个标准记法，叫对数似然比（LLR）： $$\mathrm{LLR} = \ln\frac{P(x=0 \mid y)}{P(x=1 \mid y)}$$ 其中 $y$ 是收到的信号，$x$ 是发送的比特。这个式子说白了就是回答一个问题：**“就现在收到的这个信号而言，发0的可能性是发1的多少倍？”** 取对数是为了好算——正数表示偏向0，负数表示偏向1，绝对值越大表示越笃定。LLR = +8 是“铁定是0”，LLR = -0.1 是“五五开，稍微偏1”，LLR = -6 是“八成是1”。 ```mermaid flowchart TD subgraph HD["硬判决"] A1["收到信号点"] --> B1["就近拍板"] B1 --> C1["只留0或1
犹豫丢弃"] end subgraph SD["软判决"] A2["收到信号点"] --> B2["记录置信度LLR"] B2 --> C2["不急着定案"] C2 --> D2["留给合并与译码"] end ``` 软判决保留的这份“犹豫”，正是重传合并的原材料。而且它带来一个额外红利：现代信道译码器（LDPC、Polar、卷积码的维特比译码）本来就吃软信息——给它们喂LLR而不是硬邦邦的0/1，仅此一项就能带来约2dB的编码增益。这就是为什么教科书里把“软判决译码”当作现代数字通信的标配。 ## 三、软合并：独立证词可以累加 现在回到听写课的比喻。老师念第二遍了，你怎么把两遍“拼”起来？ 数学给出一个出奇简单的答案。假设第一遍和第二遍的噪声是相互独立的（这在无线系统里基本成立，因为两次传输发生在不同的时频资源上，经历不同的衰落和干扰），那么两份观测提供的证据可以直接相加： $$\mathrm{LLR}_{合} = \mathrm{LLR}_1 + \mathrm{LLR}_2 + \cdots + \mathrm{LLR}_n$$ 直觉上这非常好懂，像一个陪审团：**每个独立证人的证词是带方向的权重，倾向0的往正方向推，倾向1的往负方向推，互相抵消的是噪声的随机摇摆，共同指向的是真实的比特值。** 一个证人拿不准的事，三个独立证人方向一致，置信度就不是三倍而是指数级增长。 用信噪比的语言描述更直观：两份相互独立的同样信号叠在一起，信号功率翻倍、噪声因为不相关只按功率平均，合并后的等效信噪比： $$\mathrm{SNR}_{合} = \mathrm{SNR}_1 + \mathrm{SNR}_2 \approx 2\,\mathrm{SNR}_1$$ 两次传输合成一次，等效信噪比翻倍，也就是**白赚3dB**。在链路预算里，3dB意味着覆盖半径明显外扩，或者等效于发射功率翻倍——而这里一分钱射频功率都没多花，只是接收机多记了一遍账。 这种“每次重传内容完全一样、接收端逐比特累加LLR”的方式，以上世纪八十年代提出它的工程师Chase命名，今天口语里常叫**Chase合并**。它简单、可靠、对缓存要求低，是软合并最朴素的形态。 ## 四、从“再念一遍”到“念另一半”：增量冗余 Chase合并赚的是信噪比，但它有个天花板：第二遍和第一遍内容一样，**没有提供任何新的编码信息**，增益上限就是功率叠加那几dB。 上世纪八十年代末，Hagenauer提出了一类“速率兼容打孔卷积码”，打开了另一扇门：编码器其实是一个“内容远超所需”的母本工厂——同样的信息比特，它可以产出包含大量校验位的完整编码，也可以按需打孔（扔掉一部分校验位）来适配信道。平时只发打孔后的“精简版”；一旦失败，**重传时发送母本里上次没发出去的那些校验比特**。接收端把新旧拼在一起，等效码率逐次降低、纠错能力逐次增强。 这就是**增量冗余（IR，Incremental Redundancy）**。回到听写课：Chase合并是“老师把原句再念一遍”，IR是“老师第一次念句子，第二次直接把关键词抄给你”。后者每一次重传都在实质性地增加纠错能力，而不只是提高音量。 三种重传思路放在一起看： | 维度 | 传统ARQ | Chase合并 | 增量冗余 | |---|---|---|---| | 失败后接收端动作 | 整包丢弃 | 保留软信息，等重复 | 保留软信息，等新校验位 | | 重传内容 | 原包重发 | 与初传完全相同 | 母本中未发过的校验比特 | | 增益来源 | 无，纯重试 | 功率叠加（两次约+3dB） | 功率叠加 + 等效码率下降 | | 软缓存开销 | 无 | 小（存一份LLR） | 大（要存整个母本对应的LLR） | | 实现复杂度 | 最低 | 低 | 高（依赖速率匹配设计） | | 典型场景 | 有线/早期系统 | 低成本终端、简单信道 | 现代宽带系统主力 | 增量冗余能落地，靠的是一个精巧的“仓库”设计：编码母本和实际发送的内容被解耦了。 ## 五、母本、循环缓冲与RV：增量冗余的仓库管理 把增量冗余想象成一个电影发行的故事。编码器产出的是**母带**——信息比特加上LDPC编码产生的大量校验比特，全长远超一次播放所需。发行方不会一次放完，而是每次从母带上剪一个**窗口**发出去： - 第一次发送（初传）：窗口对准母带开头，这一段以信息比特为主——先保证接收端“哪怕只收到这一段，也接近能解”； - 第一次重传：窗口向后挪，发的是校验比特的后半段——接收端已有的信息位不用重发，补的都是新证据； - 再重传：窗口继续挪，补齐剩余的校验比特。 **冗余版本（RV）就是“窗口从哪开始剪”的指针编号。** 母带存在一个首尾相接的循环缓冲区里，窗口从缓冲区的不同位置切入，就得到不同的RV。 ```mermaid flowchart TD A["信息比特加CRC"] --> B["LDPC编码
产出母本比特流"] B --> C["写入循环缓冲区"] C --> D["RV0窗口
系统位为主"] C --> E["RV2窗口
校验位中段"] C --> F["RV3窗口
校验位后段"] D --> G["初传"] E --> H["第一次重传"] F --> I["第二次重传"] G --> J["接收端LLR累加合并"] H --> J I --> J ``` 工程上有两个细节值得知道，它们直接影响你调试时看到的现象： **第一，重传的RV不是随便跳的。** 常见的顺序是0、2、3、1这样的固定序列——先发信息位密集的版本打底，后续重传优先补上“性价比最高”的校验段落。你在空口信令里看到一串重传的RV值跳变，背后就是这个逻辑，而不是随机数。 **第二，软合并要求“比特级对齐”。** 接收端做LLR累加时，必须知道新来的每一个比特对应母本的哪个位置——所以重传时编码母本不能换，速率匹配的行为必须完全一致，只有窗口位置（RV）可以变。这就解释了一个常见的调试困惑：**HARQ重传可以换调制方式、换RV，但不能“换个编码重新编一遍”**，否则接收端缓存的旧LLR全部作废，增量冗余直接退化成Chase合并甚至纯重传。 也正因为IR要为整个母本预留软缓存，它对终端的存储能力是个考验。成本敏感的物联网终端可能选择更省缓存的策略；宽带手机则把大软缓存当作标配，因为IR带来的吞吐增益实打实地值这个钱。 ## 六、流水线：为什么需要十几个HARQ进程 还有最后一个问题：确认和重传都要时间，这段时间信道在干嘛？ 最朴素的协议叫停等式：发一包，停下来等对端回ACK，收到了才发下一包。对讲机通话就是这样——“完毕，请回话”，对方不吭声你就干等。问题是一来一回的时间里信道完全空转。空口的往返时延是毫秒级，宽带系统每毫秒要吞吐的数据是几十上百兆比特，停等式等一个来回，容量直接腰斩再腰斩。 解法和所有流水线问题一样：**别等，并行发货，用编号区分。** 发送方同时维持多个独立的HARQ进程，每个进程管一包数据的“发送—等待—重传”生命周期。进程0发出去进等待状态时，进程1、进程2照常发送，信道一刻不停。收到NACK时，只需对指定进程号的包发起重传。 ```mermaid sequenceDiagram participant gNB participant UE Note over gNB,UE: 多进程并行，等待期不空转 gNB->>UE: 进程0 初传 gNB->>UE: 进程1 初传 UE-->>gNB: 进程0 NACK gNB->>UE: 进程2 初传 UE-->>gNB: 进程1 ACK gNB->>UE: 进程0 重传 RV2 UE-->>gNB: 进程0 ACK ``` 配套的还有一个小而关键的字段——**新数据指示（NDI）**。它只回答一个问题：这个进程号上装的是新数据，还是上次那包的重传？想象仓库管理员收到“3号货架补货”的指令，他得知道是3号货架上那箱坏货换新的，还是3号货架本来就该发新货——搞反了，接收端要么把重传当新数据（缓存里多出一份不配对的LLR），要么把新数据当重传（和八竿子打不着的旧缓存合并，全盘解错）。NDI每翻转一次，接收端就把对应进程的软缓存清空，从头开始。 一整套机制配合下来，就形成了空口数据面的心跳：初传、反馈、重传在多个进程上循环往复，链路看起来始终满负荷，而每一个包在后台都走完了自己的“发送—确认—必要时合并重传”旅程。 ## 七、现网落地：这套原理在你手上的KPI里 理解了原理，再看现网数据，很多“反直觉”的现象会突然讲得通。 **第一，初传误块率10%左右不是故障，是设计工作点。** 链路自适应把初传BLER目标定在一成附近，就是有意让HARQ有事干：MCS调得激进一点，初传偶尔失败，靠一次合并重传兜底，总吞吐反而比“保守MCS保初传”更高。所以看到小区下行的HARQ重传率在个位数到一成之间波动，先别当故障处理；**真正要警惕的是合并之后仍然失败的残留错误**——那才意味着链路质量真的恶化到自适应都追不上了。 **第二，DTX和NACK是两回事。** 理想流程里UE解不出就回NACK，但还有一种更糟的情况：UE连调度指令本身都没收到（漏检），什么都不回。发送方等不到ACK，只能按失败处理、安排重传。统计的时候如果把DTX混进NACK，你会把“下行覆盖有问题（UE听不见调度）”误诊成“合并后仍解错”，两者的优化方向完全不同。做信令分析时把ACK、NACK、DTX分开计数，是排障的基本功。 **第三，语音业务也在用HARQ，这和“实时业务不重传”不矛盾。** 说实时业务不重传，指的是RLC层为语音配置了不重传的模式——因为百毫秒级的RLC重传对语音来说太迟了，迟到的正确不如准时的错误。而物理层HARQ的重传发生在几毫秒内，远在语音的时延预算之内，所以每一帧语音照常走“初传—合并—重传”的流程，只是预算里通常只允许重传一次左右。这就是为什么语音的质量保障是“HARQ兜底+RLC放行”，而不是层层重传。 **第四，上行链路同样是这套机制，但形态不同。** 下行的反馈走上行控制信道；上行数据失败时，重传的许可通常夹在下一次的调度指令里捎带下来，而不是走一条专用的确认信道——这是两代移动宽带之间一个广为人知的设计变化，目的是让控制开销随调度灵活伸缩。另外提一句：标准允许多种实现与配置选择，具体参数行为以各厂家官方文档为准。 顺手整理一份速查表，把本文出现的机制对应到你日常看到的字段： | 参数/字段 | 它在说什么 | 排障时的看点 | |---|---|---| | HARQ进程号 | 这包数据属于流水线的哪个工位 | 进程号异常跳变可能意味着失步 | | NDI | 新包还是旧包重传 | NDI不翻转却无重传→缓存对不上 | | RV | 循环缓冲的窗口位置 | 重传RV应按序列推进，长期停在0有问题 | | HARQ-ACK | 接收端裁决结果 | 区分ACK/NACK/DTX三态 | | 软缓存 | UE能存多少待合并LLR | 终端能力项，影响IR能否全量发挥 | | 初传BLER | 链路自适应的工作点 | 个位数到10%正常，残留错误才报警 | ## 八、三个常见误解 **误解一：“重传多说明网络差。”** 恰恰相反，适度的重传是系统在激进配置下的正常呼吸。判断网络健康度的正确姿势是看“合并后仍失败的占比”和重传率的突变趋势，而不是重传的绝对量。 **误解二：“HARQ就是一种重传协议。”** 它的精髓在接收端而不在重传动作本身——没有软信息缓存和LLR合并的ARQ，就算重传一百次，每次也是从零开始。同样的重传次数，软合并的成败概率天差地别。 **误解三：“重传就是把原包再发一遍。”** 在增量冗余成为主力的今天，重传发的大概率是初传没发过的校验比特。如果你在分析重传性能时按“完整重复”建模，估出来的增益会系统性偏低。 ## 常见问题 **Q: HARQ重传和RLC层重传有什么区别？已经有两道保险，为什么都要？** A: 三点不同：层级上，HARQ在物理层与MAC层交界，RLC在它之上；粒度上，HARQ按编码比特块重传并做软合并，RLC按协议包整体重传、丢掉旧的重新收；时延上，HARQ重传在毫秒级，RLC重传要慢一个量级。分工是：HARQ用软合并吃掉绝大多数零星误码，RLC只兜HARQ都救不回来的极端情况（比如重传次数耗尽）。两道保险成本不同、速度不同，谁也不替代谁。 **Q: 初传BLER为什么定在10%而不是越低越好？** A: 把初传BLER从10%压到1%，要求更高的信噪比，意味着要么加大功率、要么调低MCS——两者都损失吞吐或覆盖。而10%的初传失败由毫秒级软合并几乎全部兜住，对上层表现为接近无损。也就是说，10%是“传输成功”这个概念被HARQ重新定义之后的最优点：链路自适应负责让初传“十拿九稳”，HARQ负责剩下的“一失”。 **Q: 重传时为什么要换RV？一直用RV0把同一段重发不行吗？** A: 一直用RV0就退化成了Chase合并——只赚功率叠加的几dB，不增加新的编码信息。换RV的目的是把母本里还没发过的校验比特补进来，让等效码率随重传次数下降。至于常见序列里跳过某些编号，是因为不同窗口里信息位与校验位的配比不同，跳到的那些位置对合并贡献小，约定俗成走性价比最高的路径。 **Q: 软合并要求两次传输噪声独立，什么情况下会被破坏？** A: 如果两次重传落在高度相关的信道状态上（比如终端静止、强反射径稳定，两次经历几乎相同的深衰落），噪声和衰落不再独立，合并增益会明显缩水。好在系统调度天然避开了这一点：重传发生在不同的时频资源上，配合跳频等机制，两次传输的信道经历通常差异足够大。 **Q: 为什么 sometimes 连续多次重传还是解不出来，系统怎么办？** A: 每个HARQ进程有最大重传次数限制。耗尽之后，这包数据在物理层宣告死亡，交由上层处理——数据业务由RLC确认模式接管重传，最终还有TCP端到端兜底；语音这类UM业务则直接丢包，靠码度和人耳的容错扛过去。所以排障时如果看到“HARQ重传次数耗尽”类事件增多，说明链路已经差到软合并都救不动，要优先查覆盖和干扰。 ## 参考来源 1. [Hybrid automatic repeat request - Wikipedia](https://en.wikipedia.org/wiki/Hybrid_automatic_repeat_request) — HARQ的总体概念、Chase合并与增量冗余两条技术路线的词条级概述 2. [Incremental redundancy - Wikipedia](https://en.wikipedia.org/wiki/Incremental_redundancy) — 增量冗余与速率兼容打孔编码的原理条目 3. [Forward error correction - Wikipedia](https://en.wikipedia.org/wiki/Forward_error_correction) — 前向纠错、软判决译码的背景知识 4. [Likelihood function - Wikipedia](https://en.wikipedia.org/wiki/Likelihood_function) — 似然函数与对数似然比的数学定义出处 5. 樊昌信、曹丽娜《通信原理》差错控制编码章节 — 软判决译码、ARQ与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 等场景全覆盖。