首页 › protocols › 5G N2接口切换信令全链拆解

5G N2接口切换（NG-based Handover）信令全链拆解

聚焦 3GPP TS 23.502 §4.9.1.3（NG-based Handover，含 4.9.1.3.2 准备阶段 / 4.9.1.3.3 执行阶段）与 TS 38.413 NGAP 消息定义，逐步拆解从测量报告到路径切换、上下文释放的完整信令链。

一、为什么需要 N2 切换：与 Xn 切换的本质差异

在 5G SA 组网中，UE 在 RRC_CONNECTED 状态下的站间移动主要依赖两种切换：Xn-based Handover 与 NG(N2)-based Handover。前者已经在我们此前的《5G Xn接口切换信令全链拆解》中拆解过，本文聚焦后者。

N2 切换并非 Xn 切换的"低配版"，而是覆盖了 Xn 切换无法触达的一整类场景。当一个 UE 从源 gNB 移动到目标 gNB，但两者之间没有 Xn 接口、或 Xn 接口被运维策略显式禁止用于切换（XnHO not permitted）、或目标 gNB 隶属于不同的 AMF Pool / 不同 UPF 服务区时，源 gNB 就必须把切换决策"上交"给核心网，由 AMF 作为信令中介完成协调。这与 LTE 时代的 S1 切换在思想上完全同构——TS 23.502 把它定义为 NG-based handover，而 RAN 侧重称其为 N2/NGAP Handover。

其本质特征可概括为三点：

AMF 居中协调：源 gNB 与目标 gNB 之间没有直接信令，所有切换准备消息都必须经 AMF 转一手，AMF 同时承担"会话资源准备"的指挥（与 SMF 通过 SBI 交互）。
信令跳数多、时延高：相对 Xn 切换的 RAN-to-RAN 直连，N2 切换每条准备消息都要穿越 NG-C 接口到达 AMF，AMF 还要拆解 PDU Session 逐条下发给 SMF。所以 N2 切换的切换中断时延（HO interruption）通常显著大于 Xn 切换。
支持 AMF 重定位（AMF Relocation）：当目标 gNB 不在源 AMF 的服务区内时，源 AMF 会基于 AMF Selection Function 选定一个目标 AMF，并通过 Namf_Communication_CreateUEContext 把完整 UE 上下文搬过去，目标 AMF 成为新的 serving AMF。

需要强调：N2 切换不要求源/目标 gNB 同 AMF、同 UPF。源/目标 gNB 可分别连接到不同的 AMF 与不同的 UPF，这正是它能在跨 Pool、跨厂家组网中广泛使用的原因。

二、整体架构与角色定义

在拆解信令前，先把参与角色与缩写钉死（沿用 free5GC 文章与 TS 23.502 的命名）：

缩写	含义	在 N2 切换中的职责
S-NG-RAN	源 gNB	触发切换决策，发出 Handover Required，做 RRC Reconfiguration，转发缓存数据
T-NG-RAN	目标 gNB	准入控制，分配目标侧无线资源，返回 Target-to-Source 透明容器
S-AMF	源 AMF	接收 Handover Required，决定是否选目标 AMF，向 SMF 发起会话更新
T-AMF	目标 AMF（可选）	AMF 重定位时承接 UE 上下文，向目标 gNB 发 Handover Request
SMF	会话管理功能	决定是否插入/重选中间 UPF，分配 N3/N9 隧道信息
PSA UPF	PDU Session Anchor	锚点 UPF，下行数据起点；切换后路径切换由它执行 end marker
S-UPF / T-UPF	源/目标（中间）UPF	用于间接转发的中间 UPF

三、准备阶段（Preparation Phase）完整时序

下图基于 TS 23.502 §4.9.1.3.2，绘制含 AMF 重定位的完整准备阶段（不重定位时跳过 Step 3/12 的 CreateUEContext）：

