51学通信

深度解析 3GPP TS 38.413：9.2.3 UE Mobility Management Messages (Part 2 - 切换执行与善后)

17分钟阅读

本文技术原理深度参考了3GPP TS 38.413 V18.5.0 (2025-03) Release 18规范中，关于“9.2.3 UE Mobility Management Messages”的核心章节，旨在为读者提供一个关于5G网络中保障用户无缝移动体验的核心——切换流程的信令交互全景视图。本文为系列解读的第二部分，重点剖析切换的“执行与善后阶段”。

深度解析 3GPP TS 38.413：9.2.3 UE Mobility Management Messages (Part 2 - 切换执行与善后)

大家好，欢迎回到我们的3GPP规范深度解析系列！在Part 1中，我们跟随乘坐高铁的直播博主Chloe，详细剖析了5G切换的“准备阶段”——从源gNB发起请求到AMF下达最终的切换命令，整个网络都在为Chloe的下一次“跳跃”铺设红毯。

今天，我们将继续这场信令芭蕾的下半场，聚焦于切换的“执行与善后”阶段。这是真正决定切换成败、确保业务连续性的关键时刻。一旦源gNB向UE下达了切换指令，一系列紧密衔接、毫秒必争的信令交互将立刻展开，以完成用户面路径的切换和旧有资源的清理。

我们将继续Chloe在高铁上的旅程。她刚刚收到了来自源gNB-A的RRCReconfiguration消息，指令她切换到目标gNB-B。现在会发生什么？我们将深入剖析以下核心消息，揭示切换“跳跃”瞬间及其后的网络动作：

  • HANDOVER NOTIFY (切换通知)：目标gNB-B如何向核心网宣告“用户已成功抵达！”

  • PATH SWITCH REQUEST (路径切换请求)：目标gNB-B如何请求核心网的用户面（UPF）将下行数据“改道”至自己这里。

  • PATH SWITCH REQUEST ACKNOWLEDGE / FAILURE (路径切换请求确认/失败)：核心网如何响应路径切换请求。

  • UE CONTEXT RELEASE COMMAND (UE上下文释放命令)：AMF如何通知源gNB-A“任务完成，可以清理现场了”。

  • HANDOVER CANCEL (切换取消)：如果在准备阶段出现意外，源gNB-A如何“紧急叫停”切换。

通过这些流程，我们将完整地看到，网络是如何将用户的“数据管道”从旧的gNB平滑地对接到新的gNB，并在此过程中清理冗余资源，完成一次干净利落的“交接仪式”。

1. 成功抵达的宣告：HANDOVER NOTIFY (切换通知)

在Part 1的结尾，源gNB-A向Chloe的手机发送了切换指令。手机随即尝试接入目标gNB-B。当gNB-B成功在空口检测到UE并完成随机接入后，它需要做的第一件事就是向核心网报告这个好消息。

9.2.3.7 HANDOVER NOTIFY

This message is sent by the target NG-RAN node to inform the AMF that the UE has been identified in the target cell and the handover has been completed.

场景引入：

Chloe的手机成功在gNB-B的小区上完成了随机接入。gNB-B通过解码UE发送的前导码（preamble）和后续消息，确认了这就是刚刚准备切换过来的那个UE。它立即向AMF-Central发送HANDOVER NOTIFY消息。

这个消息非常简洁，但意义重大。它是一个触发器，通知AMF：“切换的空口部分已经成功了！现在可以开始切换核心网侧的用户面路径了！”

表格 9.2.3.7-1: HANDOVER NOTIFY 消息内容

| IE/Group Name | Presence | Semantics description |

| :--- | :--- | :--- |

| AMF UE NGAP ID | M | UE在AMF的ID。 |

| RAN UE NGAP ID | M | UE在gNB-B的ID。 |

| User Location Information | M | UE在新小区的精确位置信息（CGI和TAI）。 |

| Notify Source NG-RAN Node | O | 一个指示，告知AMF是否需要通知源gNB。 |

AMF收到HANDOVER NOTIFY后，它就更新了UE的位置信息，并知道UE现在归gNB-B管辖。更重要的是，它将启动下一轮也是最关键的步骤——路径切换。

2. 数据流的“改道”：PATH SWITCH REQUEST (路径切换请求)

切换不仅是信令面的“交接”，更是用户面的“改道”。在切换完成前，用户下行数据仍然被发送到源gNB-A。现在，目标gNB-B需要请求核心网的用户面功能（UPF），将数据流切换到自己这里。

9.2.3.8 PATH SWITCH REQUEST

This message is sent by the NG-RAN node to inform the AMF of the new serving NG-RAN node and to transfer some NG-U DL tunnel termination point(s) to the SMF via the AMF for one or multiple PDU session resources.

