企业官网建设流程全解析

干无线通信这一行，越往后越觉得一个共识是对的：5G HARQ，也就是混合自动重传请求，是整个NR链路里最容易被低估、却最容易出问题的一环。平时聊到5G物理层，很多人第一反应是OFDM、子载波间隔、大规模天线，HARQ往往被当成“错了就重传”的老机制一带而过。可真到项目现场——不管你是做基站研发、终端协议栈、网优调测还是车联网集成——你会发现HARQ几乎出现在每一次疑难问题排查里：重传率异常、ACK/NACK反馈对不上、切换后数据丢失、URLLC业务时延超预算……背后都指向HARQ设计。

这篇内容我想把5G NR HARQ协议的来龙去脉、关键参数、实际调测方法一次讲透，不铺开太多空泛概念，重点放在“为什么这么设计”和“现场怎么用”两个层面。适合三类人看：刚接触5G协议想建立体系认知的同学，在基站或终端侧写代码、做协议开发的工程师，以及做网络优化、投诉处理和行业应用集成的老手——尤其是那些刷到了“5G全网排障”“端口5G应用”“车联网调测”却发现自己对HARQ理解还不够深的同行。

1. 再聊HARQ之前，先把它在5G链路里到底干什么说清楚

1.1 从ARQ到HARQ：为什么5G非要“混合”一把

要说清楚5G HARQ，得先回到最基本的问题：无线通信为什么会需要重传。空口信道不像光纤那么稳定，衰减、干扰、阴影效应、多径衰落随时可能把一个数据块打穿。如果接收端发现数据错了，最简单粗暴的办法就是让发送端再发一次，这就是传统ARQ，自动重传请求。

ARQ有个天然问题：效率太低。以TCP/IP网络里的场景类比，相当于你给别人寄一份合同，对方收到后发现缺页了，让你把整份合同重新寄一遍，之前的半页纸信息全部作废。在时延敏感、频谱资源昂贵的无线环境里，这种“整包丢弃再重来”的方式很难接受。

HARQ的做法更聪明，它把前向纠错FEC和ARQ结合到了一起。发送端在发送数据前先做信道编码，加入冗余比特；接收端收到数据后，即使第一次解码失败，也不直接扔掉，而是把收到的软信息保存在软缓存里。等重传版本到达后，把两次接收到的信号合并起来再做一次联合解码，成功率立刻大幅提升。

5G里主要采用两类合并方式。一种是Chase合并，重传和初传使用完全相同的比特和冗余版本，接收端把多次接收的符号按软信息累加，相当于把有效信号能量叠加起来，信噪比会随重传次数提升。另一种是增量冗余IR合并，每次重传的冗余版本不同，通过多次传输拼出更完整的编码母码，等效码率不断下降，纠错能力越来越强。NR的HARQ更偏重IR方式，地空口上通过RV版本号来区分不同冗余版本。

HARQ等于先让前向纠错挡住一部分错，再利用反馈和软合并把剩余错误补救回来，这也是“混合”这个词的由来。5G业务种类比4G复杂得多：eMBB大流量、URLLC低时延、mMTC海量连接，对重传的可靠性、时延、开销要求各不相同，HARQ的设计就必须更精细。

1.2 5G HARQ在协议栈中的位置与完整流程

HARQ实体在MAC层维护，但实际的数据处理过程跨越MAC和物理层。发送端：MAC层从逻辑信道取出数据，组装成一个传输块TB，交给物理层加CRC、做信道编码、速率匹配、调制、RE映射，最后在天口上发出去。接收端：物理层解调和解码，把解码结果反馈给MAC层HARQ实体，由其判断ACK还是NACK。

一个完整流程大概是这样：gNB通过PDCCH下发DCI调度信息，终端根据DCI在对应时频资源上接收PDSCH，解调后通过PUCCH或PUSCH上报HARQ-ACK反馈。如果反馈NACK，或者gNB判断终端没有正确接收，就安排一次新传输，把同一个HARQ进程里的数据再发一遍，或者带上新的冗余版本。

这里有个关键问题：无线信道的传播时延和处理时延决定了HARQ来回一次需要时间。如果采用简单的“等-停协议”，发一个数据等一次反馈，信道利用率会非常低。HARQ之所以高效，核心在于多进程并行：协议栈同时维护多个HARQ进程，一个进程在等反馈，另外几个进程可以继续传新数据，整个传输过程像一个多线程流水线而不是单线程循环。

