企业官网建设流程全解析

1. 为什么要聊重传协议，以及它到底解决什么问题

1.1 无线信道的不可靠性从哪来

做5G空口开发或者协议栈的人，每天睁开眼面对的第一个问题就是：信道不可靠。这不是什么偶发事件，而是物理规则决定的。电磁波在空间里传播，会碰到衰减、多径、干扰、多普勒频移，任何一个因素都能让一个本来完好的传输块在接收端变成一坨乱码。尤其是中高频段，信道变化快，衰落深，误码率别说10的负几次方，在某些恶劣环境下连10的负二次方都压不住。

有人说，那我对编码狠一点，加足够多的纠错比特不就行了？不行。前向纠错不是万能的，纠错能力越强，冗余开销越大，频谱效率就越低。而且信道恶劣到一定程度，比如信噪比崩塌，任何编码都救不回来。这个时候就需要另一层机制：让发送端知道“你发的东西我没收到，或者收到了但坏了”，然后重新发一遍。这就是重传协议存在的根本理由。

重传协议在5G里不是配角，它是整个空口可靠性的兜底。没有它，你手机上的视频通话、工业控制的下行指令、自动驾驶的实时路况同步，都会因为一两个误包而卡顿、失控甚至中断。而且5G承载的业务类型比4G复杂得多，从几十字节的URLLC控制报文到几百MB的eMBB大文件，从毫秒级时延要求到海量连接，重传机制必须同时应付这些极端差异化的场景。

1.2 前向纠错与反馈重传的组合思路

既然单独靠前向纠错不现实，单独靠重传又为什么不行？因为重传本身有代价。第一是时延，发一个包，等反馈，不行再重发，一个来回至少多出好几毫秒，这还没算排队和调度。第二是缓冲区，发送端和接收端都得缓存数据，才能做到出错后快速重发，不能从头再来。第三是反馈信令本身也要消耗空口资源，反馈太频繁，资源就被吃掉了。

所以现代通信系统从来不走“非此即彼”的路线，而是把前向纠错（FEC）和重传（ARQ）绑在一起，形成混合自动重传请求，也就是HARQ。FEC负责兜住那些轻微损伤的数据块，HARQ负责处理那些FEC救不回来的情况。这样设计的好处非常明显：多数场景下靠冗余比特就能修复，不用启动重传，时延和资源都是最优的；少数严重受损的情况才付出重传代价，速度和可靠性取了一个平衡。

这里我插一句经验之谈：很多人初学的时候会把HARQ看成“简单的重传加纠错”，但实际做协议栈或者做物理层联调的时候会发现，HARQ的复杂度远不止“重传”两个字，它牵扯到软合并、冗余版本、进程管理、时序关系、调度策略，每一环都是坑。后面几节我会逐一拆开讲。

2. 从经典ARQ到现代HARQ的演进路线

2.1 经典ARQ：停等、回退N、选择性重传

在进入5G的HARQ细节之前，有必要先把经典ARQ家族的三个基本款理清楚，因为它们是理解一切的基础。

第一款是停等协议，Stop-and-Wait，逻辑最简单：发一个包，等确认，收到确认再发下一个，没收到就超时重发。优点是实现简单、内存占用小，缺点是效率极低，链路大部分时间都在空等。4G/5G为什么不用纯停等？因为空口带宽宝贵，一个载波上一秒钟能传几千上万个传输块，你要是发一个停一次，吞吐量直接废了。解决方案不是抛弃停等，而是用多个停等进程并行跑，这个思想一直延续到了5G，后面讲HARQ进程数量时会细说。

第二款是回退N重传，Go-Back-N。这个协议允许发送端连续发多个包，但接收端只按顺序收，一旦某个序号缺失，之后的一律不要，全部丢掉，发送端得从那个缺失的包开始重发后面所有的包。优点是不用给每个包做重排缓冲，接收端省内存，缺点是信道稍差就疯狂重传，浪费巨大。在高速率、低时延要求的5G场景里，回退N显然不是理想选择。

