# 5G N2切换（NGAP Handover）信令全链拆解：核心网控制的移动性深度解析 ## 一、为什么需要 N2 切换：与 Xn 切换的本质分野 在 5G 系统（5GS）中，UE 在 CM-CONNECTED 状态下于 gNB 间移动时，主要有两条切换路径：**Xn 切换**与 **N2 切换**。前者由源/目标 gNB 通过 Xn 接口直接协调，核心网（AMF）仅在切换完成后做路径更新；后者则**完全由 AMF 通过 N2/NGAP 接口居中调度**，源 gNB 与目标 gNB 之间不必存在 Xn 链路。 N2 切换被触发的典型场景有三类： 1. **源 gNB 与目标 gNB 之间无 Xn 接口**（如跨厂商、跨域、新开局点未配 Xn）； 2. **需要 AMF 重定位（AMF Relocation）**——UE 移动到了属于不同 AMF 服务区域的 gNB； 3. **网络策略或切片约束**——目标 gNB 归属不同的 S-NSSAI 需要由核心网重新裁决，或者源 gNB 显式请求核心网参与（例如对某些 QoS Flow、对某些安全策略）。 其规范锚点为 **3GPP TS 23.502 clause 4.9.1.2 "N2-based Handover"**，信令编解码遵循 **TS 38.413（NGAP）clause 8（Elementary Procedures）与 clause 9（Messages and IEs）**，安全密钥推演依赖 **TS 33.501**。本文聚焦该机制的完整信令链、关键 IE、数据转发策略、状态机演进与实战排错。 ## 二、完整信令时序图 下图给出的是**同 AMF、同 SMF** 条件下的标准 N2 切换全流程（最常见场景），并在关键节点标注与"AMF 重定位"变体的差异点。 ```mermaid sequenceDiagram autonumber participant UE participant Src as 源gNB participant AMF as AMF participant SMF as SMF participant UPF as UPF participant Tgt as 目标gNB Note over UE,Tgt: ══ 准备阶段 (Preparation) ══ UE->>Src: RRC MeasurementReport（A3/A2事件） Src->>AMF: NGAP HANDOVER REQUIRED
(Handover Type, Cause, Target ID,
Src2Tgt Transparent Container, PDU Session List) Note over AMF: ①若Target AMF Set ID存在且不同AMF
→触发AMF重定位(Namf_CreateUEcontext) AMF->>SMF: Nsmf_PDUSession_UpdateSMContext
(Operation="Preparing",Ho="preparing") SMF->>UPF: N4 Session Modification Request
(建立到目标的转发隧道DL-Forwarding TNL) UPF-->>SMF: N4 Session Modification Response SMF-->>AMF: Nsmf_PDUSession_UpdateSMContext response
(含目标侧UP TNL Info、转发Info) AMF->>Tgt: NGAP HANDOVER REQUEST
(AMF UE NGAP ID, Src2Tgt Container,
PDU Session Setup List, Security Key+NH+NCC,
Allowed NSSAI, UE-AMBR, Security Context) Tgt-->>AMF: NGAP HANDOVER REQUEST ACKNOWLEDGE
(Tgt2Src Container, Admitted List,
DL Forwarding TNL Info) Note over AMF: ②AMF重定位时：目标AMF→源AMF
Namf_Communication_CreateUEcontext Rsp Note over UE,Tgt: ══ 执行阶段 (Execution) ══ AMF->>Src: NGAP HANDOVER COMMAND
(Tgt2Src Container, Handover List,
Data Forwarding Info) Src->>UE: RRCReconfiguration（含HO Command） Note over UE,UPF: ③下行数据转发开始
Direct: Src→Tgt(Xn-U) / Indirect: Src→UPF→Tgt UE->>Tgt: RRCReconfigurationComplete（UE同步到目标） Tgt->>AMF: NGAP HANDOVER NOTIFY（UE已到达） Note over UE,Tgt: ══ 路径切换与释放阶段 (Completion) ══ AMF->>SMF: Nsmf_PDUSession_UpdateSMContext
(Ho="completed", User Location Info) SMF->>UPF: N4 Session Modification
(切换DL隧道至目标gNB, 释放转发隧道) SMF-->>AMF: response SMF->>PCF: SmPolicyAssociationUpdate（可选,计费/QoS变更） AMF->>Src: NGAP UEContextReleaseCommand Src-->>AMF: NGAP UEContextReleaseComplete Note over AMF: ④AMF重定位时：源AMF释放UE上下文 ``` ## 三、准备阶段逐消息 IE 解析 ### 3.1 HANDOVER REQUIRED（源 gNB → AMF） 这是 N2 切换的**起点**，由源 gNB 在 RRC 测量报告（典型为 A3 事件：邻区质量优于服务小区偏移量）触发切换决策后发出。其关键 IE 如下表： | IE 名称 | 含义 | 设计意图 | |---------|------|----------| | **Handover Type** | 取值 `5gs-to-5gs`/`5gs-to-eps`/`eps-to-5gs` 等 | 让 AMF 知晓是系统内还是跨系统切换，决定是否触发 N26 接口与 EPS 交互 | | **Cause** | 如 `ho-desirable-for-radio`、`time-critical-ho` | 区分常规覆盖类切换与时延敏感切换，影响 QoS 接纳优先级 | | **Target ID（Target NG-RAN node ID）** | 目标 gNB 全局标识 + 选定的 TAC | AMF 据此解析目标 AMF Set、目标 gNB，并校验 TAC 是否触发 AMF 重定位 | | **AMF Set ID**（可选） | 源 gNB 建议的目标 AMF 集合 | AMF 重定位的依据；若空则保持当前 AMF | | **Source to Target Transparent Container** | 携带 RRC/无线侧 AS 上下文 | **对 AMF 完全不透明**，AMF 只做透传；内容由 TS 38.423/38.331 定义，含源小区 AS 配置、安全能力、DRB/SDAP/PDCP 配置，供目标 gNB 快速重建无线承载 | | **PDU Session Resource(s) to be Setup List** | 待切换的 PDU 会话及 QoS Flow 清单 | 让 AMF 逐 PDU 会话与 SMF 协商，决定哪些会话被目标接纳 | | **Masked IMEISV**（可选） | 脱敏的终端标识 | 用于合法拦截、轨迹追踪，避免明文 IMEI 泄露 | ### 3.2 AMF 的核心裁决：是否重定位 AMF 收到 HANDOVER REQUIRED 后，第一件大事是判断 **Target ID 所指 gNB 是否仍归属本 AMF**。这通过比较 gNB 与 AMF 的服务区域（TA List / AMF Region/Set）完成： - **不重定位**：本 AMF 直接驱动后续 N2 消息（上图的默认链路）。 - **重定位**：本（源）AMF 通过 **`Namf_Communication_CreateUEcontext`** 服务请求，将 UE 上下文迁移到目标 AMF；目标 AMF 接管后向目标 gNB 发 HANDOVER REQUEST。这一步是 N2 切换区别于 Xn 切换的标志性能力——Xn 切换原则上不能换 AMF。 ### 3.3 AMF ↔ SMF：Nsmf_PDUSession_UpdateSMContext 对每个待切换的 PDU 会话，AMF 调用 SMF 的 `Nsmf_PDUSession_UpdateSMContext`，关键参数： - **Operation**：`Updating`； - **Ho ("preparing"/"prepared"/"completed")**：阶段指示，本次为 `preparing`； - **PDU Session ID**、**PDU Session Type**； - **N2 SM Information**：携带源侧给目标侧的 QoS Flow 描述、TEID 等。 SMF 据此判断数据转发路径：若需**间接转发（Indirect Forwarding）**，SMF 通过 **N4 Session Modification** 在 UPF 上建立一条从源 gNB 方向到目标 gNB 方向的临时转发隧道（DL Forwarding TNL Info），UPF 返回新的 F-TEID。 ### 3.4 HANDOVER REQUEST（AMF → 目标 gNB） 这是目标 gNB 的**资源接纳与承载建立**依据，是 N2 切换最重的消息。关键 IE： | IE 名称 | 含义与作用 | |---------|------------| | **AMF UE NGAP ID** | 目标侧 UE 的 NGAP 标识（RAN UE NGAP ID 此时还未分配） | | **Source to Target Transparent Container** | 透传自源 gNB 的无线 AS 上下文 | | **PDU Session Resource Setup List** | 含每个 QoS Flow 的 GBF/MBR、UP TNL Info（目标侧 N3 F-TEID）、转发 Info | | **Security Key / Security Context** | 携带 KgNB 或 NH + NCC（Next Hop Chaining Count）、安全算法、UE 安全能力，供目标 gNB 推导接入层密钥 | | **Allowed NSSAI** | 目标 gNB 所在 PLMN/TA 允许的切片，供其按切片调度无线资源 | | **UE-AMBR** | UE 级聚合速率上限 | | **Mobility Restriction List** | 禁止区/服务区限制，防止越权移动 | 目标 gNB 完成接纳判决与无线资源预留后，回 **HANDOVER REQUEST ACKNOWLEDGE**，携带 **Target to Source Transparent Container**（内含给 UE 的 RRC HO Command，即 `reconfigurationWithSync`）以及 **DL Forwarding TNL Info**（用于源侧下行转发）。 ## 四、执行阶段：从命令到同步 AMF 将 `Tgt2Src Transparent Container` 封装进 **HANDOVER COMMAND** 下发源 gNB。源 gNB 提取其中的 RRC HO Command，经 **RRCReconfiguration** 透传给 UE。UE 收到后： 1. 与源小区去同步； 2. 在目标小区发起随机接入（基于 Container 内 preconfiguration 的 RACH 资源）； 3. 完成上行同步后回 **RRCReconfigurationComplete** 给目标 gNB。 值得注意的是，**N2 切换在空口仍是"硬切换"语义**（UE 在某时刻只连一个 gNB），但通过**数据转发**保证分组不丢，从而在业务面表现为"无缝"。 随后目标 gNB 发 **NGAP HANDOVER NOTIFY** 告知 AMF：UE 已成功到达。该消息仅含 **AMF UE NGAP ID** 与 **User Location Info**（目标小区 CGI），却是一个关键里程碑——它标志着执行阶段结束，进入路径切换。 ## 五、数据转发：直接转发 vs 间接转发 这是 N2 切换中最容易被忽视、却最影响时延与丢包的设计点。下图给出两种转发路径的拓扑差异： ```mermaid flowchart LR subgraph 直接转发["直接转发 (Direct Forwarding)"] A1[源gNB] -->|Xn-U隧道| B1[目标gNB] end subgraph 间接转发["间接转发 (Indirect Forwarding / IDFT)"] A2[源gNB] -->|N3隧道| B2[源/中间UPF] B2 -->|N9隧道| C2[目标UPF] C2 -->|N3隧道| D2[目标gNB] end style 直接转发 fill:#e8f5e9 style 间接转发 fill:#fff3e0 ``` **设计逻辑**：N2 切换本就发生在"无 Xn"或"换 AMF"场景，因此**直接转发往往不可用**，核心网必须提供一条绕行路径——这就是**间接转发隧道（Indirect Data Forwarding Tunnel, IDFT）**。SMF 在准备阶段通过 N4 同时在源侧 UPF（接收来自源 gNB 的下行数据）与目标侧 UPF 间建立 N9 转发隧道，使源 gNB 来不及发送的下行 PDU 经 UPF 中转抵达目标 gNB，再投递给 UE。 UPF 侧的 IDFT 创建与删除遵循 **TS 23.502** 的数据转发条款，Cisco 等厂商在 UPF 配置手册中专门描述了 IDFT 的 N4 规则下发与生命周期（切换完成后由 SMF 发 N4 删除转发隧道）。 ## 六、切换后的路径切换与资源释放 HANDOVER NOTIFY 后，AMF 调用 SMF 的 `Nsmf_PDUSession_UpdateSMContext`（Ho="completed"），SMF 随即： 1. **N4 Session Modification**：把下行（DL）N3 隧道的 F-TEID 从源 gNB 改到目标 gNB（即真正的"路径切换"，Path Switch）； 2. **释放转发隧道**：向相关 UPF 发 N4 删除间接转发规则； 3. **更新计费/QoS**：若用户位置变化触发费率区或 QoS 变更，调用 PCF 的 `SmPolicyAssociationUpdate`。 与此同时，AMF 向源 gNB 发 **NGAP UEContextReleaseCommand**，源 gNB 回 **UEContextReleaseComplete**，释放源侧无线与传输资源。若发生 AMF 重定位，源 AMF 还需在收到目标 AMF 通知后清理本地 UE 上下文。 ## 七、状态机与安全密钥演进 ### 7.1 切换阶段状态图 ```mermaid stateDiagram-v2 [*] --> 切换准备 切换准备 --> 准备失败: 目标接纳失败/超时 切换准备 --> 切换执行: HANDOVER COMMAND下发 切换执行 --> 执行失败: UE未同步/HO失败 切换执行 --> 路径切换: HANDOVER NOTIFY 路径切换 --> 完成: 源侧资源释放 完成 --> [*] 准备失败 --> [*]: 源gNB回退,维持连接 执行失败 --> 连接重建: RRC Reestablishment尝试 ``` 需要强调：在整个 N2 切换过程中，UE 始终处于 **CM-CONNECTED / RRC_CONNECTED**，N2 切换是"在线切换"，不会回到空闲态。 ### 7.2 安全密钥推演（TS 33.501） HANDOVER REQUEST 中的 **Security Key** 与 **NH（Next Hop）+ NCC（Next Hop Chaining Count）** 决定了目标 gNB 的接入层密钥 `KgNB*`： - 若 NCC 与 UE 当前值相同，目标 gNB 用当前 `KgNB` 派生； - 若 NCC 更新，则使用经过 `KAMF → NH` 横向推演得到的新鲜 NH 派生 `KgNB*`。 这一设计避免了每次切换都回溯 KAMF，实现了**前向安全的密钥链**，是 N2 切换相对 EPS S1 切换在安全上的重要延续。 ## 八、N2 切换 vs Xn 切换对比 | 维度 | N2 切换（NGAP） | Xn 切换 | |------|----------------|---------| | 主控方 | **AMF（核心网）** | 源/目标 gNB（接入网） | | 必需接口 | N2（源/目标 gNB 都连 AMF） | Xn（源/目标 gNB 间） | | 是否支持 AMF 重定位 | **支持** | 不支持（保持原 AMF） | | 信令跳数 | 多（经 AMF/SMF/UPF） | 少（gNB 间直达） | | 准备时延 | 较长（>Xn） | 较短 | | 数据转发 | 直接（需 Xn-U）或**间接（IDFT 经 UPF）** | 直接 Xn-U 为主 | | 典型场景 | 无 Xn、跨厂商、跨 AMF、切片重选 | 同厂商同域、Xn 可达 | | 规范条款 | TS 23.502 §4.9.1.2 | TS 23.502 §4.9.1.1 | 工程经验：**现网 N2 切换准备时延通常比 Xn 高 30–80ms**，主要消耗在 AMF↔SMF↔UPF 的多次 SBI/N4 往返。因此规划上应优先保证同区域 gNB 间 Xn 互通，N2 切换作为兜底与跨域手段。 ## 九、实战：抓包识别与故障定位 ### 9.1 如何在 Wireshark 中识别 N2 切换 在 N2 接口（SCTP/IP，NGAP over SCTP）上抓包，关键过滤器： - `ngap.procedureCode == 0`（HandoverPreparation）定位 HANDOVER REQUIRED； - `sctp.srcport == 38412 or sctp.dstport == 38412` 锁定 N2 流； - 在 N4（PFCP over UDP/SCTP，端口 8805）上观察 `pfcp.msg_type == 52/53`（Session Modification）的密集出现，是间接转发隧道建立的特征。 判断切换类型的小技巧：**若看到目标 gNB 在切换前没有 Xn 链路建立消息，且 AMF 频繁参与 SMF/UPF 交互，基本可判定为 N2 切换**；若切换全程 AMF 仅在末端出现 UEContextRelease/Path Switch，则是 Xn 切换。 ### 9.2 常见故障点 1. **HANDOVER REQUIRED 后无 HANDOVER REQUEST**：检查 AMF 是否因 Target ID 解析失败、AMF 重定位目标不可达、或切片不匹配而丢弃。 2. **目标 gNB 接纳失败（HANDover Preparation Failure）**：多为无线资源不足、QoS Flow 无法满足、Allowed NSSAI 与目标 gNB 配置不一致。 3. **切换执行后 UE 重建（RRC Reestablishment）**：常见于目标侧安全密钥推演错误（NCC/NH 不同步）、或目标小区 RACH 资源耗尽。 4. **数据面中断（丢包/卡顿）**：检查 SMF 是否正确下发了间接转发隧道 N4 规则——若 IDFT 未建立，源 gNB 缓存的下行 PDU 将在切换瞬间丢失。 5. **切换成功但下行不通**：路径切换阶段 SMF 未把 DL F-TEID 切到目标 gNB，或 UPF 的 N4 规则更新延迟。 ## 十、行业影响与前沿 N2 切换作为核心网控制的通用移动性手段，是**跨厂商互通、跨域移动、AMF 池弹性伸缩**的基石。学术界对切换时延与可靠性的研究亦围绕其展开：arXiv 2403.04379 从解析角度评估了条件切换（CHO）性能，而 Springer 2023 的 5G-NR 切换管理综述（doi:10.1186/s13638-023-02261-4）系统对比了 Xn/N2 的触发机制与失败模式。随着 R18/R19 引入**卫星接入（NTN）**与**多播广播**，N2 切换在 NTN 场景下因超大传播时延面临"准备阶段超时"的新挑战，催生了基于预测的提前准备（Early Handover Preparation）等增强方向。 ## 常见问题 **Q1: N2 切换和 Xn 切换最本质的区别是什么？** A: 控制面主控方不同。Xn 切换由 gNB 间直接协调、核心网事后更新；N2 切换由 AMF 通过 NGAP 居中调度。因此 N2 切换不要求源/目标 gNB 间有 Xn 接口，且支持 AMF 重定位，代价是信令跳数更多、时延更长。 **Q2: 既然 N2 切换通常发生在"无 Xn"场景，数据怎么从源 gNB 转发到目标 gNB？** A: 通过**间接数据转发隧道（IDFT）**。SMF 在准备阶段经 N4 在 UPF 上建立临时转发规则，源 gNB 的下行残余数据经 N3→UPF→N9→UPF→N3 抵达目标 gNB，从而避免切换瞬间丢包。直接转发仅当源/目标 gNB 间存在 Xn-U 时可用。 **Q3: HANDOVER REQUIRED 里的 "Transparent Container" 为什么叫透明容器？AMF 不解析它吗？** A: 对。Source to Target / Target to Source Transparent Container 携带的是 RRC/无线 AS 上下文（TS 38.423/38.331 定义），AMF 作为转发节点**不解码其内容**，只做字节级透传。这样既保证核心网与无线侧解耦，又避免 AMF 实现复杂的 RRC 解析。 **Q4: N2 切换过程中 UE 会回到空闲态吗？** A: 不会。N2 切换属于 CM-CONNECTED/RRC_CONNECTED 状态下的在线切换。若切换执行失败，UE 会尝试 RRC 连接重建（Reestablishment），而非直接回空闲态。 **Q5: AMF 重定位发生在 N2 切换的哪个环节？** A: 准备阶段早期。源 AMF 收到 HANDOVER REQUIRED 后，若解析出 Target ID 指向不同 AMF 服务区，便通过 `Namf_Communication_CreateUEcontext` 把 UE 上下文迁移给目标 AMF，后续 HANDOVER REQUEST 由目标 AMF 直接发给目标 gNB。 ## 参考来源 1. [3GPP TS 23.502 — Procedure for 5G System, clause 4.9.1.2 N2-based Handover](https://www.3gpp.org/dynareport/23502.htm) — N2 切换主流程与准备/执行/释放阶段定义 2. [3GPP TS 38.413 — NGAP; clause 8 Elementary Procedures / clause 9 Messages & IEs](https://www.3gpp.org/dynareport/38413.htm) — HANDOVER REQUIRED/REQUEST/COMMAND/NOTIFY 的 IE 编解码 3. [5G SA Inter gNB Handover | 5G NGAP Handover — Techplayon](https://www.techplayon.com/5g-sa-inter-gnb-handover-n2-or-ngap-handover/) — N2/NGAP 切换端到端 call flow 图解 4. [Introduction of Xn and NG (N2) based handover — free5GC](https://free5gc.org/blog/20251105/20251105/) — 开源 5GC 实现视角下 N2 与 Xn 切换对比、N4 路径切换 5. [Indirect Forwarding Tunnel (IDFT) — Cisco UCC 5G UPF Guide](https://www.cisco.com/c/en/us/td/docs/wireless/ucc/upf/2025-03/config-admin/ucc-5g-upf-config-and-admin-guide_2025-03/m_indirect_forwarding_tunnel.pdf) — 间接转发隧道的 N4 建立与删除实践 6. [A survey on handover management in 5G-NR cellular networks — Springer (2023)](https://link.springer.com/content/pdf/10.1186/s13638-023-02261-4.pdf) — 5G-NR 切换机制、触发与失败模式综述 --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。