51学通信

深度解析 3GPP TS 38.413：9.2.3 UE Mobility Management Messages (Part 1 - 切换准备阶段)

21分钟阅读

本文技术原理深度参考了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 1 - 切换准备阶段)

大家好，欢迎回到我们的3GPP规范深度解析系列！在掌握了如何解读NGAP消息的“语法”后，我们今天将正式潜入5G网络中最核心、最能体现“移动通信”魅力的流程之一——UE移动性管理（UE Mobility Management），也就是我们通常所说的切换（Handover）。

你是否曾惊叹于在高速飞驰的列车上，视频通话依然流畅不中断？这背后，正是移动性管理流程在以毫秒级的精度，为你完成一次又一次无感的网络“接力”。当你的手机从一个基站（gNB）的覆盖范围移动到另一个时，网络必须在连接中断前，为你“铺好”通往新基站的道路，将你的业务、安全状态、QoS保障等所有“数字档案”无缝迁移过去。

本章定义的UE Mobility Management Messages，就是这套复杂“接力赛”的裁判指令集。它详细规定了源gNB、目标gNB以及核心网AMF这三位“运动员”之间，如何通过一系列精确的信令交互，完成切换的准备、执行和善后工作。

由于切换流程涉及的消息众多且逻辑严密，我们将把9.2.3章节拆分为三个部分进行深度剖析。本文作为Part 1，将聚焦于切换的“准备阶段”——从源gNB下定决心发起切换，到目标gNB万事俱备，只欠UE“纵身一跃”的全部幕后准备工作。

为了生动地理解这一系列复杂操作，让我们再次请出科技评测博主Chloe。她正乘坐一辆时速300公里的高铁，并使用她的旗舰5G手机进行一场高清视频直播，以测试网络的无缝覆盖能力。

  • UE: Chloe的5G手机

  • 场景: 在高铁上进行高清直播，即将从gNB-A小区切换到gNB-B小区。

  • 网络节点: 源基站gNB-A，目标基站gNB-B，以及共同的上级AMF-Central。

我们将通过Chloe这次跨越两个基站的无感切换之旅，来深入剖析以下核心消息：

  • HANDOVER REQUIRED: 源gNB-A如何“吹响”切换准备的号角。

  • HANDOVER REQUEST: AMF如何向目标gNB-B传达“贵宾即将抵达”的通知。

  • HANDOVER REQUEST ACKNOWLEDGE: 目标gNB-B如何回复“红毯已铺好，请指示”。

  • HANDOVER COMMAND: AMF如何向源gNB-A下达“可以起跳”的最终指令。

  • HANDOVER PREPARATION FAILURE / HANDOVER FAILURE: 在准备过程中，如果出现意外（如目标gNB客满），网络如何处理失败。

准备好了吗？让我们发车，一同揭秘高铁上流畅5G体验背后的信令芭蕾！

1. 切换的起点：HANDOVER REQUIRED (切换要求)

当源gNB认为一个UE不再适合由自己服务，而切换到另一个邻居gNB会获得更好的服务质量时，切换流程便由源gNB发起。

9.2.3.1 HANDOVER REQUIRED

This message is sent by the source NG-RAN node to the AMF to request the preparation of resources at the target.

场景引入：

Chloe乘坐的高铁正高速驶离gNB-A的覆盖中心。Chloe的手机持续向gNB-A上报测量报告（Measurement Report），报告中显示，当前服务小区（gNB-A）的信号强度（RSRP）正在快速下降，而一个邻近小区（属于gNB-B）的信号强度则在快速上升并超过了某个门限。

gNB-A的切换算法判断，为了保证Chloe的4K直播不卡顿，必须立即将她切换到gNB-B。于是，gNB-A向核心网的AMF-Central发送了第一条指令——HANDOVER REQUIRED。

这封消息，是源gNB向AMF发出的、一份详尽的“切换申请书”。

表格 9.2.3.1-1: HANDOVER REQUIRED 消息内容

