5G NR RRC Inactive态RNA更新与RAN寻呼机制全流程拆解

一、机制背景与设计动机

3GPP在5G NR中引入了一个全新的RRC状态——RRC_INACTIVE，这是LTE时代所没有的。在LTE中，UE只有RRC_IDLE和RRC_CONNECTED两种状态，导致一个核心矛盾：长时间保持RRC_CONNECTED会浪费无线资源，而回落到RRC_IDLE又意味着重新建立连接时需要经历完整的RRC Setup + NAS Registration + PDU Session Establishment流程，时延高达数百毫秒。

RRC_INACTIVE的设计意图正是在两者之间寻找平衡点：

• UE侧：释放RRC连接，停止监听PDCCH上的C-RNTI调度，大幅降低功耗
• 网络侧：UE仍处于CM-CONNECTED状态（NAS层面），核心网感知不到状态变化，AMF/UPF的N2/N3会话保持不变
• gNB侧：锚点gNB（Last Serving gNB）保留完整的UE AS上下文，包括安全上下文、DRB配置、SRB配置等

这使得UE从RRC_INACTIVE恢复到RRC_CONNECTED的时延可以压缩到20ms以内，相比从RRC_IDLE建立连接的100ms+，提升了一个数量级。

核心规范参考： - TS 38.300 Section 9.2.2 — RRC状态机总体描述 - TS 38.331 Section 5.3.13 — RRC Resume/RNA Update过程 - TS 38.331 Section 6.2.2 — SuspendConfig IE定义 - TS 38.401 Section 8.2 — NG-RAN中I-RNTI结构与上下文检索

二、RRC状态机与RNA概念

2.1 三态转换全景

stateDiagram-v2
    [*] --> RRC_IDLE : 开机/开机注册

    RRC_IDLE --> RRC_CONNECTED : RRC Setup\n(NAS Service Request)
    RRC_CONNECTED --> RRC_INACTIVE : RRC Release\n(suspendConfig)
    RRC_INACTIVE --> RRC_CONNECTED : RRC Resume\n(数据到达/RNA Update)
    RRC_INACTIVE --> RRC_IDLE : RRC Reject / 上下文丢失\nNAS Registration
    RRC_CONNECTED --> RRC_IDLE : RRC Release\n(无suspendConfig)

    state RRC_INACTIVE {
        [*] --> RNA内移动
        RNA内移动 --> RNA外移动 : 小区重选\n到RNA外
        RNA外移动 --> RNA_Update : 触发RRC Resume\n(cause=rnaUpdate)
        RNA内移动 --> 周期性更新 : t380超时
        周期性更新 --> RNA_Update : 触发RRC Resume\n(cause=rnaUpdate)
        RNA内移动 --> RAN寻呼响应 : 收到RAN Paging
        RAN寻呼响应 --> RRC_CONNECTED : 恢复连接
    }

2.2 RNA（RAN Notification Area）结构

RNA由锚点gNB在SuspendConfig中配置，可以表示为以下三种形式之一：

关键约束：RNA必须包含在UE注册的TAI List之内，这是RRC_INACTIVE状态下UE仍在CM-CONNECTED的逻辑基础。

三、进入RRC_INACTIVE：SuspendConfig深度解析

3.1 SuspendConfig IE结构

当gNB决定将UE挂起到RRC_INACTIVE时，通过RRC Release消息携带suspendConfig字段：

graph TD
    A[RRCRelease消息] --> B{suspendConfig存在?}
    B -->|是| C[进入RRC_INACTIVE]
    B -->|否| D[进入RRC_IDLE]

    C --> E[fullI-RNTI<br/>40 bit]
    C --> F[shortI-RNTI<br/>24 bit]
    C --> G[ran-PagingCycle<br/>RAN寻呼周期]
    C --> H[t380<br/>周期性RNA更新定时器]
    C --> I[ran-NotificationRadioBearer]

    E --> E1[高位: gNB ID<br/>低位: UE Context ID]
    F --> F1[高位: 截断gNB ID<br/>低位: 截断UE ID]

3.2 I-RNTI内部结构拆解

I-RNTI是RRC_INACTIVE机制的核心标识符，其40位结构的精巧设计直接影响了跨gNB场景下的上下文检索效率：

