深度解析 3GPP TS 38.423：8.2.11-8.2.13 高级移动性与上下文管理

本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“8.2.11 RAN Multicast Group Paging”、“8.2.12 Retrieve UE Context Confirm”以及“8.2.13 Partial UE Context Transfer”这三个核心章节。本文旨在将这些在特定场景下发挥关键作用的高级移动性与上下文管理流程进行整合解读，为读者揭示5G网络在处理组通信、复杂双连接移动性和小数据传输等场景时的精巧设计。

1. 引言：从康庄大道到阡陌小径

在之前的探索中，我们跟随初级工程师小林和他的导师陈工，已经走过了XnAP协议中最为繁忙的“康庄大道”——基础的切换和上下文恢复流程。这些流程保障了“李雷”这样典型的eMBB用户在高速移动中的无缝体验。

这天，小林在完成了一次成功的Retrieve UE Context流程仿真后，长舒了一口气：“陈工，感觉5G的移动性管理核心就是围绕着上下文的准备、传递和释放。掌握了这些，是不是就掌握了XnAP的精髓？”

陈工笑着呷了一口茶：“你掌握了主干道，但一个高效的交通网络，同样离不开那些设计精巧的‘阡陌小径’和‘专用匝道’。它们虽然不常被普通‘车辆’使用，但在特定场景下，其作用无可替代。比如，当城市需要进行紧急广播时，如何同时通知成千上万的‘车辆’，而不是挨个打电话？当一辆‘房车’（双连接UE）搬家后，如何确保它的两个‘停车位’（MN和SN的资源）被妥善交接？当一个只需要送一封信的‘邮差’（IoT设备）进入城市时，我们是否需要为他分配一个完整的‘豪宅’（UE上下文）？”

“今天，”陈工继续说道，“我们就来探索XnAP协议中的这几条‘特殊路径’。它们分别是为组通信、复杂的双连接后处理以及物联网时代的小数据传输量身定制的解决方案。它们是：”

• 8.2.11 RAN Multicast Group Paging (RAN多播组寻呼)：为群体唤醒而生的高效广播。
• 8.2.12 Retrieve UE Context Confirm (UE上下文检索确认)：复杂移动性场景下的“收尾确认函”。
• 8.2.13 Partial UE Context Transfer (部分UE上下文传输)：为物联网“轻装上阵”设计的“经济适用房”。

掌握了它们，你才能真正理解5G网络是如何在满足多样化业务需求的同时，实现信令开销、网络资源和终端功耗的极致平衡。

2. 8.2.11 RAN Multicast Group Paging - 组通信的“集结号”

首先，我们来看一个截然不同的场景。城市发生紧急情况，一支由数十名队员组成的应急救援队“尖峰-01”需要立刻接收到指挥中心下发的最新指令。他们的通信设备都加入了同一个MBS（多播/广播服务）会话，并且为了省电，大部分设备都处于RRC_INACTIVE状态。

2.1 8.2.11.1 General (概述) - 从“单点呼叫”到“群体广播”

The purpose of the RAN Multicast Group Paging procedure is to enable the NG-RAN node1 to request paging of UEs that have joined an MBS Session in the NG-RAN node2. The procedure uses non UE-associated signalling.

陈工为小林剖析道：“这个流程与我们之前学的RAN Paging（8.2.5）有本质区别。RAN Paging是针对单个UE，通过I-RNTI进行‘精确点名’。而RAN Multicast Group Paging则是针对一个群体，通过MBS会话ID进行‘喊号集合’。这就像在机场，前者是广播‘旅客李雷请注意’，后者则是广播‘前往北京的CA1088次航班旅客请开始登机’。”

• 角色定义：node1是知道需要发起组寻呼的节点（通常是与核心网UPF相连，接收到多播数据的gNB-UP），node2则是需要协助在空口广播寻呼的邻居节点。
• 非UE关联信令：与RAN Paging一样，这也是一个非UE关联的Class 2流程，它不依赖于任何已建立的UE信令连接，保证了广播的广泛性和低开销。

2.2 8.2.11.2 Successful Operation (成功操作) - RAN MULTICAST GROUP PAGING消息解析

流程非常简单，node1向node2发送一个RAN MULTICAST GROUP PAGING消息即可。但这封“集结号”的内容却大有讲究。

