企业官网建设流程全解析

在无线侧干活的人，大概率都经历过这种场面：网管上某个小区的HARQ重传率飙到三成以上，肉眼看起来像是要出大事，结果后台跑了一圈用户感知测试，发现用户正在顺畅地刷高清视频，完全没受任何影响。这是为什么？因为5G的重传协议，早就不是我们早年做数据通信时理解的那种“发错了就原样重发一遍”的笨办法了。它是一套分层的、带软合并增益的、能根据信道状态自我调节的精密机制。

这一篇专门聊5G的重传协议，也就是HARQ和RLC ARQ这一整套接力体系。读完你会明白：为什么物理层需要一次极快但“不完美”的重传来兜底，为什么RLC层还要再补一道更彻底但更慢的重传，以及这两者之间怎么配合才不会互相拖后腿。无论是刚入行的网优工程师，还是做协议开发、终端测试的朋友，搞清楚这套机制，对排查吞吐率异常、时延抖动、丢包类问题都会有直接的帮助。

1. 重传分工的底层逻辑：为什么5G要配两套重传机制

1.1 无线信道误码的“瞬时性”决定了第一道防线必须快

先搞清楚一个前提问题：有线通信里，光纤的误码率低到可以忽略，偶尔纠错一次就完事。无线通信完全不是这个画风，手机在移动、人在遮挡、天气在变化，信道质量的波动是毫秒级的。上一毫秒信道条件还不错，下一毫秒可能因为一辆卡车挡在信号传播路径上，信噪比直接掉十几个dB。

这种突变意味着两件事：第一，误码是必然会发生的，不是“可能不会发生”；第二，误码往往成群出现，一个传输块坏了，紧接着的几个传输块也可能不健康。所以无线通信体系里必须有一个错误恢复机制，而且第一道防线必须特别快，快到能跟上信道变化的速度。

我们常说的HARQ，全称是Hybrid Automatic Repeat reQuest，混合自动重传请求，它工作在MAC层，站在物理层传输的上方。它最大的特点就是“快”：下行方向上，终端收到一个传输块之后，立刻做CRC校验，校验失败就马上通过PUCCH或PUSCH反馈一个NACK给基站，基站调度器看到NACK之后，会在极短的时间内安排重传。这个反馈和重传的周期，可以缩短到几个毫秒甚至更短。

为什么非要做在MAC层？原因很简单，这里离物理层最近，反馈路径最短，调度器可以直接参与重传资源的分配。如果第一道防线的重传周期太长，信道早就变了，重传的数据大概率还会继续错，整个链路就陷入“传了错、错了传”的恶性循环。

1.2 ARQ为什么还要存在：再快的HARQ也有鞭长莫及的时候

很多人会问：既然HARQ这么快，为什么还需要RLC层的ARQ再兜一层？我自己在做协议测试的时候也想过这个问题，后来在一次现网弱覆盖场景的测试里才算真正理解透。

HARQ再快，也有它的软肋：第一，HARQ的重传次数是受限的。每个HARQ进程的重传次数不可能无限增加，因为每一次重传都在消耗调度资源、占用时频资源、增加时延。第二，HARQ的反馈本身也可能出错。ACK被误判成NACK就导致无效重传，NACK被误判成ACK就会造成数据静默丢失，这种情况是HARQ自己无法感知的。第三，HARQ只管单个传输块的收发对错，它不关心上层数据的顺序和完整性。

所以5G在RLC层又设计了一套ARQ，专门解决“HARQ都救不回来”的数据块。RLC ARQ的特点是：它基于序号和状态报告来工作，接收端会明确告诉发送端“我缺了哪些数据”，发送端再把缺的那些数据补发过来。它的速度当然没有HARQ快，但它的可靠性和覆盖范围是HARQ给不了的。

打个比方，HARQ像是工地上第一道质检员，负责在每个环节快速检查刚加工出来的零件，不合格立刻返工，速度极快；RLC ARQ则是最终的验收员，手里有完整的发货清单，等一批零件全部到齐后逐一核对，发现哪个缺了就联系上游补货，宁可慢一点也要保证整批货完整交付。

