深度解析 3GPP TS 38.423：9.1.1 基础移动性消息 (Part 3 - RRC Inactive态唤醒)
本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“9.1.1 Messages for Basic Mobility Procedures”的核心章节，特别聚焦于与
RRC_INACTIVE态UE唤醒相关的RAN PAGING(9.1.1.7) 以及RETRIEVE UE CONTEXT系列消息 (9.1.1.8 至 9.1.1.10)。本文将深入剖析5G网络如何通过基站间的协同，高效、安全地唤醒处于“浅度睡眠”状态的UE。
1. 引言：唤醒沉睡的“游牧者”
在之前的篇章中，我们跟随工程师小林和他的导师陈工，已经全面掌握了UE在RRC_CONNECTED态下的移动性管理，即切换流程的完整信令交互。但5G的智慧远不止于此。当用户“李雷”结束通话，手机进入RRC_INACTIVE节能状态后，他便化身为一个在网络中“沉睡的游牧者”。他的“户口本”（UE Context）留在了最后服务的基站（锚点基站），而他本人则可能已经悄无声息地“迁徙”到了几十公里外的新基站覆盖下。
此时，一个新的挑战摆在网络面前：当一条微信消息抵达，核心网只知道李雷身处一个广阔的“RAN通知区域”（RNA），如何才能在这片茫茫人海中，精确地找到并唤醒他？
“陈工，”小林问道，“核心网会向整个RNA区域广播寻呼，这我知道。但RNA里那么多基站，只有锚点基站A有李雷的档案，其他基站B、C、D对他一无所知。这个协作过程是怎么实现的？UE被唤醒后，新基站B又是如何从远方的A那里拿到档案，快速恢复服务的呢？”
“你的问题精准地指出了RRC_INACTIVE态移动性管理的两大核心环节：分布式寻呼和跨站上下文检索。”陈工回答道，“这正是XnAP协议中另一套精妙的基础移动性流程。今天，我们就来学习这套‘唤醒’组合拳，看看基站之间是如何通过RAN PAGING发出‘寻人启事’，并通过RETRIEVE UE CONTEXT系列消息，完成一场高效、安全的‘档案跨省迁移’的。”
2. 9.1.1.7 RAN PAGING - 跨基站的“寻人启事”
当核心网需要联系一个RRC_INACTIVE态的UE时，它会向该UE所在的RNA内的所有基站发送NGAP PAGING消息。持有UE上下文的锚点基站收到此消息后，便会触发XnAP的RAN PAGING流程。
2.1 消息结构概览
这是一个Class 2流程，由锚点基站单向通知RNA内的其他基站，协助寻呼。
RAN PAGING 消息内容 方向: NG-RAN node₁ → NG-RAN node₂
| IE/Group Name | Presence | IE type and reference | Semantics description |
|---|---|---|---|
| Message Type | M | 9.2.3.1 | |
| CHOICE UE Identity Index Value | M | 唯一的UE身份索引值 | |
| >Length-10 | M | BIT STRING (SIZE(10)) | 10位索引 |
| UE RAN Paging Identity | M | 9.2.3.43 | UE的RAN寻呼身份 (I-RNTI) |
| Paging DRX | M | 9.2.3.66 | UE的寻呼DRX周期 |
| RAN Paging Area | M | 9.2.3.38 | 寻呼区域 |
| … (其他可选IE) | O | … | 如寻呼优先级、eDRX信息等 |
2.2 核心IE深度剖析
1. UE RAN Paging Identity (UE RAN寻呼身份)
- Presence: M
- 陈工解读：“这是‘寻人启事’上的姓名。对于
RRC_INACTIVE态的UE，这个身份就是I-RNTI (Inactive RNTI)。锚点基站A通过这个IE，请求邻居基站B和C在它们的空口上广播这个I-RNTI。所有处于INACTIVE态的UE都在周期性地监听寻呼信道，当李雷的手机听到自己的I-RNTI时，它就知道自己被‘点名’了，需要苏醒并响应。”
2. Paging DRX (寻呼DRX)
- Presence: M
- 陈工解读：“这是‘寻人启事’上标注的**‘最佳联系时间’**。
INACTIVE态的UE为了省电，并不会一直监听网络。它会按照一个DRX（非连续接收）周期，只在特定的寻呼时机（Paging Occasion, PO）醒来几毫秒。这个IE就是告诉所有协助寻呼的基站：‘这个UE只会在这些特定的时间点听广播’。这确保了网络不会在错误的时间做无用功，是实现UE长待机的关键。”
3. RAN Paging Area (RAN寻呼区域)
- Presence: M
- 陈工解读：“这份‘寻人启事’的**‘发布范围’**。它定义了本次寻呼需要覆盖的小区列表或区域ID列表。锚点基站A会根据UE进入
INACTIVE时注册的RNA（RAN-based Notification Area），来构建这个寻呼范围，确保寻呼能够覆盖UE所有可能在的位置。”
3. 9.1.1.8-10 Retrieve UE Context - “档案”的跨站迁移
当李雷的手机在新基站B的覆盖下，听到了自己的I-RNTI被广播，它会立刻被唤醒，并向基站B发起RRC Resume流程。基站B收到请求后，解析出其中的I-RNTI，从而知道了UE的“档案保管员”是旧基站A。于是，一场跨越Xn接口的“档案迁移”大戏正式拉开帷幕。这是一个完整的Class 1流程。
3.1 RETRIEVE UE CONTEXT REQUEST (9.1.1.8) - 调档申请
RETRIEVE UE CONTEXT REQUEST 消息内容
方向: new NG-RAN node → old NG-RAN node
| IE/Group Name | Presence | IE type and reference | Semantics description |
|---|---|---|---|
| Message Type | M | 9.2.3.1 | |
| New NG-RAN node UE XnAP ID reference | M | NG-RAN node UE XnAP ID 9.2.3.16 | 新节点分配的ID |
| UE Context ID | M | 9.2.3.40 | 关键！ 包含I-RNTI等信息 |
| Integrity protection | M | BIT STRING (SIZE(16)) | 关键！ 完整性保护校验码 |
| New Cell Identifier | M | NG-RAN Cell Identity 9.2.2.9 | UE当前所在的小区ID |
| … | O | … | … |
陈工的解读：“这封‘调档申请’的核心是安全与精确。”
UE Context ID(I-RNTI)：这是档案的“索引号”，告诉旧基站A要去哪个档案柜里找文件。Integrity protection(完整性保护)：这是“接头暗号”。UE在发送RRCResumeRequest时，会用它与旧基站A之间共享的密钥，计算出一个MAC值（resumeMAC-I）。新基站B会将这个MAC值原封不动地放在这个IE里发给A。旧基站A收到后，会用自己保存的密钥和B提供的New Cell Identifier，重新计算一遍MAC值。只有两个MAC值完全匹配，A才能确认这次请求是由合法的UE通过合法的B发起的，从而同意交付档案。这个机制有效防止了UE身份欺骗和重放攻击。
3.2 RETRIEVE UE CONTEXT RESPONSE (9.1.1.9) - 档案的“打包交付”
完整性校验通过后，旧基站A就会将UE的完整上下文打包，通过此消息回复给新基站B。
RETRIEVE UE CONTEXT RESPONSE 消息内容
| IE/Group Name | Presence | IE type and reference |
|---|---|---|
| … | … | … |
| UE Context Information – Retrieve UE Context | M | 9.2.1.13 |
| >UE Security Capabilities | M | 9.2.3.49 |
| >AS Security Information | M | 9.2.3.50 |
| >PDU Session Resources To Be Setup List | M | 9.2.1.1 |
| >RRC Context | M | OCTET STRING |
| >UE Context Reference at the S-NG-RAN node | O | |
| … |
陈工的解读：“这是整个流程中信息量最大、也最有价值的消息。它几乎就是HANDOVER REQUEST消息中UE Context Information部分的翻版。新基站B拿到这份‘大礼包’后，就拥有了重建UE连接所需的一切：”
- 安全上下文 (
AS Security Information): B可以用它来恢复与UE的加密和完整性保护。 - PDU会话资源 (
PDU Session Resources...): B根据这个列表，为UE的所有业务（上网、游戏、通话等）重建无线承载和用户面隧道。 - RRC上下文 (
RRC Context): B可以将这个容器里的配置直接应用到UE上，快速恢复RRC连接，无需重新协商所有参数，极大地缩短了连接恢复时延。 - 双连接信息 (
UE Context Reference at...): 如果这个UE之前处于双连接状态，这里会包含其SN的信息，使得B作为新的MN，可以选择保留或释放这个SN。
3.3 RETRIEVE UE CONTEXT FAILURE (9.1.1.10) - “查无此档”
如果旧基站A无法提供上下文，它会回复此消息。
RETRIEVE UE CONTEXT FAILURE 消息内容
| IE/Group Name | Presence | Semantics description |
|---|---|---|
| … | … | … |
| Cause | M | 失败原因 |
| Old NG-RAN node To New NG-RAN node Resume Container | O | 用于SDT场景的透明容器 |
陈工的解读：“‘调档’失败主要有三个原因，都通过Cause IE来体现：”
unknown-local-ng-ran-node-ue-xnap-id: I-RNTI无效。可能是UE休眠太久，上下文已被A删除。- Integrity check failure: 完整性校验失败，即“暗号对不上”。
non-relocation-of-context: A决定不迁移上下文。这通常发生在SDT（小数据传输）场景。A认为迁移完整上下文“小题大做”，于是拒绝迁移，并可能在Resume Container中附带一个RRC消息，让B直接转发给UE，以完成这次轻量级的数据交互。
新基站B收到FAILURE后，会中断RRC Resume流程，并命令UE进入RRC_IDLE态，然后通过核心网发起完整的Service Request流程来重建连接。
4. 总结：低功耗与快速响应的完美结合
RAN Paging与Retrieve UE Context这两个流程，如同一对配合默契的组合，共同构成了5G RRC_INACTIVE态移动性管理的核心。它们的设计，完美地体现了5G网络在追求极致用户体验、降低网络信令负荷和延长终端电池寿命这三个看似矛盾的目标之间所做的精妙平衡。
- 分布式寻呼 (
RAN Paging)：通过基站间的协同，实现了在广域RNA内对单个UE的精准、高效唤醒，并支持eDRX等深度节能技术。 - 跨站上下文检索 (
Retrieve UE Context)：通过Xn接口的直接交互，实现了UE上下文的快速、安全迁移，极大地缩短了连接恢复时延，并减轻了核心网的信令负担。
这两个流程的成功协作，使得RRC_INACTIVE态真正成为了一个兼具IDLE态低功耗和CONNECTED态快速连接优势的“黄金状态”，是5G支持海量物联网（mMTC）和提升智能手机用户体验的关键技术。
FAQ
Q1：RAN Paging中的I-RNTI和核心网寻呼中的5G-S-TMSI有什么关系？
A1：5G-S-TMSI是UE在核心网（AMF）的唯一临时身份标识，用于在NG接口上发起寻呼。I-RNTI是UE在无线接入网（NG-RAN）的RRC_INACTIVE态下的临时身份标识，用于在空口和Xn接口上进行寻呼。当核心网需要寻呼UE时，它使用5G-S-TMSI向锚点基站发起NGAP PAGING。锚点基站收到后，根据5G-S-TMSI找到对应的UE上下文，从中取出I-RNTI，然后再通过XnAP RAN PAGING和空口寻呼消息广播这个I-RNTI。
Q2：如果UE收到了寻呼，但它没有响应，会发生什么？ A2：网络侧的寻呼定时器（在AMF）会超时。AMF会认为UE不可达，并根据策略进行处理。例如，如果寻呼是由下行数据触发的，AMF可能会通知SMF，SMF再通知UPF丢弃数据。如果寻呼是由于网络侧需要执行某些操作（如配置更新），则该操作会失败。
Q3：Retrieve UE Context流程和切换流程（Handover）都要传递UE上下文，它们传递的内容有什么不同吗？
A3：传递的核心内容（安全、PDU会话、RRC配置等）非常相似，因为目标都是在新节点上为UE重建一个完整的服务环境。主要区别在于封装它们的“信封”和一些辅助IE不同。HANDOVER REQUEST是为CONNECTED态切换设计的，会包含更多与切换决策相关的IE（如Cause、Target Cell Global ID等）。而RETRIEVE UE CONTEXT RESPONSE是为INACTIVE态恢复设计的，其核心载荷就是这份纯粹的UE Context Information。
Q4：为什么UE Context Release消息在Retrieve UE Context流程成功后也要发送？
A4：是的，Retrieve UE Context流程成功后，新基站B在UE成功恢复RRC连接后，必须向旧基站A发送UE CONTEXT RELEASE消息（8.2.7节）。这就像你成功办理了户口迁移后，新派出所会通知旧派出所“此人户口已迁出，请销档”。这确保了UE的上下文在网络中只存在一份（在新的锚点基站B处），避免了状态不一致和资源浪费。
Q5：Partial UE Context Transfer（8.2.13节）和Retrieve UE Context流程在FAILURE消息中的容器（Container）有什么关系？
A5：它们是紧密相关的，服务于SDT（小数据传输）场景。当新基站B为进行SDT的UE发起Retrieve UE Context时，旧基站A如果决定不迁移完整上下文（non-relocation-of-context），它有两种选择：1）在FAILURE消息的容器里直接附带一个需要转发给UE的RRC消息；2）发起一个Partial UE Context Transfer流程，向B提议一次轻量级的上下文传输。选择哪种方式取决于具体的场景和厂商实现，但目的都是为了在不进行完整上下文迁移的情况下，高效地完成这次小数据交互。