<!-- title: 5G N2切换信令全链拆解 -->
<!-- domain: protocols -->

# 5G N2切换信令全链拆解：从测量上报到上下文释放的端到端解析

## 一、为什么需要专门讲 N2 切换

在 5G 移动性管理中，连接态（RRC_CONNECTED）切换主要有两条信令路径：**Xn 切换**与 **N2 切换**。许多工程师对 Xn 切换已经很熟悉——因为它在 gNB 之间直连完成、控制面不经核心网，时延低、流程简洁。但一旦 Xn 接口不可用、跨跟踪区（TA）、跨 AMF、或源/目标 gNB 属不同厂商且未建立 Xn，网络就必须回退到 **N2 切换**（也称 NGAP 切换、核心网控制切换）。

N2 切换的特殊之处在于：**AMF 始终处于控制面信令路径上**，负责协调源 gNB、目标 gNB、SMF、UPF 四个网元完成切换准备、数据转发与路径切换。它的信令跳数更多、涉及的 IE 更复杂，也因此成为 5G 切换中最容易出问题、最考验对协议理解深度的流程。

本文依据 **3GPP TS 23.502 V18.10.0 第 4.9.1.3 节**（N2-based Handover）和 **TS 38.413 V18.x（NGAP）** 第 8.2 节（Handover Preparation）、第 9 节（消息与 IE 定义）逐消息拆解这一流程，并给出抓包识别与排错方法。

> 子域计算说明：今日为 2026-07-07，`date +%j` = 188，今日索引 = (188 + 1 − 1) % 6 = 2，对应 **protocols（协议与信令）** 子域。

## 二、触发条件与决策前提

N2 切换的起点和 Xn 切换一样，都源于 **UE 的 RRC 测量上报**。源 gNB 通过 RRC Reconfiguration 给 UE 下发测量配置，UE 周期性或事件触发地上报 `MeasurementReport`。最常见的事件是 **A3 事件**（邻区信号质量比服务小区好一个偏置），其次是 A2（服务小区差于门限）、A4（邻区好于门限）、A5（服务小区变差且邻区变好）。

源 gNB 收到测量报告后，会做一次"切换判决"，判决结果决定了走哪条路径：

1. 检查是否存在到目标小区的 **Xn 接口**；
2. 检查是否 **跨 AMF**（目标小区归属的 AMF 与当前 AMF 不同）；
3. 检查 Xn 接口是否允许承载本次切换（例如是否需要变更 UPF 锚点、是否同 TA）。

当上述任一条件不满足时，源 gNB 不走 Xn，而是发起 **N2 切换**。也就是说，N2 切换是一种"兜底但更通用"的切换方式，它不依赖 gNB 之间的 Xn 接口，兼容性最强，但代价是控制面时延更高。

设计上之所以保留 N2 切换作为通用方案，是因为 5G 网络部署初期或异厂商组网场景下，Xn 接口并不总是就绪；同时跨 AMF 切换（如跨大区 AMF 池）必须由核心网主导。N2 切换让移动性管理 **不依赖于 RAN 之间的全互联接口**，保证了网络演进过程中的平滑过渡。

## 三、完整信令时序图（N2 切换，源/目标同 AMF 场景）

下图为最常见的"N2 切换且不更换 AMF"场景的端到端信令流（依据 TS 23.502 §4.9.1.3.2）：

```mermaid
sequenceDiagram
    participant UE
    participant SG as 源gNB
    participant AMF
    participant SMF
    participant UPF
    participant TG as 目标gNB
    UE->>SG: RRC MeasurementReport (Event A3)
    SG->>AMF: ① NGAP HANDOVER REQUIRED
    Note over AMF: 选择目标侧 / 确定 PDU 会话归属 SMF
    AMF->>SMF: ② Nsmf_PDUSession_UpdateSMContext (HO Prepare)
    SMF->>UPF: ③ N4 Session Modification (分配/更新转发隧道)
    SMF-->>AMF: ④ Nsmf_PDUSession_UpdateSMContext Response (N2 SM Info)
    AMF->>TG: ⑤ NGAP HANDOVER REQUEST
    Note over TG: 准入控制 / 分配无线资源与 N3 DL TEID
    TG-->>AMF: ⑥ NGAP HANDOVER REQUEST ACKNOWLEDGE
    AMF->>SMF: ⑦ Nsmf_PDUSession_UpdateSMContext (HO Prepared)
    SMF->>UPF: ⑧ N4 Session Modification (源侧转发隧道)
    AMF->>SG: ⑨ NGAP HANDOVER COMMAND
    SG->>UE: ⑩ RRC Reconfiguration (含 HO Command)
    Note over SG,UPF: 开始下行数据转发（直接/间接）
    UE->>TG: ⑪ Random Access + RRCReconfigurationComplete
    TG->>AMF: ⑫ NGAP HANDOVER NOTIFY
    AMF->>SMF: ⑬ Nsmf_PDUSession_UpdateSMContext (HO Completed)
    SMF->>UPF: ⑭ N4 Session Modification (切换 DL 路径, 发 End Marker)
    AMF->>SG: ⑮ NGAP UE CONTEXT RELEASE COMMAND
    SG-->>AMF: ⑯ NGAP UE CONTEXT RELEASE COMPLETE
    Note over SMF,UPF: 定时器到期后释放转发隧道
```