场景引入：

在发送HANDOVER NOTIFY之后，gNB-B会立即向AMF-Central发送PATH SWITCH REQUEST消息。

表格 9.2.3.8-1: PATH SWITCH REQUEST 消息内容

| IE/Group Name | Presence | Semantics description |

| :--- | :--- | :--- |

| RAN UE NGAP ID | M | UE在新gNB的ID。 |

| Source AMF UE NGAP ID | M | UE在旧gNB处，由AMF分配的ID。 |

| User Location Information | M | UE的最新位置信息。 |

| PDU Session Resource to be Switched in Downlink List | 1 | 需要切换下行路径的PDU会话列表。 |

| >Path Switch Request Transfer | M | 透明容器，包含发送给SMF的具体路径切换信息。 |

核心IE深度解读：

  • Source AMF UE NGAP ID: 注意，这里gNB-B需要同时提供旧的ID（Source AMF UE NGAP ID）和新的ID（RAN UE NGAP ID）。这使得AMF能够准确地找到并更新UE的上下文。

  • Path Switch Request Transfer: 再次出现了我们的老朋友——透明容器。gNB-B将为Chloe的直播PDU会话分配的新的下行GTP隧道端点信息（IP地址和TEID）封装在这个容器中。AMF收到后，将其透明地转发给SMF。

  • SMF的动作: SMF收到这个Transfer IE后，会向UPF发送一个N4会话修改请求，指令UPF：“对于这个PDU会话，停止向旧的隧道（指向gNB-A）发送数据，开始将数据包封装到这个新的隧道（指向gNB-B）中并发送。”

一旦UPF执行了这个指令，Chloe的4K直播数据流就成功地从gNB-A切换到了gNB-B，用户面路径切换完成。

3. “改道”的确认与失败处理

核心网在完成路径切换后，需要将结果反馈给gNB-B。

  • PATH SWITCH REQUEST ACKNOWLEDGE (路径切换请求确认) (9.2.3.9)

    • 流程: SMF通知AMF路径切换成功后，AMF向gNB-B回复PATH SWITCH REQUEST ACKNOWLEDGE。

    • 核心内容: 这个消息中，AMF可能会下发更新后的UE上下文信息，例如新的**Security Context（用于后续的密钥更新）和更新的Mobility Restriction List等。它还包含一个PDU Session Resource Switched List**，明确告知gNB哪些PDU会话的路径切换已成功。

  • PATH SWITCH REQUEST FAILURE (路径切换请求失败) (9.2.3.10)

    • 流程: 如果SMF或UPF在执行路径切换时遇到问题（例如，资源问题或内部错误），AMF会向gNB-B回复PATH SWITCH REQUEST FAILURE。

    • 后果: 这通常是一个严重的失败。gNB-B会释放为该UE准备的所有资源，并可能导致UE的连接中断。

4. “打扫战场”：UE CONTEXT RELEASE COMMAND (UE上下文释放命令)

在路径切换成功后，AMF确认UE已经完全由gNB-B服务。此时，源gNB-A中为Chloe保留的上下文和资源就成了冗余，需要被清理。

9.2.2.5 UE CONTEXT RELEASE COMMAND

This message is sent by the AMF to request the release of the UE-associated logical NG-connection over the NG interface.

AMF向源gNB-A发送UE CONTEXT RELEASE COMMAND消息。这个消息我们在上一章已经见过，但在切换场景下，它的触发时机就是路径切换成功之后。

场景演绎：

AMF-Central在收到来自gNB-B的PATH SWITCH REQUEST并成功处理后，立即向gNB-A发送UE CONTEXT RELEASE COMMAND。消息中包含了Chloe的UE NGAP ID。gNB-A收到后，就明白了“交接仪式”已经完成，它可以安全地删除Chloe的所有本地上下文，并释放为其分配的所有无线和传输资源。

至此，一次完整的N2切换流程宣告结束。Chloe的直播业务从gNB-A无缝迁移到了gNB-B，而网络内部也完成了所有必要的资源更新和清理。

5. 紧急制动：HANDOVER CANCEL (切换取消)

在现实世界中，切换准备阶段可能会出现各种意外。HANDOVER CANCEL流程就是源gNB的“紧急制动”机制。

9.2.3.11 HANDOVER CANCEL

This message is sent by the source NG-RAN node to the AMF to request the cancellation of an ongoing handover.

场景引入：

