简介这份资源是TD-LTE数字蜂窝移动通信网Uu接口技术要求第7部分RLC协议的中文技术报告由中国通信标准化协会发布面向从事LTE空口协议开发、测试与标准研究的工程师及通信专业学习者用于系统理解RLC子层在Uu接口中的功能定位与规范要求。压缩包内共1个doc文档约1.74MB内容涵盖RLC协议范围、规范性引用文件、术语定义与缩略语并展开E-UTRA RLC子层结构、实体模型、上下层业务交互、协议数据元格式与参数以及未知或错误协议数据的处理方式同时涉及实现架构、测试方法与测试用例等规定。该报告与3GPP TS 36.331等规范衔接可帮助读者对照标准条文梳理AM、UM、TM等传输模式下的数据分段、重传与纠错机制适合作为协议栈开发与一致性测试的案头参考。目前已有490人学习下载。1. RLC 协议为什么一个“中间层”能决定 LTE 空口数据能不能活着到达很多人第一次翻 3GPP 协议栈会把 RLC 当成一个“透明管道”——MAC 负责调度、PDCP 负责加密RLC 夹在中间能有什么存在感但真正在空口丢包率飙到 10% 的现场待过的人会告诉你RLC 才是那个决定数据“能不能活着到达对端”的层。TD-LTE 数字蜂窝移动通信网 Uu 接口技术要求第 7 部分专门为 RLC 单独成册这件事本身就说明它不是一个可有可无的适配层而是一套完整的可靠性机制。这份技术报告把 RLC 拆成 TM、UM、AM 三种实体分别对应“完全不保护”“只排序不重传”“确认加重传”三种可靠性等级背后是一整套关于窗口、定时器、状态变量的精密设计。搞懂它你才能理解为什么 LTE 空口在那么恶劣的无线环境下还能跑出稳定的吞吐。2. 三种模式不是“功能开关”而是三套独立的状态机2.1 TM 模式为什么它连头都不加透明模式TM是 RLC 三种模式里最“反直觉”的一个。按常理一个协议层至少得有个头来标识自己但 TM RLC 实体在发送时明确规定RLC SDUs 不进行分段也不进行级联在 TMD PDUs 中不包含任何 RLC 头。这意味着 TM 模式下的 RLC PDU 就是上层 SDU 的裸拷贝RLC 层在这里几乎“不存在”。为什么这么设计因为 TM 模式承载的是 BCCH、PCCH、CCCH 这类信道。这些信道的共同特点是数据量小、对时延极度敏感、且上层本身已经具备足够的容错能力。比如寻呼消息它本身就是周期重复发送的丢一次下一次还会来再比如公共控制信道的消息它走的是竞争随机接入流程HARQ 和 MAC 层的重传已经能覆盖大部分场景。如果在这种信道上再加 RLC 头、再做分段重组只会增加不必要的处理时延和字节开销。从实现角度看TM 发送实体的逻辑简单到可以用一句话概括收到 SDU原封不动交给 MAC。接收实体同样收到 PDU原封不动交给上层。没有状态变量没有定时器没有窗口。这种“零状态”设计让 TM 模式的处理路径极短适合那些“宁可丢也不能等”的控制面消息。但要注意一个容易踩坑的地方TM 模式虽然不加头但它仍然受 MAC 传输机会的约束。协议里写得很清楚仅当下层已通知了一个传输机会时才形成 RLC PDU。这意味着 TM 实体不能自己攒数据必须等 MAC 说“现在可以发”它才把当前 SDU 递下去。这个约束在所有 RLC 模式里都成立是 RLC 与 MAC 之间最核心的接口契约。2.2 UM 模式排序窗口和 t_Reordering 的配合逻辑非确认模式UM是 LTE 里用得最广的 RLC 模式因为绝大多数用户面数据——比如视频流、网页浏览——走的都是 UM。UM 的核心矛盾是它不做重传但必须保证按序交付。这两件事看起来冲突因为空口乱序是常态不做重传就意味着丢失的 PDU 永远不会补上那怎么还能保证按序答案是一套“重排序窗口 定时器”的机制。UM 接收实体维护一个状态变量 VR(UH)表示“已接收到的最高 SN 的下一个”。重排序窗口的定义是若 (VR(UH) – UM_Window_Size) SN VR(UH)则 SN 落在窗口内。收到一个 UMD PDU 时如果它的 SN 在窗口外且小于 VR(UR)期望接收的下一个说明是重复包直接丢弃如果 SN 在窗口内就放进接收缓存。关键操作在 5.1.2.2.3 节当一个 PDU 被放入缓存后如果它的 SN 恰好等于 VR(UR)说明按序的那个包到了于是更新 VR(UR) 为下一个尚未接收到的 SN然后把所有 SN 小于新 VR(UR) 的缓存 PDU 重组并向上层分发。如果此时 VR(UH) VR(UR)说明还有空洞就启动 t_Reordering 定时器并把 VR(UX) 设为 VR(UH)。t_Reordering 的作用是“给乱序包一个等待窗口”。当它超时接收实体不再等那个缺失的包了直接把 VR(UR) 跳到 VR(UX) 的位置把缓存里能重组的都重组上交。这个设计的精妙之处在于它用时间换顺序既避免了无限等待导致的时延爆炸又尽可能保证了按序交付。UM_Window_Size 和 t_Reordering 的取值是网络配置的参数直接决定了 UM 模式在“时延”和“丢包率”之间的权衡点。2.3 AM 模式ARQ 状态变量和重分段机制确认模式AM是 RLC 最复杂的形态因为它要同时做三件事按序交付、丢包重传、窗口流控。AM 实体分为发送部分和接收部分各自维护一套状态变量。发送部分的核心变量是 VT(A) 和 VT(MS)。VT(A) 表示“最早未被确认的 SN”VT(MS) 表示“发送窗口的上界”。发送窗口的定义是若 VT(A) SN VT(MS)则 SN 落在传输窗口内。发送实体不会向下层分发任何 SN 落在窗口外的 PDU——这就是流控。每发送一个新的 AMD PDUVT(S) 加 1每收到一个肯定应答VT(A) 向前推进。接收部分的核心变量是 VR(R)、VR(MR)、VR(H) 和 VR(MS)。VR(R) 是期望接收的下一个按序 SNVR(MR) 是接收窗口上界VR(H) 是已接收到的最高 SN 加一VR(MS) 是“尚未完全接收的最高 SN”。接收窗口的定义是若 VR(R) SN VR(MR)则 SN 落在接收窗口内。AM 最独特的机制是重分段。协议 5.2.1 节规定当重传一个 AMD PDU 时如果它不能完全适合下层指示的传输机会总大小发送部分可以对该 AMD PDU 分段形成一个新的 AMD PDU 分段。而且重分段的分段数量没有限制。这意味着一个 1000 字节的 AMD PDU 在重传时可能被切成 3 个 300 多字节的段分别发送。这个设计是为了适配 MAC 调度的动态性——重传时信道条件可能变差MAC 只能给更小的传输块RLC 必须能灵活适配。但重分段带来一个副作用接收端需要跟踪“字节段”级别的接收状态。协议 3.1.1 节定义了字节段一个 AMD PDU 的数据域的一个字节字节段序号 0 对应数据域的第一个字节。接收实体在 5.1.3.2.2 节中要判断“SNx 的 AMD PDU 的字节段序号 y 到 z 是否在之前已被接收”如果是就丢弃重复字节段。这种字节粒度的状态跟踪是 AM 模式实现复杂度的主要来源。3. 轮询、状态报告与定时器AM 可靠性的三个支点3.1 轮询触发条件PDU_WITHOUT_POLL 和 BYTE_WITHOUT_POLLAM 发送实体不能无限发数据而不问对端“你收到了吗”。协议设计了两个计数器来触发轮询PDU_WITHOUT_POLL 和 BYTE_WITHOUT_POLL。每组装一个新 AMD PDUPDU_WITHOUT_POLL 加 1每映射一个新字节到数据域BYTE_WITHOUT_POLL 加对应字节数。当 PDU_WITHOUT_POLL pollPDU 或 BYTE_WITHOUT_POLL pollByte 时发送实体在该 PDU 的 P 域置“1”表示轮询。pollPDU 和 pollByte 是 RRC 配置的参数。pollPDU 控制“最多发多少个 PDU 就必须轮询一次”pollByte 控制“最多发多少字节就必须轮询一次”。两个条件满足其一就触发这是为了防止大 PDU 和小 PDU 场景下的轮询频率失衡。比如如果只按 PDU 计数那发送大量小 PDU 时轮询会很频繁如果只按字节计数那发送少量大 PDU 时可能很久都不轮询。两个计数器同时存在保证了轮询频率在不同业务形态下都合理。还有一个触发条件是“发送缓存和重传缓存均空”。这个条件的意思是如果发送实体手里没数据了那它应该主动轮询一下确认对端是否都收到了以便及时释放缓存和推进窗口。这个设计避免了“发送方以为还有数据要发实际上已经空了但因为没有轮询而不知道对端接收状态”的尴尬。3.2 STATUS PDU 的触发与禁止t_StatusProhibit 的作用接收实体发送 STATUS PDU 的触发条件有三个收到 P 域为“1”的 PDU、t_Reordering 超时、以及检测到接收失败。但触发不等于立即发送协议用 t_StatusProhibit 定时器来控制发送频率。当 STATUS 报告被触发时如果 t_StatusProhibit 未运行接收实体在下层指示的首个传输机会构造并分发 STATUS PDU然后启动 t_StatusProhibit。如果 t_StatusProhibit 正在运行则要等到它超时后的首个传输机会才发送而且即使期间触发了多次也只构造一个 STATUS PDU。这个“禁止定时器”的设计动机是STATUS PDU 本身也要占用空口资源如果每次收到轮询就立即回一个 STATUS在信道条件差、丢包频繁的场景下会产生大量 STATUS PDU反而挤占了本可用于数据传输的资源。t_StatusProhibit 强制拉开两次 STATUS 之间的最小间隔让接收实体有机会累积多个触发事件用一条 STATUS PDU 一次性报告所有缺失的 PDU。这是一种“批处理”思想在协议层的体现。3.3 t_PollRetransmit 超时后的重传决策发送实体在包含轮询的 PDU 分发到下层后会启动或重启 t_PollRetransmit。如果对端在定时器超时前没有回复包含 POLL_SN 确认的 STATUS 报告发送实体就认为轮询丢了需要重传。超时后的行为在 5.2.2.3 节有明确规定如果发送缓存和重传缓存均空或者无新 PDU 能发送比如窗口延迟则认为 SN VT(S)-1 的 AMD PDU 用于重传或者认为任何未被肯定应答的 AMD PDU 用于重传并再次包含一个轮询。这里有一个容易忽略的细节重传的对象不一定是原来那个带轮询的 PDU。如果那个 PDU 已经被确认了但轮询本身丢了发送实体可以选择重传任何未被确认的 PDU 来携带新的轮询。这个灵活性是为了避免“为了重传一个已经确认的 PDU 而浪费资源”。实现上发送实体通常会选择最早未被确认的那个 PDU 来重传这样既能触发对端回复 STATUS又能顺便推进窗口。4. 避坑与排查RLC 实现和调试中的常见问题4.1 现象UM 模式下接收端频繁上报“重组失败”上层收到大量不完整 SDU原因t_Reordering 设置过小导致接收实体在乱序包还没到齐时就超时把缓存中不完整的 SDU 片段强行重组上交。UM 模式没有重传一旦 t_Reordering 超时缺失的 PDU 就永远缺失了重组出来的 SDU 自然不完整。解决检查 RRC 配置中的 t_Reordering 值。这个值应该大于空口最大乱序时延通常需要根据 HARQ 重传次数和 MAC 调度周期来估算。如果 HARQ 最大重传 4 次、每次调度间隔 8ms那 t_Reordering 至少应该覆盖 32ms 以上的乱序窗口。同时检查 UM_Window_Size 是否足够大窗口太小会导致乱序包被直接丢弃。4.2 现象AM 模式下发送窗口停滞window stallingVT(A) 长时间不推进原因STATUS PDU 丢失或对端没有正确触发状态报告。发送实体在窗口满后无法发送新 PDU只能等 VT(A) 推进而 VT(A) 推进依赖对端的肯定应答。如果对端因为 t_StatusProhibit 配置过大而迟迟不发 STATUS或者 STATUS PDU 本身在空口丢了发送窗口就会卡死。解决检查 t_PollRetransmit 是否正常工作。发送实体在窗口停滞时应该通过轮询强制对端回复 STATUS。如果 t_PollRetransmit 超时后重传的 PDU 仍然没有触发 STATUS需要排查对端的 t_StatusProhibit 是否设置过大或者 STATUS PDU 的调度优先级是否被 MAC 忽略。另外检查 pollPDU 和 pollByte 是否设置得过大导致轮询频率太低。4.3 现象AM 重传时接收端报“字节段重复”但发送端认为这是首次重传原因重分段后新 AMD PDU 分段的字节段序号映射错误。协议规定新 AMD PDU 分段只映射原 AMD PDU 的数据域头要按照第 6 节描述设置。如果实现时错误地把原 PDU 的头也算进数据域或者字节段序号计算偏移了接收端就会认为这些字节段已经收到过。解决检查重分段代码中数据域映射的起始位置。原 AMD PDU 的数据域是从头之后开始的重分段时新 PDU 的数据域应该从原数据域的对应字节开始不能包含原头。同时检查 SO段偏移字段的设置是否正确SO 的单位是字节不是 PDU 序号。4.4 现象TM 模式下发送端提交 SDU 后MAC 迟迟收不到数据原因TM 实体没有正确响应 MAC 的传输机会通知。协议规定仅当下层通知了一个传输机会时才形成 RLC PDU。如果实现时 TM 实体在收到 SDU 后立即尝试向下层分发而不是等 MAC 的传输机会指示就会导致 MAC 在未准备好时收到数据或者数据被丢弃。解决检查 RLC 与 MAC 之间的接口实现。TM 实体应该维护一个“待发送 SDU”缓存收到 MAC 的传输机会指示后才从缓存中取出 SDU 并向下层分发。这个缓存不需要很大因为 TM 模式通常用于小数据量信道但必须有否则会违反协议规定的“传输机会驱动”原则。4.5 现象AM 接收端重组出的 SDU 顺序错乱上层 PDCP 报“序号跳变”原因接收实体在更新 VR(R) 后重组和分发 SDU 的顺序不对。协议 5.1.3.2.3 节规定当 x VR(R) 且该 PDU 的所有字节段被接收时要“从 SN 落在接收窗口之外的 AMD PDUs 的任何字节段重组 RLC SDUs并依次处理 SNVR(R) 的 AMD PDU 的字节段”然后“按序向上层分发重组后的之前未分发过的 RLC SDUs”。如果实现时先处理了高 SN 的 PDU 再处理低 SN 的或者没有按 SN 升序分发就会导致顺序错乱。解决检查重组逻辑中的排序步骤。接收缓存中的 PDU 应该按 SN 排序后再重组重组出的 SDU 也应该按 SN 升序分发。特别注意“之前未分发过的”这个限定词——已经分发过的 SDU 不能重复分发实现时需要一个“已分发 SN”的记录来避免重复。5. 从状态变量到定时器RLC 设计里的取舍与验证思路RLC 协议最值得玩味的地方是它在“可靠性”和“时延”之间划出的那条动态边界。TM 模式完全放弃可靠性换取极低时延UM 模式用重排序窗口和 t_Reordering 在“等”和“不等”之间找平衡AM 模式用 ARQ 和状态报告把可靠性拉到最高但代价是复杂的重分段和窗口管理。这三种模式不是简单的功能叠加而是三套独立的状态机各自有完整的状态变量、定时器和触发条件。从实现角度看RLC 的复杂度主要集中在 AM 模式。发送部分要维护 VT(A)、VT(S)、VT(MS) 三个窗口变量接收部分要维护 VR(R)、VR(MR)、VR(H)、VR(MS) 四个窗口变量再加上 PDU_WITHOUT_POLL、BYTE_WITHOUT_POLL、POLL_SN、RETX_COUNT 等辅助变量以及 t_PollRetransmit、t_Reordering、t_StatusProhibit 三个定时器。这些变量和定时器之间的交互关系构成了 RLC 状态机的全部行为。验证一个 RLC 实现是否正确最直接的方法是构造边界场景。比如发送窗口刚好满时收到一个肯定应答VT(A) 推进后是否能立即发送新 PDU接收窗口刚好满时收到一个窗口外的 PDU是否正确丢弃t_Reordering 超时和 PDU 到达同时发生时状态变量更新的顺序是否与协议一致这些边界场景在正常测试中很难覆盖但恰恰是现场问题的高发区。我自己的习惯是每次拿到一个新的 RLC 实现先不看代码而是画一张状态变量迁移图把所有触发条件和迁移路径标出来然后对照协议 5.1 节和 5.2 节的描述逐条核对。如果发现某个迁移路径在代码里找不到对应实现或者某个定时器的启动/停止条件与协议不一致那基本可以确定这里有坑。这份 TD-LTE RLC 协议中文技术报告的价值就在于它把 3GPP 英文协议里的关键机制用中文完整呈现省去了在英文术语和中文理解之间反复切换的成本。对于做协议栈开发或测试的人来说手边有一份中文版对照排查问题时能快不少。希望帮到你。本文还有配套的精品资源点击获取
简介这份资源是TD-LTE数字蜂窝移动通信网Uu接口技术要求第7部分RLC协议的中文技术报告由中国通信标准化协会发布面向从事LTE空口协议开发、测试与标准研究的工程师及通信专业学习者用于系统理解RLC子层在Uu接口中的功能定位与规范要求。压缩包内共1个doc文档约1.74MB内容涵盖RLC协议范围、规范性引用文件、术语定义与缩略语并展开E-UTRA RLC子层结构、实体模型、上下层业务交互、协议数据元格式与参数以及未知或错误协议数据的处理方式同时涉及实现架构、测试方法与测试用例等规定。该报告与3GPP TS 36.331等规范衔接可帮助读者对照标准条文梳理AM、UM、TM等传输模式下的数据分段、重传与纠错机制适合作为协议栈开发与一致性测试的案头参考。目前已有490人学习下载。1. RLC 协议为什么一个“中间层”能决定 LTE 空口数据能不能活着到达很多人第一次翻 3GPP 协议栈会把 RLC 当成一个“透明管道”——MAC 负责调度、PDCP 负责加密RLC 夹在中间能有什么存在感但真正在空口丢包率飙到 10% 的现场待过的人会告诉你RLC 才是那个决定数据“能不能活着到达对端”的层。TD-LTE 数字蜂窝移动通信网 Uu 接口技术要求第 7 部分专门为 RLC 单独成册这件事本身就说明它不是一个可有可无的适配层而是一套完整的可靠性机制。这份技术报告把 RLC 拆成 TM、UM、AM 三种实体分别对应“完全不保护”“只排序不重传”“确认加重传”三种可靠性等级背后是一整套关于窗口、定时器、状态变量的精密设计。搞懂它你才能理解为什么 LTE 空口在那么恶劣的无线环境下还能跑出稳定的吞吐。2. 三种模式不是“功能开关”而是三套独立的状态机2.1 TM 模式为什么它连头都不加透明模式TM是 RLC 三种模式里最“反直觉”的一个。按常理一个协议层至少得有个头来标识自己但 TM RLC 实体在发送时明确规定RLC SDUs 不进行分段也不进行级联在 TMD PDUs 中不包含任何 RLC 头。这意味着 TM 模式下的 RLC PDU 就是上层 SDU 的裸拷贝RLC 层在这里几乎“不存在”。为什么这么设计因为 TM 模式承载的是 BCCH、PCCH、CCCH 这类信道。这些信道的共同特点是数据量小、对时延极度敏感、且上层本身已经具备足够的容错能力。比如寻呼消息它本身就是周期重复发送的丢一次下一次还会来再比如公共控制信道的消息它走的是竞争随机接入流程HARQ 和 MAC 层的重传已经能覆盖大部分场景。如果在这种信道上再加 RLC 头、再做分段重组只会增加不必要的处理时延和字节开销。从实现角度看TM 发送实体的逻辑简单到可以用一句话概括收到 SDU原封不动交给 MAC。接收实体同样收到 PDU原封不动交给上层。没有状态变量没有定时器没有窗口。这种“零状态”设计让 TM 模式的处理路径极短适合那些“宁可丢也不能等”的控制面消息。但要注意一个容易踩坑的地方TM 模式虽然不加头但它仍然受 MAC 传输机会的约束。协议里写得很清楚仅当下层已通知了一个传输机会时才形成 RLC PDU。这意味着 TM 实体不能自己攒数据必须等 MAC 说“现在可以发”它才把当前 SDU 递下去。这个约束在所有 RLC 模式里都成立是 RLC 与 MAC 之间最核心的接口契约。2.2 UM 模式排序窗口和 t_Reordering 的配合逻辑非确认模式UM是 LTE 里用得最广的 RLC 模式因为绝大多数用户面数据——比如视频流、网页浏览——走的都是 UM。UM 的核心矛盾是它不做重传但必须保证按序交付。这两件事看起来冲突因为空口乱序是常态不做重传就意味着丢失的 PDU 永远不会补上那怎么还能保证按序答案是一套“重排序窗口 定时器”的机制。UM 接收实体维护一个状态变量 VR(UH)表示“已接收到的最高 SN 的下一个”。重排序窗口的定义是若 (VR(UH) – UM_Window_Size) SN VR(UH)则 SN 落在窗口内。收到一个 UMD PDU 时如果它的 SN 在窗口外且小于 VR(UR)期望接收的下一个说明是重复包直接丢弃如果 SN 在窗口内就放进接收缓存。关键操作在 5.1.2.2.3 节当一个 PDU 被放入缓存后如果它的 SN 恰好等于 VR(UR)说明按序的那个包到了于是更新 VR(UR) 为下一个尚未接收到的 SN然后把所有 SN 小于新 VR(UR) 的缓存 PDU 重组并向上层分发。如果此时 VR(UH) VR(UR)说明还有空洞就启动 t_Reordering 定时器并把 VR(UX) 设为 VR(UH)。t_Reordering 的作用是“给乱序包一个等待窗口”。当它超时接收实体不再等那个缺失的包了直接把 VR(UR) 跳到 VR(UX) 的位置把缓存里能重组的都重组上交。这个设计的精妙之处在于它用时间换顺序既避免了无限等待导致的时延爆炸又尽可能保证了按序交付。UM_Window_Size 和 t_Reordering 的取值是网络配置的参数直接决定了 UM 模式在“时延”和“丢包率”之间的权衡点。2.3 AM 模式ARQ 状态变量和重分段机制确认模式AM是 RLC 最复杂的形态因为它要同时做三件事按序交付、丢包重传、窗口流控。AM 实体分为发送部分和接收部分各自维护一套状态变量。发送部分的核心变量是 VT(A) 和 VT(MS)。VT(A) 表示“最早未被确认的 SN”VT(MS) 表示“发送窗口的上界”。发送窗口的定义是若 VT(A) SN VT(MS)则 SN 落在传输窗口内。发送实体不会向下层分发任何 SN 落在窗口外的 PDU——这就是流控。每发送一个新的 AMD PDUVT(S) 加 1每收到一个肯定应答VT(A) 向前推进。接收部分的核心变量是 VR(R)、VR(MR)、VR(H) 和 VR(MS)。VR(R) 是期望接收的下一个按序 SNVR(MR) 是接收窗口上界VR(H) 是已接收到的最高 SN 加一VR(MS) 是“尚未完全接收的最高 SN”。接收窗口的定义是若 VR(R) SN VR(MR)则 SN 落在接收窗口内。AM 最独特的机制是重分段。协议 5.2.1 节规定当重传一个 AMD PDU 时如果它不能完全适合下层指示的传输机会总大小发送部分可以对该 AMD PDU 分段形成一个新的 AMD PDU 分段。而且重分段的分段数量没有限制。这意味着一个 1000 字节的 AMD PDU 在重传时可能被切成 3 个 300 多字节的段分别发送。这个设计是为了适配 MAC 调度的动态性——重传时信道条件可能变差MAC 只能给更小的传输块RLC 必须能灵活适配。但重分段带来一个副作用接收端需要跟踪“字节段”级别的接收状态。协议 3.1.1 节定义了字节段一个 AMD PDU 的数据域的一个字节字节段序号 0 对应数据域的第一个字节。接收实体在 5.1.3.2.2 节中要判断“SNx 的 AMD PDU 的字节段序号 y 到 z 是否在之前已被接收”如果是就丢弃重复字节段。这种字节粒度的状态跟踪是 AM 模式实现复杂度的主要来源。3. 轮询、状态报告与定时器AM 可靠性的三个支点3.1 轮询触发条件PDU_WITHOUT_POLL 和 BYTE_WITHOUT_POLLAM 发送实体不能无限发数据而不问对端“你收到了吗”。协议设计了两个计数器来触发轮询PDU_WITHOUT_POLL 和 BYTE_WITHOUT_POLL。每组装一个新 AMD PDUPDU_WITHOUT_POLL 加 1每映射一个新字节到数据域BYTE_WITHOUT_POLL 加对应字节数。当 PDU_WITHOUT_POLL pollPDU 或 BYTE_WITHOUT_POLL pollByte 时发送实体在该 PDU 的 P 域置“1”表示轮询。pollPDU 和 pollByte 是 RRC 配置的参数。pollPDU 控制“最多发多少个 PDU 就必须轮询一次”pollByte 控制“最多发多少字节就必须轮询一次”。两个条件满足其一就触发这是为了防止大 PDU 和小 PDU 场景下的轮询频率失衡。比如如果只按 PDU 计数那发送大量小 PDU 时轮询会很频繁如果只按字节计数那发送少量大 PDU 时可能很久都不轮询。两个计数器同时存在保证了轮询频率在不同业务形态下都合理。还有一个触发条件是“发送缓存和重传缓存均空”。这个条件的意思是如果发送实体手里没数据了那它应该主动轮询一下确认对端是否都收到了以便及时释放缓存和推进窗口。这个设计避免了“发送方以为还有数据要发实际上已经空了但因为没有轮询而不知道对端接收状态”的尴尬。3.2 STATUS PDU 的触发与禁止t_StatusProhibit 的作用接收实体发送 STATUS PDU 的触发条件有三个收到 P 域为“1”的 PDU、t_Reordering 超时、以及检测到接收失败。但触发不等于立即发送协议用 t_StatusProhibit 定时器来控制发送频率。当 STATUS 报告被触发时如果 t_StatusProhibit 未运行接收实体在下层指示的首个传输机会构造并分发 STATUS PDU然后启动 t_StatusProhibit。如果 t_StatusProhibit 正在运行则要等到它超时后的首个传输机会才发送而且即使期间触发了多次也只构造一个 STATUS PDU。这个“禁止定时器”的设计动机是STATUS PDU 本身也要占用空口资源如果每次收到轮询就立即回一个 STATUS在信道条件差、丢包频繁的场景下会产生大量 STATUS PDU反而挤占了本可用于数据传输的资源。t_StatusProhibit 强制拉开两次 STATUS 之间的最小间隔让接收实体有机会累积多个触发事件用一条 STATUS PDU 一次性报告所有缺失的 PDU。这是一种“批处理”思想在协议层的体现。3.3 t_PollRetransmit 超时后的重传决策发送实体在包含轮询的 PDU 分发到下层后会启动或重启 t_PollRetransmit。如果对端在定时器超时前没有回复包含 POLL_SN 确认的 STATUS 报告发送实体就认为轮询丢了需要重传。超时后的行为在 5.2.2.3 节有明确规定如果发送缓存和重传缓存均空或者无新 PDU 能发送比如窗口延迟则认为 SN VT(S)-1 的 AMD PDU 用于重传或者认为任何未被肯定应答的 AMD PDU 用于重传并再次包含一个轮询。这里有一个容易忽略的细节重传的对象不一定是原来那个带轮询的 PDU。如果那个 PDU 已经被确认了但轮询本身丢了发送实体可以选择重传任何未被确认的 PDU 来携带新的轮询。这个灵活性是为了避免“为了重传一个已经确认的 PDU 而浪费资源”。实现上发送实体通常会选择最早未被确认的那个 PDU 来重传这样既能触发对端回复 STATUS又能顺便推进窗口。4. 避坑与排查RLC 实现和调试中的常见问题4.1 现象UM 模式下接收端频繁上报“重组失败”上层收到大量不完整 SDU原因t_Reordering 设置过小导致接收实体在乱序包还没到齐时就超时把缓存中不完整的 SDU 片段强行重组上交。UM 模式没有重传一旦 t_Reordering 超时缺失的 PDU 就永远缺失了重组出来的 SDU 自然不完整。解决检查 RRC 配置中的 t_Reordering 值。这个值应该大于空口最大乱序时延通常需要根据 HARQ 重传次数和 MAC 调度周期来估算。如果 HARQ 最大重传 4 次、每次调度间隔 8ms那 t_Reordering 至少应该覆盖 32ms 以上的乱序窗口。同时检查 UM_Window_Size 是否足够大窗口太小会导致乱序包被直接丢弃。4.2 现象AM 模式下发送窗口停滞window stallingVT(A) 长时间不推进原因STATUS PDU 丢失或对端没有正确触发状态报告。发送实体在窗口满后无法发送新 PDU只能等 VT(A) 推进而 VT(A) 推进依赖对端的肯定应答。如果对端因为 t_StatusProhibit 配置过大而迟迟不发 STATUS或者 STATUS PDU 本身在空口丢了发送窗口就会卡死。解决检查 t_PollRetransmit 是否正常工作。发送实体在窗口停滞时应该通过轮询强制对端回复 STATUS。如果 t_PollRetransmit 超时后重传的 PDU 仍然没有触发 STATUS需要排查对端的 t_StatusProhibit 是否设置过大或者 STATUS PDU 的调度优先级是否被 MAC 忽略。另外检查 pollPDU 和 pollByte 是否设置得过大导致轮询频率太低。4.3 现象AM 重传时接收端报“字节段重复”但发送端认为这是首次重传原因重分段后新 AMD PDU 分段的字节段序号映射错误。协议规定新 AMD PDU 分段只映射原 AMD PDU 的数据域头要按照第 6 节描述设置。如果实现时错误地把原 PDU 的头也算进数据域或者字节段序号计算偏移了接收端就会认为这些字节段已经收到过。解决检查重分段代码中数据域映射的起始位置。原 AMD PDU 的数据域是从头之后开始的重分段时新 PDU 的数据域应该从原数据域的对应字节开始不能包含原头。同时检查 SO段偏移字段的设置是否正确SO 的单位是字节不是 PDU 序号。4.4 现象TM 模式下发送端提交 SDU 后MAC 迟迟收不到数据原因TM 实体没有正确响应 MAC 的传输机会通知。协议规定仅当下层通知了一个传输机会时才形成 RLC PDU。如果实现时 TM 实体在收到 SDU 后立即尝试向下层分发而不是等 MAC 的传输机会指示就会导致 MAC 在未准备好时收到数据或者数据被丢弃。解决检查 RLC 与 MAC 之间的接口实现。TM 实体应该维护一个“待发送 SDU”缓存收到 MAC 的传输机会指示后才从缓存中取出 SDU 并向下层分发。这个缓存不需要很大因为 TM 模式通常用于小数据量信道但必须有否则会违反协议规定的“传输机会驱动”原则。4.5 现象AM 接收端重组出的 SDU 顺序错乱上层 PDCP 报“序号跳变”原因接收实体在更新 VR(R) 后重组和分发 SDU 的顺序不对。协议 5.1.3.2.3 节规定当 x VR(R) 且该 PDU 的所有字节段被接收时要“从 SN 落在接收窗口之外的 AMD PDUs 的任何字节段重组 RLC SDUs并依次处理 SNVR(R) 的 AMD PDU 的字节段”然后“按序向上层分发重组后的之前未分发过的 RLC SDUs”。如果实现时先处理了高 SN 的 PDU 再处理低 SN 的或者没有按 SN 升序分发就会导致顺序错乱。解决检查重组逻辑中的排序步骤。接收缓存中的 PDU 应该按 SN 排序后再重组重组出的 SDU 也应该按 SN 升序分发。特别注意“之前未分发过的”这个限定词——已经分发过的 SDU 不能重复分发实现时需要一个“已分发 SN”的记录来避免重复。5. 从状态变量到定时器RLC 设计里的取舍与验证思路RLC 协议最值得玩味的地方是它在“可靠性”和“时延”之间划出的那条动态边界。TM 模式完全放弃可靠性换取极低时延UM 模式用重排序窗口和 t_Reordering 在“等”和“不等”之间找平衡AM 模式用 ARQ 和状态报告把可靠性拉到最高但代价是复杂的重分段和窗口管理。这三种模式不是简单的功能叠加而是三套独立的状态机各自有完整的状态变量、定时器和触发条件。从实现角度看RLC 的复杂度主要集中在 AM 模式。发送部分要维护 VT(A)、VT(S)、VT(MS) 三个窗口变量接收部分要维护 VR(R)、VR(MR)、VR(H)、VR(MS) 四个窗口变量再加上 PDU_WITHOUT_POLL、BYTE_WITHOUT_POLL、POLL_SN、RETX_COUNT 等辅助变量以及 t_PollRetransmit、t_Reordering、t_StatusProhibit 三个定时器。这些变量和定时器之间的交互关系构成了 RLC 状态机的全部行为。验证一个 RLC 实现是否正确最直接的方法是构造边界场景。比如发送窗口刚好满时收到一个肯定应答VT(A) 推进后是否能立即发送新 PDU接收窗口刚好满时收到一个窗口外的 PDU是否正确丢弃t_Reordering 超时和 PDU 到达同时发生时状态变量更新的顺序是否与协议一致这些边界场景在正常测试中很难覆盖但恰恰是现场问题的高发区。我自己的习惯是每次拿到一个新的 RLC 实现先不看代码而是画一张状态变量迁移图把所有触发条件和迁移路径标出来然后对照协议 5.1 节和 5.2 节的描述逐条核对。如果发现某个迁移路径在代码里找不到对应实现或者某个定时器的启动/停止条件与协议不一致那基本可以确定这里有坑。这份 TD-LTE RLC 协议中文技术报告的价值就在于它把 3GPP 英文协议里的关键机制用中文完整呈现省去了在英文术语和中文理解之间反复切换的成本。对于做协议栈开发或测试的人来说手边有一份中文版对照排查问题时能快不少。希望帮到你。本文还有配套的精品资源点击获取