sequenceDiagram
    autonumber
    participant UE
    participant S as 源 gNB (S-NG-RAN)
    participant SAMF as 源 AMF (S-AMF)
    participant TAMF as 目标 AMF (T-AMF)
    participant SMF
    participant UPF as PSA/中间 UPF
    participant T as 目标 gNB (T-NG-RAN)

    Note over UE,T: Step 0~1: 测量报告触发切换决策
    UE->>S: MeasurementReport (A3事件)
    S->>S: 切换决策，选定目标 gNB

    Note over S,TAMF: Step 1: Handover Required
    S->>SAMF: Handover Required (Target ID + S2T透明容器 + PDU Session列表 + 直转可用指示)

    Note over SAMF,TAMF: Step 2~3: AMF 选择 + 上下文搬迁（可选）
    SAMF->>SAMF: AMF Selection Function 选定 T-AMF
    SAMF->>TAMF: Namf_Communication_CreateUEContext Request (完整UE上下文)

    Note over TAMF,UPF: Step 4~7: 会话资源准备
    TAMF->>SMF: Nsmf_PDUSession_UpdateSMContext Request (每个PDU Session)
    SMF->>UPF: N4 Session Establishment/Modification
    Note over SMF,UPF: 若UE移出当前UPF服务区，SMF插入/重选中间UPF
    UPF-->>SMF: CN Tunnel Info (N3 UL / N9 DL)
    SMF-->>TAMF: Nsmf_PDUSession_UpdateSMContext Response (N2 SM信息)

    Note over TAMF,T: Step 9~10: 目标侧资源准备
    TAMF->>T: Handover Request (S2T容器 + N2 SM列表 + 安全上下文 + 移动限制列表)
    T->>T: 准入控制（Admission Control）
    T-->>TAMF: Handover Request Acknowledge (T2S容器 + 已接纳PDU Session + N3 AN Tunnel + 转发隧道地址)

    Note over TAMF,SAMF: Step 11~12: 转发隧道协商 + 回送
    TAMF->>SMF: 转发 T-RAN N2 SM响应（每个PDU Session）
    SMF->>UPF: 配置源/目标转发隧道（间接转发时）
    SMF-->>TAMF: DL 转发隧道信息
    TAMF-->>SAMF: Namf_Communication_CreateUEContext Response (T2S容器 + DL转发信息)

四、准备阶段关键消息与 IE 逐条拆解

Step 1：`Handover Required`（源 gNB → 源 AMF）

这是 N2 切换的起点，对应 NGAP 消息 HandoverRequired（TS 38.413 §9.2.1.x）。源 gNB 在这条消息里"声明"它要把 UE 切给谁、切哪些会话。关键 IE 如下：

graph TD
    HR["Handover Required"] --> A["AMF UE NGAP ID"]
    HR --> B["RAN UE NGAP ID"]
    HR --> C["Handover Type<br/>5GS-to-5GS / 5GS-to-EPS"]
    HR --> D["Cause<br/>e.g. handover-desirable-for-radio-reason"]
    HR --> E["Target ID<br/>(目标gNB ID + Cell ID)"]
    HR --> F["Source to Target<br/>Transparent Container"]
    HR --> G["PDU Session Resource<br/>to be Setup List"]
    HR --> H["Direct Forwarding Path<br/>Availability"]
    F --> F1["UE上下文 / RAN信息<br/>为转发的QoS Flow列表"]
    G --> G1["PDU Session ID<br/>+ N2 SM Information"]

Target ID：标识目标 gNB 及目标小区，AMF 据此做 AMF 选择与寻址。
Source to Target Transparent Container：源 RAN 打包的"给目标 RAN 看的"上下文，核心网不解析其内容，原样转发。这是 3GPP 一贯的"透明容器"设计——把厂商私有的 RAN 上下文隔离在 RAN 之间，避免核心网成为 RAN 实现细节的耦合点。
Direct Forwarding Path Availability：指示源 gNB 是否具备到目标 gNB 的直连 IP 可达性，决定后续走直接转发还是间接转发。
PDU Session Resource to be Setup List：列出本次切换涉及的全部 PDU Session 及其 N2 SM 信息（已建立的 QoS Flow 列表、上行隧道等）。