整个流程分为三个清晰的阶段：**准备（Preparation）** = 消息 ①–⑨；**执行（Execution）** = 消息 ⑩–⑪；**完成（Completion）** = 消息 ⑫–⑯。下面逐消息解析关键 IE。

## 四、准备阶段逐消息 IE 解析

### ① NGAP HANDOVER REQUIRED（源 gNB → AMF）

这是 N2 切换的起点，源 gNB 在这条消息里把"UE 是谁、要去哪、带什么资源、怎么加密"一次性告诉 AMF。依据 TS 38.413 §9.x，关键 IE 如下：

| IE 名称 | 含义 | 作用说明 |
|---------|------|---------|
| `AMF UE NGAP ID` | AMF 分配的 UE 标识 | 关联 AMF 中已存在的 UE NGAP 上下文 |
| `RAN UE NGAP ID` | 源 gNB 分配的 UE 标识 | 关联源 gNB 的 UE 上下文 |
| `Handover Type` | 切换类型 | 取值 `intra5gs` / `fivegs-to-eps` / `eps-to-fivegs` / `fivegs-to-utran` |
| `Cause` | 触发原因 | 典型如 `radio network layer`，`handover-desirable-for-radio-reasons` |
| `SourceToTarget-TransparentContainer` | 源→目标透明容器 | 携带目标小区所需的小区 ID、UE 无线能力、源 AS 安全与无线配置 |
| `PDU Session Resource Setup List HO Req` | 待切换 PDU 会话资源列表 | 含 PDU Session ID、N2 SM Info（QoS 流、UL 隧道） |
| `UE Security Context` | UE 安全上下文 | 含接入层算法、下一跳密钥推导材料 |
| `Allowed NSSAI` | 允许的网络切片 | 目标 gNB 据此做切片级资源管理 |

其中 **`SourceToTarget-TransparentContainer`** 是"透明容器"——AMF 不解析其内容，只原样透传给目标 gNB。容器内部由源 gNB 按 TS 38.413 §9.3.1.x 编码，包含目标小区 ID、UE 的 RRC/无线能力、源 AS 安全配置、用于生成目标侧 AS 密钥的 `nextHopChainingCount`（NCC）等信息。这一点和 Xn 切换的容器机制一致，但在 N2 切换中容器要"绕一圈"经 AMF 转发。

### ②③④ AMF→SMF→UPF 的 N2 SM 信息传递

AMF 收到 HANDOVER REQUIRED 后，**不会直接去问目标 gNB**，而是先为每个待切换的 PDU 会话联系其归属 SMF。AMF 向 SMF 发送 `Nsmf_PDUSession_UpdateSMContext Request`，其中的 `Operation` 标志为 **HO Prepare**，并携带从透明容器中拆出的 N2 SM 信息。

SMF 随后通过 **N4 Session Modification** 与 UPF 交互：
- 决定采用直接转发还是间接转发；
- 如为间接转发，向 UPF 请求分配转发隧道的 F-TEID；
- 准备好给目标 gNB 用的 **N3 上行（UL）F-TEID**（UPF 侧接收隧道）。

SMF 在 ④ 的 Response 中把"N3 UL 隧道 + 转发隧道信息（若有）"打包成新的 **N2 SM Info** 回给 AMF。这一步是 N2 切换区别于 Xn 切换的关键：**核心网在准备阶段就参与用户面资源编排**，而不像 Xn 切换那样只在最后做 Path Switch。