第三款是选择性重传，Selective Repeat。它的改进在于：接收端对每个包单独确认，哪个坏了重传哪个，其余正确接收的包继续使用。这样就不会因为一个坏包连累一堆好包。代价是接收端要做重排序缓冲区，同时发送端要维护一个复杂的状态窗口。5G RLC层的AM模式，本质就是一个带窗口机制的选择性重传协议，但它不和物理层交织，主要用于处理PDCP之下、MAC之上的重排序。

2.2 HARQ的核心思想：把前向纠错和反馈重传融合在一起

ARQ本身听上去不复杂，但问题是它动辄重传一整个协议数据单元，而且没有利用接收端收到的坏包里的有用信息。HARQ厉害的地方在于：接收端收到坏包后不会立刻扔掉，而是先存下来，等待重传版本到来，然后做合并解码。

合并解码有两种思路。第一种叫追尾合并，Chase Combining。所有重传版本和首次传输使用完全相同的编码比特，接收端把多次接收的软比特按符号位对齐后做等增益合并，等效于把同一个信号传输了多次，信噪比叠加，解码成功率自然提高。第二种叫增量冗余，Incremental Redundancy。每次重传携带不同的冗余比特，第一次传的可能是系统码和部分校验码，重传时补充新的校验码，等效于在接收端逐步组成一个更低码率的纠错码。IR方案的纠错增益比CC方案更高，但实现复杂度也更高，因为要生成和管理多个冗余版本。

5G里把CC和IR结合使用，具体的做法是按冗余版本编号来区分。传输块首次发送时用一个RV，重传时依次换其他的RV，接收端可以自行选择是合并还是增量解码。这样做的好处在实际系统里看得非常清楚：一个传输块首次传输后，如果CRC校验失败，接收端不会把它丢掉，而是把软比特缓存下来；等到重传版本来了，两个版本叠加后，很可能一次重传就能解出来，不需要第二次重传。如果还是不行，再叠加第三个版本，以此类推。

有人会问，既然IR这么强，为什么不一开始就把冗余全部发出去？当然不行。冗余越多，有效数据越少，首次传输的成功率高没有意义，因为频谱效率被拉低了。HARQ的精髓在于“按需分配”：轻信噪比环境下，少冗余就够；差信道条件下，才逐步付出额外开销。信道是变的，所以这个度也是动态的，这就是为什么HARQ要跟链路自适应联动。

3. 5G NR中的HARQ实现细节

3.1 HARQ进程数量与并行调度

前面说过，纯停等效率低，所以系统用多个并行停等进程来掩盖反馈和重传的等待时间。4G LTE用的是8个下行HARQ进程，5G NR对下行最多支持16个HARQ进程，上行则是12个。为什么从8个增加到16个？一个重要原因是5G的子载波间隔更高，时隙更短，在同样的反馈等待时间内，可能已经发出去更多的传输块，如果没有足够的并行进程，发送端会被迫停顿等待。

进程数量的设计不是拍脑袋决定的，它取决于一个关键不等式：进程数必须足够涵盖从数据发送到反馈返回的整个往返时间，包括传播时延、处理时延、调度周期和反馈信令的传输时间。以中频段为例，时隙长度是0.5毫秒，如果往返时间需要4毫秒，那就至少需要8个进程才能填满这条流水线。5G因为灵活的子载波间隔配置，不同场景下时隙长度差异很大，所以进程数上限要留足余量，16个就是一个工程折中。

HARQ进程在调度器中的管理逻辑是：每个进程有独立的状态机，包括空闲、正在传输、等待反馈、重传排队等状态。调度器分配资源时，必须考虑哪个进程当前可以承载新的数据或者重传数据，不能把一个还在等反馈的进程再次调度给新数据，否则接收端就分不清哪个传输块对应哪个HARQ序号了。这听起来简单，但在多用户、多业务并发的时候，调度器要维护全局状态表，冲突率一旦上升，系统性能就会明显下降。实测中经常看到吞吐量抖动，排查到最后发现是HARQ进程管理逻辑在极端流量下出了竞态。

