如果你做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层的ARQ
5G的用户面协议栈从上到下大概是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. HARQ：5G低时延的功臣，也是参数最敏感的家伙
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轮转。基站调度器在发送新数据时一般选rvid=0，重传时按当前HARQ进程的重传计数选择接下来的冗余版本。增量冗余在信道极差或首次传输几乎完全不可用时作用很明显，因为新校验比特带来的信息增益远大于把同一份噪声平均一下。
我在实际外场测试中常遇到一种情况：信道一般差的时候，追逐合并和增量冗余差别不显著，但随着误码上升到高负载干扰场景，增量冗余的优势就出来了。干扰不是恒定不变的，重传间隔里信道可能已经变了，这时多收一批校验比特远比重复收同一份比特有用。
2.3 5G HARQ的关键参数和配置思路
协议上影响HARQ行为的主要有HARQ进程数、反馈时序、最大重传次数和CBG配置。
- 下行HARQ进程数：高层配置，最多16个。如果业务时延要求高、调度器能力充足，尽量把进程数配到较大值，避免调度器因为在等反馈而歇着。
- 上行HARQ进程数：同样是高层配置，最多16个。上行调度更依赖终端的处理能力，所以终端能力上报里会有关于HARQ进程支持的字段。
- HARQ反馈时序：下行数据的反馈时机由基站通过DCI中的PDSCH-to-HARQ反馈时序指示，不同的时隙偏移对应不同的反馈时延。
- 最大重传次数（maxHARQ-Tx）：MAC层控制消息里配置。配置过高会挤占新数据传输资源，配置过低则可能导致高误码场景下数据频繁交给RLC，甚至因为RLC重传不及时而影响业务层时延。
从调度器视角看，还要关注“同步/异步”和“自适应/非自适应”两组特性。异步HARQ指重传可以发生在任意时刻，调度器可以自由分配资源；同步HARQ指重传必须发生在特定时间。自适应重传允许调制编码方式和资源块分配在每次重传时重新配置，非自适应则必须沿用首次传输的配置。5G几乎全部采用异步自适应HARQ，这样调度器灵活性最大，也最能适配多变的多用户调度场景。
2.4 CBG传输：把大传输块拆开重传，省的不是一点半点
5G一个很大的演进是CBG（Code Block Group）级的HARQ反馈和重传。一个传输块由若干码块组成，以前是一整包纠错，错一个比特就把整个传输块重发。到了高带宽、高MCS的场景，一个传输块可能大得离谱，重传整个包消耗的资源很浪费。
CBG传输把传输块按一定规则分成多个码块组，每个码块组在反馈时都有独立的HARQ确认位。基站收到某个CBG的NACK后，可以只重传这个CBG。重传的资源大小也比整个传输块小得多，终端侧把重传的CBG对应的软比特和之前缓存的合并，最终把这一传输块完整解码出来。
启用CBG需要网络侧和终端侧都支持，高层配置里需要打开CBG相关能力，并约定一个传输块最多分多少个CBG。调度器还需要维护每个CBG的收发状态，不像以前只维护整个传输块的状态。复杂度确实上来了，但在大包业务、下行高速率传输时收益非常明显。在某跨平台系统的验证测试中，大包重传场景开启了CBG之后，同样的信道质量下，重传资源开销可以显著下降。
3. RLC层的ARQ：HARQ兜不住的那部分，靠它来兜底
3.1 RLC的三种模式：TM、UM、AM
RLC层的传输模式比较好理解。透明模式（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-Tx>4</maxHARQ-Tx> <harq-ProcID-Offset>0</harq-ProcID-Offset> </macConfig> <rlcConfig> <mode>AM</mode> <t-PollRetransmission ms="45"/> <maxRetxThreshold>16</maxRetxThreshold> <pollPDU>32</pollPDU> <pollByte bytes="65536"/> </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时优先发了PUSCH，HARQ反馈只能复用或延迟。修复方法是调整反馈时序列表，或者给该终端预留独立的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窗口的关系也梳理一遍，它们之间的“交接单据”同样藏着不少有意思的细节。
