51学通信

深度解析 3GPP TS 38.410：6.4 UE Mobility Management Procedures (UE移动性管理流程)

15分钟阅读

好的，我们继续跟随5G基站工程师小雷，深入探索NG接口上那些定义了5G网络基础交互模式的关键功能。在完成了UE与核心网的“初次邂-逅”之后，我们将聚焦于贯穿UE整个连接生命周期的移动性管理流程。

深度解析 3GPP TS 38.410：6.4 UE Mobility Management Procedures (UE移动性管理流程)

本文技术原理深度参考了3GPP TS 38.410 V18.2.0 (2024-06) Release 18规范中，关于“6.4 UE Mobility Management Procedures”的核心章节，并重点剖析其所包含的切换（Handover）相关流程，为读者完整呈现5G网络中，为保障用户“永不掉线”的移动体验，NG接口上所进行的精密信令交互。

引言：在速度与激情中，编织一张无缝的“天罗地网”

我们的主角，基站工程师小雷，深知他所构建的5G网络，其价值不仅在于提供极致的峰值速率，更在于为高速移动的用户，提供如影随形、无缝切换的连续覆盖。想象一下，一辆时速超过300公里的高铁上，乘客们正享受着流畅的VR直播；一辆自动驾驶汽车在城市峡谷中穿梭，与边缘计算节点的连接从未中断。

这一切“行云流水”般体验的背后，是移动通信领域最复杂、最精妙的技术之一——切换（Handover）。

我们在5.4节功能概述中，已经了解了切换的“是什么”（三阶段理论）。而6.4节“UE移动性管理流程”，则是NG接口关于切换的“怎么做”的完整操作手册。它将5.4节的理论，分解为一系列具体的、按部就班的NGAP信令流程。

本篇文章，我们将以一场惊心动魄的N2切换（跨gNB、通过核心网中转的切换）为例，再次“慢动作回放”这场“信令芭蕾”的每一个舞步，但这一次，我们的焦点将是6.4节所定义的、每一个具体的NGAP流程名称和它们在整个切换大戏中的精确角色。

1. 切换的“剧本”：6.4节定义的流程全家桶

6.4 UE Mobility Management Procedures

The following UE Mobility management procedures are used to prepare, execute or cancel handovers:

  • Handover Preparation;
  • Handover Resource Allocation;
  • Handover Notification;
  • Path Switch Request;
  • …
  • Handover Cancellation;
  • Handover Success;
  • …

6.4节列出了一系列与切换相关的NGAP流程。其中，Handover Preparation、Handover Resource Allocation和Path Switch Request是构成一场N2切换的“三部曲”。我们将把它们重新嵌入到切换的准备、执行、完成三大阶段中，来理解其内在的逻辑联系。

2. 第一幕：切换准备 (Preparation) - 一场跨越核心网的“隔空订位”

场景设定： 用户“张三”正连接在小雷的gNB-A上，高速驶向gNB-B的覆盖区。gNB-A与gNB-B之间没有Xn接口。

2.1 触发与决策 (gNB-A)

  • gNB-A通过UE的测量报告，做出切换决策。
  • 它发现需要进行一次N2切换。

2.2 “转接申请” - Handover Preparation 流程

NGAP Procedure: Handover Preparation (AMF Initiated)

这是一个由AMF发起的流程，但在N2切换中，它是由gNB-A的一个请求间接触发的。

  1. gNB-A → AMF (HANDOVER REQUIRED):

    • gNB-A向AMF发送HANDOVER REQUIRED消息。这不是一个独立的流程，而是Handover Preparation这个大流程的第一条上行消息。
    • 它向AMF提出了切换的“申请”，并附上了需要转交给目标gNB的“UE档案（透明容器）”。

  2. AMF → gNB-B (HANDOVER REQUEST):

    • AMF收到申请后，向目标gNB-B发送HANDOVER REQUEST消息。这条消息，正式启动了Handover Preparation流程的下行部分。
    • AMF扮演“中转站”，将gNB-A的“UE档案”和核心网侧的PDU会话信息，一同发给gNB-B，请求其“预留座位”。