Step 2~3：AMF 选择与上下文搬迁

源 AMF 收到 Handover Required 后，会判断目标 gNB 是否落在自己的服务区。若不在，则触发 AMF 重定位：

基于 AMF Selection Function（TS 23.501 §6.3.5），按目标 gNB 的 GUAMI / AMF Set 指向，选定 T-AMF。
通过 SBI 服务 Namf_Communication_CreateUEContext 把完整 UE 上下文（签约数据、移动限制列表、安全上下文、PDU Session 上下文、PEI 等）从 S-AMF 搬到 T-AMF。

设计要点：搬迁的是完整上下文而非增量，这样 T-AMF 才能在后续作为新的 serving AMF 独立工作。这也是为何 AMF 重定位场景的 N2 切换信令最重。

若源 AMF 仍可服务目标区域（intra-AMF），Step 3 直接跳过，S-AMF 同时扮演 T-AMF。

Step 4~7：会话资源准备（SMF 主导）

T-AMF（或兼任的 S-AMF）对每个 PDU Session 调用 Nsmf_PDUSession_UpdateSMContext Request，把目标侧信息（Target ID、N2 SM 信息）传给 SMF。SMF 这里要做两个关键判断：

目标 gNB 是否在当前 UPF 服务区内？ 若 UE 已移动出当前 UPF（PSA 之外的中间 UPF）的服务范围，SMF 会插入新的中间 UPF（T-UPF）或重选中间 UPF，并在 PSA 与 T-UPF 之间建立 N9 隧道、在 T-UPF 与目标 gNB 之间建立 N3 隧道。
分配隧道信息：SMF 通过 N4 Session Establishment/Modification 从 UPF 拿到 N3 侧的 UP 地址与上行 CN Tunnel ID，回填到 N2 SM 信息中。

最终 SMF 通过 Nsmf_PDUSession_UpdateSMContext Response 把 N2 SM 信息（N3 UL 隧道、QoS 参数、安全执行信息、转发可用性）回给 T-AMF。

Step 9：`Handover Request`（T-AMF → 目标 gNB）

这是 NGAP 消息 HandoverRequest。T-AMF 把汇集好的所有 PDU Session 的 N2 SM 信息、安全上下文（K~gNB~、NH、安全算法）、移动限制列表（Mobility Restriction List）、UE Radio Capability（或 RACS 的 Capability ID）连同透明容器一起发给目标 gNB。目标 gNB 据此做准入控制（Admission Control）：评估是否有无线资源接纳该 UE 的全部 QoS Flow。

Step 10：`Handover Request Acknowledge`（目标 gNB → T-AMF）

准入成功后，目标 gNB 返回 HandoverRequestAcknowledge，携带：

Target to Source Transparent Container：目标 gNB 打包的"给源 RAN 看的"配置——本质就是目标侧为 UE 准备的 RRC Reconfiguration 内容（目标小区 ID、新 C-RNTI、dedicated rach-Config、目标侧安全算法等）。源 gNB 将其透传给 UE。
已成功准备的 PDU Session 列表（含 N3 AN Tunnel Info）。
准备失败的 PDU Session 列表及原因。
数据转发隧道地址（若目标 gNB 支持转发）。

Step 11~12：转发隧道协商与回送

T-AMF 把目标 gNB 的 N2 SM 响应回送各 SMF。SMF 据此配置源/目标侧的数据转发隧道：

直接转发：SMF 把目标 gNB 在 Step 10 给的 N3 转发地址直接下发给源侧。
间接转发：在源 UPF（或专门的转发 UPF）与目标 gNB 之间，经由一个转发 UPF 中转，SMF 需要建立额外 N4 隧道。