| IE/Group Name | Presence | Range | IE type and reference | Semantics description | Criticality | Assigned Criticality |

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

| Message Type | M | | 9.3.1.1 | | YES | reject |

| AMF UE NGAP ID | M | | 9.3.3.1 | | YES | reject |

| RAN UE NGAP ID | M | | 9.3.3.2 | | YES | reject |

| Handover Type | M | | 9.3.1.22 | | YES | reject |

| Cause | M | | 9.3.1.2 | | YES | ignore |

| Target ID | M | | 9.3.1.25 | | YES | reject |

| Direct Forwarding Path Availability | O | | 9.3.1.64 | | YES | ignore |

| PDU Session Resource List | 1 | | | | YES | reject |

| >PDU Session Resource Item | | 1.. | | | | |

| >>PDU Session ID | M | | 9.3.1.50 | | | |

| >>Handover Required Transfer | M | | OCTET STRING | Containing the Handover Required Transfer IE specified in subclause 9.3.4.14. | | |

| Source to Target Transparent Container | M | | 9.3.1.20 | | YES | reject |

核心IE深度解读：

  • Cause: 切换原因。明确了本次切换的目的。对于Chloe的场景，Cause值就是"Radio reasons"（无线原因）。其他可能的原因还包括"Resource optimisation"（资源优化，即负载均衡）、"Reduce load in serving cell"（降低服务小区负载）等。

  • Target ID: 明确了切换的目标。gNB-A会在这里填入它从UE测量报告中识别出的目标小区的全局ID（Target NG-RAN Node ID + Target TAI）。

  • PDU Session Resource List: 这是一个列表，gNB-A必须在这里列出Chloe手机当前所有需要被切换的PDU会话。每个PDU会话都通过Handover Required Transfer IE进行描述。这是一个透明容器，里面装着源gNB（代表SMF）希望在目标gNB上为该PDU会话建立的QoS流等信息，AMF只负责转发。

  • Source to Target Transparent Container: 这是整个切换准备流程中最关键的“信息包裹”，AMF对其完全透明。它由源gNB生成，目标gNB消费。这个容器里装载了目标gNB准备切换资源所需的一切信息，主要包括：

    • 完整的UE上下文：包括UE的安全能力、已激活的安全密钥、UE无线能力等。

    • RRC配置：源gNB当前为UE配置的所有RRC参数。

    • UE History Information: UE最近服务过的小区列表。

    目标gNB-B收到这个“包裹”后，无需再向AMF查询，也无需与UE交互，就能“凭空”在自己这边为Chloe的手机重建一个几乎一模一样的上下文环境，并准备好无线资源。

2. 核心网的“传旨”：HANDOVER REQUEST (切换请求)

AMF收到HANDOVER REQUIRED后，扮演了“中央调度员”的角色。它会进行一些必要的检查（例如，检查Chloe的移动性策略是否允许她接入目标小区），然后向目标gNB-B转发切换请求。

9.2.3.4 HANDOVER REQUEST

This message is sent by the AMF to the target NG-RAN node to request the preparation of resources.

AMF向目标gNB-B发送HANDOVER REQUEST消息。这相当于AMF在说：“gNB-B请注意，有一位VIP用户（Chloe）正向你移动，这是她的全部档案和业务需求，请立即为她准备好资源。”

HANDOVER REQUEST消息的核心内容

这个消息的大部分内容，都是从gNB-A发来的HANDOVER REQUIRED消息中“继承”而来的：

  • Source to Target Transparent Container: AMF将这个“透明包裹”原封不动地传递给了gNB-B。

  • PDU Session Resource Setup List HOReq: AMF将gNB-A为每个PDU会话准备的Handover Required Transfer IE，重新组织成一个PDU Session Resource Setup List HOReq，下发给gNB-B。这个列表明确了gNB-B需要为Chloe的直播PDU会话建立哪些QoS流，以及相应的用户面隧道信息（由SMF在后台已经准备好并下发给了AMF）。

  • UE Security Capabilities, Security Context, Allowed NSSAI等: AMF还会将自己保存的、关于Chloe的核心网层面的“档案”信息一并下发，确保gNB-B获得最权威、最完整的UE上下文。

