企业官网建设流程全解析

简介：3GPP LTE RLC中文协议是TD-LTE数字蜂窝移动通信网Uu接口系列技术要求的第7部分，由中国通信标准化协会组织制定，面向LTE协议开发、网络优化及测试工程师，提供了RLC协议中文规范的重要参考。这份技术报告对RLC协议的功能、架构与工作机制进行了详细规定，涵盖E-UTRA RLC子层结构、实体划分、数据传输机制、错误检测与纠正机制，并对协议数据单元格式及异常数据处理作出了明确说明。资源为单个doc格式文档，压缩包大小约1.74MB，内容完整保留了技术报告原文结构，从范围、规范性引用文件、术语定义到协议详细规范逐章展开，便于按章节查阅与学习。报告还包含RLC协议实现架构、测试方法与测试用例等相关规定，为实际组网应用、协议栈开发调试及一致性测试提供了重要指导。已有489人学习该资源，适合需要研读TD-LTE Uu接口技术规范、从事LTE协议栈研发或通信标准学习的技术人员使用。

1. 3GPP LTE RLC中文协议：协议栈里最容易被低估的一层，却卡住了大半新人

刚接触LTE协议栈的人，多半从RRC或PDCP开始翻，等真正动手调RLC重传时才发现，这一层的问题全是状态变量和窗口机制带来的。所谓"3GPP LTE RLC中文协议"，指的就是把3GPP TS 36.322这套英文规范吃透、整理成能对着实现的中文资料。RLC在PDCP和MAC之间做分段、级联、重传和按序递交，SRB和DRB都绕不开它，读懂这一层是调试上行丢包、下行乱序、吞吐掉零的前提。这篇笔记按实现者的视角，把规范位置、三种模式选型、状态机推进、PDU比特级拆解和常见翻车点一次讲透。

2. 先定位规范源头：RLC在36.322里的角色、版本差异与三种模式选型

2.1 为什么RLC值得单独啃一遍

很多从业者习惯把LTE协议栈画成一张分层图，然后默认RLC只不过是"MAC和PDCP之间的搬运工"。这个理解在早期版本里勉强成立，到了LTE-A和后续R10/R11引入eNB间载波聚合、多流传输后，RLC的重排序和重传逻辑直接决定用户体验。3GPP把RLC的完整规范放在TS 36.322，和36.321（MAC）、36.323（PDCP）、36.331（RRC）并列。如果你去翻36.322正文，会发现它通篇在定义三类东西：状态变量、控制PDU格式、以及状态迁移条件。

RLC的职能拆开看有三件：一是把上层PDCP的SDU按MAC调度的传输块大小做动态分段和级联；二是在AM模式下用状态报告触发对端重传；三是在接收侧做重复检测、乱序重排和按序递交。这三件事直接影响TCP窗口、语音时延和切换成功率。一个典型场景是：下行速率明明调度到了100Mbps，测速却只有40M，排查到最后往往是RLC的t-Reordering配得过大或过小，导致接收窗频繁阻塞。

2.2 UM/AM/TM三种模式分别在什么场景下被启用

36.322定义了三种传输模式，选型依据是上层业务对时延、误码率、按序性的容忍度。

TM（透明模式）最轻量，不添加任何RLC头，直接透传，一般用于随机接入过程中的SRB0消息，比如RRC Connection Request。它不做分段，也就要求MAC调度的TB大小刚好容纳整个SDU，所以只适合控制面早期消息和广播场景。

UM（非确认模式）加了RLC头，包含SN序号和分段信息，接收侧能检测丢包并重排，但不发状态报告、不重传。语音VoIP业务和某些实时视频走UM，丢了就丢了，重传反而引入抖动。UM要注意的是SN长度可配5bit、6bit或10bit，小区边缘用户调度周期长时，SN太短会绕回，需要靠配置兜底。

AM（确认模式）是最复杂的模式，发送侧维护重传缓存，接收侧维护接收窗和状态报告，支持ARQ重传、poll轮询、t-Reordering重排序。所有DRB（数据无线承载）默认走AM，因为TCP业务不允许丢包。AM下又分UM承载能映射到AM承载吗？不行，逻辑信道到RLC模式的映射在RRC建立时定死，中途不能切换。

2.3 不同版本规范下的行为差异对照

做协议栈的都知道，同一个RLC实体在不同3GPP版本下，行为和字段定义有小幅演进。R8基础版本定义了AM/UM/TM、AMD PDU和状态PDU基本格式；R9/R10引入了载波聚合，RLC层本身变化不大，但分段时需要考虑MAC分集调度的多个进程；R11之后对eNB间双连接有增强，RLC在Split Bearer场景下需要支持发送侧SDU在Master和Secondary路径上分配SN，这对轮询和状态报告的触发逻辑提出了新约束。