关键设计洞察：gNB ID长度是PLMN级参数，这意味着同一运营商网络内所有gNB必须使用相同的gNB ID长度。当gNB ID取32位时，UE Context ID仅剩8位（256个），这严重限制了单个gNB可同时挂起的UE数量。实际部署中，运营商通常选择22-26位的gNB ID长度，为UE Context ID留出14-18位（16K-256K）空间。

Short I-RNTI（24位）用于Msg1/Msg3中承载，节省空口开销，代价是gNB ID和UE ID都做了截断，新gNB可能需要通过试探匹配或广播配置来解析。

3.3 SuspendConfig关键参数表

四、RNA更新流程完整信令拆解

4.1 触发条件

根据TS 38.300 Section 9.2.2.4，RNA Update在以下三种条件下触发：

1. 移动性触发：UE小区重选到一个不属于当前RNA的小区
2. 周期性触发：定时器t380超时
3. RAN寻呼响应：UE收到RAN Paging后发起Resume

4.2 RNA Update完整信令时序图

sequenceDiagram
    participant UE
    participant New_gNB as 新gNB
    participant Anchor_gNB as 锚点gNB
    participant AMF
    participant UPF

    Note over UE: RRC_INACTIVE态<br/>小区重选到RNA外

    UE->>UE: 1. 检测到新小区不在RNA内<br/>触发RNA Update

    rect rgb(230, 245, 255)
    Note over UE,New_gNB: 随机接入阶段
    UE->>New_gNB: 2. MSG1: PRACH Preamble
    New_gNB->>UE: 3. MSG2: Random Access Response<br/>(RA-RNTI, TC-RNTI, TA)
    end

    rect rgb(255, 245, 230)
    Note over UE,New_gNB: RRC Resume请求（SRB0/CCCH）
    UE->>New_gNB: 4. RRCResumeRequest<br/>resumeIdentity=I-RNTI<br/>resumeCause=rnaUpdate<br/>shortMAC-I (16bit)
    Note over New_gNB: 5. 从I-RNTI解析出<br/>Anchor gNB ID
    end

    rect rgb(230, 255, 230)
    Note over New_gNB,Anchor_gNB: Xn接口上下文检索
    New_gNB->>Anchor_gNB: 6. XnAP: RETRIEVE UE CONTEXT REQUEST<br/>I-RNTI值 + shortMAC-I
    Note over Anchor_gNB: 7. 验证shortMAC-I<br/>查找UE AS上下文
    Anchor_gNB->>New_gNB: 8. XnAP: RETRIEVE UE CONTEXT RESPONSE<br/>UE Context (安全上下文/DRB/SRB配置)<br/>UE Context Reference
    end

    alt 上下文验证成功
        rect rgb(255, 230, 255)
        Note over New_gNB,UE: RRC响应
        New_gNB->>UE: 9a. RRCRelease (suspendConfig)<br/>新I-RNTI + 新RNA配置<br/>新t380 + 新ran-PagingCycle
        Note over UE: 保持RRC_INACTIVE<br/>更新RNA配置
        end

        New_gNB->>Anchor_gNB: 10a. XnAP: UE CONTEXT RELEASE<br/>（可选：不迁移上下文）
        Note over Anchor_gNB: 保留UE上下文

    else 上下文迁移（锚点重定位）
        rect rgb(255, 255, 230)
        New_gNB->>UE: 9b. RRCRelease (suspendConfig)<br/>新I-RNTI（本gNB分配）
        Note over UE: 保持RRC_INACTIVE
        end

        New_gNB->>AMF: 10b. NGAP: PATH SWITCH REQUEST<br/>UE NGAP IDs + 隧道信息
        AMF->>UPF: 11b. N4 Session Modification<br/>更新DL F-TEID
        UPF->>AMF: 12b. N4 Session Modification Response
        AMF->>New_gNB: 13b. NGAP: PATH SWITCH REQUEST ACK
        New_gNB->>Anchor_gNB: 14b. XnAP: UE CONTEXT RELEASE<br/>（锚点迁移，释放旧上下文）
        Note over Anchor_gNB: 释放UE上下文
    end

4.3 逐步信令IE详解

Step 4: RRCResumeRequest消息

这是RNA Update流程的起点消息，承载在SRB0（CCCH逻辑信道）上，使用Msg3资源发送：

shortMAC-I的计算过程（TS 38.331 Section 5.3.13.4）：

1. 使用UE和锚点gNB共享的安全密钥（KRRCenc、KRRCint）
2. 输入参数：I-RNTI、源PCI（Physical Cell Identity）、目标PCI、resumeCause
3. 输出经过截断的16位认证标签

