NR RLC AM ARQ重传与再分段三层定时器博弈

聚焦 3GPP TS 38.322 V19.x，拆解 RLC AM 确认模式下的 ARQ 重传、STATUS PDU 交互、再分段（Resegmentation）以及三层定时器（t-PollRetransmit / t-Reassembly / t-StatusProhibit）的联动博弈机制。

一、为什么 RLC AM 需要独立于 HARQ 的 ARQ？

5G NR 的可靠性保障是一个双层架构：

HARQ 负责快速、物理层的纠错，但存在两个盲区：

1. HARQ 达到最大重传次数后仍然失败（max HARQ transmissions 耗尽），MAC 层丢弃 TB，但 RLC AM 在 L2 还可以发起 ARQ 重传；
2. 多个 HARQ 进程并行时，某些进程的 NACK 可能被 MAC 层复用丢失或因 MAC CE 调度优先级被抢占，导致 PDCP 之下的数据"黑洞"。

RLC AM 的 ARQ 正是这两道防线之间的兜底机制。TS 38.322 Section 5.2.1 定义了 AM RLC 实体的完整架构，包含发送端（Transmitting Side）和接收端（Receiving Side），两端各自维护一套状态变量和定时器。

核心设计意图：HARQ 解决"微秒级"的快衰落，RLC ARQ 解决"毫秒级"的持续信道恶化和 HARQ 覆盖不到的边缘场景。

二、RLC AM 实体状态变量全景图

TS 38.322 Section 7 定义了 AM RLC 实体的全部状态变量。理解这些变量是掌握 ARQ 博弈的前提。

graph TB
    subgraph TX["发送端 Transmitting Side"]
        VTA["VT(A)<br/>最早未确认SN"]
        VTS["VT(S)<br/>下一个待分配SN"]
        VTMS["VT(MS)<br/>发送窗口上沿<br/>= VT(A) + AM_Window_Size"]
        POLL_SN["POLL_SN<br/>最近一次Poll时的SN"]
        PDU_WITHOUT_POLL["PDU_WITHOUT_POLL<br/>距上次Poll已发PDU数"]
        BYTE_WITHOUT_POLL["BYTE_WITHOUT_POLL<br/>距上次Poll已发字节数"]
    end

    subgraph RX["接收端 Receiving Side"]
        VRR["VR(R)<br/>下一个期望的按序SN"]
        VRX["VR(X)<br/>t-Reassembly触发SN"]
        VRMS["VR(MS)<br/>STATUS PDU报告上沿<br/>= VR(R) + AM_Window_Size"]
        VRH["VR(H)<br/>收到的最高SN+1"]
    end

    VTA -->|"滑动：收到ACK后前推"| VTS
    VTS -->|"窗口约束：不能超过VT(MS)"| VTMS
    VRR -->|"按序接收后前推"| VRH
    VRX -->|"t-Reassembly到期时"| VRMS

关键状态变量详解

AM_Window_Size 取决于 SN 长度配置（TS 38.322 Section 7）：

三、ARQ 完整信令时序流

下面是基于 TS 38.322 Section 5.3.3（ARQ 复位）和 Section 5.2.3（STATUS PDU 传输）的完整 ARQ 交互时序图：

sequenceDiagram
    participant TX as AM RLC TX
    participant RX as AM RLC RX

    Note over TX,RX: 正常发送阶段
    TX->>RX: AMD PDU (SN=10, SI=完整)
    TX->>RX: AMD PDU (SN=11, P=1, SI=完整)
    Note right of TX: P=1 触发Poll<br/>启动 t-PollRetransmit

    Note over RX: 收到SN=11<br/>检测缺口: 缺少SN=10
    Note over RX: 启动 t-Reassembly
    RX-->>TX: STATUS PDU (ACK_SN=10, NACK_SN=10)
    Note left of RX: 检查 t-StatusProhibit<br/>未运行才发送
    Note over TX: 收到STATUS<br/>停止 t-PollRetransmit

    Note over TX,RX: 重传阶段 - 原始PDU过大需再分段
    TX->>RX: AMD PDU segment (SN=10, SI=第一段, SO=0)
    TX->>RX: AMD PDU segment (SN=10, SI=最后段, SO=500)
    Note right of TX: 再分段: 原始1000字节<br/>分为两段发送

    Note over RX: t-Reassembly 运行中<br/>等待SN=10完整接收
    RX-->>TX: STATUS PDU (ACK_SN=12)
    Note over TX: VT(A) 滑动到 12
    Note over TX: 通知 PDCP: SDU 10,11 已确认