1.3 两级重传和时延预算怎么平衡

既然有两级重传，就一定会有一个先后顺序和时机配合的问题。在5G的协议栈里，数据从IP层下来，经过PDCP、RLC、MAC，最后到物理层发送出去。接收端的处理是反过来的：物理层先收，MAC层做HARQ合并和反馈，然后把完整的数据块交给RLC层，RLC确认顺序无误后再交给PDCP。

这个顺序就是你理解了也会背，可内部的时延预算非常紧张。业内设计时通常给HARQ流程留出极短的周期：下行方向上，从PDSCH发送到收到HARQ反馈，典型情况下可以设计在5到10毫秒以内；如果NACK了，调度器在下一个可用时机就要安排重传。而RLC ARQ是另一种节奏，它只有在检测到数据缺失之后才会触发状态报告，发送端再根据状态报告重传缺失的PDU，这个过程通常要等几十毫秒甚至更久。

正因如此，5G的设计哲学是：能用HARQ快速解决的误码，绝不让RLC ARQ出手；HARQ兜不住的，RLC再上。两者构成了“快而浅”加“慢而深”的双层防线。这种设计并不是冗余，而是应对无线信道复杂性的必然选择。

2. HARQ的软合并机制：重传不是单纯重发，而是把能量攒起来

2.1 Chase合并与增量冗余：两种思路的取舍

一开始很多人以为HARQ重传就是把原来那个数据块原封不动再发一遍，然后接收端丢弃之前收到的错误版本，再去解新收到的版本。这其实是很多年前笨办法的思路，现在早就进化了。

现代HARQ的核心思想是“软合并”，接收端不会扔掉解码失败的数据，而是把多次收到的信号按一定规则合并在一起，再去做解码。这样每一次接收都在为最终解码积累能量，重传次数越多，合并增益越大，解出来的概率越高。

软合并有两种主流方案，一种叫Chase合并，另一种叫增量冗余。Chase合并的思路很简单：每次重传都发送与初传完全相同的数据，接收端把多次收到的软比特按位相加，等效于做了一个时间分集，信噪比提升了，解码成功率自然就上来了。它的优点是实现简单、反馈开销小、接收端缓存管理容易，缺点是没有提供任何新的编码信息。

增量冗余的思路不同：初传发送一部分校验比特，重传时发送的是另外一部分校验比特，接收端把几次传输拼接起来，等效于一个更低码率的、更强纠错能力的编码。说得直白一点，第一步传的数据让接收端能看懂大概内容，第二步传的是补强的校验信息，让接收端能够纠出残留的错误。增量冗余的增益比Chase合并更高，但代价是接收端需要更大的软缓存来存储多次收到的版本，调度端的RV参数设计也要更精细。

在5G实际系统里，这两种方式并不是二选一，而是可以动态配置的。用RV（Redundancy Version，冗余版本）这个参数来控制每次传输携带的是哪一份编码比特。RV0通常用于初传，后续重传可以选RV1、RV2、RV3之一，也可以重新回到RV0。如果选RV0再做一次合并，就相当于Chase合并；如果换到其他RV，就走增量冗余路线。

2.2 冗余版本、NDI和MCS：一次完整重传的微观故事

把重传的微观逻辑拆开看，一次典型的重传过程是这样的：基站调度器要给某个终端发一个传输块，先通过DCI（Downlink Control Information）下发调度信息，里面包含资源分配、调制编码方案（MCS）和HARQ相关字段。DCI里有几个关键字段：HARQ进程号、NDI（New Data Indicator，新数据指示符）、RV和HARQ反馈时序。

NDI的作用特别有意思。它是一比特信息，用来区分当前这个HARQ进程上传输的是新数据还是重传数据。协议规定，新传一块数据时，NDI要发生翻转；而重传时，NDI保持不变。接收端一看NDI的变化就知道：这个进程上又有新数据进来了，之前缓存的旧数据可以清掉了。这个机制保证了接收端不会把新数据和旧数据混淆在一起做合并，避免了解码错乱。