锚点gNB收到RETRIEVE UE CONTEXT REQUEST后，使用保存的UE安全上下文重新计算shortMAC-I并与收到的值比对。若不匹配，请求将被拒绝。

Step 6-8: XnAP上下文检索

新gNB通过I-RNTI中的gNB ID部分确定锚点gNB地址，发起Xn接口的上下文检索：

Step 9a: RRCRelease with suspendConfig

典型的RNA Update响应——UE无需真正恢复连接，只需要更新位置信息：

SuspendConfig ::= SEQUENCE {
    fullI-RNTI                BIT STRING (SIZE(40)),    -- 新的完整I-RNTI
    shortI-RNTI               BIT STRING (SIZE(24)),    -- 新的短I-RNTI
    ran-PagingCycle           PagingCycle,              -- 新的RAN寻呼周期
    ran-NotificationRadioBearer  ENUMERATED {srb1, srb2},
    t380                      ENUMERATED {min5, min10, ...},  -- 重置定时器
    ...
}

如果锚点gNB决定不迁移上下文（UE移动范围有限），新gNB仅充当中继角色，转发RNA Update请求并中继回新的SuspendConfig。这种"轻量级"处理避免了NGAP信令交互，是RNA Update在正常情况下的最高效路径。

五、RAN寻呼机制深度分析

5.1 RAN Paging vs CN Paging对比

5.2 RAN Paging触发与转发流程

当DL数据到达锚点gNB，而UE处于RRC_INACTIVE时：

sequenceDiagram
    participant UPF
    participant AMF
    participant Anchor as 锚点gNB
    participant gNB2 as RNA内gNB2
    participant gNB3 as RNA内gNB3
    participant UE

    UPF->>Anchor: DL Data (GTP-U, N3隧道)
    Note over Anchor: 查找UE上下文<br/>发现UE在RRC_INACTIVE

    rect rgb(255, 230, 230)
    Note over Anchor: 本地寻呼（锚点gNB小区）
    Anchor->>UE: Paging (PCCH)<br/>I-RNTI + PagingIdentity
    end

    rect rgb(230, 230, 255)
    Note over Anchor,gNB3: Xn转发RAN寻呼
    Anchor->>gNB2: XnAP: RAN PAGING<br/>I-RNTI + UE Context Reference
    Anchor->>gNB3: XnAP: RAN PAGING<br/>I-RNTI + UE Context Reference

    gNB2->>UE: Paging (PCCH)<br/>I-RNTI
    gNB3->>UE: Paging (PCCH)<br/>I-RNTI
    end

    Note over UE: 在gNB3小区收到RAN Paging<br/>发起RRC Resume

    UE->>gNB3: RRCResumeRequest<br/>resumeCause=mt-Access
    gNB3->>Anchor: XnAP: RETRIEVE UE CONTEXT REQUEST
    Anchor->>gNB3: XnAP: RETRIEVE UE CONTEXT RESPONSE<br/>(完整UE上下文)
    gNB3->>gNB3: 恢复UE上下文，配置L1/L2
    gNB3->>UE: RRCResume<br/>(RadioBearerConfig等)
    UE->>gNB3: RRCResumeComplete

    gNB3->>AMF: NGAP: PATH SWITCH REQUEST
    AMF->>UPF: N4 Session Mod (更新DL F-TEID)
    UPF->>gNB3: DL Data (新N3隧道)
    gNB3->>Anchor: XnAP: UE CONTEXT RELEASE

5.3 RAN Paging的关键IE

在TS 38.331中，Paging消息对RRC_INACTIVE UE使用PagingRecord中的I-RNTI-Value作为寻呼标识：

Paging DRX机制：RRC_INACTIVE UE按照ran-PagingCycle（在SuspendConfig中配置）和UE自行计算的 Paging Frame + Paging Occasion 来监听寻呼。ran-PagingCycle独立于CN Paging Cycle（在SIB1中广播的defaultPagingCycle），这允许网络对RRC_INACTIVE UE使用更短的寻呼周期以降低寻呼时延。

六、锚点重定位决策机制

6.1 何时触发锚点迁移

锚点gNB在处理RNA Update时，需要决定是否将UE上下文迁移到新gNB。决策依据包括：

当锚点决定迁移时，新gNB需要发起NGAP Path Switch Request通知AMF更新N3隧道端点，这引入了额外的核心网信令开销。