NR进程数比LTE多，下行和上行都支持最多16个HARQ进程，DCI里用4比特的HARQ process number字段指示具体进程号。为什么LTE下行8个进程、上行8个进程就够用，NR要扩到16个？因为NR带宽更大、帧结构更复杂，TDD上下行配比不固定，还支持mini-slot调度、多波束传输，固定数量的进程很容易被调度器排除在外。多一点进程，就多一点调度的灵活性。

2. 5G NR为什么把HARQ设计成“异步自适应”

2.1 同步与异步，自适应与非自适应该怎么理解

圈里聊HARQ，永远绕不开“同步/异步”和“自适应/非自适应”这两对概念。第一次接触的人容易懵，我用大白话解释一下。

同步HARQ：重传和初传之间有固定的时间关系。比如LTE上行，终端在子帧n发了数据，如果失败了，重传会自动排在n+8这个时刻，不需要额外调度信令。好处是省信令开销，坏处是调度器没有自由度，一旦信道变化、资源冲突、优先级调整，固定时序很可能不合适。

异步HARQ：重传时间完全由调度器决定，调度器下发DCI告诉终端“现在重传哪个进程，用哪些资源”。代价是每次重传都需要PDCCH调度信令，开销比同步大，但灵活性特别好。

自适应与非自适应，说的是重传格式能不能变。非自适应重传，沿用初传的MCS、资源块大小、发射功率，调度器不用管细节；自适应重传，每次重传的MCS、时频资源、波束、发射功率都能重新配置，适合信道快速变化的场景。

LTE时代的经典搭配是：下行异步自适应HARQ，上行同步自适应HARQ。上行之所以用同步，主要为了降低PDCCH开销，让终端按固定时序自动重传。但5G NR把上行也改成了异步自适应，这是个很重要的设计变化。

2.2 全异步自适应，NR到底图什么

NR全面转异步自适应，不是拍脑袋决定的，背后对应了5G几个根本性需求。

第一个推力是帧结构灵活。NR的子载波间隔可以是15kHz、30kHz、60kHz、120kHz，TDD上下行配比可以按小区独立配置，还支持动态TDD，上下行方向随时可能调整。如果重传时序固定绑定在哪一个slot，调度器会很痛苦。异步方案把时间决策权收回到调度器手里，想什么时候发就什么时候发，完美适配TDD的上下行动态切换。

第二个推力是大规模天线和波束管理。NR的高频段和Massive MIMO里，每次发送可能用不同波束，不同波束下的信道质量差异巨大。重传时如果强行沿用初传的波束和MCS，可能完全匹配不上当前信道。自适应重传允许调度器根据最新CSI选择更好的波束、调制方式和资源块，重传成功率会明显上升。

第三个推力是URLLC和确定性时延。工业控制、车联网这类低时延业务要求“关键数据可以随时插队发”，如果重传必须等固定时间窗，端到端时延很难下来。异步调度允许URLLC业务抢占eMBB资源，重传也能走最高优先级，低时延压得住。

同步省开销，异步换灵活——这个交换在5G场景下非常划算。因为NR的PDCCH本身设计比较强，调度信令开销可以承受，况且调度器还可以用“免调度”的配置授权传输减少一部分信令压力。

2.3 进程号、NDI和RV：DCI里几个关键字段的配合

实际看DCI格式时，HARQ相关字段就那么几个，却承载了完整的重传控制逻辑。

进程号字段用来标识当前传输属于哪个HARQ进程。一个进程同一时间只维护一个传输块的状态，进程内的初传和重传都指向同一个数据。接收端拿到DCI后，先看进程号，再结合NDI判断这是新数据还是老数据的重传。

NDI叫新数据指示器。每次调度一个新的传输块时，NDI在原有值上翻转一次；如果调度的是同一个TB的重传，NDI保持不变。接收端只要发现“进程号相同，NDI没变”，就知道是重传，把接收缓存里的旧软信息和当前收到的信号合并。

RV冗余版本决定发送的是哪种冗余比特模式。NR定义了RV0、RV1、RV2、RV3四种版本，每次传输或重传通过DCI里的RV字段通知接收端。初传通常用RV0，重传顺序可以根据算法选。增量冗余的精髓就在这里：第一次解不出来，第二次换了不同的打孔位置，合并以后能纠错的信息更多。

看一个典型的下行调度过程：gNB在slot n下发DCI，进程号=3，NDI翻转，RV=0，同时指示K0；物理层在slot n+K0传输PDSCH；终端解调后按K1的指示在某个上行时隙反馈HARQ-ACK；如果反馈NACK，gNB不一定立即重传，可能等到slot m再下发一条DCI，进程号仍是3，NDI不变，RV换成其他值。整个过程没有固定时间限制，完全由gNB的调度器决定，这就是异步自适应的真实工作方式。

