LTE RLC协议实战指南：从状态变量到ARQ的落地读法-北京尧图网络

简介面向LTE无线接入网研发、协议栈实现与测试岗位工程师的学习资料聚焦TD-LTE数字蜂窝移动通信网Uu接口中的RLC协议。内容依据中国通信标准化协会技术报告系统规定E-UTRA RLC子层结构、RLC实体、上下层业务关系、功能划分以及协议数据单元格式、参数与异常数据处理方式并覆盖确认模式等关键机制适合需要理解RLC架构、数据传输与错误检测纠正流程的读者查阅对照。资源包共1个doc文件约1.74MB为中文技术报告正文含目次、前言、范围、规范性引用文件、术语定义与缩略语等章节便于按条目检索协议要求。目前已有493人学习可作为协议栈开发、接口联调与测试用例设计时的案头参考帮助快速定位RLC功能定义与实现测试要点。1. 一份把 LTE RLC 讲透的中文协议从状态变量到 ARQ 的落地读法调 LTE 空口的时候最让人抓狂的不是物理层解不出星座图而是 MAC 明明报了传输机会PDU 也发出去了可上层业务就是卡着不动。抓 log 一看RLC 层在重排序窗口边缘反复横跳t_Reordering 超时、STATUS PDU 迟迟不发、VT(A) 和 VT(S) 之间的窗口卡死——这类问题翻 3GPP 英文原文能看个大概但状态变量的更新顺序、字节段byte segment的重复判定、轮询触发的那几个计数器英文读三遍还是容易漏。这份《TD-LTE 数字蜂窝移动通信网 Uu 接口技术要求第 7 部分RLC 协议》就是冲着这个痛点来的它是中国通信标准化协会组织制定的通信标准类技术报告把 E-UTRA RLC 子层的结构、三种传输模式、状态变量、ARQ 与状态报告流程全部落成中文术语和缩略语对照齐全。适合正在做 LTE 协议栈开发、空口信令分析、或者准备协议一致性测试的从业者拿它当案头手册比啃英文规范省事得多。2. RLC 三种模式怎么选TM/UM/AM 的边界与逻辑信道映射拿到这份协议第一章别急着翻过程定义先把 4.2 节的 RLC 结构吃透。RLC 实体挂在 MAC 之上、PDCP/RRC 之下一个实体只配一种模式模式决定了它走哪条逻辑信道、带不带头、有没有重传。选错模式后面所有状态变量都是白搭。2.1 TM/UM/AM 的能力对照与适用信道协议 4.2.1 把三种模式讲得很清楚我按落地视角整理成一张表方便你在设计实体时直接对号入座模式典型逻辑信道分段/级联RLC 头重排序ARQ 重传重复检测TMBCCH、PCCH、DL/UL CCCH不做无无无无UMDL/UL DTCH做有有无有AMDL/UL DCCH、DL/UL DTCH做有有有有这张表的读法是TM 就是一根透明管子SDU 进来原样出去连头都不加所以它只能承载广播、寻呼、公共控制这类不需要可靠性的消息UM 加了 SN 和分段能重排序、能丢重复但不回确认适合对时延敏感、能容忍少量丢包的业务AM 才是完整形态发送部分维护发送窗口做 ARQ接收部分维护接收窗口发 STATUSDCCH 上的信令和 DTCH 上的可靠数据都走它。提示协议明确写了 TM 实体“RLC SDUs 不进行分段也不进行级联”且“TMD PDUs 中不包含任何 RLC 头”。这意味着 TM 的 SDU 大小必须和 MAC 给的传输机会严丝合缝实际实现里通常靠上层保证别指望 RLC 帮你切。2.2 从逻辑信道反推实体配置实际配置时我一般是从逻辑信道倒推的。比如你要配一个 SRB信令无线承载走 DCCH那必然是 AM要配一个语音承载走 DTCH多数是 UM系统消息走 BCCH只能 TM。协议 4.2.1.1.1 到 4.2.1.3.1 分别列了每种实体能挂的信道这里有个容易翻车的点AM 实体能挂 DCCH 和 DTCH但 UM 只能挂 DTCH你要是把一条 DCCH 配成 UM协议层面就不成立。配置实体时还要注意 AM 的特殊结构——它由发送部分和接收部分组成协议 4.2.1.3.2 和 4.2.1.3.3 是分开描述的。发送部分管分段、级联、重传、轮询接收部分管重排序、重复检测、STATUS 上报。写代码时这两块的状态变量是独立的别混在一个结构体里否则调试时你会分不清是发送窗口卡了还是接收窗口卡了。2.3 业务接口SAP 与传输机会协议 4.3 节定义了 RLC 和上下层的接口。往上RLC 通过单一 SAP 从 RRCCCCH 时或 PDCP其它情况收 SDU往下通过单一逻辑信道和 MAC 交互。这里最关键的一句是 4.2.1 里的“仅当下层即 MAC 层已通知了一个传输机会时才形成 RLC PDU”。这句话是整个 RLC 调度的根RLC 不是想发就发而是等 MAC 说“这次给你 N 字节”RLC 才按这个尺寸去分段、级联、组 PDU。4.3.2 进一步明确RLC 期望从 MAC 得到两样东西数据传输能力以及“传输机会及该机会中将被发送 RLC PDU(s) 尺寸总大小的通知”。落地时这就是一个回调接口MAC 每次调度把 grant size 传上来RLC 据此决定这次组多大的 PDU。很多新手在这里踩坑以为 RLC 自己缓存了数据就能主动推给 MAC结果实现出来 MAC 没 grant 也在组包空口上根本发不出去log 里全是“组了但没发”的假象。3. 状态变量与窗口UM/AM 接收侧的重排序怎么落地RLC 的玄学全在状态变量上。协议第 5 章把 UM 和 AM 的接收操作拆成了“收到 PDU 时”“PDU 入缓存时”“t_Reordering 超时时”三个分支每个分支里一串 VR 变量的更新顺序不能乱。这一章我按“先建窗口、再走分支”的顺序拆给你一套能直接对着写代码的读法。3.1 UM 接收窗口VR(UH)、VR(UR)、VR(UX) 三件套UM 接收侧维护一个重排序窗口协议 5.1.2.2.1 给的判定是若(VR(UH) – UM_Window_Size) SN VR(UH)则 SN 落在窗口内。三个变量的分工是VR(UH)接收到的最高 SN 加一窗口的上边界VR(UR)还没向上层递交的第一个 SN窗口的下边界参考VR(UX)t_Reordering 的触发参考点记录启动定时器时的 VR(UH)。收到一个 SNx 的 UMD PDU 时先做丢弃判定5.1.2.2.2如果VR(UR) x VR(UH)且之前已收过或者(VR(UH) – UM_Window_Size) x VR(UR)直接丢。前者是窗口内的重复包后者是已经递交过的老包。否则放进接收缓存。入缓存后的操作5.1.2.2.3是重头戏我把它写成伪代码逻辑方便对照# UM 接收侧SNx 的 UMD PDU 放入接收缓存后的状态更新 def on_umd_buffered(x, state): if x state.VR_UH: # x 落在重排序窗口之外上方 state.VR_UH x 1 deliver_sdus_below(state.VR_UH) # 重组并升序递交去 RLC 头 if state.VR_UR state.VR_UH - UM_WINDOW_SIZE: state.VR_UR state.VR_UH - UM_WINDOW_SIZE # 下边界滑出窗口则拉回 if state.VR_UR in state.rx_buffer: # 缓存里有下边界那个包 state.VR_UR first_missing_sn_above(state.VR_UR) deliver_sdus_below(state.VR_UR) if state.t_reordering_running: if state.VR_UX state.VR_UR or \ (state.VR_UX state.VR_UH - UM_WINDOW_SIZE and state.VR_UX ! state.VR_UH): stop_and_reset(state.t_reordering) if not state.t_reordering_running and state.VR_UH state.VR_UR: start(state.t_reordering) state.VR_UX state.VR_UH这段逻辑的关键在最后几行t_Reordering 只在“有空洞且定时器没跑”时启动启动时把 VR(UX) 钉在当前 VR(UH)。定时器超时5.1.2.2.4时把 VR(UR) 推到SN VR(UX)的第一个未收包把之前的都递交然后如果还有空洞就再启动一次。参数上 UM_Window_Size 由 RRC 配置常见取值是 512 或 1024具体看承载类型t_Reordering 也是 RRC 配的单位毫秒配小了会频繁超时递交、增加乱序配大了空洞等待变长、时延上去。3.2 AM 接收窗口字节段级别的重复判定AM 比 UM 多一层复杂度它的重传可能把原 PDU 重分段所以接收侧判重不能只看 SN要看“字节段序号 y 到 z”。协议 5.1.3.2.2 写得很明确收到包含 SNx、字节段序号 y 到 z 的 AMD PDU 时若 x 落在接收窗口外或该字节段之前已收过丢弃否则入缓存且若该 AMD PDU 的部分字节段之前已收丢掉重复的那部分。接收窗口的边界是VR(R) SN VR(MR)其中 VR(MR) VR(R) AM_Window_Size。入缓存后的更新5.1.3.2.3比 UM 多两个变量VR(MS) 和 VR(H)。VR(MS) 是“还没收全的第一个 SN”用于 STATUS 上报VR(H) 是收到的最高 SN 加一。核心分支是若 x VR(R) 且该 PDU 所有字节段收全则推进 VR(R) 到下一个没收全的 SN同步更新 VR(MR)然后重组递交若 x VR(H)更新 VR(H) 为 x1。# AM 接收侧SNx 的 AMD PDU字节段 y..z入缓存后的关键更新 def on_amd_buffered(x, y, z, state): if all_segments_received(state, state.VR_MS): state.VR_MS first_incomplete_sn_above(state.VR_MS) if x state.VR_R and all_segments_received(state, x): state.VR_R first_incomplete_sn_above(state.VR_R) state.VR_MR state.VR_R AM_WINDOW_SIZE reassemble_and_deliver(state, uptostate.VR_R) if x state.VR_H: state.VR_H x 1 if state.t_reordering_running: if state.VR_X state.VR_R or \ (state.VR_X state.VR_R or state.VR_X state.VR_MR) and state.VR_X ! state.VR_MR: stop_and_reset(state.t_reordering) if not state.t_reordering_running and state.VR_H state.VR_R: start(state.t_reordering) state.VR_X state.VR_H这里最容易翻车的是“字节段重复判定”和“VR(MS) 更新时机”。协议注 2 特别强调t_Reordering 超时触发 VR(MS) 更新但 STATUS 报告要在 VR(MS) 更新之后才触发。实现时如果先发 STATUS 再更新 VR(MS)对端收到的 NACK 范围就是旧的重传回来的包还是对不上表现为“一直重传、一直收不全”的死循环。3.3 重建时的收尾能重组就递交不能就丢协议在 UM 和 AM 的接收部分都写了 RLC 重建时的行为若可能从乱序接收的 PDU 重组 SDU 并递交丢弃任何不能重组进 SDU 的剩余 PDU初始化相关状态变量并停止相关定时器。落地时这一步常被忽略重建比如切换、重配时缓存里还压着一堆半截包不清理就会带到新配置里SN 空间一变全乱。我的习惯是重建入口先 stop 所有定时器再按“能重组就递交、剩下的丢”走一遍最后把 VR/状态变量按新配置重置。4. AM 发送侧与 ARQ轮询、STATUS 与重传阈值怎么配AM 的可靠性全靠发送侧和接收侧的一问一答发送侧发数据、按条件轮询接收侧收数据、发 STATUS发送侧据 STATUS 推进窗口或重传。协议 5.1.3.1 和 5.2 把这条链路拆得很细参数配错就是“窗口卡死”或“无脑重传”。4.1 发送窗口与 VT 变量什么时候不能发发送侧维护发送窗口VT(A) SN VT(MS)VT(A) 是最早未被肯定应答的 SNVT(MS) VT(A) AM_Window_SizeVT(S) 是下一个新 PDU 要用的 SN。协议 5.1.3.1.1 明确不应向下层分发任何 SN 落在发送窗口之外的 RLC 数据 PDU。这就是“窗口延迟window stalling”的根源——对端迟迟不回 STATUSVT(A) 推不动VT(S) 顶到 VT(MS)新数据就发不出去了。发送优先级协议也定了控制 PDU 优先于数据 PDU重传数据 PDU 优先于新数据 PDU。实现时调度器要按这个顺序取包否则 STATUS 被新数据挤在后面对端等不到确认窗口越卡越死。4.2 轮询触发pollPDU、pollByte 与 t_PollRetransmit轮询是发送侧主动要 STATUS 的手段。协议 5.2.2.1 给了几个触发条件我按实现顺序列一下每组装一个新 AMD PDUPDU_WITHOUT_POLL加 1BYTE_WITHOUT_POLL加上该 PDU 数据域的新字节数若PDU_WITHOUT_POLL pollPDU或BYTE_WITHOUT_POLL pollByte在该 PDU 里带轮询若该 PDU 发完后发送缓存和重传缓存都空排除等确认的已发 PDU或没有新 PDU 能发比如窗口延迟也带轮询。带轮询的动作是P 域置 1两个计数器清零PDU 分发到下层、VT(S) 增加后置POLL_SN VT(S) – 1启动或重启 t_PollRetransmit。# AM 发送侧组装新 AMD PDU 时的轮询判定 def maybe_poll(pdu, state, cfg): state.PDU_WITHOUT_POLL 1 state.BYTE_WITHOUT_POLL len(pdu.data_field) # 只算数据域新字节 need_poll (state.PDU_WITHOUT_POLL cfg.pollPDU or state.BYTE_WITHOUT_POLL cfg.pollByte) if buffers_empty_except_pending(state) or cannot_send_new(state): need_poll True if need_poll: pdu.header.P 1 state.PDU_WITHOUT_POLL 0 state.BYTE_WITHOUT_POLL 0 state.POLL_SN state.VT_S - 1 # 注意在 VT(S) 增加之后 restart(state.t_PollRetransmit)参数上pollPDU 和 pollByte 都是 RRC 配的pollPDU 常见几十到几百pollByte 常见几十万字节量级具体看承载。配小了轮询太频繁STATUS 挤占空口配大了对端迟迟不回窗口卡死。t_PollRetransmit 是轮询重传定时器超时后5.2.2.3若缓存空或发不出新包就把SN VT(S)-1的 PDU 或任何未被肯定应答的 PDU 标记重传并再带一次轮询。4.3 STATUS 报告与禁止定时器别把确认打成风暴接收侧发 STATUS 的触发5.2.3主要有两个收到 P 域为 1 的 PDU轮询或 t_Reordering 超时检测到丢包。触发后不是立刻发要看 t_StatusProhibit没在跑就在下一个传输机会构造并下发在跑就等它超时后的首个传输机会且期间多次触发只发一个 STATUS。STATUS 下发后启动 t_StatusProhibit。这个禁止定时器是防止 STATUS 风暴的关键。配小了每个乱序包都触发一次 STATUS空口上全是确认包配大了对端等确认等到窗口卡死。常见做法是让它略大于一个 RTT具体值跟承载和调度周期走。构造 STATUS 时5.2.3 末尾对VR(R) SN VR(MS)范围内未收全的 AMD PDU 按序填 NACK这个范围就是“还缺什么”的精确表达。4.4 重传阈值 maxRetxThreshold什么时候上报失败协议 5.2.1 定义了 RETX_COUNT 的维护首次重传时置 0之后每次“已不再等待重传”时加 1当RETX_COUNT maxRetxThreshold时向上层指示已达到最大重传。这个阈值是 RLC 把“我尽力了”告诉 RRC 的出口配得太小稍微有点空口抖动就报失败、触发重建配得太大一个包在 RLC 里反复重传时延早就爆了上层还不知道。落地时这个值要和上层比如 PDCP 的丢弃定时器对齐别让 RLC 还在死磕、PDCP 那边已经超时丢了。5. 避坑与排查RLC 调试里最常见的五个翻车现场协议读得再熟落到实现和抓包还是会有各种“看起来对、跑起来不对”。这一章是我踩过的几个典型坑按“现象 → 原因 → 解决”记下来你对着 log 排查能少走弯路。5.1 现象UM 业务时延忽高忽低log 里 t_Reordering 频繁超时原因t_Reordering 配得过小或者 UM_Window_Size 配得和承载不匹配。定时器太小一个正常的空口乱序就被判成丢包提前递交导致上层收到乱序数据窗口太小SN 回绕快老包和新包在窗口边界打架。解决先确认 t_Reordering 是否大于一个 HARQ RTT 加调度余量再核对 UM_Window_Size 是否覆盖得住最大在途包数。调参时一次只动一个抓 t_Reordering 超时次数和上层乱序率两个指标一起看。5.2 现象AM 一直重传同一个包STATUS 里 NACK 范围不变原因接收侧 VR(MS) 更新和 STATUS 构造的顺序反了。协议注 2 要求 t_Reordering 超时先更新 VR(MS) 再触发 STATUS如果实现里先构造 STATUS 再更新NACK 范围就是旧的对端重传回来的还是对不上。解决把 STATUS 构造放到 VR(MS) 更新之后抓包看 STATUS 里的 NACK SN 是否随 VR(MS) 推进。另外检查字节段重复判定重分段后的字节段序号 y 到 z 有没有正确比对。5.3 现象发送窗口卡死VT(S) 顶到 VT(MS)新数据发不出去原因对端迟迟不回 STATUS或轮询根本没发出去。常见是 pollPDU/pollByte 配得太大加上 t_PollRetransmit 没启动或超时后没重新带轮询发送侧一直在等一个永远不会来的确认。解决抓发送侧 P 域为 1 的 PDU 频率确认轮询按 pollPDU/pollByte 正常触发再看 t_PollRetransmit 超时后有没有把未确认 PDU 标记重传并再带轮询。窗口卡死时优先怀疑轮询链路而不是空口质量。5.4 现象STATUS 风暴空口上确认包占比异常高原因t_StatusProhibit 配得太小或者没生效。每个乱序包都触发 STATUS接收侧不停地发确认挤占了数据调度。解决确认 t_StatusProhibit 在 STATUS 下发后确实启动了且值大于一个 RTT检查“期间多次触发只发一个 STATUS”的逻辑有没有实现。抓包统计 STATUS PDU 占比正常应该远低于数据 PDU。5.5 现象RLC 重建后业务异常SN 对不上原因重建时没按协议清理缓存和状态变量。UM/AM 接收部分都要求重建时“能重组就递交、不能就丢、初始化状态变量并停止定时器”漏了这步旧缓存的半截包带着旧 SN 进了新配置。解决重建入口统一走一遍清理流程stop 所有定时器、按序重组可重组部分并递交、丢弃剩余、重置 VR/VT 变量。抓重建前后的 SN 连续性确认没有旧包混入。6. 把协议变成可验证的检查清单从状态变量到一致性测试协议读到最后真正的价值不是“看懂了”而是“能拿它去验证一个实现对不对”。这份技术报告的结构本身就适合做检查清单第 4 章给结构和功能第 5 章给过程第 6 章给 PDU 格式和参数。我一般按“状态变量 → 定时器 → PDU 字段”三层去对实现。第一层对状态变量。UM 侧重点看 VR(UH)/VR(UR)/VR(UX) 的更新顺序尤其是入缓存后“先更新 VR(UH)、再判下边界、再判定时器”这个次序AM 侧重点看 VR(R)/VR(MR)/VR(MS)/VR(H)/VR(X) 五个变量的联动特别是 VR(MS) 和 STATUS 构造的先后。可以写个小脚本把抓到的 SN 序列喂进去模拟状态机跑一遍和实际 log 里的变量值比对对不上就是实现有偏差。第二层对定时器。t_Reordering、t_PollRetransmit、t_StatusProhibit 三个定时器的启动、停止、重置条件协议里都是“若…则启动/停止/重启”的句式逐条抄成检查项。比如 t_PollRetransmit 的停止条件是“收到包含 POLL_SN 确认或否定的 STATUS”重启条件是“带轮询的 PDU 分发后”这两条如果实现里只做了启动没做重启轮询就会漏。第三层对 PDU 字段。第 6 章的 PDU 格式里UMD PDU 的 FI成帧信息、E扩展比特、SN、LSF末段标志、SO段偏移这些字段每个都有明确的置位规则。抓包时逐字段核对尤其是重分段场景下 SO 和 LSF 的组合错了对端就重组不出来。检查层重点对象验证手段常见偏差状态变量UM 三变量 / AM 五变量脚本模拟状态机比对 log更新顺序反、边界判定漏定时器t_Reordering / t_PollRetransmit / t_StatusProhibit逐条抄启动停止条件只启动不重启、超时后不重带轮询PDU 字段FI / E / SN / LSF / SO抓包逐字段核对重分段时 SO/LSF 组合错这套清单我每次接手一个新的 RLC 实现都会走一遍血泪经验是别信“看起来能跑”状态变量的更新顺序错一步短时间业务正常一到切换或高负载就原形毕露。从那以后我每次做 RLC 相关改动都强制把这三层检查走一遍再上测试环境后悔药没处买。希望帮到你。本文还有配套的精品资源点击获取

LTE RLC协议实战指南：从状态变量到ARQ的落地读法

相关推荐

MSA存储认证题库笔记：DAS/NAS/SAN与虚拟存储考点梳理

戚安邦《项目管理》PPT：可嵌入工程实践的知识骨架

SSM框架个人健康管理系统源码实战：从部署到二次开发

更多资讯

VOS3000操作手册精讲：费率套餐配置与话单报表避坑指南

信息学竞赛校级预选赛：变量命名、赋值语法与数组索引三大基础考点解析

知识竞赛系统面试高频考点：幂等设计、实时榜单与高并发防作弊

MATLAB矩阵对角化实战：特征值、若当标准形与符号运算避坑指南

大数运算实现详解：从数组存储到快速幂的完整设计

Java Swing 麦田物语课程设计：从零构建种田交易与存档的完整指南

今日更新

MATLAB缩进快捷键与批量格式化实战指南

用Poco实现Qt风格信号与槽的跨平台C++方案

ESXi裸机虚拟化安装指南：从硬件兼容到虚拟机部署

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？