3.2 上行与下行HARQ时序关系

5G NR的HARQ和LTE有一个很大的差异：时序关系是动态可配的，而不是固定死的。在LTE里，下行数据传输到ACK/NACK反馈之间的时间基本上是固定的，你可以在标准里查到一张死板的时间表。NR把这套固定时序打破了，引入了动态时序指示，比如下行数据到达后，基站可以通过PDCCH调度的时域资源分配字段，显式告诉终端在时隙n之后的第K个时隙反馈HARQ信息。这个K值在RRC配置和DCI里联合控制，实际工程中要根据业务时延需求、处理能力上限和信道环境做联合优化。

这个灵活性对URLLC业务至关重要。URLLC要求端到端时延低至个位数毫秒，如果还像LTE那样固定4毫秒之后才能反馈，光往返就耗掉一大半预算。所以5G允许把反馈提前，甚至在同一个时隙里完成数据接收和反馈发送。代价是终端必须在极短时间内完成数据校验和软比特缓存更新，对硬件处理时延要求很高，这也是很多终端厂商在早期实现时容易踩坑的地方。

上行HARQ也有自己的门道。终端发数据到基站，基站通过DCI或者专用RRC参数配置上行反馈时序，同时还涉及跳频和资源分配。特别要提的是，上行HARQ和下行HARQ不能简单复用一套进程管理，因为上行调度受限于终端能力和功率预算，终端同时能维护的HARQ进程数可能小于理论上限。实际网络配置时，会有一个HARQ能力协商过程，终端上报自己能支持多少进程，基站按上报值配置，超出能力硬撑的话，终端处理不过来，丢包率会暴涨。

3.3 自适应调制编码与HARQ的联动

HARQ不是孤立工作的，它和AMC（自适应调制编码）是深度绑定的。AMC根据信道质量选择一个调制阶数和编码码率，目标是把初始误块率控制在10%上下。这个数字听着很怪，为什么不把初始误块率设得很低，比如1%？因为初始误块率设得太低，就意味着AMC选了一个过于保守的编码方案，频谱利用率被牺牲掉了。10%是工程上的平衡点：大多数数据块能一次成功，剩下10%左右的失败通过一次或者多次HARQ重传救回来，综合频谱效率和时延后，整体表现最优。

基站内部有一个外环调节算法来做这个联动。基本原理是：如果一个HARQ进程经历了一次重传就成功，说明MCS选择基本合理；如果经常需要两次以上重传，说明信道质量在恶化，外环就把信道估计结果往下修正，调度器选择更低的MCS；如果长时间没有重传，说明信道条件好于预期，外环可以把信道估计往上抬，尝试更高的MCS。这个外环参数我在实际优化里调过很多次，上升步长通常很小，下降步长很大，因为从失败恢复的成本远高于从保守到激进的成本。

这里有一个非常重要的实测心得：HARQ重传率本身不是“越低越好”。如果全网统计的HARQ重传率低得离谱，比如不到1%，反而说明你这个网络的MCS配置偏保守，吞吐量还有上升空间。健康的网络重传率通常在5%到15%之间，关键看业务模型和信道分布。很多刚入门的人一看重传率10%就吓得要死，其实这恰恰说明链路自适应在正常工作。

4. RLC层的AM模式与重传补充

4.1 RLC AM模式的窗口机制

MAC层的HARQ负责快速重传，但它不是万能的。HARQ的最多重传次数有限（NR里下行默认配置一般是不超过4次），如果超过了这个次数仍然解码失败，数据就得向上层交底。这时候RLC层还在下面设了第二道重传保险，这就是RLC的AM模式。