RV则是告诉接收端，当前这份数据里携带的是编码器输出的哪一段比特流。初传通常是RV0，如果解码失败，重传时基站可能会选择RV2或者RV3，让接收端拿到额外的校验比特来补强解码。这里有一个容易被忽略的细节：MCS字段在重传和初传时的含义是不完全一样的。如果是新传，MCS表示本次传输采用的调制阶数和码率；如果是重传，DCI里MCS字段的含义被重新解释为RV的附加信息。也就是说，重传时基站可以改变传输的调制方式，但调试者要理解这种字段复用规则，否则容易在提取调度日志时看错。

我们做调度日志分析时，最容易犯的一个错就是把NDI、RV当作独立的随机值去统计。实际上它们是有咬合关系的：NDI翻转且RV=0，这是初传；NDI不变且RV=0/1/2/3，这是重传；NDI翻转但RV不是0，这种情况在标准里基本都是非法组合，出现在日志里往往意味着DCI解析错位或者协议栈实现有bug。

2.3 HARQ进程数：为什么不多不少就这些

HARQ还有一个关键概念叫HARQ进程。因为无线重传是停等协议的一种变体——发一个传输块，等反馈，再决定是否重传——如果只有一个进程，那么在等待反馈的这段时间里信道完全是空闲的，效率极低。解决思路就是引入多个并行进程：进程0在等反馈的同时，进程1已经在传下一个传输块了。

5G下行最多支持16个HARQ进程，具体配置取决于帧结构和TDD上下行配比。在FDD模式下，下行和上行的HARQ进程数通常配置到16个；在TDD模式下，进程数要和上下行时隙配比匹配，下行多的配比可以设计更多下行进程，上行同理。

这个进程数直接影响一个关键指标：往返时延（RTT）内的数据吞吐。粗略估算一下，如果每个进程从发送到收到反馈需要8毫秒，那么至少需要8个进程才能让调度器在这8毫秒内每个进程都发一个传输块，从而把信道占满。进程数太少，调度器只能在等待反馈时“干瞪眼”，吞吐率上不去；进程数太多，终端侧软缓存压力大，处理复杂度也上来了。所以16个进程是一个比较合理的折中，它能够在常见RTT范围内把调度器喂饱。

3. HARQ进程与调度行为：同步异步、自适应非自适应的真实含义

3.1 同步重传和异步重传的差异

HARQ进程除了数量，还有一个容易被新手忽略的分类维度：重传可以是同步的，也可以是异步的，可以是自适应的，也可以是非自适应的。

同步HARQ的含义是：重传必须发生在预定义的时间位置上，比如初传之后固定间隔的某个时隙。它的好处是调度器几乎不需要额外指示，终端自己就知道什么时候该准备接收重传了，控制信令开销很小。缺点是时间位置一旦定死，调度灵活性就差了。

异步HARQ正好相反，重传可以发生在任意可用的时隙上，完全由调度器临时决定。代价是调度器必须在DCI里明确携带HARQ进程号，让终端能够区分“这次重传的是哪个进程的数据”。5G的下行HARQ默认就是异步自适应的，因为下行方向控制信道资源相对充裕，调度器需要最大的灵活性来应对信道变化。

自适应和非自适应的区别则在于：重传时能不能改变资源大小、调制阶数、发射功率等传输参数。自适应重传允许调度器根据最新的信道质量重新分配资源，比如原来用16个资源块传失败了，现在信道更差，调度器可以改用32个资源块再传一次，用更强的编码冗余去对抗深度衰落。非自适应重传则必须沿用初传的参数，什么都不能变，好处是终端处理简单，DCI开销进一步降低。

3.2 下行为什么执着于异步自适应

5G把下行HARQ设计成异步自适应，是有深层考虑的。第一，下行的调度权完全在基站手里，基站对信道信息掌握最全面，它可以利用终端上报的最新CSI（信道状态信息）来为重传选择最优的时频资源和调制方式。第二，下行数据来自多个用户，调度器需要动态调配资源给不同用户，异步机制给了它足够的腾挪空间，不会因为某个固定时隙被某个用户的重传占死而影响整个小区的调度效率。