实际开发中，芯片平台和网络侧EnodeB厂商（华为、爱立信、中兴）对某些字段的容忍度不同。比如AMD PDU的P字段（Poll bit）在规范里只是"置1表示请求状态报告"，但有些基站固件对连续poll的间隔有隐含限制。做互操作测试时不要迷信R8基线，务必要确认目标网络跑的是R9还是R11，尤其是载波聚合场景下的重分段和SN分配策略。

3. 把AM收发状态机拆成白话：状态变量、窗口与重传触发条件

RLC AM的难不在PDU格式，在状态机。规范里用了一堆缩写——VR(R)、VR(MR)、VR(X)、VR(MS)、VR(H)、VT(A)、VT(S)——看起来像黑匣子，其实每个变量对应一个窗口边界。

3.1 发送侧状态变量与窗口推进逻辑

发送侧最重要的两个变量是VT(S)和VT(A)。VT(S)是下一个新传PDU要分配的SN；VT(A)是已经被对端确认过的最大SN，可以理解为重传缓存的最低有效位。每次发送新AMD PDU时，给该PDU打上当前VT(S)，然后VT(S)自增；收到对端状态报告里的ACK_SN时，把VT(A)推进到ACK_SN，VT(A)到VT(S)之间就是还没被确认的窗口。

窗口大小受协议规定限制。AM的SN是10位（部分场景12位），最大窗口不能超过SN空间一半，否则会出现确认帧无法区分新旧序列的问题。实现时常见做法是在发送侧维护poll计时器和poll计数器：当连续发送的PDU数量达到pollPDU，或字节数达到pollByte时，在下一个AMD PDU上置P字段为1，请求对端回状态报告。

发送侧容易出错的地方在于：状态PDU里只带ACK_SN和NACK_SN列表，NACK粒度可以是SN级别，也可以是SO段级别。如果用的是SO段级别NACK，重传时只重发未确认的SO段，而不是整个PDU。这部分逻辑在36.322的5.2.1里写得很细，但落到代码时很容易把"重传整个PDU"和"重传SO段"混在一个分支里。

python # 发送侧AMD PDU生成的关键状态推进（伪码） vt_s = last_sn + 1 # 下一个新传SN vt_a = highest_acked_sn # 对端确认的最大SN # 发送一个AMD PDU def send_amd_pdu(sdu_segment, vt_s): pdu = build_amd_header(sn=vt_s, poll_bit=should_poll()) pdu.payload = sdu_segment retx_buffer[vt_s] = pdu # 进重传缓存 vt_s += 1 return pdu

这段伪码对应的是发送侧最小流程。vt_s在每个新传时递增，重传缓存以SN为索引保存PDU，收到状态报告后再把对应条目清掉。关键字是retx_buffer：如果高层新数据到达你却把缓存写成覆盖式，那AM的重传就名存实亡了。

3.2 接收侧状态变量与t-Reordering定时器的联动

接收侧一眼看过去有VR(R)、VR(MR)、VR(X)、VR(MS)好几个变量，实际上只需要抓住三个核心：VR(R)是下一个期望按序递交的SN，VR(MR)是接收窗的上界，等于VR(R)加窗口大小；VR(X)是在t-Reordering启动时记录的那个"缺失SN"。

当收到一个SN大于等于VR(R)的PDU时，先丢进重排缓存，再检查它是否等于VR(R)。如果大于VR(R)，说明中间有缺失PDU，此时启动t-Reordering，记录VR(X)为当前缺失值；在t-Reordering超时前，后续到的乱序PDU都停在缓存里不递交，超时后如果缺的那个还没来，就把VR(R)之前能连续递交的PDU全部上报给PDCP，再对缺失部分触发状态报告请求对端重传。

t-Reordering的取值是接收侧吞吐抖动的关键。设小了，乱序还没等齐就先把缺口报出去，对端立刻重传，造成不必要的空口资源浪费；设大了，真的丢包时要干等超时，TCP层感知到RTO超时开始慢启动，吞吐悬崖式下跌。业内常见配置是20ms到40ms之间，但高速场景下有经验的工程师会按调度周期和HARQ反馈的来回时延去推算，而不是直接用默认值。

3.3 关键参数表：pollPDU、pollByte对吞吐和时延的影响

pollPDU和pollByte是AM发送侧最常调的协议参数，它们在RRC配置里由eNB下发给UE。pollPDU表示每发多少个AMD PDU就置一次P字段；pollByte表示累计发多少字节就置一次P字段。两者是"或"关系，任一条件满足就触发poll。

