做4G LTE空口协议分析这几年我最大的感受是网上讲信令流程、讲MAC调度、讲PDCP加密的帖子不少但专门把RLC层讲透的内容真的不多。很多入门的同学一打开Wireshark或者LTE仿真平台看到RLC那一堆PDU头字段就犯迷糊要么把SN当成没用的序号直接忽略要么在AM模式的重传机制里绕不出来。其实RLC这个层的逻辑一点都不复杂它就是个“货车装载调度员”负责把上层的大包拆成小包、编排序号、丢了补发、乱序重排。这篇文章我就从协议栈定位、三种模式、PDU结构、重传机制、参数配置、问题排查这几个维度把RLC层一次讲透内容主要基于3GPP TS 36.322以及我这几年的抓包排障经验希望能给做LTE协议开发和无线网络优化的朋友一些实际参考。1. RLC在4G LTE协议栈中的核心定位1.1 从协议栈分层看RLC的职责边界RLCRadio Link Control无线链路控制在LTE协议架构里位于PDCP和MAC之间。从用户面往下看从上到下依次是IP层、PDCP、RLC、MAC、PHY。这个位置不是随便选的。PDCP层负责IP头压缩、加密和完整性保护它吐出来的PDCP PDU通常有几十到上百字节最常见的就是包含完整TCP/IP头的数据包。而MAC层实际和物理层交换的传输块TB大小是随着CQI、MCS、RB分配数量动态变化的信道好的时候可以塞大量数据信道差的时候可能连一个小IP包都放不下。如果让PDCP的大包直接去撞MAC的传输快大小结果就是要么硬塞不下要么丢包重来。中间如果没有一个层来做拆分和缓冲TCP这类上层协议会频繁触发超时重传效率低下到没法用。RLC就是来做这个“削峰填谷”工作的。发送端它把PDCP PDU分成长度适中的RLC PDU交给MAC层组装到传输块里接收端则把MAC送上来的一堆RLC PDU按序列号拼回完整的PDCP PDU。这个过程跟物流中转站拆包裹、拼包裹非常像一件大货物放不进小车就拆成几件分车运到了目的地再按编号拼装还原。理解了这个原则RLC为什么设计成分段、串联、按序递交这几个功能就顺理成章了。另外要强调一点RLC的接口不只是向下对MAC、向上对PDCP它还有一条旁路通向RRC。RRC负责配置RLC实体的工作模式、SN长度、各定时器参数同时在无线链路失败RLF等异常场景下RLC也会往上传状态事件。做协议开发的时候如果只盯着数据面忽略了RLC和RRC之间的配置交互遇到配置错误导致的异常行为往往一头雾水。1.2 RLC为什么不做加密、不做调度很多人刚接触协议栈时有个习惯喜欢把各层功能往一个“大管道”里装觉得反正都是处理数据谁干都一样。但LTE协议栈的分层非常严格。RLC层有自己的职责清单按3GPP TS 36.322的定义主要包含上层PDU的传输也就是说它是个承载通道分段segmentation与重组reassembly串联concatenation把多个小SDU塞进一个PDU里减少头部开销支持三种传输模式TM、UM、AMAM模式下的ARQ纠错对UM/AM模式下的重复包检测对AM模式下的协议错误检测与恢复对AM模式下的发送端流量控制请注意RLC不负责加密加密是PDCP的活RLC不负责物理层调度资源分配是MAC和PHY的事。我经常在信令分析里看到有人把“RLC重传多”直接等同于“物理层信号差”这个判断方向本身没错但推导逻辑不严谨。RLC重传率高确实经常反映空口质量差但根源可能在MAC层的HARQ失败可能在PDCP下发的数据本身就对丢包敏感也可能是RLC参数配置不当不要一上来就断定是底层信号问题。RLC还有一个容易忽略的职责就是对AM模式的发送窗口和接收窗口做管理。AM模式用序列号维护一个滑动窗口发送窗口大小一般是相对于最大SN的一半比如SN是10比特时发送窗口最大为512。窗口的作用是防止接收端处理不过来导致缓存溢出也方便发送端决定哪些PDU还需要保留缓存以备重传。很多做上层应用开发的朋友不理解为什么RLC要设窗口——你可以把它想象成快递柜的格口数量柜子一共只能存这么多包裹存满了就必须等收件人取走才能放新的设置窗口就是防止无限制地把包裹堆进来把柜子撑爆。2. 三种工作模式的设计逻辑从对讲机到快递签收2.1 TM透明模式只干活不记账TMTransparent Mode透明模式是RLC里最省事的一种模式。它不加RLC头部不做分段不做重组没有序列号也没有任何反馈机制。上层PDU长什么样RLC就原封不动地传给MAC像一根直通管道。听起来像什么都没干那为什么还需要它因为在LTE里存在一些点对多点的广播信道比如BCCH广播控制信道和PCCH寻呼控制信道。基站向小区内所有终端喊话喊完就完不可能指望某个终端回一个“我收到了”的确认也不可能为了一个终端去重传广播消息。更关键的是这些系统消息MIB、SIB的尺寸本身很小完全不需要分段加上序列号和反馈机制反而是纯开销。所以SRB0就使用了TM模式用来传输RRC的系统消息和寻呼消息。我最早看协议文档时对TM模式有一种“因为它太简单所以不重要”的错觉。实际做VoLTE呼叫流程分析时发现BCCH上承载的SIB1如果反复读取失败终端甚至无法完成小区接入这层“透明”其实是整个连接建立的地基。而且要注意TM模式下RLC虽然不做加密和完整性保护但PDCP层在BCCH上也不做加密所以TM模式在安全性上完全依赖物理层和上层协议的保护系统消息被伪造的风险也是靠RRC层的验证来控制的。2.2 UM非确认模式丢了不管但至少有序UMUnacknowledged Mode非确认模式比TM进了一步给PDU加了RLC头部和序列号接收端可以靠SN做排序和重复检测。但UM模式没有ACK/NACK没有ARQ重传接收端发现中间缺了一段不会去索要只能把这个空洞如实告诉上层由上层决定怎么办。打个比方UM就像寄平信信封上有编号你收到信后能看出哪封缺了但邮局不会因为你缺了某一封而单独补寄一封。UM模式的典型场景是VoLTE的语音RTP数据以及一些时延敏感、允许少量丢包的业务。为什么语音要用UM而不用AM原因很简单语音帧如果因为等待重传而晚到200毫秒用户听到的不是“少了一个字”而是整句话都错位、卡顿体验反而更差。语音业务对完整性不敏感对时延极度敏感。与其花时间重传不如让接收端容忍丢帧靠PLC丢包补偿算法或者静音填充去弥补听感。搞VoLTE优化的人都清楚UM模式下RLC本身不做重传语音质量的好坏更多取决于MAC层HARQ能否在毫秒级把误块救回来。UM模式的另一个作用是配合PDCP层的按序递交。因为PDCP层保证上层数据按序递交如果下层没有顺序保证PDCP还得自己去排序工作量就大了。UM RLC在收到乱序的RLC PDU后会基于SN做重排等一等乱序的数据能拼成完整PDCP PDU才往上交。这个“缓冲等待”的代价是时延UM配置里有一个t-Reordering参数就是控制接收端愿意等多久的时间阈值后面在参数配置部分会展开说。2.3 AM确认模式精准到分片级的可靠交付AMAcknowledged Mode确认模式是RLC里最复杂、用得最多、也是排障时最需要花心思的模式。AM模式提供可靠、按序的传输服务接收端对上来的数据要确认发送端对没确认的数据要重传直到对端明确表示收到为止。它像寄快递签收加售后你发出包裹对方签收后系统才有回执长时间没回执你就要打电话去问丢了就补发。AM模式用在SRB1、SRB2RRC信令和绝大多数DRB数据无线承载上。RRC信令绝对不能丢丢了终端的状态很可能错乱必须AM。TCP业务虽然上层自己有重传机制但TCP重传的代价非常大——每次重传要等超时等RTO如果RLC不做底层纠错TCP层的吞吐量会被频繁的超时拉低到惨不忍睹。RLC在空口做一层快速ARQ把偶发丢包挡在下面TCP层基本无感知。AM模式引入了几个核心机制发送缓存、轮询Polling、状态报告Status Report、重排与重组、流量控制。发送端会把没有收到确认的PDU一直放在缓存里收到对端的STATUS PDU确认某个SN后才删除如果收到NACK就把对应的PDU重新取出来发送。接收端则要维护接收窗口对乱序到达的PDU进行缓冲等中间的空洞补上之后再按顺序把数据交给PDCP。AM模式还支持分段级重传也就是说NACK可以精确到某一个PDU的某一段偏移发送端只需要重传缺失的片段而不是整个PDU在弱场下可以减少不少重传开销。AM模式的另一个重要机制是SDU丢弃。如果上层数据因为时延等原因被判定为过期RRC配置了丢弃定时器AM RLC就会丢弃对应的SDU并通知上层。这个机制在实时性要求高的业务里很重要比如某些业务数据不能无限期等待重传宁可丢弃也不能把整个发送窗口堵住。3. RLC PDU结构解析与协议分析实操3.1 三类数据PDU的头部差异要做RLC层协议分析第一关就是把PDU头看懂。RLC的PDU分成两大类数据PDU和控制PDU。数据PDU承载上层PDCP PDU控制PDU特指状态PDU用于AM模式下的反馈。TMD PDU最简单在TM模式下RLC头部是空的PDU内容就是上层PDU的一个原样复制抓包时你不会看到任何RLC专属字段。UMD PDU头部则包含几个关键字段固定头部里的SI字段Framing Info2比特表示这个RLC PDU和上层SDU的边界关系。SI00表示一个完整的SDU的开始和结束都在这个PDU里SI01表示这是某个SDU的开始部分但后面还有分段SI10表示这是中间分段既不是开始也不是结束SI11表示这是SDU的最后一个分段。E位Extension bit用来指示后面是否还有LILength Indicator扩展字段当多个SDU被串联到同一个PDU时需要用LI标记前一个SDU结束的位置。SN序列号UM模式使用6位或12位的SN具体由RRC配置。SN长度直接影响窗口大小和传输效率SN太短在高速率下容易回绕这也是配置时要注意的点。AMD PDU头比UMD多一个分段偏移字段。AMD PDU固定头是2字节或3字节SN为10比特时固定头2字节SN为12比特时固定头3字节。关键字段有D/C位0表示数据PDU、SN、E位、FI字段功能同UM的SI以及可选的SOSegment Offset分段偏移。当一个PDU被分段重传时SO用来指示该分段在原PDU中的起始字节位置。我录制过几个LTE空口抓包课程每次讲解UMD和AMD头部时都提醒学员Wireshark里看到的“Framing Info”字段就是从SI字段翻译过来的它描述的是RLC层对SDU分段后的位置状态跟PDCP层、IP层的任何字段都没有关系。很多人把SI看成了某种IP分片标志理解就偏了。3.2 STATUS PDU反馈的“账单”STATUS PDU是AM模式RLC的“生命线报文”类似于接收端给发送端的一份账单我收到了哪些哪个SN丢了精确到分段级别。STATUS PDU的核心字段包括D/C位为1表示控制PDUCPT字段Control PDU Type值为0时表示STATUS PDUACK_SN确认序列号表示在ACK_SN之前的PDU都已经按序收到了注意这个值的含义是“下一个预期接收的SN”NACK_SN一个或多个每个代表一个缺失的AMD PDU的序列号SO_start和SO_end用于分段级别的NACK说明缺的是某个PDU的哪个字节范围发送端可以根据这个信息进行分段重传协议分析中状态PDU里的NACK信息含量非常丰富。如果ACK_SN相比前一个状态报告跳跃了很多说明接收端一口气收到了大量连续的PDU信道状况良好如果NACK_SN成片出现则说明空口丢包严重或者底层传输块错误率很高。我遇到过一次上层TCP速率突然掉到三分之一的问题抓空口数据一看RLC状态PDU里NACK从SN200一路列到SN400几十条NACK清清楚楚列在那里问题方向和严重程度马上就能判断出来。3.3 用Wireshark解RLC的实操方法目前分析LTE空口数据的首选工具还是Wireshark。在配合USRP、商用扫频仪或者LTE仿真平台抓包时数据里一般会保留MAC层信息Wireshark能基于MAC上下行指示和逻辑信道类型自动识别并解码RLC层。但有几个细节需要特别留意。首先如果抓包数据里缺少MAC层上下文Wireshark会把RLC PDU当作无方向的通用UM/AM数据处理解出来的SN可能是乱序的重传检测也会失效。这时候可以在Wireshark里右键选择“Decode As”手动指定RLC channel类型和方向前提是你知道这条流实际走的逻辑信道。其次用TShark命令行处理大量RLC数据时合理的字段导出能显著提高效率。比如我可以导出frame.number、rlc.sn、rlc.nack_sn、rlc.fi等字段然后用Python脚本按时间戳统计NACK的分布。分析数据不需要看每个包的细节只要看整体趋势。这里有个判断RLC重传的注意点Wireshark对RLC重传的标记依赖于上下文缺少MAC方向信息时不准确需要结合NACK_SN和数据PDU的SN来交叉验证。另外处理大量抓包文件时我习惯先用tshark过滤出RLC控制面的STATUS PDU统计NACK分布再做FFT分析丢包周期。这个思路在定位“周期性丢包”问题上非常有效。比如某小区的上行丢包总是集中在每秒钟的第几百毫秒时间轴对齐一看正好是某个终端周期性发送测量报告的窗口这往往是半静态调度和动态调度冲突导致的一般很难靠肉眼发现。4. 重传机制RLC ARQ和MAC HARQ的分工与协作4.1 HARQ快、ARQ稳两套重传不是重复建设LTE空口有两条重传链路MAC层的HARQ和RLC层的ARQ。这两者经常被混为一谈但它们的工作级别完全不同我先把分工说清楚。HARQ是物理层和MAC层的快速重传工作在传输块级别。发送端通过HARQ进程和冗余版本等待接收端的ACK/NACK反馈。HARQ的最大特点是快往返延迟在几毫秒到十几毫秒之间特别适合物理层传输块的抢救。但HARQ的重传次数有上限由参数maxHarqTx限制常见配置是4到5次。如果传输块重传达到上限还是失败MAC层会把这个块放弃丢包的事实就上升到了RLC层。RLC ARQ是HARQ失败后的兜底机制。它的重传单位是RLC PDU延迟通常在几十毫秒甚至更长但机制更精细。RLC ARQ不是盲目对整个传输块重发而是根据接收端STATUS PDU里的NACK信息精确到具体的SN和分片偏移来补发。为什么需要这两层因为HARQ虽然快但能救的范围有限如果HARQ重传次数打到上限还没成功没有上层ARQ就该彻底丢包了而如果每个PDU都要靠RLC ARQ重传时延又是语音等实时业务无法接受的。两层配合HARQ负责快且频繁的抢救ARQ负责精准且兜底的补偿效率和可靠性就都保证了。4.2 轮询机制发送端不能干等也不该瞎问AM模式下发送端不能一直干等接收端主动汇报。如果接收端收包顺利可能很久都不发一个STATUS PDU发送端根本不知道该不该清空缓存。所以协议设计了轮询机制发送端在发送一些PDU时会把RLC头里的Poll位置1请求接收端回一个STATUS PDU。触发轮询的条件由协议和配置参数决定常见的有发送端未确认的RLC PDU数量超过pollPDU阈值未确认的数据量超过pollByte字节数发送窗口快被占满需要推进t-PollRetransmit定时器到期说明上一次轮询没有收到回应接收端收到带Poll位的PDU后会停止t-Reordering定时器立刻生成STATUS PDU回应。这里有个容易搞混的点接收端即使没有收到Poll自己在检测到序列号空洞时也会主动上报状态反过来发送端设了Poll也不代表对端一定马上回因为AM模式下可能被t-StatusProhibit定时器挡住。理解这个因果关系看状态报告频率突然变化时才不会误判。4.3 关键定时器各自的作用边界AM模式涉及几个关键定时器配置上有微妙的权衡t-PollRetransmit是发送端轮询的重传定时器。发送端发出Poll后如果在t-PollRetransmit时间内没有收到任何状态报告就会重发轮询并可能重传最老的未确认PDU。这个值设置太短会导致频繁轮询大量STATUS PDU挤占空口资源设置太长发送端迟迟发现不了状态报告的丢失缓存占用和时延都会变大。t-Reordering是接收端的重组定时器。接收端发现SN空洞后会启动这个定时器在它到期之前先到的乱序PDU都缓存在接收窗口里等待空洞补齐。这个值直接决定了AM模式的时延和乱序容忍能力。设太短空洞还没补上就往上递交上层会看到乱序设太长数据在RLC层滞留过久端到端时延增加。我在VoLTE优化项目中调过这个参数默认20毫秒在弱场下语音分片乱序严重调到40毫秒后语音包顺序性明显改善MOS分也提高了。但这个值不能盲目加大时延敏感业务加大t-Reordering反而会损害体验必须结合业务场景平衡。t-StatusProhibit是状态报告禁止定时器。接收端发出一次STATUS PDU后在这个定时器到期前不允许再发新的状态报告除非有更高优先级的触发条件。它的作用是抑制状态报告风暴如果每个乱序PDU都触发一个STATUS PDU空口上行会迅速被反馈包淹没。但t-StatusProhibit设太大发送端发现丢包的速度会变慢吞吐量受影响。低时延业务要把这个值设小一点高频反馈能加快丢包恢复。maxRetxThreshold是最大重传次数。单个RLC PDU重传超过这个阈值RLC就认为无线链路出了问题上报RLF给RRC触发无线链路重建或切换流程。配置上如果小区覆盖差适当调低这个值能更快触发切换避免用户长时间吊在弱小区里如果想让终端在弱场多扛一会儿就调高。工程上要结合无线环境统计来定。5. 关键参数配置与无线承载映射5.1 RLC模式与无线承载的对应关系在LTE网络里无线承载分成信令无线承载SRB和数据无线承载DRB通过RRC信令在连接建立时配置。RLC模式和承载的对应关系实践中的选择逻辑很清晰| 承载类型 | 典型用途 | RLC模式 | 选择理由 | | SRB0 | BCCH/PCCH上的RRC系统消息 | TM | 广播消息无法反馈消息尺寸小 | | SRB1 | RRC信令含NAS直传 | AM | 信令不可丢可靠性优先 | | SRB2 | NAS信令 | AM | 同样不可丢 | | DRBVoLTE语音 | RTP语音包 | UM | 对时延敏感允许少量丢包 | | DRB普通数据 | TCP/HTTP等 | AM | 需要可靠按序传输 |还有一部分特殊业务会用UM模式的DRB比如一些实时视频流或直播业务。选择的核心原则就一句话凡是要求数据可靠且能容忍一定延迟的优先选AM凡是实时性高于可靠性、少量丢包可以接受的选UM。配置无线承载的时候RRC里会下发RLC-Config信息单元其中包括SN长度、t-Reordering、pollPDU、pollByte、maxRetxThreshold等参数。SN长度影响窗口大小和可寻址的PDU数量高速率大窗口的业务需要更长的SN来避免回绕。5.2 参数配置速查与经验我整理了一份比较实用的AM模式参数配置表便于做无线参数优化时快速查阅| 参数 | 3GPP取值范围 | 常见取值 | 工程经验 | | t-PollRetransmit | 5ms~2500ms | 40ms~80ms | 弱场可适当调大避免频繁轮询 | | t-StatusProhibit | 0ms~1000ms | 10ms~20ms | 需要快速反馈可设为0但要低负载场景 | | t-Reordering | 0ms~1000ms | 20ms~40ms | 弱场语音适当调大低时延业务调小 | | maxRetxThreshold | 1~128 | 32或64 | 覆盖差调低加速RLF切换 | | pollPDU | 1~1024 | 32或64 | 取决于业务速率 | | pollByte | 1KB~无穷 | 8KB~16KB | 结合承载速率调整 |配置AM参数有一个很实用的经验不要单看一个定时器要整体考虑反馈链路。如果把t-StatusProhibit调大来省反馈开销就得配合更长的t-PollRetransmit否则发送端会因收不到反馈而频繁触发轮询重传如果把t-Reordering调得很大来提升乱序容忍就要考虑接收缓存容量和时延预算。参数之间是联动的改了一个不检查其他几个往往越调越乱。5.3 一个参数优化的实例之前做过一个FDD LTE下行吞吐量优化项目某区域RSRP在-105dBm左右的弱场用户下行速率一直不稳定从统计看RLC重传率有8%。一开始我调低了t-Reordering希望让接收端尽快上交数据结果重传率没降反而因为顺序递交被打乱TCP层出现了更多的快速重传。后来我反过来调大t-Reordering到40ms同时把maxRetxThreshold从64调到32让确实救不回来的PDU更快被放弃让TCP更快感知丢包整体的RLC重传率反而降到了3%吞吐量提升了近20%。这个案例说明弱场环境下联动的参数优化比单一参数调整靠谱得多。6. 常见问题与排查技巧实录6.1 典型问题速查表在LTE网络优化和终端协议栈调试中RLC层的疑难问题往往都有迹可循。我整理了下面几个高频问题用表格方便对照| 现象 | 可能原因 | 排查思路 | | RLC重传率超过5% | 弱覆盖、干扰导致BLER高HARQ失败上抛 | 看RSRP、SINR、MCS、BLER曲线先确认底层 | | STATUS PDU里连续大量NACK | 下行连续丢包或者上行反馈链路质量差 | 同时查看上下行BLER和PDCCH调度情况 | | TCP吞吐量突然掉半 | RLC层重传加窗口停滞 | 统计RLC重传时间点看是否与MCS切换、干扰突发对齐 | | VoLTE通话卡顿但RSRP很好 | t-Reordering配置不当或状态报告延迟 | 解析RTP包序号和RLC重传时间看延迟分布 | | RRC连接建立成功率低 | SRB0/SRB1相关RLC配置异常 | 核查BCCH重复周期、TM模式承载配置、RLF统计 |遇到RLC层问题一定要先做“分层定位”。RLC重传多根源八成在下面两层物理层的BLER高、MCS被压低、MAC层HARQ失败率高。只有当RLC重传率高但MAC层各项指标正常、PDCP层下发也没有异常时才怀疑RLC自身的配置或实现问题。6.2 一个真实排障案例下行吞吐量只有一半某次外场测试中下行吞吐量只有80Mbps理论上限150Mbps。抓空口数据后我首先看RLC层的统计重传PDU比例超过12%这个数字明显偏高。接着看MAC层调度发现MCS被调度器压到了接近最低档HARQ失败率高。这说明物理层信道质量已经差到了相当程度RLC重传只是结果不是原因。后来调整了天线方向RSRP从-110dBm提升到-97dBmSINR从3dB提升到12dBRLC重传比例直接从12%降到2%以内吞吐量恢复到140Mbps左右。这个案例看似简单但能说明一个容易忽略的问题RLC指标是上层综合反映定位时先排除MAC和PHY因素否则很容易在RLC参数上做无用功。6.3 另一个案例罕见的分段偏移BUG还有一次遇到某款4G模组在接入后上行总是丢包表现为状态PDU里NACK反复指向同一个AMD PDU。检查发送端后发现这个PDU被重新分段重传时SO偏移设置和接收端预期不一致。进一步排查确认是模组固件里RLC分段重传的实现版本和基站不兼容导致的解析BUG。这种问题在公版协议栈里极少见但一旦出现仅靠调参数是没用的最终通过升级模组固件解决了。这也提醒我们RLC层大部分问题是参数和环境问题但偶尔也会是协议栈实现层面的问题。遇到NACK集中指向同一PDU且伴随SO字段异常的情况可以考虑是否存在版本兼容问题。6.4 常用分析命令速查我用TShark和Python组合比较多。常用的几个命令过滤RLC数据PDU并导出关键字段tshark -r lte_capture.pcapng -Y rlc.sn -T fields \ -e frame.number -e frame.time_epoch -e rlc.channel_type \ -e rlc.sn -e rlc.length rlc_pdus.csv筛选STATUS PDU看ACK和NACKtshark -r lte_capture.pcapng -Y rlc.control_type 0 -T fields \ -e frame.number -e rlc.ack_sn -e rlc.nack_sn rlc_status.csv统计RLC重传标记数量tshark -r lte_capture.pcapng -Y rlc.retransmission 1 \ -T fields -e frame.number | wc -l这里需要提醒一点Wireshark里rlc.retransmission字段依赖上下文判断如果抓包数据里没有MAC层的方向信息或初始化信息这个字段可能根本不会出现或者出现但是不准确。此时要结合SN的连续性和STATUS PDU里的NACK来人工判断重传情况。我习惯把导出的RLC NACK数据按时间画成散点图看分布是否均匀、有没有周期性。之前定位一个周期性丢包问题就是靠NACK时间分布发现丢包集中在特定TTI附近再配合上行调度数据分析锁定了半静态调度和动态调度的冲突点。可视化的价值在这种场景下远超过肉眼看抓包界面。7. 排查RLC问题的几个实用心得最后分享几个我自己在实际操作中的体会。第一画图优先。遇到RLC层性能问题先把RLC重传率、MAC HARQ失败率、BLER、RSRP、MCS这几个指标放在同一个时间轴上你会很直观地看到是哪一层先劣化的。RLC重传率上升的时间点如果比BLER劣化晚几百毫秒那基本就是底层触发的如果MAC一切正常偏偏RLC重传率飙升才轮到怀疑RLC自己的状态机或缓存逻辑。第二排查NACK有时候要倒过来想。NACK多代表接收端没收到数据但收不到的原因不一定是空口丢包也可能是接收端的处理能力不足、窗口配置太小导致来不及接收或者状态报告被t-StatusProhibit定时器压制了。在分析双向流量时尤其要检查STATUS PDU的上行传输质量如果上行反馈丢了AM发送端也会盲目重发造成“努力白费”的假象。第三不要忽视RLC的版本和配置一致性。LTE终端和基站之间的RLC参数是通过RRC配置协商的但实际工程中偶尔出现基站侧配置了下发、终端侧没有启用的情况。遇到两边不一致造成的异常还是先查RRC信令里的RLC-Config字段再考虑下层。协议分析不是背文档关键是把每个字段和现实问题串起来。你把RLC三种模式的头部画几遍把SN、FI、SO、NACK这些字段的来龙去脉想清楚了后面去到任何一个LTE协议分析工具里都能很快看明白数据在讲什么故事。