5G RLC层：三种传输模式的设计哲学

一个快递站的管理智慧

想象你是一个快递站的站长，每天要处理三种截然不同的包裹：

• 小区广播通知（比如停水通知）：塞进每家信箱就行，丢了也无所谓，明天还会再发
• 外卖订单：15分钟内必须送到，汤洒了一点客户勉强接受，但绝不能晚
• 合同文件：必须准确无误送达，缺一页都不行，客户签字确认才算完成

5G网络中的RLC（Radio Link Control，无线链路控制）层面对的正是这样的场景。它位于PDCP层和MAC层之间，是Layer 2的"中间管理层"。来自上层的数据包种类繁多——有系统广播、有语音、有视频、有文件下载——RLC必须为每种业务选择最合适的传输策略。

这就是RLC三种传输模式诞生的根本原因：不是一种模式不够好，而是没有一种模式能同时满足所有业务的需求。

RLC层在协议栈中的位置

先看全貌，理解RLC层在整个协议栈中的位置和职责：

graph TB
    subgraph "用户面协议栈"
        APP["应用层<br/>（微信/视频/文件下载）"]
        PDCP["PDCP层<br/>加密 · 头压缩 · 排序"]
        RLC["RLC层<br/>分段/重组 · ARQ重传"]
        MAC["MAC层<br/>复用 · HARQ · 调度"]
        PHY["物理层<br/>调制 · 编码 · 发射"]
    end

    APP --> PDCP
    PDCP -->|"RLC SDU"| RLC
    RLC -->|"RLC PDU"| MAC
    MAC -->|"传输块 TB"| PHY

    style RLC fill:#FF6B6B,color:#fff,stroke:#333
    style PDCP fill:#4ECDC4,color:#fff,stroke:#333
    style MAC fill:#45B7D1,color:#fff,stroke:#333
    style PHY fill:#96CEB4,color:#fff,stroke:#333

RLC层从PDCP层接收的数据单元叫 RLC SDU（Service Data Unit），经过处理后向下发送给MAC层的数据单元叫 RLC PDU（Protocol Data Unit）。这个"S到P"的转换过程，就是RLC层工作的核心。

为什么要分段？——理解RLC的核心问题

在深入三种模式之前，必须先理解一个根本问题：为什么需要分段？

MAC层每次调度给手机的资源大小是不固定的——这取决于当前信道质量、小区负载、调度策略等。假设PDCP层下来一个1500字节的IP包，但MAC层这次只给了800字节的空间，怎么办？

RLC层的解决方案是：把大包切成小片，分多次发送。 这就是分段（Segmentation）。接收端的RLC层再把这些片段重新拼装回去，这就是重组（Reassembly）。

这个分段/重组能力，是RLC最基础的功能。而三种模式的核心区别，就在于除了分段/重组之外，还提供哪些额外服务。

模式一：透明模式（TM）——"原封不动地传"

核心思想

透明模式下，RLC层什么也不做。上层来的数据原封不动地传给MAC层，不加任何协议头，不做任何处理。

类比：就像你往信箱里塞传单，传单上不需要写收件人地址（因为是广播），也不需要挂号回执（丢了就丢了）。

TM的特点

TM用在哪里？

TM模式只用于两种逻辑信道：

• BCCH（广播控制信道）：基站广播系统信息（SIB），告诉所有手机"我是谁、我在哪、频段是什么"
• PCCH（寻呼控制信道）：基站发寻呼消息，通知某个手机"你有来电"

这两种消息有一个共同特点：面向全体终端，追求最小开销，允许丢失。 系统信息会周期性重复广播，丢了就等下一轮；寻呼消息也会重发，不需要RLC层操心。

为什么这样设计？

• 广播消息不能针对单个终端建立重传机制。 如果1000个手机都没收到SIB，难道基站要重传1000次？不现实。
• 系统信息本身会周期性重复。 SIB每160ms发一次，这次没听到，160ms后还有机会。
• 零开销意味着更多空间留给真正的数据。 一个RLC头部虽然只有几个字节，但在资源极其紧张的广播信道上，省一点是一点。

模式二：非确认模式（UM）——"分段到位，丢了不管"

核心思想

UM模式给数据包加上了RLC头部（包含序列号SN和分段信息），支持分段/重组和按序递交，但不提供重传机制。包发出去了就不管了，收到就收到，丢了就丢了。

类比：就像送外卖——你把订单编号写在袋子上（序列号），汤和菜分开装（分段），送到之后不要求客户签收确认（不重传）。因为外卖的核心诉求是快，而不是100%确认送达。