3.1 正常发送阶段的关键步骤

发送端（TS 38.322 Section 5.3.2）： 1. PDCP 通过 RLC_DATA_REQ 原语递交 RLC SDU 2. AM RLC 将 SDU 放入 Transmission Buffer，分配 SN = VT(S) 3. 当 MAC 层通过 MAC_DATA_REQ 请求时，RLC 从 Buffer 取出 SDU 进行分段（如需要），添加 RLC 头（含 SN、SI、P 字段） 4. 如果触发 Poll 条件满足（见第四章），设置 P=1，记录 POLL_SN = VT(S)-1，启动 t-PollRetransmit

接收端（TS 38.322 Section 5.2.3）： 1. 收到 AMD PDU，根据 SN 和 SI 判断是否为分段 2. 如果 SN ≥ VR(H)，更新 VR(H) = SN + 1 3. 如果检测到缺口（SN > VR(R) 但 VR(R) 尚未收到），启动 t-Reassembly，设置 VR(X) = VR(H) 4. 如果 P=1，触发 STATUS PDU 发送（受 t-StatusProhibit 约束）

3.2 STATUS PDU 格式与 IE 解析

STATUS PDU 是 RLC AM 的"心脏跳动"。TS 38.322 Section 6.3.3 定义了其精确格式：

STATUS PDU 格式 (TS 38.322 Section 6.3.3):
+--+----+--------+----+----+----+
|D/C| CPT|ACK_SN | E1 | E2 | E3 |
+--+----+--------+----+----+----+
|  NACK_SN (可选)                  |
|  SOstart (可选, E2=1)           |
|  SOend   (可选, E2=1)           |
|  NACK_SN range (可选, E3=1)     |
+---------------------------------+

设计意图：E1/E2/E3 的扩展标志链式结构允许一个 STATUS PDU 中报告多个不连续的缺口和分段级的精确NACK，避免逐个 PDU 报告带来的信令开销。

四、Poll 机制：发送端的主动试探

Poll 是 RLC AM ARQ 中的"主动试探"机制。发送端不能一直被动等待接收端的 NACK，需要主动设置 P=1 来触发 STATUS 报告。

4.1 Poll 触发条件（TS 38.322 Section 5.3.4）

flowchart TD
    START[发送新AMD PDU/段] --> CHECK1{新PDU到Buffer<br/>且Buffer变空?}
    CHECK1 -->|是| POLL[设置 P=1]
    CHECK1 -->|否| CHECK2{新段到Retx Buffer<br/>且Retx Buffer变空?}
    CHECK2 -->|是| POLL
    CHECK2 -->|否| CHECK3{PDU_WITHOUT_POLL<br/>≥ pollPDU?}
    CHECK3 -->|是| POLL
    CHECK3 -->|否| CHECK4{BYTE_WITHOUT_POLL<br/>≥ pollByte?}
    CHECK4 -->|是| POLL
    CHECK4 -->|否| CHECK5{t-PollRetransmit<br/>超时?}
    CHECK5 -->|是| POLL
    CHECK5 -->|否| NOP[不设置Poll]

    POLL --> RECORD[记录 POLL_SN = VT(S)-1]
    RECORD --> RESTART[重启 t-PollRetransmit]
    RESTART --> RESET_COUNTER[PDU_WITHOUT_POLL=0<br/>BYTE_WITHOUT_POLL=0]

4.2 Poll 参数配置与博弈

RRC 通过 RLC-BearerConfig → RLC-Config → AM-RLC 配置以下参数（TS 38.331 Section 6.3.2）：

实战博弈分析：

• eMBB 大包场景（如视频流）：pollByte 设为 256KB~1MB，pollPDU 设为 64~128。因为大包场景下 PDU 数量多但单个大，字节维度触发更合理。
• URLLC 低时延场景：pollPDU 设为 4~8，t-PollRetransmit 设为 5~10ms。需要快速检测丢包并重传。
• VoNR 语音场景：语音包小（~40 bytes），pollPDU 设为 16~32 即可，避免频繁 Poll。