gNB-A向AMF发送了HANDOVER REQUIRED后，启动了一个定时器等待AMF的HANDOVER COMMAND。但可能发生以下情况：

  1. UE突然离开: Chloe的手机信号突然完全消失（例如，高铁进入了隧道）。gNB-A与UE失去了无线连接，切换已经没有意义。

  2. 更优目标出现: 在等待AMF响应期间，UE的测量报告显示，另一个邻居gNB-C的信号突然变得比gNB-B更好。gNB-A决定取消向gNB-B的切换，转而启动向gNB-C的切换。

在这些情况下，gNB-A会立即向AMF发送HANDOVER CANCEL消息。AMF收到后，如果它已经向gNB-B发送了HANDOVER REQUEST，它会立即通知gNB-B取消准备；如果还没有，则直接中止流程。最后，AMF会回复HANDOVER CANCEL ACKNOWLEDGE确认取消操作完成。

FAQ

Q1: 在路径切换期间，会不会有数据包丢失？5G如何保证业务的连续性？

A1:

会，但5G设计了**数据转发（Data Forwarding）**机制来最大程度地减少丢包。在目标gNB-B向核心网请求路径切换的这段短暂时间内，UPF可能仍然会将一些数据包发往源gNB-A。为了不丢失这些数据，在切换准备阶段，gNB-A和gNB-B之间会建立一个临时的转发隧道（通过Xn接口或NG-U接口）。

gNB-A会将这些“迟到”的下行数据包通过这个隧道转发给gNB-B，gNB-B再将它们发送给UE。同时，UE在上行方向也可能先将数据发送给gNB-B，gNB-B再转发给gNB-A，由gNB-A送往核心网，直到上行路径也切换完成。通过这种“双边收发、内部转发”的机制，保证了用户数据的平滑过渡。

Q2: 为什么需要一个单独的HANDOVER NOTIFY消息，而不是直接在PATH SWITCH REQUEST中一起完成？

A2:

这是一个解耦和职责分离的设计。HANDOVER NOTIFY和PATH SWITCH REQUEST虽然通常由目标gNB连续发送，但它们报告的是两个不同层面的事件，并触发核心网不同的逻辑：

  • HANDOVER NOTIFY是接入层（AS）事件的报告。它告诉AMF：“UE的无线连接已经成功建立在我这里了。” 这使得AMF可以立即更新UE的移动性状态（如位置信息），并触发对源gNB的资源释放。

  • PATH SWITCH REQUEST是用户面（UP）路径的建立请求。它告诉AMF/SMF：“请将数据流切换到我这里。”

将两者分开，使得协议逻辑更清晰。例如，在某些特殊场景下（如仅信令切换），可能只需要HANDOVER NOTIFY而不需要路径切换。

Q3: 如果PATH SWITCH REQUEST失败了，用户的连接会怎么样？

A3:

PATH SWITCH REQUEST失败是一个非常严重的问题，通常会导致用户连接中断。因为此时，UE的信令面已经由目标gNB管理，但用户面数据流仍然指向源gNB（或者已经中断）。UE处于一种“身心分离”的状态。在这种情况下，gNB会释放UE上下文，UE很可能会检测到无线链路失败（RLF），并需要重新发起RRC连接建立或重建过程，相当于一次掉线重连。

Q4: 整个N2切换过程耗时大概是多久？

A4:

整个切换过程，从源gNB发送HANDOVER REQUIRED到UE成功在目标小区通信，通常被设计在几十毫秒（ms）内完成。3GPP定义的中断时间（Handover Interruption Time）目标是0ms（对于DAPS切换等高级特性）到几十毫秒。对于VoNR等实时业务，中断时间必须控制在30-60ms以内，才能保证用户无感知。这要求所有涉及的信令交互和资源分配都必须在极短的时间内完成。

Q5: 在Part 1和Part 2中，我们看到了很多“透明容器”。可以总结一下它们在切换流程中的作用吗？

A5:

当然。在N2切换中，AMF就像一个繁忙的“邮件分发中心”，而这些透明容器就是不同部门（gNB、SMF）之间传递的、AMF无需拆阅的“内部文件”：

  1. Source to Target Transparent Container: 从源gNB发往目标gNB，内容是UE的完整AS层上下文和RRC配置。这是目标gNB“克隆”一个UE上下文所需的所有信息。

  2. Handover Required Transfer: 从源gNB发往SMF，内容是需要在目标gNB上建立的PDU会话和QoS流信息。

  3. Target to Source Transparent Container: 从目标gNB发往源gNB，内容是给UE的最终切换指令RRCReconfiguration。

  4. Handover Request Acknowledge Transfer: 从目标gNB发往SMF，内容是为PDU会话准备好的新的下行用户面隧道信息。

通过这些透明容器，NGAP协议巧妙地实现了RAN内部信息、RAN-SMF信息的端到端传递，同时保持了AMF作为纯粹信令路由节点的简洁性。

关系图谱