最后 T-AMF 通过 Namf_Communication_CreateUEContext Response 把 T2S 透明容器、DL 转发信息回送给 S-AMF，准备阶段结束。

五、执行阶段（Execution Phase）完整时序

下图基于 TS 23.502 §4.9.1.3.3：

sequenceDiagram
    autonumber
    participant UE
    participant S as 源 gNB
    participant SAMF as 源 AMF
    participant TAMF as 目标 AMF
    participant SMF
    participant UPF as PSA/中间UPF
    participant T as 目标 gNB

    Note over S,UE: Step 1~2: 下发切换命令
    SAMF->>S: Handover Command (T2S容器 + 转发地址 + 失败PDU列表)
    S->>UE: RRC Reconfiguration (= Handover Command, 含目标小区配置)

    Note over S,T: Step 2a~2c: PDCP状态保序
    S->>SAMF: Uplink RAN Status Transfer (各DRB的PDCP SN)
    SAMF->>TAMF: 转发(AMF重定位时)
    TAMF->>T: Downlink RAN Status Transfer

    Note over S,T: Step 3: 数据转发启动
    S->>T: 下行缓存数据转发(直转/间转)
    UE->>UPF: 上行数据(经目标gNB→T-UPF→PSA)

    Note over UE,T: Step 4~5: 目标侧接入完成
    UE->>T: RACH (基于rach-ConfigDedicated)
    UE->>T: RRC Reconfiguration Complete (= Handover Confirm)
    T->>TAMF: Handover Notify (UE位置/TAI)

    Note over TAMF,SMF: Step 6~11: 路径切换
    TAMF->>SAMF: Namf_Communication_N2InfoNotify (AMF重定位时,启动S-RAN释放定时器)
    TAMF->>SMF: Nsmf_PDUSession_UpdateSMContext Request (Handover Complete指示)
    SMF->>UPF: 切换用户面路径 + 发送End Marker(经旧N3隧道)
    SMF-->>TAMF: Nsmf_PDUSession_UpdateSMContext Response

    Note over UE,S: Step 12~14: 源侧清理
    UE->>UE: (条件)发起Mobility Registration Update
    SAMF->>S: UE Context Release Command
    S-->>SAMF: UE Context Release Complete
    SMF->>UPF: 释放源UPF/转发隧道资源(转发定时器到期后)

执行阶段的关键在于保序（in-order delivery）与无损（lossless）。三件事支撑了这一点：

RAN Status Transfer（Step 2a~2c）：源 gNB 把每个 DRB 的 PDCP 上行/下行接收/发送状态（SN、HFN）通过 UplinkRANStatusTransfer 发给 AMF，AMF 再以 DownlinkRANStatusTransfer 转给目标 gNB。目标 gNB 据此知道"哪些 PDCP SN 已经发过、哪些还要发"，避免重复与乱序。这条消息对 RAN 是透明的——AMF 仅搬运 RANStatusTransfer-TransparentContainer。
数据转发（Step 3）：源 gNB 把尚未确认的下行 PDCP PDU 转发到目标侧（直接或经转发 UPF），UE 在目标侧重排序。
End Marker（路径切换时）：PSA UPF 在旧 N3 隧道发送 End Marker，目标 gNB 收到 End Marker 后就知道"旧路径数据已到尽头"，可以放心把重排序缓冲区的内容按序投递。

Handover Notify（Step 5）是 RAN 侧确认切换成功的标志，触发随后的用户面路径切换。AMF 收到 Notify 后，会向 SMF 携带 Handover Complete 指示，SMF 完成 PSA 到目标 gNB（或 T-UPF）的路径切换。若发生 AMF 重定位，T-AMF 会通过 Namf_Communication_N2InfoNotify 通知 S-AMF，S-AMF 启动一个定时器，到期后释放源 gNB 的 UE 上下文（Step 14 的 UEContextReleaseCommand）。

最后，若切换使 UE 离开了原注册区（Registration Area），UE 会发起 Mobility Registration Update（Step 12），这是 N2 切换常见的"尾随信令"，需在排错中加以识别。