3. 目标gNB的“回禀”：HANDOVER REQUEST ACKNOWLEDGE (切换请求确认)

目标gNB-B在收到HANDOVER REQUEST后，会立即开始“铺设红毯”——即分配无线资源。

9.2.3.5 HANDOVER REQUEST ACKNOWLEDGE

This message is sent by the target NG-RAN node to inform the AMF about the prepared resources at the target.

完成资源准备后，gNB-B会向AMF回复HANDOVER REQUEST ACKNOWLEDGE。

核心IE深度解读：

  • PDU Session Resource Admitted List: gNB-B在这个列表中，详细报告了哪些PDU会话的资源已经成功准备就绪。对于每个成功的会话，它会生成一个Handover Request Acknowledge Transfer IE。这是一个透明容器，里面包含了gNB-B为下行数据转发分配的GTP隧道端点信息，这份“回执”最终将被送达SMF，以便UPF开始向目标gNB转发数据。

  • PDU Session Resource Failed to Setup List HOAck: 如果gNB-B因为资源不足等原因，无法为某个PDU会话准备资源，它会在这里报告失败，并说明原因。这支持了部分切换——即使用户的某些业务无法切换，只要关键业务（如语音）能成功，切换依然可以继续。

  • Target to Source Transparent Container: 这是另一个至关重要的透明容器！它由目标gNB-B生成，最终将被送达源gNB-A。里面装着什么呢？它装着一条完整的RRC消息——RRCReconfiguration。这条消息是gNB-B为Chloe的手机量身定制的，包含了手机接入gNB-B所需的所有空口配置。源gNB-A在收到这条消息后，会将其透明地转发给手机，手机执行这条指令后，就完成了向gNB-B的“跳跃”。

4. AMF的“最终指令”：HANDOVER COMMAND (切换命令)

AMF收到HANDOVER REQUEST ACKNOWLEDGE后，切换准备阶段进入尾声。AMF现在需要将目标gNB准备好的“通行证”（RRCReconfiguration消息）发回给源gNB。

9.2.3.2 HANDOVER COMMAND

This message is sent by the AMF to inform the source NG-RAN node that resources for the handover have been prepared at the target side.

AMF向源gNB-A发送HANDOVER COMMAND消息。

这个消息的核心内容就是原封不动地传递从gNB-B收到的Target to Source Transparent Container。

场景演绎：

gNB-A收到了HANDOVER COMMAND。它打开里面的“透明容器”，取出RRCReconfiguration消息，然后通过空口发送给Chloe的手机。这条RRC消息相当于在说：“Chloe，立即切换到频点XXX，小区ID为YYY，并使用这些新的无线参数。”

Chloe的手机收到并执行该指令后，就会与gNB-A断开连接，并尝试接入gNB-B。至此，切换的“准备阶段”圆满结束，后续的“执行阶段”（如Handover Notify, Path Switch等）即将开始，我们将在本系列的Part 2中详细解读。

5. 准备阶段的“意外”：Failure Procedures

  • HANDOVER PREPARATION FAILURE (切换准备失败) (9.2.3.3)

    • 发起方: AMF。

    • 场景: AMF在收到HANDOVER REQUIRED后，在转发给目标gNB之前就发现了问题。例如，AMF发现Chloe的签约信息禁止她接入目标小区所属的区域。此时，AMF会直接向源gNB-A回复HANDOVER PREPARATION FAILURE，并在Cause中说明原因。切换流程提前终止。

  • HANDOVER FAILURE (切换失败) (9.2.3.6)

    • 发起方: 目标gNB。

    • 场景: 目标gNB-B收到了HANDOVER REQUEST，但在资源准备阶段失败了。例如，当时gNB-B正承载着一场大型音乐会的所有直播流，资源已经饱和，无法再接纳Chloe的高带宽直播业务。

    gNB-B会向AMF回复HANDOVER FAILURE，Cause为"No radio resources available in target cell"。AMF再将这个失败结果通知源gNB-A。gNB-A会中止本次切换，可能会尝试选择另一个候选小区，或者维持当前连接。