RLC AM的基本机制和经典的选择性重传很像，但有几个关键差异。第一，RLC的序号空间比HARQ的传输块序号大得多，它可以跨越很多个传输块一直计数，允许做长窗口管理。第二，RLC维护发送窗和接收窗，窗口大小由RRC协议参数配置，实际网络中默认配置通常能支持非常大的在途数据量。第三，RLC的状态报告是由接收端触发的，接收端检测到序号空洞后，会向发送端发送一个状态PDU，告知哪些序号已经收到、哪些缺失，发送端根据状态报告进行选择性重传。

窗口机制的核心是序号连续性。发送端维持一个发送状态，记录下一待确认的序号。当收到接收端的ACK时，窗口滑动，释放对应的发送缓存。如果窗口满了，发送端必须暂停发送，等待接收端的确认或重传请求。在某些高性能场景比如大量小包汇聚时，RLC窗口很容易成为瓶颈，尤其是时延往返较大的场景，窗口不够大会直接限制吞吐量。所以4G/5G系统里的RLC窗口默认配置一般做得比较大，但也不能无限制大，因为窗口越大，接收端需要缓存的数据就越多，内存开销和重排复杂度都涨。

4.2 丢包、重排序与重复检测

重传协议绕不开一个基础问题：接收端怎么处理乱序包和重复包？

在MAC层，HARQ是停等进程并行的，接收端收到的传输块天然可能在时间上乱序；在RLC层，AM模式下面的PDU也可能因为HARQ重传过程导致乱序。乱序的数据不能直接往上层递送，因为上层协议如PDCP要求序号连续，乱序会导致IP报文重组失败。所以RLC接收端必须有重排序缓冲区，把乱序的PDU缓存起来，等待缺失的序号补上后再按顺序提交。

重复检测同样重要。一个RLC SDU可能在某些极端情况下被重复发送，比如发送端的ACK丢了，发送端不知道接收端已经收到，就会重发一遍。这时候接收端必须能识别出重复的PDU并将其丢弃，不能重复向上层递交。RLC通过序号比对来完成这个功能，收到的序号的某个PDU如果已经在缓冲区里了，就直接丢弃新到的副本。

实际工程里，重排序和重复检测最容易在高吞吐的大包场景出问题。我在一次模拟环境测试中就碰到过，RLC接收窗口在某时刻填满了大量乱序PDU，窗口无法滑动，导致吞吐量突然降到零，终端侧表现为大文件传输卡住不动。后来分析发现，是某个小概率的乱序场景触发了窗口锁死状态，标准里的重排序定时器作用没有完全覆盖这种情况。解决的办法是通过配置参数调整重排序定时器和轮询机制，增加了触发状态报告的频率，把窗口卡死条件绕开。

4.3 RLC与MAC层重传的分工边界

很多人搞不清楚MAC层HARQ和RLC层AM重传的分工到底在哪。我习惯用一个比方：MAC层的HARQ是急救室，快速响应、马上处理，每次抢在几毫秒内完成止血；RLC层的AM是康复病房，等急救处理完之后，还有问题的话再来一遍，速度慢一些但也能修复。

从时延角度看，HARQ的一轮重传通常在几毫秒内完成，而且多数情况下一次重传就能成功，它处理的是物理信道瞬时衰落造成的随机误码。RLC重传要经过步骤：看到丢失报告，发送一个状态PDU，发送端再调度RLC重传，这个流程走下来，时延往往要几十毫秒甚至更多。它处理的是HARQ耗尽后的持续信道恶化、建设优化缺失、调度器考虑不周等问题。

从资源角度看，HARQ重传需要物理层资源重新调度，每个传输块都有对应的软合并缓存。RLC重传不涉及物理层重编码和软合并，它只是重新组装一个PDU交到MAC层进行一次新的传输，复杂度较低，但它占用的传输资源依然要经由调度器分配。