实际调优时我一般先看空口环境。信道质量好、误块率低时，pollPDU可以放大到16或32，减少上行反馈开销；信道差时反而要调小poll间隔，让对端尽快感知缺失并重传。pollByte在纯语音小包场景意义不大，视频大包场景要改成和分段大小匹配的数值。

4. 从英文规范到中文实现笔记：整理一份自己能复现的协议要点

对着36.322原文啃RLC，最大的阻力不是英文而是叙述顺序。规范先讲抽象模型再讲字段格式，最后才讲状态迁移，和实现者的思路正好相反。常见做法是先抓"分段、级联、填充"三个动作，再做比特级拆解，最后固化成自己的中文笔记。

4.1 先抓协议正文里的三个"动"：分段、级联、填充

RLC对SDU做的事可以概括成三个动词。分段发生在SDU大小超过当前MAC可用的TB大小时，把SDU切段，每段挂上RLC头；级联发生在多个SDU都小于剩余空间时，把几个小SDU装进同一个RLC PDU；填充发生在分段加级联后还剩少量字节时，用Padding字节补齐。

理解这三个动作，才能看懂MAC的调度反馈。MAC的DCI grant给多少字节，RLC就按这个字节数裁剪PDU。所以RLC实现里都有一个"Segment Buffer"，记录当前正在分段的SDU在上下文中位的位置。常见翻车点是在AM模式下重分段（re-segment)时忘了保存原始SN，导致网络侧按段号找不到归属的父PDU。

4.2 把每一条字段定义转成比特级注释——用AM PDU解析示例

AMD PDU头至少包含D/C字段（1bit）、RF字段（1bit）、P字段（1bit）、SI字段（2bit）、SN字段（10bit）。如果是重分段（RF=1），后面还要跟LSF字段（1bit）和SO字段（15bit）。这些字段的位宽和顺序在36.322第6.2.1.3节有表格，实现时最容易错的是bit序——3GPP的图是高位在前，和常用CPU的小端序正好相反，暴力读raw bits会全部错位。

# AMD PDU头解析（10bit SN，非重分段） def parse_amd_header(raw_byte0, raw_byte1): dc = (raw_byte0 >> 7) & 0x01 rf = (raw_byte0 >> 6) & 0x01 p = (raw_byte0 >> 5) & 0x01 si = (raw_byte0 >> 3) & 0x03 sn = ((raw_byte0 & 0x07) << 7) | (raw_byte1 & 0x7F) return dc, rf, p, si, sn

代码里的关键在读位顺序：rf在最前面，sn跨两个字节。注释里我已经标明这是10bit SN，所以低7位取第二字节的0x7F。如果业务配置的是12bit SN，这个函数的掩码和移位要全部重算——这是改协议版本时最常见的翻车点。

4.3 维护一份"中文协议"自己该怎么组织——哪些必抄、哪些可省

把36.322整理成能用的中文资料，不需要逐字翻译。我一般会拆成四张表：状态变量表（VT(A)/VT(S)/VR(R)/VR(MR)等）、PDU字段对照表（AMD/UMD/STATUS/饥饿状态）、状态迁移表（每种事件引发的动作）和参数速查表（网络侧RRC下发的RLC配置项）。表格里标注规范原文章节号，留一列写"实现备注"，记录踩过坑的位序、边界条件。

状态迁移表才是最值钱的部分。规范里的状态机图是给设计者看的，实现者更需要的是"事件到动作"的映射：收到ACK、收到NACK、t-Reordering超时、poll计时器到期，每一个事件对应哪些变量要更新、哪些PDU要发出去。把这张表做出来，"中文协议"就脱离翻译文档的层面，成为自己能维护的实现手册了。

5. 避坑：RLC实现中绕不开的五个真实问题

做RLC调试，有些问题是规范里写了但你不会留意的，有些是规范没写全靠血泪验证的。下面按现象、原因、解决的顺序记录五条高频踩坑经验。

一、状态报告丢失后，发送侧窗口卡死。现象是下行速率突然降为0，稍后自行恢复。原因是AM发送侧发了poll但状态PDU在网络中丢失，发送侧不知道哪些PDU被确认，不敢推进窗口、也不敢发新PDU。解决方法是：发送侧必须启动poll重传定时器（t-PollRetransmit），在定时器超时且仍未收到状态PDU时重新发起poll。这个定时器在RRC配置里有，不少实现默认值偏大，建议按RTT的两倍去设。