我在调试一个下行速率异常的问题时，曾经抓到过一个典型的场景：某终端的信道质量在快速波动，调度器每次重传都选择不同的资源块位置和MCS等级，日志里看NDI一直不变，但RV值在0、2、3之间来回跳。当时第一反应是“这个终端的重传怎么这么乱”，后来对照CSI反馈数据才发现，调度器是在根据实时的信道测量结果动态调整重传策略：信道稍微好一点就用RV0做Chase合并，信道继续恶化就切到RV2/RV3去增加冗余。这种灵活调整正是异步自适应HARQ的核心价值。

3.3 上行K1时序、TDD配比与进程冲突

上行的HARQ反馈和调度要稍微绕一点。下行数据从基站发给终端，终端反馈HARQ的时机用K1来表示，也就是PDSCH所在时隙与HARQ-ACK所在时隙之间的偏移。在TDD配比下，K1不是固定值，而是取决于上下行时隙的具体排列。如果PDSCH所在的时隙和PUCCH可用的上行时隙之间隔着多个下行或特殊时隙，反馈就要等好几个时隙才能发出去，这种等待本身就是时延的一部分。

上行方向还面临一个更现实的约束：终端的处理能力和功率预算有限。终端在同时进行数据发送和HARQ反馈时，发送功率要分一部分给PUSCH，还要分一部分给PUCCH上的HARQ-ACK，如果两者在同一时隙撞在一起，就需要特殊的复用或优先级处理规则。做上行吞吐率优化时，最怕看到的场景就是上行HARQ重传和新的上行授权挤在一起，终端来不及准备发送缓冲区里的数据，导致连续几个时隙都在处理旧数据的重传，新数据反而得不到调度机会。

这种“重传挤掉新传”的现象，在优化经验里有个直白而准确的判断标准：如果终端的上行缓存里总有积压数据，而调度器分配了大量重传机会，就要考虑是调制编码策略选得过于激进、还是K1配置不合理导致反馈周期过长。

4. RLC AM模式的ARQ兜底：状态报告、重排序和参数调优

4.1 从HARQ漏网之鱼到状态报告召回

HARQ虽然功能强大，但如果一个传输块经过多次重传还是解不出来，或者接收端连传输块是否存在都无法判断（比如调度信息本身就丢失了，终端根本没收到DCI，自然也就不会反馈任何信息），这时候HARQ就到了能力的尽头。谁来接手？RLC层的AM（Acknowledged Mode，确认模式）就要登场了。

RLC AM模式下，发送端和接收端各自维护一组序号（SN）。每个RLC数据PDU都会被编号，接收端收到数据之后，要么向上递交，要么在发现缺失时产生一个状态报告。状态报告就像一封“欠货通知单”，发送端根据这份通知单精确知道哪些序号的数据需要重传，然后把这些PDU重新打包进新的MAC传输块里发出去。

有一个细节值得特意说明：RLC层重传的数据，走到底层仍然要重新经过一次HARQ。也就是说，RLC重传并不意味着这个数据块就能“免检”直达接收端，它照样要通过物理层发送，照样会有解码失败的可能。这种“重传里嵌套重传”的机制，恰恰体现了协议栈在可靠性和效率之间的层层妥协。

为什么HARQ救不回来的数据，RLC能救回来？核心原因在于HARQ的反馈丢失往往是物理层信号问题，而RLC的状态报告是承载在高层信令和数据里的，它接收端在逻辑层面上判断缺失，不受物理层HARQ进程状态的限制。哪怕底层某个HARQ进程彻底失联，只要RLC状态报告能到达发送端，重传就能发生。

4.2 重排序：宁可等一等，也不能乱

RLC AM接收端还有一个重要职责：重排序。因为并行HARQ进程的存在，数据到达接收端的顺序很可能不是发送顺序。进程0的数据可能晚于进程3的数据到达，这个顺序上的错乱如果不处理，上层就会收到乱序的数据包，TCP的接收窗口就会受到影响。

