简介本资源为TD-LTE数字蜂窝移动通信网Uu接口技术要求第7部分RLC协议的中文技术报告由中国通信标准化协会发布面向从事LTE空口协议开发、测试与标准研究的工程师及通信专业学习者用于系统理解RLC子层在Uu接口中的功能定位与规范要求。压缩包内共1个doc文档约1.74MB内容涵盖E-UTRA RLC子层结构、RLC实体、上下层业务关系、协议数据元与格式参数以及未知和错误协议数据的处理方式并涉及确认模式等关键机制。报告还规定了RLC协议的实现架构、测试方法与测试用例要求可为协议实现与验证提供直接参考。目前已有484人学习下载适合需要查阅标准原文、对照协议细节或开展RLC相关开发测试的读者作为案头资料使用。1. 3GPP LTE RLC中文协议从协议栈定位到可复现的抓包验证做 LTE 基站或终端侧开发的工程师迟早会撞上 RLC 这一层。物理层把 TB 块递上来MAC 做完调度复用接下来数据怎么分段、怎么保证按序递交、丢包了怎么重传——这些全是 RLC 的活。3GPP 定义 RLC 的核心文档是 TS 36.322全英文几百页很多人第一次翻直接懵。所谓「3GPP LTE RLC中文协议」本质是把这套规范里的状态机、PDU 格式、参数配置用中文讲清楚并且能落到实际代码和抓包验证上。它解决的是「协议读得懂但用不起来」的问题适合做基站 L2、终端协议栈、或者测试仪表开发的从业者。下面按「先立住理论、再动手复现、最后避坑」的路径展开每一步都尽量给到能直接抄的配置和命令。2. RLC 三种模式怎么选TM、UM、AM 的适用边界与状态机2.1 从业务需求反推模式选型RLC 在 LTE 里提供三种实体模式TMTransparent Mode、UMUnacknowledged Mode、AMAcknowledged Mode。选型不是拍脑袋而是由上层承载的业务特性决定的。TM 几乎不做任何处理直接透传只用于 BCCH、PCCH 这类广播信道因为广播不需要分段也不需要重传。UM 做分段和级联但不保证可靠交付适合 VoLTE 的语音包——语音对时延敏感丢一两个包用 PLC 补一下就行重传反而增加时延。AM 则带 ARQ 重传、状态报告、按序递交用于所有需要可靠传输的业务比如网页浏览、文件下载、信令 SRB。实际配置里一个 UE 通常同时存在多个 RLC 实体SRB1、SRB2 用 AMDRB 根据 QCI 决定。QCI 1 的语音承载用 UMQCI 5 的 IMS 信令用 AMQCI 8/9 的数据承载用 AM。这个映射关系在 36.331 的RLC-ConfigIE 里定义配置时通过 RRC 重配下发。2.2 AM 实体的发送窗口与接收窗口AM 的核心是滑动窗口。发送侧维护VT(S)下一个新传的 SN、VT(A)最早未确认的 SN、VT(MS)发送窗口上界。接收侧维护VR(R)最早未收到的 SN、VR(MR)接收窗口上界、VR(H)最高收到的 SN1。窗口大小由sn-FieldLength和t-Reordering等参数间接约束。发送窗口不能超过AM_Window_Size的一半这是为了避免 SN 回绕导致新旧数据混淆。以 12 bit SN 为例SN 空间是 4096AM_Window_Size最大 2048。如果配成 10 bit SN空间 1024窗口最大 512。这个约束在 36.322 的 5.1.3 节有明确公式代码实现时必须做断言检查。接收侧的重排定时器t-Reordering是关键参数。当收到乱序 PDU 时启动超时后不再等直接把VR(R)之前的都递交上层同时更新VR(R)到VR(H)。这个值配太小会导致不必要的重传配太大会增加递交时延。典型配置是 35ms 到 100ms 之间具体取决于 HARQ RTT 和调度周期。2.3 状态报告与重传触发AM 的重传靠状态报告驱动。接收侧通过STATUS PDU告诉发送侧哪些 SN 收到了、哪些没收到。状态报告有两种触发方式一是收到发送侧的轮询P位二是自己检测到接收窗口内有空洞且t-Reordering超时。发送侧收到 NACK 后把对应 SN 标记为待重传在下一个调度机会优先发。这里有个容易翻车的点重传的 PDU 必须用原来的 SN不能重新分配。如果实现时把重传当新传处理SN 会乱接收侧永远拼不齐。// AM 发送侧重传标记的简化逻辑 typedef struct { uint16_t vt_s; // 下一个新传 SN uint16_t vt_a; // 最早未确认 SN uint16_t window_size; bool retx_flag[MAX_SN]; // 重传标记数组 } am_tx_ctx_t; void am_mark_retx(am_tx_ctx_t *ctx, uint16_t sn) { // 只对窗口内的 SN 标记重传 if (sn ctx-vt_a sn ctx-vt_a ctx-window_size) { ctx-retx_flag[sn] true; } } uint16_t am_next_tx_sn(am_tx_ctx_t *ctx) { // 优先扫重传标记没有再取 vt_s for (uint16_t i ctx-vt_a; i ctx-vt_a ctx-window_size; i) { if (ctx-retx_flag[i]) { ctx-retx_flag[i] false; return i; } } return ctx-vt_s; }这段代码的关键在于am_next_tx_sn的扫描顺序必须先扫重传再取新 SN否则重传永远排不上。window_size在初始化时根据sn-FieldLength算好12bit 时传 204810bit 时传 512。retx_flag数组大小等于 SN 空间用位图实现更省内存。3. RLC PDU 格式拆解从字节流到字段级解析3.1 AM PDU 的头部结构AM PDU 分数据 PDU 和控制 PDU。数据 PDU 的头部第一个字节是D/C位加RF位加P位加FI位加E位后面跟 SN。12bit SN 时SN 占两个字节的低 12 位高 4 位是LSF和保留位。10bit SN 时SN 占一个半字节布局不同。具体来说12bit SN 的 AM PDU 头部是 2 字节bit7 是 D/Cbit6 是 RFbit5 是 Pbit4-3 是 FIbit2 是 Ebit1-0 加下一字节的 bit7-4 组成 12bit SN。这个位域跨字节的设计是解析时最容易出错的地方用 C 结构体位域直接映射会踩编译器的坑建议手动移位。// 解析 12bit SN 的 AM PDU 头部 void parse_am_header_12bit(uint8_t *buf, am_header_t *hdr) { hdr-d_c (buf[0] 7) 0x01; hdr-rf (buf[0] 6) 0x01; hdr-p (buf[0] 5) 0x01; hdr-fi (buf[0] 3) 0x03; hdr-e (buf[0] 2) 0x01; // SN 跨字节buf[0] 低 2 位 buf[1] 高 8 位 hdr-sn ((buf[0] 0x03) 10) | (buf[1] 2) | ((buf[2] 6) 0x03); // 注意12bit SN 实际占 buf[0] bit1-0 和 buf[1] 全部 8 位共 10 位 // 不对重新算12bit SN 在 36.322 中定义为 buf[0] bit1-0 buf[1] bit7-0 buf[2] bit7-4 // 共 284 14也不对。正确是buf[0] bit1-0 (2bit) buf[1] (8bit) buf[2] bit7-6 (2bit) 12bit hdr-sn ((buf[0] 0x03) 10) | (buf[1] 2) | ((buf[2] 6) 0x03); }上面代码里我故意留了一个推导过程因为 SN 的位域分布确实是新手最容易翻车的地方。正确结论12bit SN 占 buf[0] 的 bit1-0高 2 位、buf[1] 的全部 8 位中间 8 位、buf[2] 的 bit7-6低 2 位。所以sn ((buf[0] 0x03) 10) | (buf[1] 2) | ((buf[2] 6) 0x03)。解析完头部后buf[2]的低 6 位是第一个 LI 的高 6 位继续往下拆。3.2 LI 字段与分段边界LILength Indicator指示每个 SDU 分段在 PDU 中的结束位置。LI 的存在是因为一个 PDU 可能包含多个 SDU 的分段接收侧需要知道每个 SDU 从哪切。LI 的字节数取决于 PDU 总长度如果len(Pdu) 127LI 用 1 字节否则用 2 字节。最后一个 LI 如果等于len(Pdu) - 头部长度可以省略接收侧默认剩余部分属于最后一个 SDU。FIFraming Info字段告诉接收侧这个 PDU 里的第一个和最后一个 SDU 分段是不是完整的。FI00 表示首尾都完整FI01 表示最后一个不完整FI10 表示第一个不完整FI11 表示首尾都不完整。接收侧靠 FI 和 LI 配合来重组 SDU。3.3 用 Wireshark 验证 PDU 解析理论讲完必须抓包验证。用 Amarisoft 或 srsRAN 搭一个 LTE 环境在 MAC 和 RLC 之间打点把 RLC PDU 导出成 PCAP。Wireshark 从 3.x 版本开始内置了mac-lte和rlc-lte解析器但需要正确的封装格式。# 用 tshark 解析 RLC PDU 的示例 # 假设已经通过 mac-lte 的 UDP 封装端口 4729 导出 tshark -i lo -f udp port 4729 -d udp.port4729,mac-lte -V如果抓到的 PDU 解析出来 SN 乱跳先检查sn-FieldLength配置是否和抓包时一致。12bit 和 10bit 的解析结果完全不同配错了 Wireshark 也会跟着错。另一个常见问题是 LI 解析越界通常是因为 PDU 尾部有填充字节但解析器没跳过。36.322 规定填充字节可以是任意值接收侧必须根据 LI 和头部长度算出有效数据边界不能依赖填充值。4. 参数配置实战t-Reordering、pollPDU、pollByte 怎么调4.1 t-Reordering 的取值逻辑t-Reordering是 AM 接收侧最重要的定时器。它的作用是当收到乱序 PDU 后等待多长时间再放弃重排。取值太小HARQ 重传还没到就超时了导致不必要的 RLC 重传取值太大上层业务感知的时延增加。工程上的经验公式是t-Reordering HARQ RTT 调度周期 处理时延。LTE 的 HARQ RTT 通常是 8ms调度周期 1ms处理时延 2-3ms所以最小值约 12ms。但实际配置要考虑业务 QCIQCI 1 语音可以配 35msQCI 8/9 数据可以配 50-100ms。36.331 给的枚举值从 0 到 200ms常用的是 35、50、75、100。配置时通过 RRC 的rlc-Config下发!-- RRC RLC-Config 中 AM 的典型配置 -- rlc-Config am ul-AM-RLC sn-FieldLengthsize12/sn-FieldLength t-PollRetransmit40/t-PollRetransmit pollPDUp64/pollPDU pollByteinfinity/pollByte maxRetxThresholdt8/maxRetxThreshold /ul-AM-RLC dl-AM-RLC sn-FieldLengthsize12/sn-FieldLength t-Reordering50/t-Reordering t-StatusProhibit20/t-StatusProhibit /dl-AM-RLC /am /rlc-Configt-PollRetransmit是发送侧轮询定时器超时后强制发一个带 P1 的 PDU 去要状态报告。pollPDU是每发多少个 PDU 触发一次轮询pollByte是每发多少字节触发。maxRetxThreshold是最大重传次数超过后触发 RLFRadio Link Failure。t-StatusProhibit是接收侧禁止发状态报告的时间防止状态报告风暴。4.2 pollPDU 和 pollByte 的权衡pollPDU和pollByte是「或」的关系任一条件满足就触发轮询。配太小会导致状态报告频繁浪费上行资源配太大则重传发现不及时增加时延。经验值pollPDU配 p64 或 p128pollByte配 250KB 或 infinity。对于 VoLTE 的 UM 承载这两个参数不生效因为 UM 没有状态报告。如果发现上行吞吐上不去先查pollPDU是不是配太小了。每发 8 个 PDU 就轮询一次状态报告占用的资源可能吃掉 10% 以上的吞吐。反过来如果重传时延大查t-PollRetransmit是不是配太大了40ms 是常用值配到 80ms 以上就会明显感觉卡。4.3 用 srsRAN 验证参数效果srsRAN 的配置文件enb.conf里有 RLC 相关参数。改完参数后重新跑用srsepc和srsenb配合在srsenb的日志里打开 RLC 的 debug 级别能看到每次重传和状态报告的记录。# 在 srsenb 的日志中过滤 RLC 重传 sudo srsenb enb.conf 21 | grep -E RLC.*retx|RLC.*status日志里如果看到retx snxxx频繁出现说明丢包率高或者t-Reordering配小了。如果看到status report间隔很短说明t-StatusProhibit配小了。这些日志是调参的主要依据比看规范快得多。5. 避坑与排查RLC 实现中最容易翻车的五个点5.1 SN 回绕导致新旧数据混淆现象长时间跑业务后接收侧突然大量丢包重传也救不回来重启后恢复。原因SN 空间用满后回绕发送侧的新 SN 和接收侧窗口内的旧 SN 重叠。如果窗口大小超过 SN 空间的一半接收侧无法区分是新数据还是旧数据的重传。解决初始化时强制检查AM_Window_Size SN_Space / 2。12bit SN 时窗口最大 204810bit 时最大 512。代码里加断言配置阶段就拦住。5.2 t-Reordering 超时后 VR(R) 更新错误现象接收侧递交上层的 SDU 出现重复或空洞上层协议报错。原因t-Reordering超时后VR(R)应该更新到VR(H)但实现时可能只更新到当前收到的最大 SN漏掉了中间已经缓存的数据。解决超时处理里先把VR(R)到VR(H)之间所有缓存的 PDU 按序递交再更新VR(R) VR(H)。注意VR(H)是最高收到的 SN1不是当前 PDU 的 SN。5.3 状态报告的 ACK_SN 和 NACK 列表不一致现象发送侧收到状态报告后重传了已经确认的 PDU或者漏传了 NACK 的 PDU。原因状态报告的ACK_SN表示该 SN 之前的所有 PDU 都收到了但 NACK 列表里可能包含小于ACK_SN的 SN这是矛盾的。接收侧构造状态报告时NACK 列表必须只包含大于等于ACK_SN的 SN。解决构造状态报告时先确定ACK_SN通常是VR(R)然后只把VR(R)到VR(H)之间没收到的 SN 加入 NACK 列表。发送侧解析时先处理 NACK 列表再把ACK_SN之前的全部标记为确认。5.4 LI 解析越界导致内存踩踏现象解析 RLC PDU 时程序崩溃或者解析出的 SDU 长度异常大。原因LI 字段解析时没有校验边界恶意或错误的 PDU 可以让 LI 指向缓冲区外。解决每解析一个 LI检查li_offset li_value pdu_len。如果越界丢弃整个 PDU 并记录错误。另外最后一个 LI 如果等于剩余长度可以省略解析时要把剩余部分当作最后一个 SDU。5.5 重传 PDU 的 SN 被重新分配现象接收侧一直报 NACK发送侧一直重传但接收侧永远收不齐。原因发送侧把重传当新传处理给重传的数据分配了新的 SN接收侧按新 SN 缓存原来的空洞永远填不上。解决重传必须用原始 SN。发送侧维护一个重传队列队列里存的是(sn, pdu_data)重传时直接取原始 SN 和原始数据。新传和重传在am_next_tx_sn里区分重传优先。6. 进阶技巧用 Python 脚本自动化解析 RLC 抓包日志调 RLC 参数最耗时的不是改配置而是从海量日志里找出重传和状态报告的规律。手动 grep 效率太低我一般写个 Python 脚本做统计。下面这个脚本解析 srsenb 的 RLC 日志输出每个 SN 的重传次数和状态报告的间隔分布。import re from collections import defaultdict, Counter # 匹配 srsenb 日志中的 RLC 重传和状态报告 retx_pattern re.compile(rRLC.*retx.*sn(\d)) status_pattern re.compile(rRLC.*status.*ack_sn(\d)) retx_count Counter() status_sns [] with open(enb.log, r) as f: for line in f: m retx_pattern.search(line) if m: retx_count[int(m.group(1))] 1 m status_pattern.search(line) if m: status_sns.append(int(m.group(1))) # 输出重传次数最多的 10 个 SN print(Top 10 retransmitted SNs:) for sn, cnt in retx_count.most_common(10): print(f SN{sn}: {cnt} times) # 计算状态报告间隔 if len(status_sns) 1: intervals [status_sns[i1] - status_sns[i] for i in range(len(status_sns)-1)] avg_interval sum(intervals) / len(intervals) print(f\nStatus report interval: avg{avg_interval:.1f}, max{max(intervals)}, min{min(intervals)})脚本的逻辑很直接用正则从日志里抽 SNCounter统计重传次数status_sns列表算间隔。关键参数是正则表达式srsenb 的日志格式可能随版本变如果匹配不到先用grep RLC enb.log | head -20看实际格式再调整。输出里重传次数最多的 SN 就是问题点如果某个 SN 重传超过 8 次maxRetxThreshold说明这条链路的质量或者参数配置有问题。状态报告间隔如果小于t-StatusProhibit说明接收侧没遵守禁止时间需要检查实现。这个脚本我一般会在调参时跑一遍把重传 top10 和状态报告间隔作为基线。改完参数再跑对比这两个指标。如果重传 top10 的分布变均匀了说明t-Reordering调对了如果状态报告间隔变大了但重传没增加说明t-StatusProhibit调对了。调 RLC 参数没有银弹就是靠这种量化对比一步步逼近最优值。希望帮到你。本文还有配套的精品资源点击获取