### ⑤ NGAP HANDOVER REQUEST（AMF → 目标 gNB）

AMF 现在集齐了所有信息，向目标 gNB 发起资源请求。这条消息（TS 38.413 §9.2.x）携带：

```mermaid
graph TD
    A[NGAP HANDOVER REQUEST] --> B1[AMF UE NGAP ID 新分配]
    A --> B2[Handover Type]
    A --> B3[SourceToTarget-TransparentContainer 透传]
    A --> B4[PDU Session Resource Setup List]
    A --> B5[UE Aggregate Maximum Rate]
    A --> B6[UE Security Context / Security Key]
    A --> B7[Allowed NSSAI]
    A --> B8[Trace Activation 可选]
    B4 --> D1[PDU Session ID]
    B4 --> D2[N2 SM Information]
    D2 --> E1[PDU Session Type / S-NSSAI]
    D2 --> E2[QoS Flow Setup Request List<br/>含 5QI, ARP, GFBR/MFBR]
    D2 --> E3[UL NG-U UP TNL Information<br/>UPF 分配的 N3 UL F-TEID]
    B6 --> F1[AS 算法 / NH / NCC]
```

目标 gNB 收到后执行**准入控制（Admission Control）**：判断无线资源是否够、QoS 流能否满足、切片是否允许。若全部通过，目标 gNB 为 UE 预留 DRB/SRB、分配 **N3 下行（DL）F-TEID**（目标 gNB 侧接收隧道），并构造 `TargetToSource-TransparentContainer`。

### ⑥ NGAP HANDOVER REQUEST ACKNOWLEDGE（目标 gNB → AMF）

目标 gNB 在 ⑥ 中回送准备结果，关键 IE：`PDU Session Resource Admitted List`（被接纳的会话与 QoS 流）、`TargetToSource-TransparentContainer`（含目标侧无线配置、给 UE 的 HO Command 载荷）、以及可选的 `Data Forwarding Request`（请求建立转发隧道的地址）。

### ⑦⑧⑨ 准备收尾：转发隧道建立与命令下发

AMF 再次通过 ⑦ 通知 SMF 准备完成（HO state = Prepared），SMF 经 ⑧ 在源 UPF 侧建立转发隧道。最终 AMF 把目标侧容器与转发响应打包，通过 **⑨ NGAP HANDOVER COMMAND** 下发给源 gNB。源 gNB 从容器中提取出给 UE 的 RRC 切换命令载荷，进入执行阶段。

## 五、执行阶段与完成阶段

### ⑩⑪ 执行：UE 切到目标小区

源 gNB 通过 **RRC Reconfiguration** 把切换命令发给 UE，UE 立即断开源小区、在目标小区发起随机接入。源 gNB 在此期间开始**下行数据转发**：

- **直接转发（Direct Forwarding）**：源 gNB 通过 Xn-U（如果存在）或直连隧道把下行数据送到目标 gNB；
- **间接转发（Indirect Forwarding，TS 23.502 §4.9.1.3.3）**：源 gNB →（源）UPF → 目标 gNB，适用于无 Xn-U 的场景。

UE 在目标小区完成随机接入并发送 `RRCReconfigurationComplete`，切换的用户面就此打通。

### ⑫–⑯ 完成：路径切换与源资源释放

目标 gNB 检测到 UE 接入成功，通过 **⑫ NGAP HANDOVER NOTIFY** 告知 AMF。AMF 随即通过 **⑬** 通知 SMF（HO state = Completed），SMF 经 **⑭ N4 Session Modification** 指示 UPF：将下行路径从源 gNB 切换到目标 gNB，并向旧路径发送 **End Marker** 包——这是 GTP-U 的关键标志包，告诉源 gNB"后续无更多下行数据，可以释放缓存"。

最后，AMF 向源 gNB 发 **⑮ NGAP UE CONTEXT RELEASE COMMAND**，源 gNB 释放无线与 UE 上下文后回 **⑯ COMPLETE**。SMF 在一个定时器到期后释放临时建立的转发隧道，整个 N2 切换闭环。

## 六、N2 切换的状态机视角

从 NGAP/AMF 角度看，UE 的切换经历如下状态转换（无 `style` 语句，保证 mermaid 渲染）：