六、UE 与 gNB 侧状态转换

stateDiagram-v2
    [*] --> RRC_CONNECTED: 接入网络
    RRC_CONNECTED --> HO_Preparation: Handover Required发送
    HO_Preparation --> HO_Execution: 收到Handover Command
    HO_Execution --> Sync_Target: RACH(目标小区)
    Sync_Target --> HO_Done: RRC Reconfig Complete
    HO_Done --> RRC_CONNECTED: 目标gNB驻留
    RRC_CONNECTED --> RRC_INACTIVE: 挂起(另一流程)
    RRC_INACTIVE --> [*]
    note right of HO_Preparation
        源gNB仍持有上下文
        目标gNB已准备资源
    end note
    note right of HO_Execution
        UE尚未接入目标
        数据转发进行中
    end note

从 gNB 视角看，源 gNB 在 Step 1（Handover Required）后并不立即释放资源，而是在收到 UEContextReleaseCommand 前保持上下文并持续转发，这是切换中断期内数据不丢的根基。

七、数据转发：直接 vs 间接

维度	直接转发（Direct）	间接转发（Indirect）
路径	源 gNB → 目标 gNB（经 Xn/或 IP 直连）	源 gNB → 转发UPF（或源UPF）→ 目标 gNB
前提	源/目标 gNB 间 IP 可达 + 安全关联	直接路径不可达时
SMF 介入	轻，仅下发隧道地址	重，需额外 N4 隧道建立
信令开销	低	高
典型场景	同 Pool、同厂家	跨厂家、跨 IP 域、无 Xn

设计上，TS 23.502 把转发决策权交给 SMF：它综合判断 Handover Required 的 Direct Forwarding Path Availability、UPF 服务区与隧道可达性后，选择最合适的转发方式。直接转发可与时延敏感的转发需求对齐，间接转发则保证在无直连时切换仍可完成。

八、设计意图分析

为什么 N2 切换要把 AMF 推到信令中央？三个底层动机：

解耦 RAN 与会话管理。Xn 切换把路径切换推迟到执行后（Path Switch Request），是因为它假定"AMF/UPF 不变"。而 N2 切换从一开始就可能涉及 AMF/UPF 变更，必须在准备阶段就让 SMF 介入，确保目标侧隧道就绪后再让 UE 接入。把协调权交给 AMF，使 RAN 无需感知核心网拓扑变化。
透明容器隔离实现细节。Source to Target / Target to Source Transparent Container 让核心网只做"信使"，不感知厂商 RRC 细节，保证了多厂家互操作。
Status Transfer + End Marker 实现 PDCP 无损。这是从 LTE 时代继承的成熟范式，在 AMF 居中场景下通过 Uplink/Downlink RAN Status Transfer 把状态"搬"过去。

九、抓包识别与排错实战

如何在 Wireshark 中识别 N2 切换？

过滤 NGAP：ngap.procedureCode == 10（即 HandoverPreparation）或 ngap.procedureCode == 11（HandoverResourceModification）、ngap.procedureCode == 13（HandoverNotification）。ngap.procedureCode == 26 对应 UEContextRelease。
用 ngap.RAN_UE_NGAP_ID == <id> 锁定单个 UE 的全程信令。
注意：N2 切换中不会出现 XnAP 的 HandoverRequest/HandoverRequestAcknowledge；若抓包里看到 NGAP 的 HandoverRequired → HandoverRequest（经 AMF）而非 XnAP，即可确认是 N2 切换而非 Xn 切换。

常见故障点与排错思路：

