简介这份资源是面向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 最核心的设计是它提供了三种数据传输模式分别对应不同的业务需求。这不是随便分的而是根据“这条数据通道需不需要保证送达、需不需要保证顺序”来定的。模式全称是否分段/级联是否有 RLC 头是否重传典型承载信道TM透明模式否否否BCCH、PCCH、CCCHUM非确认模式是是否DTCHAM确认模式是是是ARQDCCH、DTCHTM 模式最“透明”上层给什么它就往下递什么不加头、不切块、不重传。广播信道、寻呼信道、公共控制信道用这种模式因为这些信息本来就是“一发多收”不需要确认谁收到没收到。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 的收发和 ARQPDCP 的 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 协议栈打交道或者想搞清楚空口可靠性到底怎么保证的拿这份中文协议对照着看比啃英文原版省不少力气。希望帮到你。本文还有配套的精品资源点击获取
简介这份资源是面向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 最核心的设计是它提供了三种数据传输模式分别对应不同的业务需求。这不是随便分的而是根据“这条数据通道需不需要保证送达、需不需要保证顺序”来定的。模式全称是否分段/级联是否有 RLC 头是否重传典型承载信道TM透明模式否否否BCCH、PCCH、CCCHUM非确认模式是是否DTCHAM确认模式是是是ARQDCCH、DTCHTM 模式最“透明”上层给什么它就往下递什么不加头、不切块、不重传。广播信道、寻呼信道、公共控制信道用这种模式因为这些信息本来就是“一发多收”不需要确认谁收到没收到。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 的收发和 ARQPDCP 的 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 协议栈打交道或者想搞清楚空口可靠性到底怎么保证的拿这份中文协议对照着看比啃英文原版省不少力气。希望帮到你。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