五、再分段（Resegmentation）机制

再分段是 RLC AM ARQ 中最精巧的设计之一。当原始 AMD PDU 的大小超过了当前 MAC 调度授权（Grant）时，发送端需要将重传的 PDU 再切割成更小的段。

5.1 分段信息（SI）字段

TS 38.322 Section 6.2.2.5 定义了 SI（Segmentation Info）字段：

5.2 再分段的具体过程

flowchart LR
    subgraph Original["原始 AMD PDU (SN=20, 1200字节)"]
        A1["RLC Header<br/>SN=20, SI=00"]
        A2["RLC Payload<br/>1200 bytes"]
    end

    subgraph Reseg["再分段后 (当前Grant仅500字节)"]
        B1["AMD PDU Segment 1<br/>SN=20, SI=01<br/>SO=0, LSF=0"]
        B2["AMD PDU Segment 2<br/>SN=20, SI=10<br/>SO=500, LSF=1"]
    end

    A1 -.->|首次发送失败| B1
    A2 -.-> B2

再分段头格式（TS 38.322 Section 6.2.2.4）：

5.3 为什么需要再分段？

MAC 层的调度授权（Grant）是动态变化的。首次发送时可能分配了 1200 字节的 TBS，但重传时信道恶化，MAC 调度器只给 500 字节。如果不支持再分段，发送端必须等待更大的 Grant 才能重传，这会引入不可预测的额外时延。

再分段的价值：用当前可用的任何 Grant 尺寸"切一块"发出去，积少成多完成重传。这对于 VoNR 和 URLLC 等时延敏感场景至关重要。

六、三层定时器联动博弈

RLC AM 的三个定时器形成了一个精妙的联动系统。任何一个配置不当，都会导致 ARQ 效率急剧下降甚至失效。

graph TB
    subgraph TX["发送端"]
        TPOLL["t-PollRetransmit<br/>触发Poll重发"]
    end

    subgraph RX["接收端"]
        TREA["t-Reassembly<br/>检测丢包缺口"]
        TSTATUS["t-StatusProhibit<br/>抑制STATUS发送频率"]
    end

    TX -->|"AMD PDU with P=1"| RX
    RX -->|"STATUS PDU (NACK)"| TX
    RX -->|"检测到SN缺口"| TREA
    TREA -->|"超时:确认丢包"| TSTATUS
    TSTATUS -->|"超时/未运行<br/>允许发送STATUS"| TX
    TX -->|"未收到STATUS<br/>超时重发Poll"| TPOLL
    TPOLL -->|"重发带P=1的PDU"| RX

    style TREA fill:#ff6b6b,color:#fff
    style TPOLL fill:#4ecdc4,color:#fff
    style TSTATUS fill:#ffe66d,color:#333

6.1 t-Reassembly：丢包检测器

定义（TS 38.322 Section 5.3.7）：

• 启动条件：接收端检测到 SN 缺口（收到 SN > VR(R) 的 PDU，但 VR(R) 本身尚未收到），且 t-Reassembly 未运行
• 停止条件：
• VR(R) 前推到覆盖了缺口位置
• VR(R) ≥ VR(X)（t-Reassembly 触发时记录的 VR(X)）
• 超时处理：
• 将 VR(R) 前推到 VR(H)，即放弃等待中间缺失的 PDU
• 触发 STATUS PDU 发送（受 t-StatusProhibit 约束），报告这些 SN 为 NACK

关键博弈：t-Reassembly 值的设置直接影响丢包检测的灵敏度。

6.2 t-StatusProhibit：STATUS 节流阀

定义（TS 38.322 Section 5.3.5）：

• 功能：防止接收端过于频繁地发送 STATUS PDU
• 机制：每次发送 STATUS PDU 后启动此定时器，运行期间禁止发送新的 STATUS PDU
• 超时后：如果有待发的 STATUS 报告（STATUS_report_needed = true），立即发送

博弈分析：