3. 5G HARQ的关键机制细节与参数配置

3.1 下行HARQ时序：K0、K1与PUCCH上的ACK/NACK

下行HARQ里最让人头晕的，就是那一堆K参数。K0是DCI所在slot与PDSCH实际传输slot之间的间隔，K1是PDSCH接收结束到HARQ-ACK反馈之间间隔的slot数。RRC层会通过dl-DataToUL-ACK配置一组K1候选值，DCI里用PDSCH-to-HARQ_feedback timing indicator字段选择其中某一个作为本次反馈的K1。

举一个具体的FDD例子。假设slot nDCI下发，K0=0，PDSCH就在slot n；终端处理需要时间，如果K1配置为4，HARQ-ACK就在slot n+4的PUCCH上反馈。这个4个slot的间隔足够覆盖解调、解码、ACK反馈准备的时间。

TDD场景更复杂一点。因为反馈ACK必须在上行时隙发，如果PDSCH结束到第一个可用的上行时隙正好被下行连续占用，K1就要拉长。这也是为什么TDD小区里K1候选值往往比FDD多，调度器要结合上下行配比动态选一个能落地的反馈时刻。

反馈信道的选择也有讲究。HARQ-ACK bit数少的时候，一般用PUCCH format 0或format 1，分别对应序列选择和BPSK/QPSK调制承载1到2比特；ACK/NACK数量多了，就用PUCCH format 2，可以承载更多bit，但占用资源也更大。DCI里有一个PUCCH resource indicator字段，用于通知终端这次反馈该用哪个PUCCH资源。

还有一个概念容易被忽略：HARQ-ACK码本。半静态码本也叫Type-1码本，终端不管实际调度了多少次PDSCH，都按RRC配置的候选PDSCH时机来生成反馈bit，长度固定；动态码本也叫Type-2码本，反馈bit数与实际调度的PDSCH数量相关，通过DAI字段让终端和基站对齐。实际网络中，如果K1配置改动、下行调度次数多、CA载波数多，一旦码本理解不一致，经常会出现“基站以为终端反馈了NACK，终端却什么都没发”的错位问题，这个后面排查部分再细说。

3.2 上行HARQ：没有PHICH，全靠调度器说了算

上行HARQ的控制逻辑和下行类似，但有一个重要区别：NR没有LTE里的PHICH信道。LTE里上行重传可以用PHICH做同步反馈，NR里gNB对上行的ACK/NACK反馈并不是通过一个独立物理信道广播的，而是通过新的UL grant来隐式表达：要么调度重传（说明前一次失败），要么调度新数据（说明前一次成功）。

这种设计的含义是，上行重传必须依赖PDCCH调度。终端在没有收到新的UL grant时，不会自动盲目重传（除非配置了配置授权场景下的自动重复）。调度器完全掌控上行重传的时间、MCS、功率，比如前一次PUSCH在干扰较大的时频资源上失败了，重传可以换一个干净的资源块，从机制上就比LTE更灵活。

配置授权（CG）是NR为低时延业务提供的重要能力。gNB通过RRC预先给终端分配一套周期性上行资源，终端在满足条件时无需等PDCCH就直接发送。CG场景里HARQ状态由谁维护？Type-1 CG的HARQ进程映射规则在RRC里配置，Type-2 CG通过激活DCI启动，终端在发送时通过CG-UCI携带HARQ进程号、RV和NDI信息，gNB收到后能明确识别这是初传还是重传、属于哪个进程。

很多URLLC场景还会开启“重复传输”，也就是同一笔数据在一个配置周期里连续发K次。这不是传统意义上的HARQ重传，因为接收端不用反馈就能收到多次副本，物理层直接把多副本软合并，可靠性提升明显。它的好处是不用等HARQ RTT，时延可控；坏处是占用资源多。实际操作中经常是“重复传输+K次”和“HARQ重传”结合使用，K值大一些能满足可靠性，HARQ用于兜底最后的错误。

3.3 CBG重传：针对大传输块的高效重传方式

NR支持的最大带宽可以到400MHz，一个传输块里包含的比特非常多。如果整个TB解码失败就要整体重传，资源浪费非常明显——可能只是其中一个码块出错，却要把整包都发一遍。