二、SN绕回时用大小比较判断窗口，导致一切错乱。现象是长时间高速业务后，出现大面积重传和重复递交。原因是RLC SN只有10bit或12bit，达到1024或4096后绕回0，如果你用sn < window_boundary做判断，绕回后就完全失效。解决方法是严格按规范用(sn - VR(R)) mod 2^bitwidth做窗口内判断，且只允许窗口最大为SN空间的一半，绕回时配合HFN（超帧号）来区分前后代。

三、t-Reordering配错导致VoIP通话断续。现象是RTP包在语音解码时有周期性丢字，但空口统计BLER很低。原因是VoIP走UM模式，UM也配了t-Reordering，乱序包在缓冲里等待超时，超时前即使后到的包也无法递交。解决方法是VoIP场景把t-Reordering设到一个调度周期以内，或者直接配置为0，让乱序包立即递交，依靠解码器的抖动缓冲去消化乱序。

四、重分段后NACK的SO字段与父PDU对应错位。现象是上行重传大幅增加，且目标基站反馈CRC错误。原因是AMD PDU被MAC分多次调度后，接收侧在状态报告里用SO（Segment Offset）指向缺失段，如果发送侧处理重分段时错误地把SDU内偏移当成PDU内偏移，重传的段就对不上。解决方法是重分段时用SO = 原始PDU中数据段的起始字节偏移，并且在驱动里把父PDU的SN、原始大小和SO存成三元组。

五、RLC和MAC的HARQ双重重传。现象是重传率达到10%以上，但有效吞吐没有明显下降。很多人以为RLC和HARQ重传的是同一个数据包，其实MAC重传的是HARQ进程里同一个传输块，RLC重传的是逻辑信道上的PDU，两者是不同层。问题是当HARQ重传把数据块推给RLC时，RLC如果已经收到对端NACK，就会重复发同一个PDU，导致接收侧重复检测PDU反复触发。解决方法是确认HARQ反馈与RLC状态反馈的时间差，配置HARQ最大重传次数略大于RLC的poll间隔，让RLC在HARQ还在抢救时不至于过早重传。

6. 验证手段与进阶技巧：用一个最小仿真把轮转计数器和窗口推进跑通

RLC的调试不适合只靠空口实测，因为空口变量太多，很难把SN绕回和窗口推进的边界复现出来。我一般会用一段本地仿真代码把发送侧和接收侧的状态机跑一遍，专门验证绕回和边界条件，再把结论带回实网测试。

6.1 用python模拟SN 12bit轮转和窗口滑动

SN_BITS = 12 WINDOW_SIZE = 512 # 最大不超过2^(SN_BITS-1) vr_r = 0 vr_mr = (vr_r + WINDOW_SIZE) % (1 << SN_BITS) def in_receive_window(sn, vr_r, vr_mr, bits=12): n = 1 << bits if vr_r < vr_mr: return vr_r <= sn < vr_mr # 绕回场景 return sn >= vr_r or sn < vr_mr # 模拟SN从4090开始收到4094，窗口正常 for sn in [4090, 4091, 4092]: assert in_receive_window(sn, vr_r, vr_mr) # 模拟SN绕回到2，判断是否在窗口内 assert in_receive_window(2, vr_r, vr_mr) # 窗口后半部分，在窗内

这段代码的逻辑关键是vr_r < vr_mr时不用取模比较，绕回时才需要分开判断。实际开发中如果直接照搬上面的简单判断，会漏掉vr_r等于vr_mr的边界——规范里窗口大小永远不会等于SN空间一半，所以不会出现相等。参数注释里建议把WINDOW_SIZE写进配置，方便模拟不同的基站配置。

6.2 参数边界验证：什么时候t-Reordering会引发吞吐瞬时掉零

另一个值得仿真的是t-Reordering对吞吐的瞬时冲击。把乱序包到达时间设为正态分布，t-Reordering设成不同值，可以看到包在缓存中滞留的时长和缺口重传的时延是此消彼长的关系。实网上如果调度周期是2ms、HARQ RTT约8ms，t-Reordering设到20ms是安全区间；低于10ms会频繁触发不必要的重传；高于50ms则会让TCP把RTO放大到200ms级别。

我个人的习惯是每次修改完RRC的RLC参数后，先用这段仿真跑一遍边界，再上车实测。这样能在进实验室前过滤掉纯逻辑错误，到实网上只关注空口固有的随机性。协议规范里没有"调试口诀"这种东西，但你把这些边界条件做成自己的清单之后，RLC就不再是玄学。

实网验证时也别只盯着吞吐，记得看终端上报的PDCP层SDU丢弃率——RLC的乱序重传一旦失控，PDCP层的丢弃计数器会先于吞吐指标报警。这算是我的个人教训，希望帮到你。

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