大多数业务场景下，理想状态是HARQ一轮重传就能兜住绝大多数随机误码，RLC几乎不需要动用重传。一旦你统计中发现RLC重传占比偏高，那往往意味着物理层的信道自适应出了系统性问题，单纯通过调整RLC参数很难根治。这是我做优化时的一个重要经验：RLC重传率是物理层和调度器健康状况的“负面镜子”，看到它涨上去，应该先去查链路自适应和功率控制，而不是马上调RLC定时器。

5. 重传协议背后的参数计算与实际配置

5.1 定时器配置经验与踩坑记录

5G NR里和重传相关的定时器和计数器不少，配置错了，轻则吞吐量异常，重则链路卡死。先列几个关键参数：HARQ最大重传次数、RLC最大重传次数、RLC轮询PDU状态上报触发、回报禁止定时器、丢弃定时器。每一个都值得认真对待。

以RLC轮询机制为例，发送端需要通过轮询bit来请求接收端发状态报告，不然接收端才不会主动告诉你“我收到了哪些”。轮询触发次数太少，状态报告不及时，乱序窗口迟迟收不到缺失数据，时延白白增长；轮询太频繁，状态报告过多，空口资源被信令吃掉。在我们实验室配置过一个测试用例，把轮询周期设置得过短，结果大量RLC状态PDU挤占了下行业务信道资源，Ping时延反而恶化了，这属于典型的“过度保底导致资源浪费”。

HARQ最大重传次数是一个更敏感的参数。它不是越大越好。重传次数增加，成功概率上升，但时延上限同步上升，缓存压力也上升。对eMBB业务，配置三四次重传很常见；对URLLC业务，时延预算就那么几毫秒，根本等不起多轮HARQ回环，所以很多URLLC配置干脆设成一到两次初始传输失败后直接丢给RLC处理，甚至直接依赖更高层的重传，而不是在空口死磕。这个取舍在标准里没有直接写死，完全靠网络配置决定。

实际配置时一定要结合频段和信道环境。在毫米波频段，信道衰减快，移动环境下多普勒频移大，重传成功率往往不如中频段。有些场景里，一个传输块重传三次还解不出来，再用第四次重传的收益已经趋近于零，在这个时候不如把资源让给新数据块。我们做过一轮实测，把毫米波场景下的HARQ最大重传次数从4降到2，整体感知吞吐量反而提升，因为重传占用的资源被释放给了新鲜数据。

5.2 传输块与HARQ进程的资源映射

HARQ进程和传输块不是一对一的固定映射，调度器可以灵活决定哪一个进程承载哪一个传输块。但这个灵活性如果处理不好，就会出现“进程饥饿”或者“进程冲突”的问题。

从终端侧看，一个HARQ进程对应一条独立的软合并缓存和状态机。当基站调度一个新传输块给某个HARQ进程时，终端会先把该进程的旧数据清空；当调度的是重传时，终端会把新到的版本和缓存里的软比特做合并。如何区分是新传还是重传？通过DCI里的NDI字段。NDI翻转表示新数据，NDI不变表示重传。这个机制是理解HARQ调度信息的老大难问题，实际上记住一句话就够：调度器想让终端清空老数据时，翻转NDI；想让终端合并新数据时，保持NDI不变。

实际工程里，NDI翻转错误是导致“接收端清错数据、反复错上加错”的头号原因。尤其在高聚合载波或者多TRP传输场景下，终端同时处理多个HARQ进程时，有一个进程的NDI解析出错，就会导致该进程后续一系列传输全部错误。排查这类问题，最快的方法是抓协议栈日志，看每个HARQ进程上NDI的历史翻转序列，一旦发现规律异常，就能快速定位。

再说一个经常被忽略的参数：HARQ软合并缓存大小。终端侧缓存大小有限，当HARQ进程很多、每个进程的软比特都很大时，终端的软合并深度可能受到限制。某些高性能终端为了支持超大传输块，不得不牺牲合并进程数或者减少冗余版本的内存占用，这些能力都会通过UE能力上报带给基站。基站配置时要根据终端能力做“量体载衣”，不能一个固定模板走天下，否则终端在特定组合下会出现缓存溢出、失去合并能力，重传成功率大幅下降。

