TD-LTE RLC协议详解：从快递比喻到ARQ重传机制

简介：这份资源是面向TD-LTE无线接入网研发、协议栈实现与测试人员的RLC协议中文技术文档，对应《TD-LTE数字蜂窝移动通信网Uu接口技术要求》第7部分，由中国通信标准化协会组织制定。内容围绕E-UTRA RLC子层展开，涵盖RLC实体结构、上下层业务关系、AM/UM/TM三种模式的数据传输机制、错误检测与纠正、协议数据单元格式及参数定义，并对未知与错误协议数据的处理方式作出说明，同时给出实现架构与测试方法方面的规定，便于读者对照3GPP TS 36.331等规范理解空中接口的可靠传输设计。压缩包内为1个doc文档，约1.74MB，适合作为协议查阅与开发对照的手册。目前已有493人学习，适合需要深入掌握LTE层二协议细节的工程师与学习者参考。

1. 到底什么是 RLC 协议：从寄快递说起

你寄过快递吧？把东西交给快递员，他负责打包、贴单、运输、派送，最后送到收件人手里。如果包裹丢了、破了，快递公司还得负责查件、补发。在 TD-LTE 这张移动通信网里，RLC 协议干的就是这个活儿——它夹在 MAC 层和 PDCP 层之间，专门负责把上层交下来的数据“打包发出去”，并且保证该到的到、该对的顺序对。

RLC 全称 Radio Link Control，中文叫无线链路控制。它属于 Uu 接口协议栈里承上启下的一层：上面是 PDCP，下面是 MAC。你手机上网、发消息、看视频，数据从网络侧一路传到你的终端，中间必须经过 RLC 这一关。它决定了数据怎么切块、怎么编号、丢了要不要补、补几次、什么时候放弃。搞懂 RLC，你就搞懂了 LTE 数据通道里“可靠性”这三个字到底是怎么落地的。

2. RLC 为什么存在：没有它，数据就是一锅粥

2.1 下层只管“送”，不管“送到没有”

MAC 层和物理层负责的是“把数据块塞进无线资源里发出去”，它们关心的是调度、调制、编码、HARQ 快速重传。但无线信道天生不稳定，信号衰落、干扰、切换都会导致数据块丢失或出错。MAC 层的 HARQ 能解决一部分快速纠错，可它管不了太细——比如一个数据包被切成好几段，某一段反复传不过去，HARQ 重传次数用完了怎么办？这时候就需要 RLC 站出来做更上层的“兜底”。

打个比方，MAC 层像快递网点的分拣员，手速快、动作麻利，但只负责把包裹扔上车；RLC 层像快递公司的客服和调度中心，负责记录哪个包裹没送到、要不要补发、补发几次之后通知寄件人“这单我们赔”。没有 RLC，上层应用收到的数据就是乱序的、残缺的，TCP 会疯狂重传，体验直接翻车。

2.2 三种模式对应三种“可靠性等级”

RLC 最核心的设计，是它提供了三种数据传输模式，分别对应不同的业务需求。这不是随便分的，而是根据“这条数据通道需不需要保证送达、需不需要保证顺序”来定的。

TM 模式最“透明”，上层给什么它就往下递什么，不加头、不切块、不重传。广播信道、寻呼信道、公共控制信道用这种模式，因为这些信息本来就是“一发多收”，不需要确认谁收到没收到。UM 模式会切块、加序号、接收端做重排序和重复检测，但不做重传——丢了就丢了，适合对时延敏感、能容忍少量丢包的业务，比如语音通话。AM 模式最完整，有发送窗口、接收窗口、状态报告、ARQ 重传、轮询机制，适合网页浏览、文件下载这种“一个字节都不能少”的业务。

2.3 分段、级联、重分段：把数据塞进“刚好够大”的盒子

下层 MAC 每次通知 RLC“这次传输机会能发这么多字节”，这个大小是动态变化的。RLC 不能自己决定发多大，只能根据下层给的“盒子尺寸”来调整。所以它必须能把上层交下来的大块数据切成小段（分段），也能把多个小块拼成一块（级联），AM 模式下重传时如果盒子变小了，还得把已经切好的段再切一次（重分段）。

通俗地说，你有一堆大小不一的行李要装进快递箱，箱子尺寸每次还不一样。RLC 就是那个负责现场裁切、拼装、重新打包的人。UM 和 AM 都支持分段和级联，TM 不支持——因为 TM 走的是广播类信道，数据块大小相对固定，不需要这套操作。

3. AM 模式为什么最复杂：ARQ 和状态报告的配合

3.1 发送窗口和接收窗口：防止序号绕圈

AM 模式用序列号（SN）来标识每个数据包。SN 位数有限，发着发着就会绕回来，所以必须用“窗口”来限定当前能发哪些、能收哪些。发送端维护 VT(A) 到 VT(MS) 的发送窗口，只有落在窗口内的 SN 才允许发出去；接收端维护 VR(R) 到 VR(MR) 的接收窗口，窗口外的包直接丢弃。

这个设计很像停车场：车位就那么多，车不能无限往里开，必须等前面的车走了、车位空出来，后面的车才能进。窗口大小由 RRC 配置，窗口卡住（window stalling）的时候发送端就得停下来等确认，这也是为什么 AM 模式需要一套完整的确认机制来推动窗口前移。

3.2 轮询和状态报告：什么时候问“你收到没”

