如果你做5G协议或无线链路性能优化一定绕不过“重传协议”这四个字。5G基站和手机之间的无线信道是出了名的不稳定信号衰减、干扰、移动多径随随便便就能让一包数据在空口上出错。这时候如果没有一套快速、省资源、又能兜底的数据重传机制视频通话会花屏、自动驾驶的传感器数据会延迟甚至网页打开都卡到怀疑人生。本章聊的重传协议就是负责把这些“失而复得”的数据救回来的底层机制。具体来说MAC层的HARQ和RLC层的ARQ构成了5G双层重传架构。这套架构既要做“快速试错”——错了马上重发又要做“精准补漏”——真正丢了的东西才重发。适合刚接触5G无线接入网的协议开发、基站物理层算法工程师、网络优化和测试人员参考也适合想读懂5G空口核心技术的学生。1. 重传协议在5G里的定位为什么无线通信离不开“再来一次”1.1 无线信道的“不靠谱”是重传存在的根本原因无线通信和有线通信最大的区别就是“信道会变”。光纤里0和1传过去基本不会错但空口上同一部手机从基站附近移动到远处又或者旁边突然多了一辆卡车挡住信号信噪比可能几毫秒内掉了几十个dB。发送端明明用了很好的调制方式接收端解调出来却是一堆错比特。有人会问那直接把调制阶数降低、控制编码冗余加大让信号抗干扰能力变强不就行了理论上可以但无线资源的频谱很贵如果真的把每个用户都配成最高冗余、最低阶的调制方式频谱效率会低到无法接受。所以5G采取的是“以快制变”的思路先让调制编码方式在一个相对激进的状态下跑传输块出错以后依靠重传机制把数据补回来并且利用接收端的软信息把多次传输的能量合并起来。也就是说重传不是单纯的“再发一次”而是每一次重传都在为最终正确译码贡献力量。无线信道的这种时变特性决定了重传协议必须分成两种节奏。一种负责“快速恢复”一种负责“最终可靠”。快速恢复就是HARQ它工作在MAC层往返时延短、开销小最终可靠是RLC层的ARQ它工作在HARQ没救回来的那些数据包里补最后一个漏。1.2 5G重传的双层架构MAC层的HARQ加上RLC层的ARQ5G的用户面协议栈从上到下大概是SDAP、PDCP、RLC、MAC和PHY。重传主要发生在MAC和RLC这两层各有各的分工。MAC层的HARQ用的是“多进程停等协议”。所谓停等就是发完一个包必须等反馈再说如果只有一个进程数据一等就是整个来回时延吞吐太低。于是协议把收发的流程拆成多个HARQ进程并行跑比如下行最多16个进程每个进程独立管理自己的传输、反馈和重传。一个进程正等着反馈别的进程照常发新数据这样整条链路不会被单个包的等待卡死。RLC层的ARQ则工作在确认模式AM下。它不关心物理层到底怎么调制而是按序列号SN管理用户数据。接收侧发现自己漏了某个序列号的数据就会通过状态报告告诉发送侧“你缺了某个包”发送侧再把缺失的PDU重发一遍。HARQ没成功递交给RLC的包ARQ可以继续补但RLC不会对每一个包都发起重传因为很多包已经被HARQ救回来了。这层架构有点像一个公司里的“客户服务”和“流程审批”。HARQ是一线的响应中心出问题马上处理速度快但只管眼前ARQ是后端的复核流程虽然慢一些但看到流程卡住了会再走一遍。两层配合既保证时延不过分拉长又保证数据不重不漏地向上层递交。1.3 和LTE相比5G重传协议到底改了什么如果从LTE切换过来最直观的感觉是5G的HARQ反馈更灵活了。LTE的HARQ时序基本是固定的反馈以前紧跟传输时刻算但5G中反馈时序可以由网络侧在调度时动态指定这一改动让基站可以更灵活地安排上下行资源。另外5G的HARQ重传在调度粒度上也做了演进。新空口允许在同一传输块里面把多个码块分成码块组CBG来反馈和重传。大包出错时不再需要整包重传而是只重传出错的CBG这在大带宽高吞吐场景下能省下大量空口资源。还有一点容易被忽略5G删除了LTE沿用多年的PHICH信道。LTE的上行HARQ反馈是在PHICH上以简单比特形式发出来的5G把上行HARQ反馈放进DCI调度信息里。也就是说基站需要重配置资源来准备反馈这让上行HARQ变得更灵活也让网络侧对上行重传的调度能力更强。代价是网络侧调度器必须维护更精细的HARQ状态算法上也要花更多功夫。2. HARQ5G低时延的功臣也是参数最敏感的家伙2.1 HARQ的基本工作过程一次传输怎么被“抢救”回来一个普通的HARQ过程可以这样看。基站调度某个HARQ进程发送一个传输块接收端对物理层译码结果做CRC校验。如果校验通过接收端向发送端反馈ACK如果没通过反馈NACK。发送端收到NACK后在同一个HARQ进程上把该传输块的重传版本再发一次。接收端不会把重传的包当成一个全新的包来处理。它会先把本次重传的软比特和之前缓存的软比特做合并重新算一遍对数似然比再交给信道译码器。正因为这个“软合并”的存在HARQ重传哪怕发的是完全一样的比特也会因为能量叠加而提高译码成功率。这是HARQ相较于简单ARQ最本质的优势。实际调度中一个HARQ进程从第一次发送到收到反馈之间存在一个往返时延。这个时延由上下行资源间隔、 Processing time、反馈信道时机等决定。5G中典型的下行HARQ RTT在用户面要算上物理层处理时间所以HARQ进程开多了能提高并行度开少了就会让调度器“无进程可用”造成吞吐空洞。2.2 软合并的两种玩法追逐合并与增量冗余软合并有两种经典方案。第一种叫追逐合并简单说是重传时把原始编码比特原样再发一遍。接收端把两次接收到的相同比特做加权平均等效于提高这些比特的接收信噪比。第二种叫增量冗余重传时不发原样的比特而是发同一传输块前几次没发过的校验比特。每多收一个版本接收端就多拿到一批新的冗余信息等效码率越来越低译码能力越来越强。5G里HARQ的重传版本由冗余版本rvid控制通常是0、2、3、1轮转。基站调度器在发送新数据时一般选rvid0重传时按当前HARQ进程的重传计数选择接下来的冗余版本。增量冗余在信道极差或首次传输几乎完全不可用时作用很明显因为新校验比特带来的信息增益远大于把同一份噪声平均一下。我在实际外场测试中常遇到一种情况信道一般差的时候追逐合并和增量冗余差别不显著但随着误码上升到高负载干扰场景增量冗余的优势就出来了。干扰不是恒定不变的重传间隔里信道可能已经变了这时多收一批校验比特远比重复收同一份比特有用。2.3 5G HARQ的关键参数和配置思路协议上影响HARQ行为的主要有HARQ进程数、反馈时序、最大重传次数和CBG配置。下行HARQ进程数高层配置最多16个。如果业务时延要求高、调度器能力充足尽量把进程数配到较大值避免调度器因为在等反馈而歇着。上行HARQ进程数同样是高层配置最多16个。上行调度更依赖终端的处理能力所以终端能力上报里会有关于HARQ进程支持的字段。HARQ反馈时序下行数据的反馈时机由基站通过DCI中的PDSCH-to-HARQ反馈时序指示不同的时隙偏移对应不同的反馈时延。最大重传次数maxHARQ-TxMAC层控制消息里配置。配置过高会挤占新数据传输资源配置过低则可能导致高误码场景下数据频繁交给RLC甚至因为RLC重传不及时而影响业务层时延。从调度器视角看还要关注“同步/异步”和“自适应/非自适应”两组特性。异步HARQ指重传可以发生在任意时刻调度器可以自由分配资源同步HARQ指重传必须发生在特定时间。自适应重传允许调制编码方式和资源块分配在每次重传时重新配置非自适应则必须沿用首次传输的配置。5G几乎全部采用异步自适应HARQ这样调度器灵活性最大也最能适配多变的多用户调度场景。2.4 CBG传输把大传输块拆开重传省的不是一点半点5G一个很大的演进是CBGCode Block Group级的HARQ反馈和重传。一个传输块由若干码块组成以前是一整包纠错错一个比特就把整个传输块重发。到了高带宽、高MCS的场景一个传输块可能大得离谱重传整个包消耗的资源很浪费。CBG传输把传输块按一定规则分成多个码块组每个码块组在反馈时都有独立的HARQ确认位。基站收到某个CBG的NACK后可以只重传这个CBG。重传的资源大小也比整个传输块小得多终端侧把重传的CBG对应的软比特和之前缓存的合并最终把这一传输块完整解码出来。启用CBG需要网络侧和终端侧都支持高层配置里需要打开CBG相关能力并约定一个传输块最多分多少个CBG。调度器还需要维护每个CBG的收发状态不像以前只维护整个传输块的状态。复杂度确实上来了但在大包业务、下行高速率传输时收益非常明显。在某跨平台系统的验证测试中大包重传场景开启了CBG之后同样的信道质量下重传资源开销可以显著下降。3. RLC层的ARQHARQ兜不住的那部分靠它来兜底3.1 RLC的三种模式TM、UM、AMRLC层的传输模式比较好理解。透明模式TM不增加任何RLC头数据不进行分段或重组大多用于信令广播或特定的控制面流程。非确认模式UM支持分段重组但不提供重传常用于对时延要求高但对丢包容忍度高的业务比如VoNR的语音包。确认模式AM就是ARQ所在的模式支持分段、重组、重传和重复包检测。AM模式之所以重要是因为它通过状态反馈保证对等RLC实体之间的数据交付。对QoS要求高的业务通常承载在AM模式上。RLC ARQ工作得怎么样直接决定了TCP层看到的丢包率和时延抖动。也就是说哪怕HARQ把绝大多数物理层错误都处理了少数漏网之鱼如果RLC重传不及时上层依然会把它们当成网络拥塞丢包触发TCP降速。3.2 状态报告与重传触发机制AM模式的RLC发送侧会维护已发送但未确认的PDU集合。接收侧发现序列号不连续时会根据自身接收窗口生成状态报告。状态报告里面用ACK和NACK位图告诉发送侧哪些PDU收到了、哪些PDU缺失。发送侧收到状态报告后会重传被NACK的PDU同时清除已经确认的PDU。状态报告什么时候触发协议给了很多触发条件比如接收到带轮询标志的数据、自身发送缓冲的轮询阈值达到触发点、定时器超时等。实际工程里轮询配置对重传延迟影响很大。如果把轮询阈值配得太大可能很久都没法发现丢失配得太小状态报告频繁上报空口开销又变大。还值得提一句RLC的重传不是收到一个NACK就马上无条件重发。发送侧也需要检查自己的窗口状态和发送机会。有些情况下为了减少重传次数系统会等一段时间再重发这可以防止HARQ重传还在进行时RLC就“抢先”重发同样的数据导致上层出现重复包或时延增加。3.3 RLC重传的超时与窗口RLC AM还有一个重要的参数叫“最大重传次数阈值”maxRetxThreshold。如果同一个RLC PDU被状态报告NACK的次数超过这个阈值RLC会触发重建或失败最终可能导致无线链路失败。这个参数的设置需要在稳定性和时延之间取平衡。还有一个概念是“轮询重传定时器”比如t-PollRetransmission。如果发送侧发了轮询之后很长时间没有等到状态报告就会重发轮询或触发其他机制。这个定时器设置太大会让链路错误暴露得慢太小又会在空口正常延迟下反复触发多余轮询。对于窗口RLC AM用发送窗口和接收窗口做流量控制。如果接收侧缓存满或者状态报告没有正常反馈发送窗口会停止推进流量控制机制自然限速。这里很容易碰到一种奇怪的“假拥塞”现象无线信道本来很好但因为RLC窗口停滞TCP吞吐率上不去。排查时往往要到RLC层看窗口状态而不是急着看底层的信号质量。3.4 分段与重组重传里的一个隐藏难点RLC在重传中还有一个经常被忽略的细节分段。首次传输时RLC可能把上层一个很大的PDCP PDU切成多个RLC PDU来适配调度资源。但重传时可调度的传输资源大小可能变小了原来的一个RLC PDU无法整个装进新的传输块。于是RLC协议允许对需要重传的PDU再次分段生成RLC子段。接收侧需要处理这种“重传子段”的重组。这个机制保证了调度灵活性但也在接收端引入了重缓存的复杂度。实现时要特别小心子段的边界判定和重组顺序否则会出现收到若干子段后无法正确拼出原PDU然后卡在RLC层等下一片子段的情况。协议栈实现里这块是RLC子层最容易出隐藏bug的地方单测、集成测试和信令一致性测试最好都把“重传后二次分段”这个场景覆盖进去。4. 重传协议的实际配置与信令流程4.1 重传相关参数配置示例在5G的RRC配置里重传相关参数分布在MAC-Config、PDSCH-Config、PUSCH-Config和RLC-Config中。实际运维中我们更多是通过无线参数模板来调整几个关键值。下面举一个简化的参数配置示例场景是某实验室的端到端5G协议栈验证项目。macConfig maxHARQ-Tx4/maxHARQ-Tx harq-ProcID-Offset0/harq-ProcID-Offset /macConfig rlcConfig modeAM/mode t-PollRetransmission ms45/ maxRetxThreshold16/maxRetxThreshold pollPDU32/pollPDU pollByte bytes65536/ /rlcConfig上面这个配置里maxHARQ-Tx配成4表示同一个HARQ进程最多重传4次。四次的冗余版本按0、2、3、1轮转如果四连都能传失败MAC向RLC报告后放弃该传输块。RLC的t-PollRetransmission配成45毫秒maxRetxThreshold配成16表示RLC最多因为同一包被连续NACK十六次才触发重建。这个组合适合对时延有一定要求的业务。如果只追求极致时延可以再调小maxHARQ-Tx如果是视频流这种大包业务常见配置可以放宽到8次左右减少RLC层介入的频率。4.2 下行传输的HARQ时序和资源调度下行HARQ调度中每次PDSCH传输会在DCI里指示HARQ进程号、NDI新数据指示和冗余版本。NDI翻转代表这个进程上开始传新数据NDI不变代表当前传输是重传。基站调度器需要记住上个时刻给每个进程发了什么收到ACK/NACK后决定是继续重传还是调度新数据。时序上PDSCH传输后终端需要一定处理时间才能在PUCCH或PUSCH上反馈HARQ。协议允许高层配置不同的反馈时机DCI里有专门的域来指示当前传输对应的HARQ反馈时隙。基站调度器在排布下行资源时必须前向预留PUCCH的资源给HARQ反馈用。如果PUCCH资源冲突或时序配置不合理终端可能在错误时隙反馈基站收到的ACK/NACK就会和数据张冠李戴。实测中遇到过一个典型问题下行重传率不高但偶发RLC重传。查了半天发现基站把PDSCH调度在某个时隙而DCI指示的反馈时机和该终端的上行PUSCH资源在同一个时隙重叠导致终端在反馈HARQ时优先发了PUSCHHARQ反馈只能复用或延迟。修复方法是调整反馈时序列表或者给该终端预留独立的PUCCH反馈资源让反馈和PUSCH错开。4.3 上行传输的HARQ时序与调度配合上行HARQ与下行略有不同最核心的差异是调度完全依赖基站授予的UL grant。终端不会自主重传而是等着基站在DCI里再次下发该HARQ进程的UL grant并携带NDI和冗余版本指示。这也意味着如果基站调度器没有及时给重传分配资源上行重传的时延会被拖长。上行HARQ还有一个常见问题下行数据到达基站端的HARQ反馈和上行数据的HARQ反馈如果都拥挤在某一段时间PUCCH和PUSCH冲突会造成反馈正确地传上去的概率下降。为此5G支持HARQ反馈在PUSCH上复用传输。当PUCCH和PUSCH重叠时终端可以把HARQ反馈放在PUSCH里一起发。这个功能虽然成熟但在配置PUSCH资源时仍需注意复用后的码率不能太高否则反馈比特本身就可能出错反而导致基站误判。野外现场出现过一次“上行忽快忽慢”的问题根因不在无线环境而是基站给上行HARQ重传分配的MCS和第一次传输相同可终端上报的信道状态却变了导致重传继续失败。后来在调度器里加上了基于最新SRS测量来决定重传MCS的逻辑重传成功率才稳定下来。这也说明5G重传不仅是“发不发”更不能忽略“用什么参数发”。4.4 与MCS选择和外环联动HARQ重传率和MCS选择是深度耦合的关系。调度器通常用外环链路自适应来调整MCS某个用户如果HARQ首次传输失败外环会把MCS稍微调低如果连续多次首次传输都成功外环会把MCS调高一些直到出现一次失败。这个“目标BLER”就对应了HARQ首次传输的失败概率。比如目标BLER为10%意思是允许10%左右的传输块在第一次传输后失败并重传。调优时要注意一个误区一味降低目标BLER不一定是好事。虽然重传率下来了但MCS被压得越来越保守用户峰值速率和新传数据量反而下降。5G系统里适当保留一点HARQ重传让链路自适应主动去试探更高阶调制反而能获得更好的频谱效率。这也是为什么“降低重传率”不能作为唯一的KPI必须结合吞吐率、首传失败率和空口资源占用率一起看。5. 常见问题与排查技巧实录5.1 重传率升高先查分层再查参数遇到“用户感觉速率变差”的投诉不要一上来就调HARQ次数或改BER目标先把重传拆开看是HARQ重传率升高还是RLC层重传率升高或者PDCP丢包率同时恶化。HARQ重传率升高大概率反映的是信道质量变差、MCS过于激进或干扰异常。RLC重传率升高而HARQ重传率不高大概率是HARQ失败后触发了RLC重传说明HARQ接收软合并或资源调度有更深层次问题。PDCP层如果出现丢包通常不是RLC重传没救回而是RLC触发了重建或RLF导致的连续性丢失。排查工具上把基站侧的MAC层计数器、终端侧物理层译码结果和RLC层统计拉出来一个个对齐。我习惯先看DCI里的NDI翻转、重传资源和当前HARQ进程状态判断是不是调度器本身错了包。有些重传率偏高的表象实际上是上下行数据缓冲管理出错导致的重复调度。5.2 外环BLER目标与重传次数如何配合很多项目里配置外环BLER目标为一个固定值比如10%然后调大maxHARQ-Tx来“托底”。这个配置在中等负载下没问题但高负载小区里重传资源过多会影响其他用户调度机会导致小区平均吞吐率下降。经验做法是分业务配置。eMBB大包业务可以把目标BLER设高一点例如10%甚至更高配合CBG重传减少重传开销URLLC类业务则尽量把目标BLER压到1%到5%并且减少最大HARQ重传次数宁可偶尔触发RLC重传也不能让时延超预算。对于RLC AM业务maxRetxThreshold也建议和端到端时延预算挂钩不能为了追求成功率无限放大。在高干扰的小区里如果HARQ重传率在20%以上持续很久只调整外环往往不够要先排查是否存在控制信道重复错误、PUCCH资源不足或下行干扰测量不准。否则MCS会不断被外环拉低重传率似乎回落了但用户速率也落在低位问题并没有真正解决。5.3 HARQ进程冲突的典型场景HARQ进程冲突常见于调度器实现不当或协议栈处理边界未对齐。一种典型场景是基站为一个HARQ进程发送了新数据但终端认为之前的传输还没有结束仍然在做重传或者反过来终端认为收到的是新数据而基站则认为刚才的是重传。导致这种情况的大多是NDI处理错误或者HARQ反馈丢失后被调度器错误复位了进程状态。排查时不要只看空口统计。要在协议栈日志里比对DCI的NDI、HARQ进程号、冗余版本和CRC结果。很多所谓“重传率异常”问题其实是日志里一个进程被打断所致。比如某厂商基站支持HARQ进程漂移而终端能力或协议栈版本不支持就会偶发状态错乱。修改方法是关闭HARQ进程漂移或者根据终端上报能力严格限制进程归属。另外一个常见坑是“HARQ进程号映射错误”。在一些多载波或载波聚合场景下进程号需要根据载波指示和偏移计算如果计算逻辑和协议规定的不一致两个载波之间的重传会互相干扰。这种问题最隐蔽因为单载波测试时一切正常多载波一开就随机出问题。我通常建议在实现层加一个自检校验记录最近一次发送给每个HARQ进程的传输块长度和优先级回调时对不上马上告警。5.4 RLC重传卡死与重建的排查RLC重传卡死是个让人头疼的问题。表现是用户速率变为0但RRC连接还在信号也正常看上去一切都在就是数据传输不动。第一步要查RLC状态报告的收发。如果发送侧一直没有收到状态报告查一下t-PollRetransmission是否触发以及接收侧的状态报告是否因为HARQ失败而没有递交给MAC。很多时候RLC状态报告本身也要依赖底层的可靠传输如果状态报告在空口上反复失败接收侧就一直得不到真实的RLC缓存状态。第二步看发送窗口是否卡死。RLC发送窗口满了之后如果对端不断反馈NACK但又迟迟不推进接收窗口发送侧会把所有没确认的包都重传但目标也收不齐形成连锁反应。这时候大概率是RLC重分段逻辑出错或者高层配置的分段模式不匹配。可以先复位RLC实体看能否恢复然后收集节点日志对比收发双方的SN和分段信息。第三步看maxRetxThreshold。如果这个值设得太大卡死时间会被拉得特别长用户已经感知到断流但系统还不知道要重建。反过来设得太小偶发脉冲干扰就会触发RLF表现为频繁掉线。调试时要结合无线环境实测数据而不是照搬默认值。6. 重传协议调优的个人心得做了这么多年无线系统我越来越觉得重传协议最大的作用不是“把错的变对”而是帮系统感知信道并自适应。每次HARQ重传都说明系统对信道估计和MCS选择不够准每次RLC重传则说明HARQ联调还有待优化的空间。所以我调试时会始终保持一个习惯把重传事件当作“信道的反馈信号”持续观察它来微调周围大量参数。经验上重传协议调优要分层看闭环。物理层看HARQ的软合并增益和BLER目标MAC层看HARQ进程调度和资源利用率RLC层看状态报告和窗口管理。每一层都有它自己的“坑”。越是想优化端到端吞吐越不能只盯着其中一层。CBG重传、最大HARQ重传次数、RLC轮询阈值这几个参数联动起来比单独改某一个效果要明显得多。最后分享一个小技巧在调试台或实验床上保持一个能实时打印HARQ进程状态和RLC窗口长度的工具很多时候莫名其妙的速率下降都是进程状态错乱和窗口卡死的最初表现。要能在十几秒内定位到数据面重传链路再定位到具体协议实体状态调试效率会完全不一样。这章内容如果可以继续扩展下一步不妨把PDCP重排序和RLC窗口的关系也梳理一遍它们之间的“交接单据”同样藏着不少有意思的细节。