t-StatusProhibit 和 t-Reassembly 的配合至关重要。如果 t-StatusProhibit > t-Reassembly，可能导致接收端检测到丢包但无法立即报告，必须等到 t-StatusProhibit 超时。这引入了额外时延。

典型配置关系：

t-StatusProhibit < t-PollRetransmit  ← 推荐

如果反过来（t-StatusProhibit > t-PollRetransmit），发送端 Poll 超时后重发 Poll，但接收端仍然被 t-StatusProhibit 抑制无法回复，造成 Poll 循环浪费。

6.3 t-PollRetransmit：Poll 守护者

定义（TS 38.322 Section 5.3.4）：

• 启动：每次发送带 P=1 的 AMD PDU 后启动/重启
• 停止：收到 STATUS PDU 后停止
• 超时处理：
• 如果 Transmission Buffer 或 Retransmission Buffer 中有数据：从 Buffer 中取出 PDU（或 Retx Buffer 中取出），设置 P=1 后发送
• 如果 Buffer 为空：发送一个带 P=1 的空 AMD PDU（SN=VT(S)，无 payload）
• 重启 t-PollRetransmit

博弈：t-PollRetransmit 需要大于 HARQ 的最大处理时间（包括可能的 HARQ 重传），否则会在 HARQ 尚未完成时就触发无谓的 Poll。

t-PollRetransmit ≥ kRTT + maxHARQTx × HARQ_RTT

其中 kRTT 是一个安全系数（通常 1.5~2）。

6.4 三定时器联动时序图

sequenceDiagram
    participant TX as TX AM RLC
    participant RX as RX AM RLC

    rect rgb(230, 245, 255)
    Note over TX: t-PollRetransmit 域
    TX->>RX: AMD PDU (SN=5, P=1)
    Note right of TX: 启动 t-PollRetransmit=80ms

    Note over RX: 缺口: SN=3 未收到
    rect rgb(255, 230, 230)
    Note over RX: t-Reassembly 域
    Note right of RX: 启动 t-Reassembly=50ms
    end

    rect rgb(255, 255, 220)
    Note over RX: t-StatusProhibit 域
    Note right of RX: t-StatusProhibit=20ms<br/>未运行,可发送STATUS
    end

    RX-->>TX: STATUS PDU (ACK_SN=3, NACK_SN=3)
    Note over TX: 停止 t-PollRetransmit
    Note right of RX: 启动 t-StatusProhibit=20ms
    end

    Note over TX: 重传 SN=3
    TX->>RX: AMD PDU (SN=3, 重传)

    Note over RX: 收到SN=3, VR(R)前推
    Note right of RX: 停止 t-Reassembly

    Note over RX: t-StatusProhibit超时(20ms后)
    RX-->>TX: STATUS PDU (ACK_SN=6)
    Note over TX: VT(A) 滑动到 6

七、maxRetxThreshold 与 RLF 触发

当 AMD PDU（或其分段）的重传次数达到 maxRetxThreshold 时，TS 38.322 Section 5.3.5 规定：

if RETX_COUNT >= maxRetxThreshold:
    指示上层（RRC）：RLC 不可恢复失败

TS 38.331 Section 5.3.10 将此作为 RLF 触发条件之一：

T310 timer trigger: "Indication from RLC that the maximum number of retransmissions has been reached for SRB1 or SRB2"

关键细节：

• 对于 SRB（信令承载），RLF 直接触发 RRC 重建
• 对于 DRB（数据承载），RLC 失败指示给 PDCP，PDCP 可选择触发数据承载的挂起，但不直接触发 RLF
• RETX_COUNT 针对的是同一个 RLC SDU（不是 PDU），即使经过再分段，只要属于同一 SDU 的重传都计入

maxRetxThreshold 配置建议

八、抓包识别与故障排查

8.1 抓包识别 RLC AM ARQ 流程

使用 Wireshark（需支持 NR RLC dissectors）或厂商专有工具（如 Ericsson ENM/LM、华为 U2020）：

8.2 常见故障模式

故障 1：STATUS PDU 风暴 - 现象：t-StatusProhibit 配置为 0ms 或过小，接收端频繁发送 STATUS PDU - 影响：上行资源被 STATUS PDU 占满，有效数据吞吐量下降 - 排查：检查 RRCReconfiguration 中 t-StatusProhibit 配置值