CBG，码块组，就是为解决这个问题出现的。终端把TB内的多个码块分成若干个组HARQ反馈和重传都以组为单位进行。例如一个TB里分了4个CBG，接收端解码后反馈4个HARQ-ACK bit，指出哪几个CBG解错了；gNB下一次重传只调度失败的CBG，而不是整个TB。

启用CBG重传需要几个条件同时满足。RRC层要配置codeBlockGroupTransmission参数，终端能力也要上报支持CBG。下行DCI用CBGTI字段指示本次传输包含哪些CBG，上行也支持类似的基于CBG的重传。反馈bit数会明显增加，所以一旦配置了CBG，PUCCH往往用format 2承载更多bit。

我自己的实测体会是，CBG重传在业务包大、信道质量居中的场景收益最明显。比如高清视频下载、XR业务，室内外都有干扰波动，整包重传可能重传几十甚至上百KB数据，CBG重传只补几个小分组，资源效率提升很可观。但如果业务包本身很小，一个TB只有一个码块，那CBG反而没有意义，还会徒增反馈开销。实际项目里要不要开CBG，得看业务模型。

4. 实际操作里的参数调优与排障思路

4.1 从指标看HARQ：重传率、BLER与HARQ成功率

做网优或测试的，每天要看一堆HARQ相关指标，但很多人对指标之间的关系理解不深。先理清几个核心概念。

初传BLER，指的是第一次传输解错的概率。eMBB业务目标通常设在10%左右，不是说10%错了无所谓，而是调度器要用这个目标去反推MCS：BLER设得越低，MCS就必须越保守，传输速率越低。10%的误块率意味着大部分数据一次成功，少部分靠HARQ重传兜住，整体频谱效率最高。URLLC业务的BLER目标可能要到1e-5甚至更低，因为它依赖的是重传前的前向纠错能力，等待HARQ重传往往来不及。

重传率，一般指HARQ重传次数占总传输次数的比例。这个指标不是越低越好。如果重传率长期接近零，说明MCS可能过于保守，浪费了信道能力；如果重传率很高，说明MCS过于激进或者信道质量短时波动大，用户感知的时延和吞吐都会受影响。正常8%~20%的重传率范围比较常见，具体还要结合小区负载、干扰和业务类型综合判断。

HARQ成功率，关注的是终解成功率，不是初传成功率。比如一个数据块初传失败，重传两次失败，第三次成功，HARQ成功率是100%，但时延已经偏高。所以看指标时不能只盯最终成功率，要多看“HARQ失败次数”“平均重传次数”这些过程指标。如果HARQ最终失败，数据一般会交给RLC层的ARQ重传，表现为RLC重传率上升，用户侧就会感到明显的速率抖动或时延增加。

4.2 哪些物理层因素最容易拉高HARQ重传

现场遇到HARQ重传异常，不要急着找参数问题，先按物理层信道的几个维度梳理。

下行方向：最常见的是干扰突变。5G小区同频组网严重，邻区业务高峰期下行干扰突然抬升，PDSCH的SINR瞬间掉好几个dB，HARQ重传自然飙升。第二类是MCS选得过高。调度器基于CQI上报评估信道质量，但CQI本身有量化误差和上报时延，信道快速变化时MCS跟不上，初传BLER就会高于目标值。第三类是PDCCH漏检。终端没收到DCI，就不会去解PDSCH，gNB收不到ACK反馈，可能判定为NACK或DTX，触发重传。这类问题往往被误认为干扰问题，实际上需要看PDCCH的解调性能和聚合等级配置。

上行方向：比较突出的是功率受限和TA偏差。终端在小区边缘，功率抬到最大还是不够，PUSCH SINR不足，解调失败。TA偏差会导致时偏，接收端解调性能下降。还有PUSCH资源碰撞，尤其多个终端配置了相同资源时，上行干扰也会拉高重传。另外，SRS估计不准、波束赋形方向偏差，同样会反映在上行初传失败上。

移动性相关：切换过程中HARQ上下文不会从一个基站搬到另一个基站。源基站侧还没传完的数据，要么靠RLC ARQ在源侧或目标侧重传，要么靠PDCP层重排恢复。所以你会在切换事件附近看到HARQ重传率有个尖峰，这不一定是信道问题，是移动性机制本身的正常现象。顺带说一句，切换里常见的热词“T304定时器”，这是终端等待RRC重配置完成的计时器；如果切换消息迟迟不来或失败，终端会触发重建，HARQ进程全部清空，业务中断会更严重。

随机接入也与HARQ相关。特别是Msg3，终端在收到随机接入响应后通过PUSCH发送RRC建立请求或恢复请求，如果Msg3解调失败，网络不会给ACK，终端在竞争解决窗口内等不到响应就会重发preamble或走退避流程。排查接入失败时，一定要把preamble重复次数和Msg3的HARQ重传次数拉到一起看。