2.3 “订位确认” - Handover Resource Allocation 流程

NGAP Procedure: Handover Resource Allocation (NG-RAN node initiated)

这是一个由目标gNB发起的流程，用于确认资源预留的结果。

  1. gNB-B 资源准备:

    • gNB-B收到HANDOVER REQUEST后，检查自身资源，并为UE预留空口资源。

  2. gNB-B → AMF (HANDOVER REQUEST ACKNOWLEDGE):

    • gNB-B向AMF发送HANDOVER REQUEST ACKNOWLEDGE消息。这是Handover Resource Allocation流程的核心。
    • 它向AMF确认“座位已预留”，并附上了发往UE的“登机牌（切换指令）”，同样打包在透明容器中。
    • 如果资源不足，gNB-B则会回复HANDOVER PREPARATION FAILURE消息。

  3. AMF → gNB-A (HANDOVER COMMAND):

    • AMF将gNB-B的“确认函”和“登机牌”，封装在HANDOVER COMMAND消息中，发回给源gNB-A。

至此，准备阶段结束。NG接口通过Handover Preparation和Handover Resource Allocation两个流程的一上一下、一来一回，完美地完成了一次跨越核心网的“隔空订位”。

3. 第二幕：切换执行 (Execution) - UE的“空中一跃”

  • gNB-A通过RRC信令，将“登机牌”发给UE。
  • UE执行切换，与gNB-B建立连接。
  • 在NG接口层面，这个阶段是“静默”的。所有的动作都发生在UE和两个gNB之间的空口上。

4. 第三幕：切换完成 (Completion) - 数据路径的“乾坤大挪移”

4.1 “落地报告” - Handover Notification 流程

NGAP Procedure: Handover Notification (NG-RAN node initiated)

  1. gNB-B → AMF (HANDOVER NOTIFY):
    • 当UE成功在新家“落地”（完成RRC重建）后，目标gNB-B会立即向AMF发送HANDOVER NOTIFY消息。
    • 这相当于在向“指挥中心”报告：“目标已成功转移到我方阵地！”
    • AMF收到此消息后，就知道切换的控制面部分已经成功。它可以开始着手进行用户面的路径切换了。

4.2 “管道改道” - Path Switch Request 流程

NGAP Procedure: Path Switch Request (NG-RAN node initiated)

这是切换完成阶段最核心、最关键的流程，其目标是将下行的用户数据流，从旧的gNB-A，切换到新的gNB-B。

  1. gNB-B → AMF (PATH SWITCH REQUEST):

    • 在发送了HANDOVER NOTIFY之后（或者合并在其中），gNB-B会向AMF发送PATH SWITCH REQUEST消息。
    • 核心内容:
      • PDU Session ID List: 列出了需要切换路径的所有PDU会话。
      • Source AMF UE NGAP ID: UE在旧AMF-gNB连接上的ID。
      • Downlink Tunnel Information: gNB-B为每一条PDU会话的下行数据流，所分配的新的GTP-U隧道端点信息（IP地址和TEID）。
    • 这条消息的本质是，gNB-B在向核心网“喊话”：“我已经为‘张三’准备好了新的收货地址，请立即将他的所有包裹改寄到这里！”

  2. AMF → SMF (Nsmf_PDUSession_UpdateSMContext):

    • AMF收到“改寄地址”的请求后，立即通知负责这些PDU会话的SMF。

  3. SMF → UPF (隧道修改):

    • SMF指令UPF，将这些PDU会话的下行GTP-U隧道，更新为gNB-B提供的新地址。
    • “乾坤大挪移”完成！ 从这一刻起，用户的数据流开始源源不断地涌向新的gNB-B。

  4. SMF → AMF → gNB-B (PATH SWITCH REQUEST ACKNOWLEDGE):

    • 路径切换成功后，SMF通过AMF，向gNB-B回复PATH SWITCH REQUEST ACKNOWLEDGE消息，确认“改道成功”。
    • 在这条消息中，核心网可能还会为需要数据转发的PDU会话，提供上行转发的隧道信息。

