企业官网建设流程全解析

做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的职责边界

RLC（Radio 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、AM
• AM模式下的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透明模式：只干活不记账

TM（Transparent 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非确认模式：丢了不管但至少有序

UM（Unacknowledged 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确认模式：精准到分片级的可靠交付

AM（Acknowledged Mode，确认模式）是RLC里最复杂、用得最多、也是排障时最需要花心思的模式。AM模式提供可靠、按序的传输服务，接收端对上来的数据要确认，发送端对没确认的数据要重传，直到对端明确表示收到为止。它像寄快递签收加售后：你发出包裹，对方签收后系统才有回执，长时间没回执你就要打电话去问，丢了就补发。

AM模式用在SRB1、SRB2（RRC信令）和绝大多数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 Info，2比特），表示这个RLC PDU和上层SDU的边界关系。SI=00表示一个完整的SDU的开始和结束都在这个PDU里；SI=01表示这是某个SDU的开始部分但后面还有分段；SI=10表示这是中间分段，既不是开始也不是结束；SI=11表示这是SDU的最后一个分段。
• E位（Extension bit）用来指示后面是否还有LI（Length 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）以及可选的SO（Segment 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，表示控制PDU
• CPT字段（Control PDU Type），值为0时表示STATUS PDU
• ACK_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从SN=200一路列到SN=400，几十条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 | 同样不可丢 | | DRB（VoLTE语音） | 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提升到-97dBm，SINR从3dB提升到12dB，RLC重传比例直接从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和NACK：

tshark -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协议分析工具里，都能很快看明白数据在讲什么故事。