FAQ

Q1: N2切换（本文描述的流程）和Xn切换有什么主要区别？网络在什么情况下会选择N2切换？

A1:

这是一个核心问题。

  • Xn切换：当源gNB和目标gNB之间存在直接的Xn接口时，优先使用。切换信令（如Handover Request/Acknowledge）直接在两个gNB之间交互，AMF只在准备阶段的开始和结束时参与，不中转大部分信令。优点是速度快、效率高。

  • N2切换：当两个gNB之间没有Xn接口，或者因为某些策略原因（如跨AMF区域切换）需要AMF深度介入时，使用N2切换。所有信令都必须通过AMF进行中转。优点是普适性强，即使gNB间无直接连接也能工作。

在Chloe的高铁场景中，如果沿线的gNB都已预先配置好了Xn邻区关系，那么大概率会走Xn切换。如果某个新部署的gNB还未建立Xn连接，那么就会触发N2切换。

Q2: 什么是“透明容器”（Transparent Container）？为什么AMF不应该解析它？

A2:

“透明容器”是3GPP协议中一种重要的设计模式，用于实现接入层（AS）与非接入层（NAS）/核心网控制面的解耦。

Source to Target Transparent Container里装的是源gNB和目标gNB之间沟通的“行话”，主要是RRC层的配置信息和UE的AS层上下文。这些信息对于AMF来说是“天书”，AMF既不需要也无法理解。让AMF透明传输这个容器，可以使得未来RRC协议无论如何演进（增加新的无线特性），AMF的NGAP协议都无需改动，大大增强了系统的可扩展性和向后兼容性。

Q3: 如果切换准备成功了，但UE在收到切换命令后，因为信号突然变得极差而无法成功接入目标gNB，会发生什么？

A3:

这属于切换的“执行阶段”失败。UE在尝试接入目标gNB失败后，会触发无线链路失败（Radio Link Failure, RLF）。之后，UE会尝试在其最后配置的候选小区列表中，重新发起**RRC重建（RRC Re-establishment）**过程。它很可能会尝试重建回原来的源gNB-A。gNB-A如果收到了重建请求，就会知道切换执行失败了，并通知AMF。这个后续过程我们将在本系列的Part 2中详细探讨。

Q4: 什么是“部分切换”（Partial Handover）？它在什么场景下有用？

A4:

“部分切换”指的是一个UE拥有多个PDU会话，但在切换时，目标gNB只成功为其中的一部分会话准备了资源。例如，Chloe的手机同时有一个VoNR语音会话和一个4K直播的数据会话。目标gNB可能资源紧张，只能保证VoNR语音所需的QoS流，但无法满足4K直播的大带宽需求。

在这种情况下，目标gNB会在HANDOVER REQUEST ACKNOWLEDGE中，将语音PDU会话放入Admitted List，将直播PDU会话放入Failed to Setup List。AMF收到后，会认为切换可以继续，因为它保证了更高优先级的业务。切换后，Chloe的电话不会中断，但直播可能会被核心网（SMF）降级或中断。

Q5: 在整个切换准备阶段，UE是否知道自己即将被切换？

A5:

完全不知道。在源gNB收到AMF发来的HANDOVER COMMAND之前，所有的信令交互都发生在网络侧的gNB和AMF之间，对UE是完全透明的。UE只知道自己需要根据网络的指令进行测量并上报测量报告。直到最后一刻，源gNB向UE发送RRCReconfiguration消息，UE才知道自己需要“跳”了。这种设计确保了UE的协议栈尽可能简单，并将复杂的移动性决策完全交由网络侧处理。

关系图谱