故障 2：Poll 超时循环 - 现象：t-PollRetransmit < HARQ 总处理时间，导致 Poll 重复超时 - 影响：下行不必要的 Poll PDU 浪费 Grant，甚至挤占业务数据 - 排查：对比 t-PollRetransmit 值与 HARQ maxTx × HARQ_RTT

故障 3：窗口停滞（Window Stall） - 现象：VT(S) 达到 VT(MS)，无法发送新数据 - 根因：接收端 STATUS PDU 丢失或 t-StatusProhibit 过长导致 VT(A) 不前推 - 排查：检查 STATUS PDU 是否被 MAC 层丢弃（优先级低），或 t-StatusProhibit 是否大于 t-PollRetransmit

故障 4：RLC RLF 误触发 - 现象：UE 在覆盖尚可的区域频繁 RRC 重建 - 根因：maxRetxThreshold 过小，或 HARQ 配置与 RLC 定时器不协调 - 排查：查看 RLC 层日志中的 RETX_COUNT 计数趋势，配合 RSRP/SINR 判断是否真的信道恶化

九、与 LTE RLC AM 的关键差异

再分段是 NR 相对 LTE 最显著的增强。LTE RLC AM 不支持再分段，意味着重传时必须用与首次发送相同大小的 PDU。如果 MAC Grant 不足，就只能等待，这在高速移动和信道快速变化场景下成为瓶颈。

常见问题

Q: RLC ARQ 和 HARQ 的重传计数是独立的吗？ A: 是的，完全独立。HARQ 在 L1 有自己的最大重传次数（max HARQ transmissions，由 RRC 配置，通常 4~8 次）。RLC ARQ 的 RETX_COUNT 只在 RLC 层维护。HARQ 耗尽最大次数后 MAC 丢弃 TB，RLC ARQ 才"看到"缺口并触发 NACK 重传。两者是串联关系，不是替代关系。

Q: t-StatusProhibit 设为 0 会有什么后果？ A: t-StatusProhibit=0 意味着接收端可以无限制地发送 STATUS PDU。在高速运动、信道频繁波动的场景下，每收到一个带缺口的 PDU 就触发一次 STATUS PDU，可能导致上行 STATUS PDU 泛滥，挤占上行数据资源。但在极低速率、极简场景下（如 NB-IoT），设为 0 可以最小化反馈时延。

Q: 再分段时 SN 是否会改变？ A: 不会。再分段后的所有段都保持原始 PDU 的 SN。接收端通过 SO（Segment Offset）和 LSF（Last Segment Flag）来区分和重组同一 SN 的不同段。这是设计上的精妙之处——SN 空间不会被重传消耗。

Q: 为什么 NR 要把 RLC 级联功能移到 MAC 层？ A: NR 引入了灵活的 numerology 和 mini-slot，MAC 层需要精确控制 TB 大小来匹配动态调度。将级联放在 MAC 层可以让调度器对 TB 内部的 RLC PDU 组合有完全控制权，实现更高效的资源利用。RLC 层专注分段和 ARQ，职责更清晰。

Q: 如何判断一个 RLF 是 RLC 层导致的还是物理层导致的？ A: 查看日志中的 RLF 触发原因。如果是 rlc-MaxNumRetx 触发，说明是 RLC ARQ 达到 maxRetxThreshold；如果是 T310 expiry（物理层问题检测定时器），说明是物理层连续失步。两者都可能导致最终 RRC 重建，但根因不同，优化方向也不同——RLC RLF 优化定时器配置和 HARQ/ARQ 协调，物理层 RLF 优化覆盖和功率控制。

参考来源

1. 3GPP TS 38.322 V19.0.0 — NR RLC Protocol Specification, Sections 5.2-5.3, 6.2-6.3, 7
2. 3GPP TS 38.331 V19.x — NR RRC Protocol, RLC-Config IE definitions
3. 3glteinfo - 5G RLC ARQ Procedures — Retransmission, Polling and STATUS in NR
4. ShareTechnote - 5G/NR RLC — RLC timers and configuration parameters
5. ACM - Formal Analysis of 5G NR RLC AM Protocol — Probabilistic Model Checking for timer optimization

本文由「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 等场景全覆盖。