故障现象	可能原因	排查方向
`HandoverRequired` 后无 `HandoverRequest`	AMF 选不到 T-AMF / AMF Set 配置错误	检查 AMF Selection 配置、GUAMI 广播
目标 gNB 回 `Handover Preparation Failure`	准入失败 / 资源不足 / 目标不在切片 S-NSSAI 服务区	看 Cause IE；核对目标小区 S-NSSAI、负荷
切换后丢包/乱序	Status Transfer 缺失 / End Marker 未到	抓包确认 Uplink/Downlink RAN Status Transfer 是否完整；检查 PSA End Marker
切换后业务中断但信令成功	路径切换未生效 / T-UPF 未就绪	核对 SMF 的 N4 Session Modification、N3 隧道
UE 切换后立刻 RRC Release / 注册失败	UE 已离开注册区，Mobility Registration Update 异常	检查 Step 12 的注册更新与 TAI 配置

厂商差异： 爱立信、华为、中兴在 N2 切换上的实现差异主要体现在三点：① 默认转发策略偏好（部分厂家默认间接转发以规避直连安全关联配置）；② AMF Pool 边界处 AMF 重定位的触发灵敏度；③ 透明容器内私有字段的编码。跨厂家组网时，透明容器的不兼容通常表现为 Handover Preparation Failure with unknown-PLMN 或 unspecified，需要打开 RAN 侧日志比对容器解码。

十、常见问题

Q1：N2 切换和 Xn 切换在信令上最直观的区别是什么？ A：看准备阶段的"协调者"。Xn 切换里，源/目标 gNB 通过 XnAP 直接交互 HandoverRequest/Acknowledge，AMF 只在切换完成后的 Path Switch Request 才介入；N2 切换里，源 gNB 发 NGAP HandoverRequired 给 AMF，AMF 居中再发 HandoverRequest 给目标 gNB——抓包里 NGAP 出现 HandoverRequired/HandoverRequest 对，即 N2 切换。

Q2：什么时候必须做 AMF 重定位？ A：当目标 gNB 不在源 AMF 的服务区（GUAMI / AMF Set 不匹配）时。源 AMF 通过 AMF Selection Function 选 T-AMF，并用 Namf_Communication_CreateUEContext 搬迁完整 UE 上下文。若两 gNB 同属一个 AMF 服务区，则不重定位，S-AMF 兼任 T-AMF。

Q3：RAN Status Transfer 为什么对 AMF 是透明的？ A：因为 PDCP 状态（每个 DRB 的收发 SN/HFN）只有源/目标 gNB 关心，AMF 既不解析也不修改。它只是把 RANStatusTransfer-TransparentContainer 从源 RAN 搬到目标 RAN（AMF 重定位时还要跨 AMF 搬一次）。这种设计避免了核心网理解 RAN 内部协议状态。

Q4：直接转发和间接转发能否混用？ A：可以，且由 SMF 按 PDU Session 粒度决定。不同 PDU Session 可能因 UPF 服务区不同而走不同转发路径。SMF 在 Step 11 综合判断后下发各自的转发隧道信息。

Q5：切换成功后 UE 为什么有时要重新注册？ A：当切换使 UE 离开原注册区（Registration Area，即 TAI 列表覆盖范围）时，UE 会发起 Mobility Registration Update 更新位置。这是 N2 切换的正常"尾随信令"，不是故障，但在性能分析中需与切换本身区分统计。

参考来源

3GPP TS 23.502 V18.x — §4.9.1.3 NG-based Handover (4.9.1.3.2 Preparation / 4.9.1.3.3 Execution) — N2 切换准备/执行阶段权威步骤定义
Introduction of Xn and NG(N2) based handover — free5GC Blog — 基于 TS 23.502 的逐步流程图解与角色说明
5G SA Inter gNB Handover | 5G NGAP Handover — Techplayon — NGAP 消息逐条拆解与 IE 说明
5G NR N2 Handover Procedure | Call Flow — 3glteinfo — N2 切换完整 call flow 与场景说明
3GPP TS 38.413 — NGAP, HandoverRequired/HandoverRequest/HandoverRequestAcknowledge/HandoverNotify 消息与 IE 定义 — NGAP 消息级规范

本文由「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学通信知识星球海报-扫码加入