6.2 上下文老化与清理

锚点gNB并非无限期保存UE上下文。TS 38.331和TS 38.401定义了以下清理机制：

1. 隐式过期：锚点gNB维护一个上下文保活定时器，若超过一定时间未收到RNA Update或RAN Paging响应，可主动释放上下文并通知AMF
2. AMF触发：AMF通过NGAP UE Context Release Command要求释放
3. OAM配置：运营商可配置最大上下文保存时间

当UE在上下文已被释放后发起RNA Update（如t380超时但锚点已清理），新gNB的RETRIEVE UE CONTEXT REQUEST将收到失败响应，UE被迫回落到RRC_IDLE执行NAS Registration。

七、安全机制深度分析

7.1 shortMAC-I验证流程

RRC_INACTIVE安全模型的核心挑战是：如何在不恢复完整安全连接的情况下验证UE身份？

flowchart TD
    A[UE发起RRCResumeRequest] --> B[携带shortMAC-I<br/>16bit认证标签]
    B --> C[新gNB通过Xn转发至锚点gNB]
    C --> D{锚点gNB验证}

    D --> E[使用保存的KRRCint密钥<br/>+ I-RNTI + 源PCI + 目标PCI<br/>重新计算MAC]
    E --> F{计算值 == 接收值?}

    F -->|匹配| G[验证通过<br/>返回UE上下文]
    F -->|不匹配| H[验证失败<br/>返回失败响应]

    H --> I[新gNB发送RRCReject<br/>UE回落RRC_IDLE]

    G --> J{锚点决策}
    J -->|不迁移| K[RRCRelease+新suspendConfig]
    J -->|迁移| L[RRCResume<br/>完整恢复连接]

7.2 安全密钥层级

RRC_INACTIVE状态下，UE和gNB保持的安全上下文包括：

KAMF (根密钥，NAS层)
  └── KgNB (gNB密钥，在RRC_CONNECTED时推演)
        ├── KRRCenc (RRC加密密钥)
        ├── KRRCint (RRC完整性保护密钥)
        │     └── 用于计算 shortMAC-I
        ├── KUPenc (用户面加密密钥)
        └── KUPint (用户面完整性保护密钥)

当UE成功Resume后，密钥通过horizontal key derivation（NH chaining）推演出新的KgNB，避免密钥重用。关键参数是nextHopChainingCount（NCC），在上下文检索响应中携带。

八、实战抓包识别指南

8.1 Wireshark过滤表达式

# 过滤RRC Resume Request（CCCH UL）
nr-rrc.UL-DCCH-Message.message.c1 == rrcResumeRequest

# 过滤RRC Release with SuspendConfig
nr-rrc.DL-DCCH-Message.message.c1.rrcRelease.suspendConfig

# 过滤I-RNTI值
nr-rrc.I-RNTI-Value

# 过滤XnAP Retrieve UE Context
xnap.RetriveUEContextRequest  (注意协议拼写)
xnap.RetriveUEContextResponse

# 过滤RAN Paging（Xn接口）
xnap.RANPaging

8.2 关键抓包观察点

九、常见故障场景与排错思路

9.1 故障场景一：RNA Update被拒

现象：UE发起RRCResumeRequest（cause=rnaUpdate）后收到RRCReject。

排错步骤： 1. 检查RRCReject中的waitTime字段——若存在，说明网络临时拒绝，UE应等待后重试 2. 检查锚点gNB日志——UE上下文是否已被清理（超时或OAM策略） 3. 若上下文已清理，UE应正确回落到RRC_IDLE并发起NAS Registration 4. 检查AMF是否已发起Implicit Deregistration

9.2 故障场景二：RAN Paging无响应

现象：锚点gNB发出RAN Paging后，UE未发起RRC Resume。

排错步骤： 1. 确认RNA配置是否正确——目标小区是否在RNA列表中 2. 检查UE的Paging DRX配置——ran-PagingCycle是否与gNB广播的PO匹配 3. 确认XnAP RAN PAGING消息是否正确转发到RNA内所有gNB 4. 检查UE日志中是否有收到Paging消息的记录——若无，可能是空口覆盖问题

9.3 故障场景三：上下文检索失败

现象：新gNB发起XnAP RETRIEVE UE CONTEXT REQUEST后收到失败响应或超时。

