简介：这份资源是TD-LTE数字蜂窝移动通信网Uu接口技术要求第7部分：RLC协议的中文技术报告，由中国通信标准化协会发布，面向从事LTE空口协议开发、测试与标准研究的工程师及通信专业学习者。内容系统规定了RLC子层结构、实体功能、上下层业务接口、协议数据单元格式与参数，以及未知或错误协议数据的处理方式，并覆盖确认模式等关键机制，可帮助读者理解RLC在数据传输与纠错中的具体职责。资源包内含1个doc文档，压缩包约1.74MB，篇幅完整、目录清晰，便于按章节查阅协议架构、数据传输机制、错误检测与纠正机制，以及实现架构、测试方法和测试用例等要求。目前已有490人学习下载，适合需要对照标准原文梳理RLC协议细节、支撑开发实现或测试验证的读者参考使用。
1. 到底什么是 RLC 协议：一个寄快递的类比
你寄过快递吧？你把东西交给快递员，快递员负责打包、贴单、运输、派送。如果包裹丢了，快递公司会赔你，或者重新寄一份。整个过程里，你不需要知道货车走哪条高速、分拣中心怎么运转，你只关心“东西到了没有”。
在 TD-LTE 数字蜂窝移动通信网里，RLC 协议扮演的就是那个“快递公司”的角色。它的全称是 Radio Link Control，无线链路控制。它夹在 MAC 层（负责调度和传输）和 PDCP 层（负责加密和头压缩）之间，专门管一件事：把上层交下来的数据，可靠地、按顺序地送到对面去。
你手机上网、刷视频、发消息，数据从应用层一路往下传，到了 RLC 这一层，它要决定：这段数据要不要切小块？要不要编号？丢了要不要重传？对面收到乱序了怎么办？这些看起来琐碎但极其要命的问题，全归 RLC 管。搞懂它，你就搞懂了移动通信里“数据为什么能靠谱地传过去”这件事。
2. RLC 为什么存在：从三种模式说起
2.1 三种传输模式：透明、非确认、确认
RLC 实体可以被配置成三种模式之一，这不是随便选的，而是根据业务需求来的。
透明模式（TM）最简单。发送端收到上层给的 RLC SDU，不做分段、不做级联、不加任何 RLC 头，直接往下扔。接收端收到什么就往上递什么。你可以理解为“裸奔模式”——不打包、不贴单、不追踪。它用在 BCCH、DL/UL CCCH、PCCH 这些逻辑信道上，传的是广播信息、寻呼信息这类不需要确认、丢了也无所谓的内容。
非确认模式（UM）进了一步。发送端会对 RLC SDU 做分段和级联，加上 RLC 头，头里带序列号（SN）。接收端收到后，会检测重复、重排序、检测丢失，然后重组出完整的 SDU 按序往上递。但它不要求重传——丢了就丢了，接收端检测到丢失后，把那些因为缺了一块而拼不起来的 PDU 直接丢弃。UM 用在 DL/UL DTCH 上，适合那些对时延敏感、但能容忍少量丢包的业务，比如语音通话、流媒体。
确认模式（AM）最复杂也最可靠。发送端同样做分段、级联、加头，但它多了一套 ARQ 机制——自动重复请求。接收端发现丢了数据，会通过 STATUS PDU 告诉发送端“我没收到某某号”，发送端就重传。重传时如果原来的 PDU 太大塞不进当前的传输机会，还能把它重新分段成更小的 AMD PDU 段。AM 用在 DL/UL DCCH 或 DL/UL DTCH 上，适合网页浏览、文件下载这类一点都不能丢的业务。
打个比方：TM 就像你往邮筒里扔一张明信片，寄到算运气；UM 像寄平信，有编号但丢了不补；AM 像寄挂号信，对方没收到你会一直补寄，直到确认签收。
2.2 为什么非要搞三种模式
你可能会问：直接全用 AM 不就行了？最可靠嘛。
问题是，可靠性是有代价的。AM 需要接收端发 STATUS 报告、发送端维护重传缓存、跑各种定时器，这些都要消耗无线资源和处理时间。语音通话丢一两个包，你耳朵根本听不出来，但如果为了补那两个包等上几十毫秒，通话就卡了。广播信息更不用说，全网都在收，你让每个用户都回确认消息，网络直接瘫掉。
所以三种模式的存在，本质是在“可靠性”和“时效性/开销”之间做取舍。TM 最轻但最不可靠，AM 最重但最可靠，UM 在中间。选哪种，取决于业务能不能忍、值不值得。
2.3 RLC 在协议栈里的位置和它管的事
RLC 上面是 PDCP，下面是 MAC。从上层看，RLC 提供三种数据传输服务：TM 数据传输、UM 数据传输、AM 数据传输（AM 还额外提供“发送成功指示”，告诉上层这个包对方确实收到了）。从下层看，RLC 期望 MAC 给它两样东西：数据传输能力，以及“传输机会”——也就是 MAC 告诉 RLC“这次你能发多少字节”。
RLC 的核心功能包括：上层 PDU 的传输、ARQ 纠错（仅 AM）、分段与级联与重组（UM 和 AM）、重分段（仅 AM）、重排序（UM 和 AM）、重复检测（UM 和 AM）、SDU 丢弃（UM 和 AM）、RLC 重建、协议错误检测（仅 AM）。
这些功能听起来多，但核心逻辑就一条：把上层给的大块数据切成适合空口传输的小块，编号，发出去，在接收端按编号拼回来。中间丢了就补（AM），乱了就排（UM 和 AM），重复了就扔（UM 和 AM）。
3. 核心机制拆解：编号、窗口、定时器
3.1 序列号与窗口：RLC 怎么知道谁是谁
RLC 给每个 PDU 分配一个序列号（SN）。UM 和 AM 都用 SN 来标识数据块。但光有编号不够，还得有个“窗口”机制来限定有效范围。
UM 接收端维护一个重排序窗口，由状态变量 VR(UH) 决定上界。SN 落在(VR(UH) - UM_Window_Size) <= SN < VR(UH)范围内，才算在窗口内。窗口外的 PDU 要么太老（已经处理过了），要么太新（超出接收能力），都会被丢弃。
AM 更复杂，发送端有发送窗口，接收端有接收窗口。发送窗口由 VT(A) 和 VT(MS) 界定：VT(A) <= SN < VT(MS)才允许发送。VT(A) 是“最早未被确认的 SN”，VT(MS) 是“最大可发送的 SN + 1”。接收窗口由 VR(R) 和 VR(MR) 界定，VR(R) 是“下一个期望按序收到的 SN”，VR(MR) = VR(R) + AM_Window_Size。
窗口的意义在于流量控制和防止 SN 回绕混淆。没有窗口，发送端可能无限发新数据，接收端缓存爆炸；或者 SN 循环一圈后，旧包和新包分不清。
3.2 重排序与定时器：等多久才算“丢了”
空口传输不像有线，PDU 到达顺序可能是乱的。RLC 接收端需要重排序，把乱序到达的 PDU 先缓存，等缺失的补上了再按序往上递。
但等不能无限等。UM 和 AM 都定义了一个定时器 t_Reordering。当接收端发现有空缺（VR(UH) > VR(UR) 或 VR(H) > VR(R)），就启动这个定时器。超时后，接收端认为缺失的 PDU 确实丢了，于是更新状态变量，把缓存里能重组的 SDU 往上递，跳过那个空缺。
AM 还多一个 t_StatusProhibit 定时器，用来控制 STATUS 报告的发送频率，避免接收端频繁发报告占用资源。以及发送端的 t_PollRetransmit，用来在轮询后没收到 STATUS 报告时触发重传。
这些定时器的值不是拍脑袋定的，需要根据空口时延、HARQ 重传时间等参数综合配置。配短了，频繁触发不必要的重传和报告；配长了，丢包恢复慢，用户体验差。
3.3 ARQ 与轮询：AM 的“后悔药”机制
AM 的可靠性靠 ARQ。发送端发了一个 AMD PDU，接收端如果没收到，会在 STATUS PDU 里标记为否定应答。发送端收到否定应答后，把对应的 AMD PDU 标记为“待重传”。
但发送端怎么知道该什么时候去要 STATUS 报告？靠轮询。AM 发送端在组装 PDU 时，会检查两个计数器：PDU_WITHOUT_POLL 和 BYTE_WITHOUT_POLL。如果发出去的 PDU 数量或字节数超过阈值（pollPDU 或 pollByte），就在这个 PDU 的头部把 P 域置为“1”，表示“请给我一个状态报告”。接收端看到 P=1，就触发 STATUS 报告。
还有一种情况：发送缓存和重传缓存都空了，或者因为窗口延迟没法发新数据了，发送端也会主动轮询，确认对面到底收到没有。
轮询之后，发送端启动 t_PollRetransmit。如果在超时前收到了包含 POLL_SN 确认的 STATUS 报告，就停掉定时器。如果超时了还没收到，就认为轮询丢了，触发重传并再次轮询。
这套机制就像你寄挂号信后，如果对方一直没签收，你会打电话问“收到了吗？”——问一次没回应，过段时间再问一次。
4. 常见误区：这些概念别搞混
4.1 RLC 重传和 HARQ 重传是一回事吗
不是。HARQ 在 MAC 层，是物理层的快速重传，基于 ACK/NACK，往返时间很短。RLC 的 ARQ 在更高层，基于 STATUS PDU，往返时间更长。两者是互补关系：HARQ 处理快速的小错误，RLC ARQ 处理 HARQ 没能纠正的残留错误。
容易混是因为都叫“重传”。区分方法：看它在哪一层、用什么反馈、多快。HARQ 的反馈是 1 比特 ACK/NACK，RLC 的反馈是 STATUS PDU 里带 SN 的位图。
4.2 分段和级联是一回事吗
不是。分段是把一个大的 RLC SDU 切成多个小块，级联是把多个小的 RLC SDU 拼成一个大块。两者可以同时发生：比如两个小 SDU 拼在一起还不够一个传输块大，那就再等一个 SDU 来，或者把一个 SDU 切一半拼进去。
UM 和 AM 都支持分段和级联，TM 两者都不做。重分段是 AM 独有的：当一个 AMD PDU 需要重传但塞不进当前传输机会时，把它再切成更小的段。
4.3 UM 的“不确认”是不是就完全不管丢包
不是。UM 虽然不重传，但它会检测丢失。接收端通过 SN 的不连续来判断丢了哪些 PDU，然后把因为缺失而无法重组的 SDU 丢弃。它还会做重排序和重复检测。所以 UM 是“检测但不恢复”，不是“完全不管”。
4.4 AM 的 STATUS PDU 和 RLC 数据 PDU 有什么区别
STATUS PDU 是控制 PDU，不携带用户数据，只携带确认信息（哪些 SN 收到了、哪些没收到）。RLC 数据 PDU（AMD PDU、UMD PDU、TMD PDU）携带用户数据。AM 实体既发数据 PDU 也发控制 PDU，UM 和 TM 只发数据 PDU。
4.5 RLC 重建和重新建立连接是一回事吗
不是。RLC 重建是协议内部的操作，发生在切换或重配置时，目的是把缓存里能重组的 SDU 尽量递上去，然后重置状态变量和定时器。它不涉及重新建立无线连接，只是 RLC 实体自身的一次“清理和复位”。
5. 什么时候用、什么时候别用：一个配置实例
假设你在做一个视频通话功能，需要选 RLC 模式。视频通话的特点是：对时延敏感，丢几帧画面花一下但能忍，不能因为重传导致画面卡住。
这时候选 UM 就比 AM 合适。UM 有 SN 可以重排序，能处理乱序到达，但不重传，不会因为等重传而增加时延。如果你选 AM，一个包丢了触发重传，等 STATUS 报告回来再重传，往返几十毫秒，画面直接卡成 PPT。
但如果是文件下载，那就必须 AM。文件一个字节都不能少，时延不敏感，重传带来的额外时间完全可以接受。
配置时还要注意几个参数：UM_Window_Size 和 AM_Window_Size 决定了接收端能缓存多少乱序 PDU，配太小会导致频繁触发 t_Reordering 超时，配太大占用内存。t_Reordering 的值要大于 HARQ 重传的最大时间，否则会把 HARQ 还没传完的包误判为丢失。pollPDU 和 pollByte 决定了轮询频率，配太密会导致 STATUS 报告过多，配太疏会导致重传发现太晚。
# 以下为示意性配置参数，非真实设备命令 rlc: mode: UM # 视频通话选非确认模式 sn_field_length: 10 # UM 常用 10 比特 SN um_window_size: 512 # 重排序窗口大小 t_reordering: 50ms # 大于 HARQ 最大重传时间这段配置的意思是：RLC 实体工作在 UM 模式，SN 用 10 比特（范围 0 到 1023），重排序窗口 512，t_Reordering 定时器 50 毫秒。参数不是固定的，要根据具体场景和网络条件调整。
注意：SN 位宽决定了窗口大小的上限。10 比特 SN 最大窗口是 512，12 比特最大是 2048。窗口不能超过 SN 空间的一半，否则新旧包会混淆。
我刚开始接触 RLC 的时候，觉得三种模式来回切换很麻烦，心想全用 AM 多省事。后来在一个语音项目上翻了车——通话断断续续，排查半天才发现是 AM 的重传把时延拉高了。从那以后我每次选 RLC 模式，都强制自己先问一句：这个业务到底能不能忍丢包？能忍就别用 AM。希望帮到你。
本文还有配套的精品资源，点击获取