```mermaid
stateDiagram-v2
    [*] --> RRC_CONNECTED
    RRC_CONNECTED --> HO_PREPARING: 源gNB 发 HANDOVER REQUIRED
    HO_PREPARING --> HO_PREPARED: 目标gNB 发 HANDOVER REQ ACK
    HO_PREPARING --> HO_PREP_FAILED: 目标拒绝或资源不足
    HO_PREP_FAILED --> RRC_CONNECTED: 发 Preparation Failure / 保持
    HO_PREPARED --> HO_EXECUTING: AMF 发 HANDOVER COMMAND
    HO_EXECUTING --> HO_COMPLETED: 目标gNB 发 HANDOVER NOTIFY
    HO_EXECUTING --> HO_FAILED: 定时器超时 / UE 未接入
    HO_FAILED --> RRC_CONNECTED: RRC Reestablishment 重建
    HO_COMPLETED --> [*]: UE CONTEXT RELEASE
```

注意 **HO_PREP_FAILED** 与 **HO_FAILED** 是两个不同的失败点：前者发生在准备阶段（目标 gNB 拒绝），通常回退到 RRC_CONNECTED 继续服务或重选目标；后者发生在执行阶段（UE 没有成功接入目标），需要依赖 **RRC 连接重建**恢复，影响较大。

## 七、N2 切换 vs Xn 切换对比

下表把两者放在同一框架下对比，帮助快速判断现网中应走哪条路径：

| 维度 | N2 切换（NGAP） | Xn 切换 |
|------|----------------|---------|
| 信令路径 | 经 AMF（N2 接口） | gNB 间直连（Xn-C） |
| 准备阶段 AMF 参与 | 是 | 否（仅完成阶段走 Path Switch Request） |
| SMF/UPF 准备阶段参与 | 是（编排转发隧道） | 否 |
| 控制面时延 | 较高（多跳） | 较低（直连） |
| UPF 锚点变化 | 可变（跨 SMF 场景） | 通常不变 |
| 适用场景 | 无 Xn / 跨 TA / 跨 AMF / 异厂商 / UPF 锚点变更 | 有 Xn、同 AMF、同 TA |
| 数据转发 | 直接或间接（经 UPF） | 直接（Xn-U） |
| 路径切换触发方 | AMF 通知 SMF | 目标 gNB 发 Path Switch Request |
| 失败影响 | 准备失败可重选目标，影响较小 | 执行失败需 RRC 重建 |

一个经验法则：**优先 Xn，回退 N2**。现网中 Xn 切换占比通常在 90% 以上，但 N2 切换是保证覆盖连续性与异厂商互通的"安全网"。

## 八、抓包识别：如何在 pcap 中认出 N2 切换

用 Wireshark/TShark 打开 N2 接口（SCTP over IP，PPID=60，端口 38412）的抓包，N2 切换的特征序列非常明显：

1. **过滤 NGAP 切换消息**：`ngap.procedureCode == 15 && ngap.initiatingMessage`（Handover Preparation）；`ngap.procedureCode == 16`（Handover Notification）；`ngap.procedureCode == 18`（UE Context Release）。
2. **匹配 UE**：用 `AMF UE NGAP ID` 把整条切换链串起来。注意 HANDOVER REQUEST 会**重新分配** AMF UE NGAP ID（目标侧新 ID），抓包时要同时关注新旧两个 ID 的映射。
3. **判断是否 N2 而非 Xn**：如果切换准备消息出现在 **N2（SCTP 38412）** 接口上，就是 N2 切换；如果只看到 XnAP（SCTP 38422）的 HO Request/ACK，则是 Xn 切换。
4. **看 N2 SM Info**：在 HANDOVER REQUEST 里展开 `PDU Session Resource Setup List HO Req → N2 SM Information`，可看到 QoS 流列表和 UPF 分配的 N3 UL F-TEID，验证核心网是否正确参与了资源编排。
5. **N4 侧验证**：在 SBI/HTTP2 或 N4（GTP-C/PFCP）抓包中，搜索 `Operation` 字段为 `HO Prepare / HO Complete` 的 `Nsmf_PDUSession_UpdateSMContext` 请求，对应准备与完成两个时点。

## 九、常见故障点与排错思路