6. 常见问题、实测经验与排查套路

6.1 调度器与HARQ进程冲突的典型故障

我遇到过的最典型的调度器冲突场景是这样：某下行大流量测试中，为了让吞吐量冲高，调度器给同一个HARQ进程连续调度了两次新数据，中间应该翻NDI但没有翻，终端认为第二次是重传，把两次完全不同的数据做了软合并，导致解码必然失败，而且失败之后还会按照重传路径继续误处理。这个问题在协议栈开发的时候其实是很难发现的，因为单看调度器代码逻辑是对的，但跨层协作的状态更新没有做同步。

排查这类问题的有效手段是模拟多径衰落，让首传失败率人为升高，然后观察重传流程的完整链路：从MAC层进程状态变迁，到DCI里的NDI、冗余版本和进程ID，再到终端侧软合并是否触发。有一次排查，我们把NDI、RV、进程ID三个字段拿出来做联合分析，画在时间轴上，瞬间就看到异常点：某个进程在同一批次连续收到两次NDI未翻转的调度，但两次的RV版本相同而数据内容完全不同。这证实了调度器侧的进程管理状态出现了重复分配。

从工程排障的角度，我给大家一个建议：不要只盯吞吐量指标，一定要同时看多个维度的计数，包括HARQ首传成功率、重传成功率、NDI异常次数、软合并命中次数、RLC状态PDU频次。这些计数器联合起来，一张表就能暴露出大多数重传相关问题的根源。

6.2 误块率目标该怎么设

前面提到，AMC的目标误块率通常打在10%左右，但真的是所有场景都适合吗？并非如此。eMBB大文件传输可以从10%起步，让HARQ承担修正职责；但URLLC业务对时延极其敏感，10%的首传失败率意味着每10个数据块就有一个要经历额外重传时延，这会造成明显尾部时延恶化。所以很多URLLC配置会把AMC目标误块率压到1%乃至更低，用频谱效率换时延确定性。

URLLC场景下还可以启用一种特殊机制：预配置多个MCS等级的传输方案，同一个数据包用多个资源块重复发送来对抗衰落，本质上是用空间和时间的分集替代重传。这种方式下，HARQ重传反而变成了兜底中的兜底，因为主要的可靠性保障来自传输本身的重复。这就是5G里所谓的多传输接收点的宏分集思想。

外环自适应在实际中还有另一个坑：目标误块率如果设得过高，比如超过20%，虽然频谱效率会上升，但HARQ进程的长时间占用也会导致调度器可利用的进程池变少，用户间的公平性和时延表现会恶化。一个传输块占着一个HARQ进程反复重传，其他数据块等着进程释放，这种排队效应在重负载下非常明显。所以不要只盯着自己的链路层指标做优化，要结合用户数、业务特性和进程池资源整体判断。

6.3 时延敏感业务怎么规避重传时延

URLLC对时延的要求苛刻到毫秒级，在这个预算内，传统HARQ的多轮反馈重传基本是不可承受的。怎么办？业界用的不只是降低目标误块率，还有“免重传”设计思路。

一种做法是资源预留。把一个数据块同时放在多个时隙、多个波束方向或者多个载波上重复传输，接收端只要有任意一个副本正确解码就成功，不需要跑反馈重传流程。另一种做法是提前重传。发送端不等接收端反馈，预估信道可能恶化，直接发送冗余版本，接收端如果首传已经解出，就直接丢弃冗余版本，浪费一点资源换取确定性。这两种做法在标准上都有对应的配置方式，关键还在于调度策略的配合。