RAN MULTICAST GROUP PAGING消息的核心IE：

• MBS Session ID: 这是识别群体的唯一标识。所有加入了“尖峰-01”救援队应急通信会话的设备，都知道这个ID。当它们在寻呼信道上监听到这个ID时，就会知道这是在呼叫自己。

• UE Identity Index List: 这个列表进一步细化了寻呼目标。在一个庞大的多播会话中，可能并不需要唤醒所有成员。通过这个索引列表，可以实现对组内成员的子组化寻呼。这就像在登机广播中加入“座位号1到30排的旅客请优先登机”，实现了更精细的管理。

• Paging DRX IE:

  If the RAN MULTICAST GROUP PAGING message includes the Paging DRX IE, the NG-RAN node2 shall, if supported, use it according to TS 38.304.

  陈工解读：“群体成员也需要省电，它们会按照一个共同的DRX周期进行休眠和监听。这个IE就是用来同步这个‘集体作息时间表’的。node1告诉node2：‘这群人会在每个周期的第X个寻呼时机醒来’。node2收到后，就只在那个精确的时刻广播寻呼，避免了在其他时间做无用功，极大地节省了宝贵的空口资源。”

场景代入： 指挥中心需要向“尖峰-01”下发指令，下行数据到达了作为gNB-UP的基站A。

1. 基站A识别出这是属于某个MBS会话的数据，需要寻呼该会话的所有RRC_INACTIVE态成员。
2. 基站A向其Xn邻居（如B、C）广播RAN MULTICAST GROUP PAGING消息。消息中包含了MBS会话ID和该组的DRX信息。
3. 基站A、B、C在约定的寻呼时机，在各自的空口上广播这个MBS会话ID。
4. “尖峰-01”的所有队员设备，无论当前在哪一个基站下，只要在RNA内，都会在同一时间被唤醒，并发起连接恢复流程，准备接收指令。

这个流程用一个简单的XnAP消息，就实现了跨多个基站的大规模、同步、高效的群体唤醒，是5G支持关键任务通信等场景的重要基石。

3. 8.2.12 Retrieve UE Context Confirm - 复杂移动后的“回执”

现在，让我们把视线转回到双连接（DC）场景。RRC_INACTIVE态下的移动性已经足够复杂，如果这个UE本身还处于双连接配置下，情况就变得更加棘手。

场景设定：李雷的手机在进入RRC_INACTIVE前，处于EN-DC状态，主节点是eNB A (旧 M-NG-RAN 节点)，次节点是gNB S (S-NG-RAN 节点)。现在，李雷移动到了新的gNB B的覆盖下，并发起RRC Resume。

3.1 8.2.12.1 General (概述) - 为何需要一个“确认”？

The Retrieve UE Context Confirm procedure is used by the new NG-RAN node to inform the old NG-RAN node whether the S-NG-RAN node associated with the old NG-RAN node for the UE that was indicated during UE context retrieval is kept or not by the new NG-RAN node during RRC resumption. In case of RACH based SDT without UE context relocation, the Retrieve UE Context Confirm procedure is also used to request the termination of SDT session from the new NG-RAN node to the old NG-RAN node.

陈工解释道：“这个流程的发起方是新基站（new NG-RAN node），接收方是旧的锚点主基站（old NG-RAN node）。它的核心作用是作为Retrieve UE Context流程的一个补充和优化，处理一些特殊情况的‘善后’工作。”

• 用途一：通报SN的‘去留’ 新基站B通过Retrieve UE Context从旧主站A那里获取了李雷的完整档案，档案里记录着“此人还有一个次节点S”。此时，B作为新的主站，需要做出一个决策：是否继续使用这个旧的次节点S？

  • 如果B和S离得很近，连接质量好，B可能会决定**保留（keep）**这个SN，这样可以快速恢复双连接，节省信令。
  • 如果B和S相距甚远，B可能会决定**释放（release）**S，后续再为UE寻找一个更近的新SN。

  “问题是，”陈工强调，“旧主站A并不知道B的这个决定。如果没有Confirm流程，A可能会出于‘严谨’，在释放自己的上下文后，再发起一个S-NODE RELEASE流程去释放S，但这可能是不必要的，因为B已经接管了S。Retrieve UE Context Confirm就是B给A的一个‘回执’，告诉A：‘放心，那个次节点S我已经处理了，你不用管了’。”