1. **目标 gNB 拒绝（HANDOVER PREPARATION FAILURE）**：常见原因是目标小区拥塞或切片资源不足。检查 Cause IE（如 `radio-resources-not-available`），并核对 `Allowed NSSAI` 是否与目标小区签约切片一致。
2. **准备成功但执行失败（UE 不接入目标）**：多半是 `TargetToSource-TransparentContainer` 中的无线配置有误，或目标小区 SSRB/DRB 参数与 UE 能力不匹配。需结合 UE 侧日志确认随机接入是否发生、是否 RRC 重建。
3. **切换完成但下行数据中断**：检查 ⑭ 的 N4 Session Modification 是否成功切换 DL 路径、End Marker 是否正确发出。若间接转发隧道未及时释放，可能造成短暂的重复投递或乱序。
4. **跨 AMF 切换失败**：N2 切换支持跨 AMF（源 AMF → 目标 AMF 的 Namf_Communication_CreateUEContext）。跨 AMF 场景下 ID 映射更复杂，需核对 UE Context 是否完整迁移，尤其是安全上下文与 PDU 会话上下文。
5. **定时器超时**：若目标 gNB 在执行阶段定时器内未收到 HANDOVER NOTIFY，会触发 HO_FAILED。排查目标侧准入与无线覆盖是否满足。
## 常见问题

**Q1：N2 切换和 Xn 切换的根本区别是什么？**
A：根本区别在于**控制面信令路径**。Xn 切换由 gNB 之间直接协商，AMF 只在最后通过 Path Switch Request 更新核心网路径；N2 切换则由 AMF 主导，准备阶段就要协调 SMF/UPF 编排转发隧道。因此 N2 时延更高，但通用性更强（不依赖 Xn、支持跨 AMF）。

**Q2：什么情况下网络一定走 N2 切换？**
A：三种典型情形：①源/目标 gNB 之间无 Xn 接口；②目标小区归属不同 AMF；③需要变更 UPF 锚点的跨 TA 切换。此外异厂商组网中 Xn 未互通时也强制走 N2。

**Q3：透明容器（Transparent Container）为什么不让 AMF 解析？**
A：容器内是 RAN 私有的无线配置与安全信息，AMF 不需要也不应该理解其细节。让 AMF 透传既保证了 RAN 实现的灵活性（不同厂商可扩展私有内容），又避免核心网与 RAN 协议耦合。AMF 只关心"从哪来、到哪去"。

**Q4：数据转发的"直接"和"间接"如何选择？**
A：当源/目标 gNB 间存在 Xn-U 接口时优先直接转发（源 gNB 直接把下行包送给目标 gNB），时延低；当没有 Xn-U 时走间接转发（经 UPF 中转，TS 23.502 §4.9.1.3.3），由 SMF 在 N4 上建立临时转发隧道。SMF 根据网络拓扑自动判决。

**Q5：N2 切换失败后 UE 会怎样？**
A：要分阶段看。**准备阶段失败**通常回退 RRC_CONNECTED，源小区继续服务，UE 几乎无感；**执行阶段失败**（UE 收到 HO Command 却没接入目标）则需触发 RRC 连接重建，可能造成短暂业务中断，是排错重点。

## 参考来源

1. [3GPP TS 23.502 V18.10.0 — Procedures for the 5G System](https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/18.10.00_60/ts_123502v181000p.pdf) — §4.9.1.3 N2-based Handover（§4.9.1.3.2 normal / §4.9.1.3.3 indirect forwarding）
2. [3GPP TS 38.413 — NG-RAN; NG Application Protocol (NGAP)](https://www.3glteinfo.com/messages/5g/ngap/) — §8.2 Handover Preparation、§9 消息与 IE 定义（HANDOVER REQUIRED / HANDOVER REQUEST / HANDOVER COMMAND / HANDOVER NOTIFY）
3. [5G SA Inter-gNB Handover | NGAP Handover — Techplayon](https://www.techplayon.com/5g-sa-inter-gnb-handover-n2-or-ngap-handover/) — N2 切换分步流程与触发条件解读
4. [N2 Handover Procedure — Cisco UCC 5G AMF Config Guide](https://www.cisco.com/c/en/us/td/docs/wireless/ucc/amf/2022-01/config-and-admin/b_ucc-5g-amf-config-and-admin-guide_2022-01/m_N2handover_withoutAMFchange.pdf) — N2 切换不更换 AMF 场景的工程实现
5. [5G NR Handover Explained — Xn/N2 Call Flow, Events, Failures & KPIs — Cafetele](https://www.cafetele.com/articles/article-5g-nr-handover-xn-n2.html) — Xn/N2 对比、测量事件与失败处理

---
> 本文由「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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