排错步骤： 1. 确认I-RNTI中解析出的gNB ID是否正确——gNB ID长度配置是否一致 2. 检查Xn接口连通性——两个gNB之间Xn是否正常建立 3. 确认锚点gNB是否已重启——重启后所有RRC_INACTIVE上下文丢失 4. 检查shortMAC-I验证日志——密钥不匹配通常意味着上下文已过期

十、Rel-18/19增强特性

3GPP Rel-18对RRC_INACTIVE引入了多项增强：

1. RRC_INACTIVE态小数据传输（SDT, Small Data Transmission）：允许UE在RRC_INACTIVE态通过MsgA（2-step RACH）或Msg3（4-step RACH）直接发送上行小包，无需先Resume到CONNECTED。这在TS 38.331 Section 5.3.13a中定义。

2. Paging Cause Indication：Paging消息中新增pagingCause字段，UE可根据原因（语音优先）优化响应策略。

3. Enhanced RNA Update：支持更灵活的RNA配置，包括条件触发的RNA Update。

4. RRC_INACTIVE态MBS接收：Rel-19允许UE在RRC_INACTIVE态接收多播/组播业务。

常见问题

Q1: RRC_INACTIVE和RRC_IDLE的本质区别是什么？

A: 核心区别在于NAS层面的连接状态。RRC_INACTIVE态UE仍处于CM-CONNECTED，核心网的N2/N3会话保持建立，AMF和UPF不知道UE处于RRC_INACTIVE。而RRC_IDLE态UE处于CM-IDLE，核心网已释放所有NGAP和GTP-U隧道。因此，从RRC_INACTIVE恢复到发送数据只需20ms级，而从RRC_IDLE建立连接需要100ms+级的完整流程。

Q2: RNA和TA的区别是什么？为什么RNA要小于TA？

A: TA（Tracking Area）是核心网级别的位置管理单位，由AMF通过Registration Accept配置。RNA是RAN级别的位置管理单位，由gNB通过SuspendConfig配置。RNA必须包含在TA之内，因为RNA Update不通知核心网——如果RNA跨越多个TA，UE可能在AMF不知情的情况下移动到另一个TA，导致CN Paging无法到达UE。

Q3: shortMAC-I只有16位，安全性是否足够？

A: shortMAC-I的设计并非用于提供完整的安全保护，而是作为身份认证标签防止简单的UE伪造。16位意味着随机猜测成功的概率为1/65536。真正的安全保护在RRC Resume完成后通过完整的完整性保护和加密实现。攻击者即使猜中shortMAC-I，也无法获取安全上下文来建立受保护的RRC连接。

Q4: 锚点gNB故障后，RRC_INACTIVE UE如何处理？

A: 锚点gNB故障意味着所有RRC_INACTIVE UE上下文丢失。当这些UE发起RNA Update时，新gNB无法从故障锚点检索到上下文，将返回RRCReject。UE收到Reject后应回落到RRC_IDLE，发起NAS Registration流程重新建立核心网连接。如果UE正在被RAN Paging，Paging也会因锚点故障而无法完成。AMF在检测到gNB故障后（通过NGAP链路中断），会对所有受影响的UE执行Implicit Deregistration。

Q5: RRC_INACTIVE态是否支持切换？

A: 不支持。RRC_INACTIVE态的UE执行的是小区重选（Cell Reselection），而非切换（Handover）。小区重选是UE自主决策过程，基于广播的邻区测量配置和重选准则。当UE重选到RNA外的小区时，通过RNA Update通知网络。这也是RRC_INACTIVE态设计的核心优势之一——UE可以在RNA内自由移动而不需要网络侧的切换信令。

参考来源

1. 3GPP TS 38.331 V19.x.x — NR Radio Resource Control (RRC) protocol specification — Section 5.3.13 (RRC Resume), Section 6.2.2 (SuspendConfig IE)
2. 3GPP TS 38.300 V19.x.x — NR and NG-RAN Overall Description — Section 9.2.2 (RRC State Machine), Section 9.3 (RNA and RAN Paging)
3. 3GPP TS 38.401 V19.x.x — NG-RAN Architecture Description — Section 8.2 (I-RNTI Structure, UE Context Management)
4. ShareTechnote — 5G NR RRC INACTIVE — RRC状态机与RNA Update交互流程图解
5. Amarisoft Tech Academy — NR RRC Inactive — RRC Inactive测试验证流程与参数配置示例

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