我实际测试过一个URLLC场景，配置的是一个极短的HARQ反馈周期，比如同一个时隙内完成下行数据接收和上行ACK发送。第一次联调时发现终端根本来不及在这么短时间内完成解码和反馈，原因是终端实现的处理流水线有固定时延，并没有按标准里理论最短路径优化。后来通过减少解调处理的级数、用专用硬件加速CRC校验，才勉强达到时序要求。这里想说明的是，协议标准给的是上限能力，实际设备的processing timeline往往决定了你能用多激进的参数。网络侧下发配置前，最好先确认终端型号的时序处理能力登记表，否则就会出现频繁的HARQ超时和一连串莫名其妙的RLC重传。

6.4 独家避坑总结：重传参数的联动影响

最后整理几个我踩过之后记忆犹新的坑，供做现网优化和协议开发的同行参考。

第一，HARQ重传进程和RLC重传的排队关系。有些协议栈实现里，RLC层重传的PDU进入MAC层后会排在缓存队列末尾，而不是走优先通道。当用户面下行缓存很大时，RLC重传PDU会被新数据挤到后面，导致RLC重传时延被无限拉长，用户感知掉线。这不是标准问题，而是实现问题，但现网中真实存在。排查办法是看RLC重传PDU的排队时延统计，超过了预期就要查MAC层的优先级处理逻辑。

第二，上下行HARQ进程数的配置不对称也会引发问题。下行16个进程配合上行12个进程是常规配置，但如果你在FDD频段下把上行的HARQ反馈时序拉得过长，下行的16个进程可能在等待反馈期间就用完了，调度器被迫空闲等待。这个过程反映到用户端就是速率忽高忽低，平均吞吐量远低于预期。

第三，软合并缓存大小和HARQ进程数是相互制约的。一台终端报告的软比特总数是固定的，如果基站配置的HARQ进程太多，每个进程能够分配到的软比特就少，高码率传输块就无法完整缓存软比特，这时候一旦首传失败，终端只能选择放弃缓存，重传时无法做完整合并，只能当新数据解码，重传成功率自然下降。所以进程数量的配置不只是看吞吐量目标，还要看终端软比特能力和典型传输块大小。

第四，RLC状态报告的传输本身也需要占用上行资源，在上下行配比极端偏向下载的场景里，如果上行资源太小，RLC状态PDU会被不断延迟，发送端迟迟收不到状态报告，发送窗口就会卡住。我在一个TDD大比重下行场景里就见过这种事，明明下行信道很好，但是RLC层因为收不到状态报告而发送停滞，最终吞吐量被上行反馈瓶颈死死按住。解决方向是增大上行反馈资源的预留比例，而不是去调下行MCS。

7. 个人体会：重传协议做久了，越做越谨慎

做了这么多年空口协议和性能优化，我对重传协议的感受是：它不像信道编码或者波束管理那样“炫技”，但它几乎参与了每一次吞吐量抖动、每一次时延坍塌、每一次用户投诉的幕后推理。重传协议设计得好的系统，你肉眼看不到它工作，但它的每一次静默成功，都是整个空口链路健康的证明。

我个人操作中的一条体会是：遇到速率或者时延问题时，先看HARQ统计，再看RLC统计，最后才去查物理层。这个顺序看起来反直觉，但实测效率很高。因为物理层问题往往已经体现在重传指标里了，重传指标恰好是所有下层问题的汇总出口。有一次一个疑难问题查了三天，最后发现只是某个站的HARQ最大重传次数的配置被篡改成了16次，导致每个坏块都要反复尝试十几次才罢休，整个小区的下行资源全被重传吃干净了。一个小参数，毁掉一个小区，这种事在现网里真的会反复发生。

最后再说一个小技巧。做外场测试的时候，记得同时开启MAC层和RLC层的日志，以HARQ进程ID为主键，把每个传输块的调度次数、重传次数、每次的RV和NDI、最终成功还是失败完整记录下来。分析的时候用表格透视，按照进程ID和时间排序，大多数重传疑惑都能在这个数据面前现出原形。这个技巧帮我在无数次联调里快速定位问题，强烈建议新入行的工程师都养成这个习惯。