发送端不能干等着对方主动汇报，它得在合适的时机“催”一下。RLC 的轮询机制就是干这个的：每发一定数量的 PDU 或字节，或者发送缓存空了，就在数据包里把轮询比特置 1，要求对端回一个状态报告。对端收到轮询后，根据接收情况构造 STATUS PDU，告诉发送端哪些收到了、哪些没收到。

这里有个关键定时器 t_PollRetransmit：轮询发出去之后启动，如果超时还没收到状态报告，就认为轮询丢了，触发重传或者再次轮询。另一个定时器 t_StatusProhibit 在接收端用，防止状态报告发得太频繁把上行资源占满。这两个定时器一收一发，配合起来才能让 ARQ 既不漏报也不刷屏。

3.3 重传计数和最大重传门限：什么时候认输

AM 模式不是无限重传。每个 AMD PDU 有一个 RETX_COUNT 计数器，每次重传加一，达到 maxRetxThreshold 就向上层指示“已达到最大重传”。这时候 RRC 可能会触发重建，或者上层决定放弃这条承载。这个门限的存在，是为了防止一个永远传不过去的包把整条链路拖死——无线环境里确实存在“这个位置就是覆盖盲区”的情况，死磕没有意义。

4. 常见误区：RLC 和 MAC、PDCP 到底怎么分

4.1 误区一：RLC 的重传和 MAC 的 HARQ 是一回事

易混点：两者都叫“重传”，都发生在数据传输出错的时候。为什么混：名字像，位置也挨着，初学者容易觉得“下面已经重传了，上面还重传干嘛”。怎么区分：HARQ 是物理层和 MAC 层的快速重传，基于软合并，追求的是低时延、少次数，通常几次之内就要出结果；RLC 的 ARQ 是更上层的重传，基于状态报告，追求的是最终可靠性，可以跨很多个传输机会。HARQ 解决“这一下没传好”，ARQ 解决“这一段最终没送到”。两者是接力关系，不是重复劳动。

4.2 误区二：UM 模式不重传，所以它不可靠、没用

易混点：一看到“非确认”就觉得是残次品。为什么混：“确认”和“可靠”在中文里容易被等同。怎么区分：UM 的“不可靠”是相对于“保证送达”而言的，但它仍然做了重排序、重复检测、丢包检测，能保证“收到的顺序是对的、重复的不会交上去”。对于语音这种业务，晚到的包比丢掉的包更讨厌，UM 恰恰是合适的选择。可靠性等级是业务需求决定的，不是越高越好。

4.3 误区三：TM 模式就是“什么都不做”

易混点：TM 没有头、不分段、不重传，看起来像直通。为什么混：功能列表确实短。怎么区分：TM 的“透明”是指对上层数据不做修改，但它仍然要服从下层的传输机会调度，仍然要在正确的逻辑信道上收发。它做的是“不加干预的搬运”，而不是“不存在”。广播信息需要的就是这种搬运方式，加了头反而浪费资源。

4.4 误区四：RLC 的 SN 和 PDCP 的 SN 是一套编号

易混点：两层都有序列号，都用于排序和重传判断。为什么混：都叫 SN，都出现在包头里。怎么区分：RLC 的 SN 是“段级别”的，管的是 RLC PDU 的收发和 ARQ；PDCP 的 SN 是“包级别”的，管的是上层数据包的加密和按序递交。一个 RLC SDU 可能被切成多个 RLC PDU，每个 PDU 有自己的 SN；而 PDCP 的 SN 在更上面一层，RLC 看不到也不需要关心。两者各管一段，不能混用。

5. 什么时候该翻这份协议，什么时候别硬啃

这份《TD-LTE 数字蜂窝移动通信网 Uu 接口技术要求 第 7 部分：RLC 协议》是一份标准类技术报告，正文里把 RLC 的实体模型、三种模式的操作流程、状态变量、定时器、PDU 格式、参数定义都写得非常细。它适合什么人看？如果你在做 LTE 协议栈的开发、测试、或者需要排查空口数据异常，这份文档就是案头必备——比如你发现某个 AM 承载频繁触发最大重传，翻到 ARQ 过程和轮询那一节，对照 RETX_COUNT 和 t_PollRetransmit 的行为，就能定位是状态报告没回来还是窗口卡住了。再比如你要确认 UM 模式下 t_Reordering 超时后接收端到底怎么更新 VR(UR)，文档里 5.1.2.2.4 节写得明明白白，比任何二手资料都准。

但如果你只是想大致了解“LTE 数据怎么传的”，没必要从这份文档的第一页开始硬啃。它用的是标准文本的写法，大量状态变量和条件分支，读起来像法律条文。更合适的路径是先建立第 2、3 章那样的框架认知，知道 TM/UM/AM 各自干什么、ARQ 和 HARQ 怎么分工，然后再带着具体问题去查对应章节。我自己的习惯是：每次遇到 RLC 相关的异常，先把状态变量表抄一遍，对着流程走一遍，再翻文档确认边界条件——血泪经验是，很多“玄学”问题最后都落在某个定时器的启动条件上，而不是协议本身写错了。

提示：读这类标准文档时，重点关注“应”字句和状态变量更新条件，那些是强制行为；带“能”字的通常是可选能力，实现时可以取舍。

这份资料把 RLC 从架构到过程到参数一次讲全，适合放在手边当查阅手册。如果你正在跟 LTE 协议栈打交道，或者想搞清楚空口可靠性到底怎么保证的，拿这份中文协议对照着看，比啃英文原版省不少力气。希望帮到你。

本文还有配套的精品资源，点击获取