UM的数据处理流程

sequenceDiagram
    participant PDCP as PDCP层
    participant RLC_Tx as RLC发送端<br/>（UM模式）
    participant RLC_Rx as RLC接收端<br/>（UM模式）
    participant MAC as MAC层

    PDCP->>RLC_Tx: RLC SDU #1 (1500字节)
    PDCP->>RLC_Tx: RLC SDU #2 (300字节)

    Note over RLC_Tx: MAC指示本次可发800字节

    RLC_Tx->>RLC_Tx: 将SDU #1分段<br/>片段A(800字节) + 片段B(700字节)
    RLC_Tx->>RLC_Tx: 添加RLC头部<br/>SI=01(首段) SN=0

    RLC_Tx->>MAC: RLC PDU (头部 + 片段A)

    Note over RLC_Tx: 下一次调度

    RLC_Tx->>RLC_Tx: 拼接：片段B(700字节) + SDU #2(300字节)
    RLC_Tx->>RLC_Tx: 添加RLC头部<br/>SI=11(中段+完整SDU)

    RLC_Tx->>MAC: RLC PDU (头部 + 片段B + SDU #2)

    MAC->>RLC_Rx: 收到PDU
    RLC_Rx->>RLC_Rx: 解析头部，提取SN和SI
    RLC_Rx->>RLC_Rx: 根据SN和SI重组SDU
    RLC_Rx->>PDCP: 递交完整的RLC SDU

RLC头部的关键字段

UM模式下的RLC头部非常精简，主要包含：

SI字段的含义：

UM用在哪里？

UM模式主要用于时延敏感、可容忍少量丢包的业务：

• VoNR语音通话：语音包每20ms一个，如果丢了一个包，等重传来不及，不如用上一帧的数据来补偿（丢包隐藏算法），继续播放
• 视频流媒体：实时视频对时延极其敏感，丢几帧画面可以接受，但卡顿不行
• 某些VR/AR业务：实时交互场景，延迟比完整性更重要

为什么不给语音加重传？

假设一个语音包的传输+处理延迟是10ms，如果RLC层重传一次，就要额外加上一个RTT（往返时间，约8ms），总延迟变成18ms。如果连续丢包触发多次重传，延迟可能飙到50ms以上——这对语音通话来说是灾难性的，用户会感觉到明显的卡顿和回声。

相比之下，丢一两个语音包（约20ms的音频），人耳几乎察觉不到，或者可以用简单的插值算法补偿。所以UM模式选择"丢了就丢了"的策略，换取更低的延迟。

模式三：确认模式（AM）——"必须签收，缺一不可"

核心思想

AM模式是RLC层功能最丰富的模式。它不仅支持分段/重组，还提供了ARQ（自动重传请求）机制，确保数据100%可靠地、按顺序地送达。

类比：就像寄合同——每一页都编好页码（序列号），收件人收到后逐页检查，发现缺页就立即通知你补发（STATUS PDU），直到所有页码齐全、顺序正确才签收确认。

AM的完整工作流程

sequenceDiagram
    participant PDCP as PDCP层
    participant RLC_Tx as RLC发送端<br/>（AM模式）
    participant RLC_Rx as RLC接收端<br/>（AM模式）

    Note over RLC_Tx: 发送窗口管理
    PDCP->>RLC_Tx: SDU 0, 1, 2, 3, 4

    RLC_Tx->>RLC_Rx: PDU SN=0 ✅
    RLC_Tx->>RLC_Rx: PDU SN=1 ❌ (丢失)
    RLC_Tx->>RLC_Rx: PDU SN=2 ✅
    RLC_Tx->>RLC_Rx: PDU SN=3 ✅

    Note over RLC_Rx: 检测到SN=1缺失<br/>VR(R)=1<br/>VR(H)=4

    RLC_Rx->>RLC_Tx: STATUS PDU<br/>ACK: SN=0<br/>NACK: SN=1

    Note over RLC_Tx: 收到NACK，重传SN=1

    RLC_Tx->>RLC_Rx: PDU SN=1 (重传) ✅

    Note over RLC_Rx: 所有SN已按序收到<br/>VR(R)更新到5

    RLC_Rx->>PDCP: 按序递交SDU 0,1,2,3,4

AM的关键机制

1. 序列号（SN）与滑动窗口

AM模式使用12位或18位的序列号。18位序列号范围达到262144，可以满足5G高速数据业务的需求。发送端和接收端各维护一组状态变量：

发送窗口的大小等于 VT(S) - VT(A)，表示"已经发出但还没确认"的PDU数量。只有收到确认后，窗口才能向前滑动，继续发送新的数据。

2. Poll机制——主动索要回执

发送端不能一直傻等，它需要主动询问接收端"收到了吗？"。这个询问机制叫Poll（轮询）。

Poll触发的条件有多种：

发送端在PDU头部设置 P bit（Poll比特）= 1，接收端看到P=1就知道"对方在问我收没收到"，于是立即回复一个STATUS PDU。

3. STATUS PDU——收发双方的"对账单"

STATUS PDU是AM模式的核心控制消息，它告诉发送端：

• ACK：哪些SN已经正确收到
• NACK：哪些SN缺失或错误，需要重传
• NACK with SO：具体是哪个SN的哪个片段缺失（精细到字节级别）

$$\text{STATUS PDU} = \text{CPT} + \text{ACK_SN} + \sum_{i}(\text{NACK_SN}_i + \text{SO}_i)$$

其中ACK_SN表示"这个SN之前的都已经收到了"，NACK_SN_i表示"第i个缺失的SN"，SO（Segment Offset）表示缺失片段在原始SDU中的偏移位置。

4. 重传与重新分段

AM模式有一个精妙的设计：重传时可以重新分段。

假设原始PDU是800字节，但重传时MAC层只给了500字节的空间。AM模式允许RLC层把原始PDU再切成两段：500+300，分两次重传。接收端通过SO（Segment Offset）字段来拼装这些片段。

这个设计解决了一个实际问题：重传时的调度资源可能比初传时更少（因为信道变差了），如果不能重新分段，重传就无法进行。

5. 重传次数限制

参数 maxRetxThreshold 控制最大重传次数，可选值为1、2、3、4、6、8、16、32。

如果某个PDU重传超过这个次数仍然失败，RLC层会向上层报告RLF（Radio Link Failure），触发RRC重建或连接释放。这是一个"保底机制"——如果连重传32次都收不到，说明信道已经烂到没法用了，不如重新建连接。

三种模式全景对比

为什么需要两层重传？——HARQ vs RLC ARQ

很多初学者的疑问是：MAC层已经有HARQ重传了，为什么RLC层还要搞ARQ重传？这不是多此一举吗？

这是一个非常好的问题。答案是：这是"纵深防御"的设计思想，两层重传各有分工、互相补充。

graph TD
    subgraph "第一道防线：HARQ（MAC层）"
        H1["快速反馈<br/>1个时隙内"]
        H2["软合并<br/>Chase/IR"]
        H3["最多重传4次"]
        H4["捕获随机错误<br/>成功率>99%"]
    end

    subgraph "第二道防线：RLC ARQ"
        R1["STATUS PDU反馈<br/>几个毫秒级"]
        R2["精确重传<br/>只补缺失片段"]
        R3["最多重传32次"]
        R4["捕获残余错误<br/>成功率≈100%"]
    end

    H1 --> H2 --> H3 --> H4
    H4 -->|"残余错误<br/>约1%概率"| R1
    R1 --> R2 --> R3 --> R4

    style H1 fill:#FF6B6B,color:#fff
    style H4 fill:#FF6B6B,color:#fff
    style R1 fill:#4ECDC4,color:#fff
    style R4 fill:#4ECDC4,color:#fff

核心逻辑：HARQ处理99%以上的传输错误（快速、高效），剩下不到1%的"漏网之鱼"交给RLC ARQ来兜底。两层配合，实现了接近100%的可靠传输。

打个比方：HARQ就像快递公司的"当日达"服务，当天没送到就立刻补发；RLC ARQ就像"签收确认"服务，如果连续几天都没签收，就启动更高级别的追查流程。两者缺一不可。

实战连接：工程师如何用到这些知识

1. 信令抓包分析

当你用Wireshark或QXDM抓取5G信令时，会看到RLC层的统计数据。如果发现某个DRB的RLC重传率异常高，说明物理层信道质量持续较差，HARQ已经无法有效纠错。这时需要排查：

• 是否存在干扰（同频干扰、外部干扰源）
• 终端是否处于小区边缘
• 是否存在塔下黑（近端信号反而差）

2. 语音质量调优

VoNR使用UM模式的RLC bearer。如果用户投诉语音质量差，但RLC层统计显示丢包率不高（<1%），那问题可能出在：

• PDCP层的抖动缓冲区配置不合理
• MAC层调度不及时（SR/BSR配置问题）
• 核心网侧的IMS媒体处理异常

如果RLC丢包率>3%，则需要优先排查无线侧问题。

3. 数据业务吞吐量优化

数据业务使用AM模式。如果发现下载速度慢，检查RLC层统计：

• RLC重传比例过高：物理层问题，检查SINR、MCS等级
• Poll触发过于频繁：窗口可能配置太小，限制了吞吐量
• STATUS PDU发送间隔过大：t-StatusProhibit定时器设置过长，导致反馈不及时

4. 常见调试陷阱

设计哲学总结：为什么是三种而不是一种？

RLC三种模式的设计，体现了通信系统设计中一个核心原则：没有免费的午餐——可靠性、实时性和开销，三者不可兼得。

$$\text{优化目标} = \alpha \cdot \text{可靠性} + \beta \cdot \text{实时性} + \gamma \cdot \text{开销最小化}$$

• TM模式：$\alpha \to 0, \beta \to \max, \gamma \to \max$（可靠性不重要，追求零开销和最快速度）
• UM模式：$\alpha \to \text{medium}, \beta \to \text{high}, \gamma \to \text{medium}$（在可靠性和实时性之间折中）
• AM模式：$\alpha \to \max, \beta \to \text{low}, \gamma \to 0$（追求极致可靠性，容忍额外延迟和开销）

5G网络承载的业务千差万别——从要求毫秒级延迟的URLLC，到要求99.999%可靠性的文件传输，再到需要覆盖所有终端的系统广播。单一模式无法同时满足这些需求，所以3GPP设计了三种模式，让每种业务都能找到最适合自己的传输策略。

这背后折射出的设计智慧是：好的系统设计不是追求"一个方案解决所有问题"，而是提供"一组工具，让每种场景都能找到最优解"。

常见问题

Q: TM模式没有任何处理能力，那它存在的意义是什么？为什么不让BCCH直接从PDCP到MAC？

A: TM模式的"什么都不做"本身就是一种选择。保留RLC层（即使只是透传）的好处是：(1) 协议栈架构统一，所有逻辑信道都经过RLC层，MAC层不需要区分有无RLC的场景；(2) 未来如果需要对广播消息做处理（比如NR MBS场景），可以在RLC层扩展，不用改架构。

Q: UM模式和AM模式都能做分段/重组，那如果我的业务既要求低延迟又要求可靠呢？

A: 5G的设计是让HARQ在MAC层提供快速重传（对所有模式都生效），RLC ARQ只用于AM模式作为第二道防线。如果你的业务是URLLC类型（既低延迟又高可靠），5G的方案是：(1) 使用AM模式但优化重传参数（减小t-PollRetransmit等定时器）；(2) 配合MAC层的高优先级调度和更激进的MCS选择来减少错误发生概率。

Q: AM模式下，如果发送端一直收不到STATUS PDU怎么办？

A: 有多重保护机制：(1) Poll定时器（t-PollRetransmit）超时后会再次发送Poll；(2) 如果重传次数超过maxRetxThreshold，会触发RLF，RRC层尝试重建连接；(3) PDCP层也有自己的重传和丢弃定时器，作为最后一道保险。

Q: 为什么5G NR的AM模式SN长度从LTE的10/12位扩展到了12/18位？

A: 因为5G的数据速率远超4G。以10Gbps速率为例，每个RLC PDU平均1500字节，每秒需要发送约80万个PDU。12位SN只能表示4096个编号，不到1ms就循环一次，可能导致序号混淆。18位SN可以表示262144个编号，提供了足够的窗口空间来应对高速数据流。

Q: RLC AM的重传和TCP的重传会不会冲突？

A: 不会冲突，但可能造成不必要的延迟叠加。这就是所谓的"RLC AM + TCP"双重重传问题。好在5G网络中RLC ARQ的RTT远小于TCP的RTT，大多数情况下RLC ARQ会在TCP超时之前就完成重传，TCP根本感知不到丢包。这也是为什么移动网络中通常建议使用RLC AM（而不是UM+TCP重传）来传输TCP业务——RLC层的重传比TCP重传快得多。

参考来源

1. ShareTechnote - 5G NR RLC — RLC层三种模式的详细图解和PDU格式分析
2. ShareTechnote - 5G HARQ — HARQ与RLC ARQ的两层重传机制对比
3. 5G NR Radio Protocol Architecture - 3G4G — 5G NR协议栈架构总览
4. RF Wireless World - RLC Layer in 5G NR — RLC层功能、模式和流程介绍
5. 《5G无线接入网技术原理与实践》 — RLC层三种传输模式的工程实践分析

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。