处理方案是设置一个重排序定时器，叫t-Reordering。接收端一旦发现某个序号的数据缺失，就启动这个定时器，在此期间，即使此前已经收到后面序号的数据，也不能立刻向上递交，只能先放在重排序缓存里等待缺失数据到来。如果定时器到期缺失数据还没来，才算作真正丢失，接收端把现有的数据按顺序递交，同时向上层标记缺失情况，后续由RLC重传来补。

这个t-Reordering的取值非常讲究。设得太短，接收端会过早放弃等待，把乱序数据一股脑递上去，上层看到的就是抖动和乱序；设得太长，数据在重排序缓存里滞留过久，端到端时延就上来了。实际网络里这个参数一般配置在几十毫秒量级，具体要和HARQ RTT、链路时延做个匹配。我们调过不少案例，发现用户感知变差但物理层指标不错的怪现象，最后追根溯源都落在t-Reordering设置不合理上。

4.3 轮询、状态禁止和最大重传阈值：三个看不见的控速器

RLC AM里有几个参数，平时不起眼，但在高误码场景下能决定生死，分别是轮询阈值、状态禁止时间、最大重传阈值。

• 轮询（Polling）：发送端为了触发接收端反馈状态报告，会定期或定量地设置轮询位，比如每发送若干PDU或累计若干字节后，就在PDU里置上轮询位。接收端收到带轮询位的PDU之后，会被要求回复一个状态报告。这是防止接收端一直憋着不反馈的手段。
• 状态禁止时间（t-StatusProhibit）：为了避免接收端过于频繁地发送状态报告导致反向链路拥塞，协议规定在一次状态报告发送之后，在一段时间之内不允许再次发送状态报告。这样可以把反向反馈的信令开销限制在一个合理水平。
• 最大重传阈值（maxRetxThreshold）：这个参数限定了一个RLC PDU最多能被重传几次。如果重传次数超过阈值，RLC层会选择放弃，触发RLF（无线链路失败）流程，让上层重新建立无线承载。这个机制是防止链路已经不可用还无休止地重传下去。

这几个参数的相互作用极其微妙。轮询太频繁，状态报告把上行信道占满，用户面的数据速率就掉下来；状态禁止时间设得太长，接收端的反馈不及时，发送端要等更久才能发现数据缺失；最大重传阈值设得太大，已经坏掉的数据链路会拖很久才被放弃，用户感知的“假死”状态会持续很长时间。这些参数没有一个能单独拍脑袋定，必须结合承载类型、时延要求、小区信道质量分布综合去调整。

5. 重传协议在真实网络中的排查经验与优化清单

5.1 别把统计口径搞混：HARQ重传率和RLC重传率不是一回事

在现网排查问题的时候，最忌讳的就是拿到一个“重传率”指标就开始动手改参数。因为“重传率”这个词在不同统计维度下含义完全不同。

HARQ重传率，统计的是MAC层传输块级别，某段时间内重传的传输块数量占全部传输块的比例。这个指标的正常范围比很多人想象得高。5G系统为了在吞吐率和误码率之间取得平衡，通常会允许初传在10%左右甚至更高的BLER（误块率）水平，也就是说大约10%的传输块第一次传就是错的，需要HARQ重传。这个数字在4G时代其实也不罕见。如果你把“HARQ重传率超过10%”直接判断为网络劣化，那就太草率了。

RLC重传率，统计的是RLC PDU级别的重传比例。这个指标正常情况下应该非常低。如果RLC重传率持续升高，说明HARQ已经兜不住误码了，链路质量或者参数配置一定出了问题。很多网管系统把两种重传率混在一个界面上展示，不仔细看统计层级就很容易误判。

我自己的经验习惯是这样：先开统计面板，看HARQ重传率作为“链路的压力表”，看RLC重传率作为“链路的溃堤信号”。前者高但后者稳，说明系统在正常自我修复；两个都高，才需要认真查。

5.2 小区重传率异常排查的实操步骤

假设你遇到一个小区，HARQ重传率从正常的12%突然跳到30%以上，同时用户反馈下载速率大幅下降。按照下面这个顺序排查，会少走很多弯路：

第一步，确认统计口径和统计周期。新版本软件升级后，统计指标的归属可能会有变化，先和厂家的文档确认一下指标定义，排除统计口径变化造成的假劣化。