• 用途二：请求终止SDT会话 在小数据传输（SDT）且上下文不迁移的场景下，UE在新基站B处完成数据发送，但上下文仍在旧基站A。此时，B需要通知A：“这个UE的本次SDT任务已完成，你可以结束会话了。”

3.2 8.2.12.2 Successful Operation (成功操作) - RETRIEVE UE CONTEXT CONFIRM消息

If the UE Context Kept Indicator IE is included and set to “True”, the old NG-RAN node shall consider that the S-NG-RAN node was kept by the new NG-RAN node and use this information as specified in TS 37.340. If the old NG-RAN node receives the SDT Termination Request IE in the RETRIEVE UE CONTEXT CONFIRM message, the old NG-RAN node shall, if supported, consider that the termination of the ongoing SDT session is requested…

这个Class 2的通知消息，通过两个关键IE来实现其功能：

• UE Context Kept Indicator IE: 当新主站B决定保留旧的次站S时，它就会在这个IE中设置为True。旧主站A收到后，就明白自己无需再发起对S的释放流程，从而避免了冗余的Xn信令交互。这是一个纯粹的信令优化机制。

• SDT Termination Request IE: 当新基站B需要通知旧的锚点基站A结束SDT会话时，就会包含此IE。A收到后，就会执行SDT会话的终止逻辑。

这个流程虽然简单，但它像是协议栈中的“润滑剂”，在复杂的DC移动性和SDT场景下，通过一个简单的“回执”，解决了节点间状态同步的潜在问题，减少了不必要的信令开销。

4. 8.2.13 Partial UE Context Transfer - 物联网的“轻骑兵”

现在，我们引入新的主角——安装在城市供水管道上的智能水表“水滴一号”。它每天只需要上报一次读数，数据量只有几十个字节。为了最大化电池寿命，它绝大部分时间都处于深度睡眠。

4.1 8.2.13.1 General (概述) - 避免“杀鸡用牛刀”

The purpose of the Partial UE Context Transfer procedure is to partially transfer the UE context from the old NG-RAN node to the new NG-RAN node.

陈工解释道：“对于‘水滴一号’这样的设备，如果每次上报数据时，它恰好移动到了一个新的基站B，而它的上下文还在旧基站A。按照标准流程，B需要通过Retrieve UE Context向A请求完整的上下文。这份上下文可能包含了几十KB的数据，安全、RRC、QoS、能力……应有尽有。为了传输几十字节的数据，先进行几十KB的信令交互，这简直是‘杀鸡用牛刀’，对于大规模物联网来说是不可接受的。”

Partial UE Context Transfer流程应运而生。它允许旧基站A只将处理本次小数据传输所必需的最少信息传递给新基站B，而无需迁移完整的上下文。

4.2 8.2.13.2 & 8.2.13.3 (成功与失败操作) - 一场轻量级的“交接谈判”

这是一个Class 1流程，因为它本质上是一次“协商”：旧基站A向新基站B提议：“我这儿有个轻量级任务，你能不能不进行完整的上下文迁移，只处理一下？” B需要明确回复同意或拒绝。

流程步骤：

1. UE（水滴一号）在新基站B处发起RRC Resume，意图进行SDT。
2. B向旧基站A发起Retrieve UE Context请求。
3. A判断这是一次SDT，决定不迁移完整上下文，于是回复Retrieve UE Context FAILURE，但同时向B发起PARTIAL UE CONTEXT TRANSFER请求。
4. 这个请求消息中包含了关键的Partial UE Context Information for SDT IE，里面只有本次SDT所需的最小上下文子集（如安全信息、DRB配置等）。
5. 如果新基站B支持并同意这种“轻量级”模式，它就会为UE建立临时资源，并回复PARTIAL UE CONTEXT TRANSFER ACKNOWLEDGE。
6. B可能还会在ACK中提供数据转发地址（SDT Data Forwarding DRB List IE），让A把可能已收到的下行小数据包转发过来。
7. 如果B不支持或资源不足，则回复PARTIAL UE CONTEXT TRANSFER FAILURE。A只能放弃，并指导UE走传统的完整连接建立流程。