4.3 “打扫战场” - UE Context Release

  • 路径切换成功后，AMF会向源gNB-A发送UE CONTEXT RELEASE COMMAND（我们在5.3节中学习过），指令其“打扫战场”，释放为“张三”保留的所有资源。

总结：一场分工明确、环环相扣的“精密手术”

通过对6.4节核心切换流程的深度剖析，我们看到了NG接口是如何通过一系列分工明确、环环相扣的NGAP流程，来支撑一场复杂而精准的“网络外科手术”的。

  • Handover Preparation 与 Handover Resource Allocation 共同完成了“术前准备”，确保了目标侧的资源预留和切换指令的生成。
  • Handover Notification 标志着“手术关键步骤”（UE空口切换）的成功，是启动后续流程的“信号枪”。
  • Path Switch Request 则是“缝合与收尾”的核心，它完成了用户面路径的“血管吻合”，确保了数据流的平滑过渡。

对于基站工程师小雷来说，精通这些流程，是他进行切换问题排查和优化的根本。当用户投诉“高铁上视频通话卡顿”时，他需要化身“网络侦探”，通过分析这些NGAP流程的信令交互记录，来判断问题究竟出在哪一环：是源gNB的切换决策太晚？是目标gNB的资源准备失败？还是路径切换的时延太高？每一个信令，都是解开谜题的一把钥匙。

FAQ

Q1：为什么需要这么多流程，而不是一个单一的“Handover”流程？ A1：这是模块化、可组合设计思想的体现。将复杂的切换过程，分解为多个职责单一的流程，带来了极大的灵活性。例如，Path Switch Request流程，不仅在切换中被使用，在UE从INACTIVE状态恢复时，如果UE出现在一个新的gNB，也需要通过这个流程来重建用户面路径。将这些功能模块化，使得它们可以在不同的上层业务逻辑中被灵活复用。

Q2：在N2切换中，AMF扮演了什么角色？它会参与切换决策吗？ A2：AMF在N2切换中，主要扮演信令中继和流程协调者的角色。它不参与切换的无线决策（即“要不要切”、“切到哪”），这个决策权完全在源gNB。AMF的职责是：1. 根据源gNB的请求，找到目标gNB，并向其转发切换请求。2. 在目标gNB确认后，将切换命令转发回源gNB。3. 在UE切换成功后，协调SMF进行路径切换，并指令源gNB释放资源。AMF是整个流程的“总调度”，但不是“无线专家”。

Q3：如果PATH SWITCH REQUEST流程失败了，会发生什么？ A3：如果路径切换失败（例如，UPF无法建立到新gNB的隧道），核心网会向新gNB-B返回PATH SWITCH REQUEST FAILURE。此时，UE的控制面虽然已经在gNB-B上，但用户面数据流仍然指向旧的gNB-A。这将导致业务彻底中断。gNB-B在收到失败指示后，通常会触发UE上下文释放流程，将这个“残缺”的连接拆除。UE会掉线，并需要重新发起一次完整的接入流程来恢复服务。

Q4：6.4节中提到的Handover Cancellation流程是做什么用的？ A4：这是一个“反悔”流程。在源gNB-A已经向AMF发出了HANDOVER REQUIRED请求，但切换的“执行”阶段（UE的空中一跃）还未开始的这段时间里，如果gNB-A突然改变了主意（例如，UE的信号突然又变好了，或者目标gNB的信号突然恶化了），它就可以向AMF发送一条HANDOVER CANCEL消息，来取消这次尚未执行的切换。AMF收到后，会终止整个切换准备流程，并通知已经预留了资源的目标gNB-B“取消订位”。

Q5：这些切换流程的时延要求有多高？ A5：非常高。一次成功的无感切换，整个端到端的流程（从源gNB决策到路径切换完成），通常需要在**几十毫秒（ms）**内完成。这对gNB、AMF、SMF、UPF所有参与节点的处理性能，以及它们之间传输网络的时延，都提出了极高的要求。任何一个环节的“慢半拍”，都可能导致用户可以感知的业务卡顿甚至中断。

关系图谱