简介这份资源是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”表示“请给我一个状态报告”。接收端看到 P1就触发 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/NACKRLC 的反馈是 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 数据 PDUAMD PDU、UMD PDU、TMD PDU携带用户数据。AM 实体既发数据 PDU 也发控制 PDUUM 和 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重排序窗口 512t_Reordering 定时器 50 毫秒。参数不是固定的要根据具体场景和网络条件调整。注意SN 位宽决定了窗口大小的上限。10 比特 SN 最大窗口是 51212 比特最大是 2048。窗口不能超过 SN 空间的一半否则新旧包会混淆。我刚开始接触 RLC 的时候觉得三种模式来回切换很麻烦心想全用 AM 多省事。后来在一个语音项目上翻了车——通话断断续续排查半天才发现是 AM 的重传把时延拉高了。从那以后我每次选 RLC 模式都强制自己先问一句这个业务到底能不能忍丢包能忍就别用 AM。希望帮到你。本文还有配套的精品资源点击获取