这个流程极大地降低了物联网设备在移动场景下进行小数据传输的信令开销和时延，是5G支持mMTC（海量物联网通信）场景的关键技术之一。

5. 总结：XnAP的精细化与场景化智慧

小林今天的学习收获颇丰。他认识到，XnAP协议的设计者们不仅构建了强大的移动性管理主框架，更针对5G多样化的业务场景，设计了这些精巧、高效的“专用工具”：

• RAN Multicast Group Paging 通过群体标识和共享DRX，解决了大规模、低时延的群体唤醒难题，服务于MBS等业务。
• Retrieve UE Context Confirm 通过一个简单的事后确认，优雅地解决了复杂DC移动性场景下的信令冗余问题，体现了对协议健壮性的深度考量。
• Partial UE Context Transfer 通过上下文子集的按需迁移，完美地平衡了物联网设备的低功耗需求和移动场景下的连接连续性，是效率至上设计哲学的典范。

这些流程虽然不是每次移动都会触发，但它们的存在，使得5G网络能够以更低的成本、更高的效率去适应从高清视频到物联网传感器的各种截然不同的业务需求，真正展现了5G作为新一代通信基础设施的灵活性与强大能力。

FAQ

Q1：RAN Multicast Group Paging和核心网发起的寻呼有什么关系？ A1：核心网（AMF/SMF/UPF）是组寻呼的最终发起者。当有多播数据到达时，核心网会向该业务对应的整个寻呼区域（Paging Area）内的所有NG-RAN节点发送NGAP Paging消息。持有该MBS会话上下文的基站（通常是gNB-UP）收到此消息后，会进一步通过XnAP RAN Multicast Group Paging流程，请求其邻居基站协同在空口进行寻呼。因此，XnAP的组寻呼是核心网寻呼在无线接入网内部的延伸和具体实现。

Q2：如果旧主站A没有收到新主站B发来的Retrieve UE Context Confirm消息（消息丢失或B不支持），会发生什么？ A2：这不会导致灾难性后果，但会产生一些冗余信令。如果B决定保留次站S但没有通知A，A在释放完自己的上下文后，可能会认为S成了“孤儿”，于是向S发起S-NODE RELEASE REQUEST。S收到后，可能会拒绝（因为它已经被B接管），或者根据实现进行处理。虽然会产生不必要的信令交互，但最终系统状态会收敛。这个Confirm流程的主要价值在于优化，而非保证基本功能的正确性。

Q3：Partial UE Context Transfer和Retrieve UE Context的核心区别是什么？ A3：核心区别在于上下文迁移的“所有权”和“完整性”。

• Retrieve UE Context：UE上下文的“所有权”从旧基站完全转移到新基站。旧基站最终会删除该上下文。迁移的是完整的UE上下文。
• Partial UE Context Transfer：UE上下文的“所有权”仍然保留在旧的锚点基站。新基站只是临时获得了一个处理当前任务所需的部分上下文“副本”。任务结束后，新基站会释放这个临时副本，UE的档案仍在旧基站。

Q4：为什么Partial UE Context Transfer要设计成Class 1，而Retrieve UE Context Confirm是Class 2？ A4：这取决于流程的性质。Partial UE Context Transfer是一次协商。旧基站（锚点）向新基站请求一项服务：“请你帮我临时处理这个UE的小数据，但不要拿走它的完整档案”。新基站需要进行资源检查和能力判断，然后明确回复是否接受这个请求。因此，必须是“有问有答”的Class 1流程。而Retrieve UE Context Confirm是一次事后通知，新基站只是告知旧基站一个已经发生的事实（“我保留了SN”或“SDT结束了”），旧基站根据这个通知去优化自己的行为即可，无需回复，因此用高效的Class 2流程最合适。

Q5：SDT（Small Data Transmission）特性是只为RRC_INACTIVE态设计的吗？ A5：SDT主要为了优化RRC_INACTIVE态下的数据传输，但它也可以用于RRC_IDLE态。在3GPP Rel-16中引入的SDT，允许UE在发送RRCResumeRequest或RRCSetupRequest时携带上行数据，从而在一个消息交换中完成连接建立和数据发送。Partial UE Context Transfer是处理RRC_INACTIVE态UE移动到新小区后进行SDT且不进行锚点迁移的一种特定场景的解决方案。