4.3 常见HARQ异常问题速查表

下面这份速查表是根据我过去做过的项目案例整理的，覆盖了经常遇到的几类问题。排查HARQ问题时，可以按这个思路快速定位。

排障时有一个习惯很建议养成：先看物理层啊什么，再看MAC层HARQ，最后看RLC层重传。物理层信道质量差，MAC层重传是正常反应；MAC层HARQ成功率正常，RLC却大量重传，那问题大概率出在切换、PDCP或RRC上下文，而不是空口信道。指标分层看，别被一个重传率数字带偏。

5. HARQ在协议栈与行业应用里的延伸

5.1 MAC HARQ与RLC ARQ的分工

看HARQ问题，离不开协议栈上一层。MAC层的HARQ和RLC层的ARQ，名字相似、功能各有侧重。HARQ快但覆盖范围有限，RLC ARQ慢但更可靠。两者配合起来，才能兼顾效率和完整性。

MAC HARQ处理单次传输的物理层误块，重传粒度小、时延低，在空口上就能快速修复大部分错误。但它有重传次数上限，达到上限还解不出来，这个传输块就被放弃了。这时候RLC层的ARQ登场，把数据包拿过来再重传一次。RLC重传的时延比HARQ大得多，因为要重新走一遍逻辑信道调度流程，但它能在HARQ失败的极端场景下保证数据的最终可靠性。

不同业务会对这两层做不同的取舍。eMBB业务一般允许RLC层开启AM模式，保证数据最终不丢；URLLC业务恰恰相反，为了把时延压在极低水平，可能会限制RLC重传次数或者直接关闭RLC ARQ，宁可偶发丢包交给应用层去处理，也不愿意等RLC层慢慢重传。这就是GTP协议栈设计的取舍：空口可靠性不是越高越好，而是够用就行。

现场排查有一个实用技巧：如果RLC重传率高，不要第一时间怀疑RLC参数，先查MAC层HARQ。HARQ成功率低，RLC重传大概率是被HARQ喂上来的；HARQ成功率正常但RLC重传仍高，再考虑上层参数、缓冲区配置、切换丢包这些因素。

5.2 车联网、港口5G等场景里HARQ的能力边界

车联网是5G低时延高可靠场景的代表。车和车、车和路侧的通信对时延要求极高，有的业务要求端到端时延在几毫秒到十几毫秒以内。传统HARQ的流程包含DCI调度、PDSCH传输、终端解码、反馈、再调度的完整回路，一个来回可能就占去好几毫秒。当业务时延预算本身很紧时，HARQ重传不一定来得及。行业里常用的做法，是用盲重复和更强的编码方式来降低对HARQ的依赖，或者把HARQ重传保留作为最后的兜底手段，但主传输路径尽可能一次成功。

港口5G应用是另一个典型场景，比如龙门吊远程控制、AGV调度、视频回传。这些业务大多需要“大上行带宽+低时延+高可靠”的组合，HARQ在上行方向的表现直接影响控制链路稳定性。实际调测时，重点看的就是上行HARQ重传率、PUSCH的BLER、终端发射功率余量。因为港口机械来回移动，信道遮挡变化快，重传率容易波动，调整功控参数、缩短调度周期、合理设计K1和反馈资源，都是日常优化的手段。

近年来讨论比较多的“轻量级5G”RedCap，保留了对HARQ的基本支持，但在终端复杂度上做了裁剪。RedCap终端可以通过能力上报告知网络自己的HARQ能力限制，比如并行进程数偏少、最大调制阶数受限。网络侧需要根据这些能力做适配，不能把一个只支持少量进程的终端调度得像旗舰手机那样满地开花。

聊到这儿，想再分享一个我自己的排查经验。很多人看HARQ问题喜欢一上来就调MCS、调功控，但我更建议先把“初传BLER、HARQ重传率、HARQ失败率、RLC重传率”这四层指标拉在同一个时间轴上对比，很多问题一眼就清楚。如果初传BLER正常、重传率略高，往往问题不大；如果重传率不高但HARQ失败率很高，那要警惕是软缓存不足、调度时序冲突，甚至是终端实现问题。HARQ是一个贯穿物理层与MAC层的机制，孤零零看任何一个计数，都容易得出片面的结论。下次再遇到现场报告“重传率告警”，可以先按这篇文章的思路层层剥开，大概率能少走不少弯路。