干无线通信这一行越往后越觉得一个共识是对的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发了数据如果失败了重传会自动排在n8这个时刻不需要额外调度信令。好处是省信令开销坏处是调度器没有自由度一旦信道变化、资源冲突、优先级调整固定时序很可能不合适。异步HARQ重传时间完全由调度器决定调度器下发DCI告诉终端“现在重传哪个进程用哪些资源”。代价是每次重传都需要PDCCH调度信令开销比同步大但灵活性特别好。自适应与非自适应说的是重传格式能不能变。非自适应重传沿用初传的MCS、资源块大小、发射功率调度器不用管细节自适应重传每次重传的MCS、时频资源、波束、发射功率都能重新配置适合信道快速变化的场景。LTE时代的经典搭配是下行异步自适应HARQ上行同步自适应HARQ。上行之所以用同步主要为了降低PDCCH开销让终端按固定时序自动重传。但5G NR把上行也改成了异步自适应这是个很重要的设计变化。2.2 全异步自适应NR到底图什么NR全面转异步自适应不是拍脑袋决定的背后对应了5G几个根本性需求。第一个推力是帧结构灵活。NR的子载波间隔可以是15kHz、30kHz、60kHz、120kHzTDD上下行配比可以按小区独立配置还支持动态TDD上下行方向随时可能调整。如果重传时序固定绑定在哪一个slot调度器会很痛苦。异步方案把时间决策权收回到调度器手里想什么时候发就什么时候发完美适配TDD的上下行动态切换。第二个推力是大规模天线和波束管理。NR的高频段和Massive MIMO里每次发送可能用不同波束不同波束下的信道质量差异巨大。重传时如果强行沿用初传的波束和MCS可能完全匹配不上当前信道。自适应重传允许调度器根据最新CSI选择更好的波束、调制方式和资源块重传成功率会明显上升。第三个推力是URLLC和确定性时延。工业控制、车联网这类低时延业务要求“关键数据可以随时插队发”如果重传必须等固定时间窗端到端时延很难下来。异步调度允许URLLC业务抢占eMBB资源重传也能走最高优先级低时延压得住。同步省开销异步换灵活——这个交换在5G场景下非常划算。因为NR的PDCCH本身设计比较强调度信令开销可以承受况且调度器还可以用“免调度”的配置授权传输减少一部分信令压力。2.3 进程号、NDI和RVDCI里几个关键字段的配合实际看DCI格式时HARQ相关字段就那么几个却承载了完整的重传控制逻辑。进程号字段用来标识当前传输属于哪个HARQ进程。一个进程同一时间只维护一个传输块的状态进程内的初传和重传都指向同一个数据。接收端拿到DCI后先看进程号再结合NDI判断这是新数据还是老数据的重传。NDI叫新数据指示器。每次调度一个新的传输块时NDI在原有值上翻转一次如果调度的是同一个TB的重传NDI保持不变。接收端只要发现“进程号相同NDI没变”就知道是重传把接收缓存里的旧软信息和当前收到的信号合并。RV冗余版本决定发送的是哪种冗余比特模式。NR定义了RV0、RV1、RV2、RV3四种版本每次传输或重传通过DCI里的RV字段通知接收端。初传通常用RV0重传顺序可以根据算法选。增量冗余的精髓就在这里第一次解不出来第二次换了不同的打孔位置合并以后能纠错的信息更多。看一个典型的下行调度过程gNB在slot n下发DCI进程号3NDI翻转RV0同时指示K0物理层在slot nK0传输PDSCH终端解调后按K1的指示在某个上行时隙反馈HARQ-ACK如果反馈NACKgNB不一定立即重传可能等到slot m再下发一条DCI进程号仍是3NDI不变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下发K00PDSCH就在slot n终端处理需要时间如果K1配置为4HARQ-ACK就在slot n4的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数会明显增加所以一旦配置了CBGPUCCH往往用format 2承载更多bit。我自己的实测体会是CBG重传在业务包大、信道质量居中的场景收益最明显。比如高清视频下载、XR业务室内外都有干扰波动整包重传可能重传几十甚至上百KB数据CBG重传只补几个小分组资源效率提升很可观。但如果业务包本身很小一个TB只有一个码块那CBG反而没有意义还会徒增反馈开销。实际项目里要不要开CBG得看业务模型。4. 实际操作里的参数调优与排障思路4.1 从指标看HARQ重传率、BLER与HARQ成功率做网优或测试的每天要看一堆HARQ相关指标但很多人对指标之间的关系理解不深。先理清几个核心概念。初传BLER指的是第一次传输解错的概率。eMBB业务目标通常设在10%左右不是说10%错了无所谓而是调度器要用这个目标去反推MCSBLER设得越低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瞬间掉好几个dBHARQ重传自然飙升。第二类是MCS选得过高。调度器基于CQI上报评估信道质量但CQI本身有量化误差和上报时延信道快速变化时MCS跟不上初传BLER就会高于目标值。第三类是PDCCH漏检。终端没收到DCI就不会去解PDSCHgNB收不到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问题时可以按这个思路快速定位。现象可能根因排查方法解决方向下行HARQ重传率持续偏高但下行平均SINR不差MCS调度过激进目标BLER设置不合理看CQI分布、MCS分布、初传BLER调整MCS门限、修正CQI偏置、回落目标BLER下行重传率在特定时段飙升邻区同频干扰、负载升高对比干扰底噪RTWP/NI、邻区PRB利用率调整负荷均衡、优化波束方向、设置频率选择性调度上行HARQ重传率高上行SINR耳机明显偏低终端发射功率受限、上行干扰、TA不准查看UE上行功控余量、TA值、干扰条带调整P0/alpha等功控参数、缩短TA调整周期、频选调度gNB反馈NACK但终端反馈DTXPDCCH漏检、K1配置不一致检查PDCCH聚合等级、CCE利用率、DCI盲检次数提高PDCCH功率或聚合等级、优化PDCCH资源分配HARQ-ACK码本错位反馈数据一个一个对不上半静态/动态码本配置与调度时机不匹配对比DAI计数、RRC中码本配置切换码本类型、修正K1候选、检查DCI格式配置了CBG但重传仍是整TB终端能力不支持、RRC未配置或DCI格式不支持查UE capability、RRC参数、DCI格式确认双方能力、换用支持CBG的DCI格式切换附近重传率高、RLC重传增加HARQ上下文切换中断PDCP层数据重排看切换成功率、路径切换过程优化切换参数、确保PDCP discard定时器合理排障时有一个习惯很建议养成先看物理层啊什么再看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层的机制孤零零看任何一个计数都容易得出片面的结论。下次再遇到现场报告“重传率告警”可以先按这篇文章的思路层层剥开大概率能少走不少弯路。