第二步，分用户维度看。重传率是集中在某个特定终端上，还是分布在全小区所有用户上？集中在单个终端，基本可以锁定终端能力、终端软件版本或该用户所处位置的专属问题；全小区普遍升高，大概率是覆盖或干扰的问题。

第三步，看时间和空间的关联性。重传率升高发生在每天的固定时段吗？比如早晚高峰，这往往与容量负载有关；还是对应着某个特定区域，比如某个路段或建筑死角，这就要查地理化分布的测量数据。

第四步，关联底层物理层指标。查每个资源块的干扰噪声水平、终端上报的CQI分布、PDSCH和PUSCH的发射功率余量。有一个很典型的组合：如果CQI平均值并没有明显下降但重传率升高，要怀疑是不是调度或者HARQ进程配置出了问题；如果CQI下降伴随重传率升高，那基本就是无线环境劣化，LTE和5G都是这个套路。

第五步，查参数配置和历史变更记录。看看最近有没有人对小区级参数做过调整，比如MCS偏置、最大MCS限制、调整目标BLER、t-Reordering等。现网出现过不止一次，参数切换时误把某个重传相关定时器改成了极端值，导致整个小区性能跳水的事故。

5.3 参数调整经验：我的几条教训

经验这个东西，纸上得来终觉浅。我说几个在重传协议上踩过的坑，都是真实教训。

第一个坑，是盲目提高最大重传阈值。有一次为了降低某个弱覆盖小区的丢包率，我直接把RLC AM的最大重传阈值从默认值调高了一倍。结果丢包率是降了，但用户的时延体验反而变差了，TCP层因为等数据等得太久频繁触发超时重传，效果适得其反。回头想，弱覆盖场景下真正该做的是改善覆盖或者调整切换策略，让用户不在这个小区死磕，而不是让RLC在一根坏链路上无限重试。

第二个坑，是忽略HARQ反馈窗口的配置。在TDD配比比较极端的场景下，如果K1配置不当，HARQ反馈会延迟好几个时隙，调度器在等反馈期间无法判断是否需要重传，吞吐率立刻掉下来。我一度把这个问题当成干扰问题排查了两天，最后在调度日志里看到反馈时序才恍然大悟。

第三个坑，是没重视PDCP重复传输和重传协议的相互作用。为了提升URLLC业务的可靠性，很多方案会开启PDCP层的重复传输，也就是同一份数据并发发送两份。这种方案确实能降低时延和丢包，但它会占用双倍的下行资源，让HARQ重传的资源变得更加紧张。在资源受限的小区里，重复传输和HARQ重传会互相挤压，最后表现出来就是重传率升高、新传数据排队。所以开启重复传输之前，最好先估算一下小区的容量余量。

5.4 从重传协议看5G时延优化的一体两面

如果你把5G的重传协议放到时延优化的全局里再去看，会发现一个很辩证的关系：重传协议的每个参数，几乎都是一对矛盾的平衡点。进程数多了吞吐高但缓存压力大，进程数少了时延低但效率差；t-Reordering设短了乱序多但时延低，设长了整齐但等待久；HARQ重传次数允许多了纠错强但时延飘，允许少了时延稳但丢包漏。

这提醒我们，评判一个重传配置好不好，不能只看单指标，要看它在“可靠性、时延、吞吐”三个维度上的综合表现。比如面向普通数据业务，允许10%左右的初传BLER、保留充足的HARQ重传机会，就是合理的取舍；面向低时延高可靠业务，跳过部分HARQ流程或者配置更激进的重传策略，也可能反而更合适。

5G协议栈里给人留下的印象是极速和宽广的吞吐，重传协议守卫的最后一道地面防线却常常被低估。它不像毫米波、大规模天线那样容易成为讨论的热点，但恰恰是它在幕后对每一个传输块负责，确保用户手里的视频不卡顿、邮件不丢失、文件不损坏。想明白重传协议这个维度，你会发现很多现网中的怪现象，都能用一套很朴素的逻辑解释清楚：不过是谁在等、谁在传、谁在补、谁该放弃而已。