首页 › protocols › N2切换NGAP信令全链拆解

5G N2切换（NGAP Inter-gNB Handover）信令全链拆解

一、为什么N2切换是协议栈里最"重"的移动性流程

在5G系统（5GS）的移动性管理家族中，gNB之间的切换被划分为两条主干路径：Xn切换与N2切换。前者由源/目标gNB在Xn接口上自行完成资源协商、AMF全程"不感知"（仅在Path Switch阶段收尾），信令轻、时延低，是现网中绝大多数站间切换的首选。但当任意一个前置条件不满足——Xn接口不存在或不可用、源/目标gNB归属不同AMF、跨PLMN漫游、或AMF需要被重定位——网络就必须回退到一条更"重"的路径：经由N2接口、以AMF为核心协调者的N2切换。

N2切换的协议定义散落在三份核心规范中：业务流程骨架在TS 23.502 Section 4.9.1.3（Inter NG-RAN node N2 based handover，含5GS内与5GS↔EPS互操作场景）；NGAP层消息编排与IE在TS 38.413（NG Application Protocol）的"Handover Preparation"、"Handover Resource Allocation"、"Handover Execution"、"Handover Completion"、"UE Context Release"等Elementary Procedure；会话面协调则依赖TS 29.502定义的Nsmf_PDUSession服务的Update操作，承载于HTTP/2 SBI之上。

与Xn切换相比，N2切换的每一次完整执行要在控制面打通"UE—源gNB—AMF—SMF—UPF—目标gNB"六个节点，并伴随PDU Session Resource在N2/N4两层接口的成对修改。本文以TS 23.502 R18为主线，逐步拆解其准备（Preparation）、执行（Execution）、完成（Completion）三阶段信令，重点解析"透明容器"、"数据转发隧道"、"N4 UL Tunnel切换"三类容易踩坑的机制。

二、N2 vs Xn：触发条件与决策逻辑

源gNB在判决切换时，第一道分叉口就是"走Xn还是走N2"。判定依据记录在TS 23.502 4.9.1与TS 38.300 9.2.3中，可归纳为下表所列的四类回退场景：

判定条件	Xn切换是否可用	回退路径	规范依据
源/目标gNB间存在可用Xn接口，且归属同一AMF	✅ 可用	优先Xn	TS 23.502 4.9.1.2
无Xn接口，或Xn链路故障/资源受限	❌	N2切换	TS 38.300 9.3
源/目标gNB归属不同AMF（AMF Set内）	❌	N2（Inter-AMF N2 HO）	TS 23.502 4.9.1.3.2a
跨PLMN漫游、跨N3IWF/non-3GPP、需AMF重定位	❌	N2	TS 23.502 4.9.1.1

设计意图：N2切换的本质是"把Xn接口承载的资源协商职责，上移到AMF"。AMF作为UE唯一的移动性锚点，天然掌握UE的SUPI、Allowed NSSAI、安全上下文与所属SMF列表，因此即使没有Xn，AMF也能在两个gNB之间充当信令中转。代价是控制面跳数翻倍、时延增加——这也是为什么协议把Xn作为默认、N2作为回退。

三、完整信令时序图

下图严格对应TS 23.502 4.9.1.3.1（Intra-AMF N2 based handover，含可选数据转发）的13个核心步骤，覆盖NGAP（N2）、HTTP/2 SBI（N11/Nsmf）、PFCP（N4）三类协议：

sequenceDiagram
    autonumber
    participant UE
    participant SgNB as 源gNB
    participant AMF
    participant SMF
    participant UPF
    participant TgNB as 目标gNB

    Note over UE,TgNB: ===== 阶段一：切换准备 Handover Preparation =====
    UE->>SgNB: RRC MeasurementReport
    SgNB->>SgNB: 判决切换 (Xn不可用 → 回退N2)
    SgNB->>AMF: NGAP Handover Required<br/>(Source→Target Transparent Container, Ho Type)
    AMF->>SMF: HTTP/2 Nsmf_PDUSession_Update<br/>(PDU Session ID, HoPreparing)
    SMF->>UPF: PFCP N4 Session Modification<br/>(建立DL Forwarding TEID, 可选)
    SMF-->>AMF: Nsmf_PDUSession_Update Response<br/>(N2 SM Info: QoS Flow→DRB映射)
    AMF->>TgNB: NGAP Handover Request<br/>(Security Ctx, Allowed NSSAI, N2 SM Info)
    TgNB->>TgNB: 接纳判决 + 分配DRB/TEID
    TgNB-->>AMF: NGAP Handover Request Acknowledge<br/>(Target→Source Transparent Container,<br/>Forwarding TNL Address)
    AMF->>SgNB: NGAP Handover Command<br/>(Target→Source Transparent Container)

    Note over UE,TgNB: ===== 阶段二：切换执行 Handover Execution =====
    SgNB->>UE: RRC Reconfiguration (含HO Command)
    Note over SgNB,TgNB: 可选：数据转发 Direct/Indirect Forwarding
    SgNB->>AMF: NGAP Uplink RAN Status Transfer<br/>(PDCP UL/DL SN状态)
    AMF->>TgNB: NGAP Downlink RAN Status Transfer
    UE->>TgNB: RACH (基于 contention-free preamble)
    UE->>TgNB: RRC ReconfigurationComplete

    Note over UE,TgNB: ===== 阶段三：切换完成 Handover Completion =====
    TgNB->>AMF: NGAP Handover Notify<br/>(User Location Info)
    AMF->>SMF: HTTP/2 Nsmf_PDUSession_Update<br/>(HoComplete, Target N3 TEID)
    SMF->>UPF: PFCP N4 Session Modification<br/>(切换UL Tunnel到目标N3)
    UPF-->>SMF: N4 Modification Response
    SMF-->>AMF: Nsmf_PDUSession_Update Response
    Note over UPF: 下行数据经由新N3隧道直达目标gNB
    AMF->>SgNB: NGAP UE Context Release Command
    SgNB-->>AMF: NGAP UE Context Release Complete
    Note over SMF: 若用了Indirect Forwarding，<br/>启动定时器释放转发隧道

四、三阶段信令与关键IE逐步解析

4.1 切换准备阶段（Steps 1–9）

Step 3：Handover Required（源gNB → AMF，NGAP）

这是N2切换的"启动报文"，由TS 38.413的Handover Preparation procedure发起。其核心IE承载了目标gNB"自助服务"所需的全部决策信息：

AMF UE NGAP ID / RAN UE NGAP ID：在AMF与源gNB两侧定位UE Context。
Handover Type：取值intra5gs、fivegs-to-eps、eps-to-fivegs，决定后续容器格式与安全算法推导路径。
Cause：触发原因，典型为handover-desirable-for-radio-reason。
Target ID：目标gNB的Global RAN Node ID，AMF据此做拓扑解析并判断是否需要Inter-AMF重路由。
PDU Session Resource(s) to Be Setup List：待切换的PDU Session及其QoS Flow列表，经AMF透传给目标gNB做接纳判决。
Source to Target Transparent Container：本流程最关键的IE，由源gNB编码、AMF原样透传、目标gNB解码（见第五节）。

Step 4–5：AMF → SMF / SMF → UPF 的"预演"

注意一个易被忽略的细节：AMF在向目标gNB发Handover Request之前，会先沿N11调用Nsmf_PDUSession_Update，将ho-preparing指示带给每个PDU Session归属的SMF（TS 29.502 5.2.2.3）。SMF据此提前向UPF下发N4 Session Modification，为可选的下行数据转发预留DL Forwarding TEID，并把"N2 SM Information"（含QoS Flow到DRB的映射建议、上行N3 TEID）回填给AMF。这一步使后续Handover Request能携带完整的会话面参数，避免目标gNB因信息不足而拒绝。

Step 6：Handover Request（AMF → 目标gNB，NGAP）

AMF在此报文中"倾倒"出UE Context的全量配置，目标gNB据此完成接纳并重建无线承载。除前述容器外，还包含：

UE Security Capabilities：UE支持的NR/E-UPDC/UP integrity & ciphering算法列表，目标gNB据此选择KgNB派生的算法。
Security Context：含next hop chaining count (nhcc)与KAMF，目标gNB据此推导KgNB*实现密钥刷新（TS 33.501 6.9）。
Allowed NSSAI：切片允许列表，约束目标gNB可选的切片资源。
Mobility Restriction List：禁止区/漫游限制，防止目标小区越权。

Step 7–8：Handover Request Acknowledge（目标gNB → AMF）

接纳成功后，目标gNB回送应答，其中Target to Source Transparent Container携带RRC Handover Command（已由目标gNB生成、可直接给UE下发），以及为下行数据转发准备的目标侧TEID/传输层地址。若目标gNB对所有PDU Session Resource均接纳失败，本应答会被Handover Preparation Failure（Cause通常为radio-resources-not-available或transport-resource-unavailable）替代，切换在准备阶段即告失败。

Step 9：Handover Command（AMF → 源gNB）

AMF把Target→Source容器与目标侧转发地址透传给源gNB，源gNB据此停止调度并准备把缓存数据转发出去。此后UE在源侧的PDCP状态即被"冻结"。

4.2 切换执行阶段（Steps 10–13）

Step 10：RRC Reconfiguration下发

源gNB把目标gNB生成的Handover Command封装进RRCReconfiguration的reconfigurationWithSync字段下发给UE。UE收到后立即与源小区断开、启动与目标小区的随机接入。

Step 11：RAN Status Transfer（可选，无损切换关键）

对于PDCP状态保持的业务（AM/UM/UM-bidir），源gNB通过Uplink RAN Status Transfer（TS 38.413）上报"已收到的上行最大PDCP SN"与"期待接收的下行下一PDCP SN"，AMF再以Downlink RAN Status Transfer转交目标gNB。这是无损切换（lossless handover）的命脉：目标gNB据此避免重复下发已确认的下行包、补发丢失的上行包。若两端无Xn，这两条状态转移消息正是经由N2穿越AMF完成的——这是N2与Xn在状态同步路径上的本质差异。

Step 12–13：UE接入目标

UE以无竞争（contention-free）preamble接入目标小区，完成上行同步后回送RRCReconfigurationComplete，标志UE侧切换完成。

4.3 切换完成阶段（Steps 14–20）

Step 14：Handover Notify（目标gNB → AMF）

目标gNB检测到UE成功接入后，立即上报Handover Notify，触发AMF执行"用户面换路"。

Step 15–18：用户面路径切换（N2切换的又一关键差异）

在Xn切换中，路径切换由目标gNB发起Path Switch Request；而N2切换中路径切换由AMF主导：AMF再次调用Nsmf_PDUSession_Update，携带ho-complete指示与目标gNB的新N3 UL TEID（由Handover Notify带给AMF）。SMF随即向UPF下发N4 Session Modification，将上行隧道的终点（F-TEID）从源gNB的N3改写为目标gNB的N3。N4修改成功后，UPF的下行数据开始直奔目标gNB，源gNB从此被"旁路"。

Step 19–20：源侧上下文释放

AMF向源gNB发UE Context Release Command，源gNB释放UE Context与无线资源后回Complete。若切换中启用了间接数据转发（indirect forwarding），SMF还会启动一个定时器，待转发隧道上的尾包送完后再向UPF/中间gNB下发N4删除。

五、关键IE深度解析

下表汇总N2切换中决定成败的7个核心IE及其作用层级：

IE名称	所在NGAP消息	作用层级	编解码方	规范章节
Source to Target Transparent Container	Handover Required / Request	RRC/AS	源gNB编、目标gNB解、AMF透传	TS 38.413 8.x / TS 38.423 9.x
Target to Source Transparent Container	HO Req Ack / HO Command	RRC/AS	目标gNB编、源gNB解	TS 38.413 8.x
PDU Session Resource Setup List	Handover Request	会话面/无线	AMF组、目标gNB消费	TS 38.413 9.x
N2 SM Information	经Nsmf下发于Handover Request	会话面	SMF编、gNB消费	TS 29.502 6.x
Forwarding TNL Address (Target)	HO Request Acknowledge	传输面	目标gNB分配	TS 38.413 9.x
UE Security Capabilities / Security Context	Handover Request	安全	AMF下发	TS 38.413 / TS 33.501
RAN Status Transfer (PDCP SN)	Uplink/DL RAN Status Transfer	PDCP	源gNB→目标gNB	TS 38.413

透明容器的工作原理可用下图直观呈现——"透明"二字意味着AMF对容器内容不解释、不修改、不感知，仅做字节搬运：

flowchart TD
    A["源gNB<br/>生成 RRC Handover Command<br/>+ 无线参数 + UE能力"] --> B["Source→Target<br/>Transparent Container<br/>(Opaque Octet String)"]
    B --> C["AMF<br/>透传 / 不解码"]
    C --> D["目标gNB<br/>解码容器<br/>生成 DRB/CellGroupConfig"]
    D --> E["Handover Request Ack<br/>回填 Target→Source Container"]
    E --> F["AMF 透传"]
    F --> G["源gNB<br/>把Target→Source Container<br/>下发给UE"]
    G --> H["UE 执行切换"]

    style B fill:#fff3cd,stroke:#856404
    style E fill:#fff3cd,stroke:#856404
    style C fill:#d1ecf1,stroke:#0c5460
    style F fill:#d1ecf1,stroke:#0c5460

容器之所以设计成"不透明"，是为了让AS层信息（小区组配置、DRB/SRB、RRM配置、安全算法选择）在两个gNB之间端到端协商，而无需把这些与无线强相关的细节暴露给核心网。这与4G S1切换的Source to Target Transparent Container（TS 36.413）一脉相承，是控制面"分层解耦"的典范。

六、数据转发机制：Direct vs Indirect

切换执行期间，源gNB尚未被UPF"换路"前到达的下行包会滞留，需要转发给目标gNB避免丢包。TS 23.502 4.9.1.3定义了两种转发路径：

Direct Forwarding（直接转发）：源gNB与目标gNB之间直接经Xn-U（GTP-U隧道）转发。仅当两gNB间存在Xn接口时可用。
Indirect Forwarding（间接转发）：源gNB先经N3隧道把数据送到UPF，再由UPF经另一条N3隧道送到目标gNB。无需Xn接口，是N2切换（往往伴随无Xn场景）的常见选择。

转发路径由SMF决定：SMF在Handover Request Acknowledge阶段根据AMF上报的"源/目标gNB是否有Xn"信息，在N4 Session Modification中分别为源侧与目标侧分配Data Forwarding TEID。间接转发隧道在切换完成后不立即删除——SMF会启动一个保护定时器（典型为十秒级），确保转发路径上的尾包全部送达后才下发N4删除，避免末尾丢包。

七、状态转换：UE Context与PDU Session Resource

N2切换涉及三类状态机的联动，下图展示UE Context在源/目标gNB侧的生命周期，以及PDU Session Resource的"换路"窗口：

stateDiagram-v2
    direction LR
    [*] --> UE_Ctx_Active_Src : Initial Context Setup
    UE_Ctx_Active_Src --> HO_Preparing : Handover Required
    HO_Preparing --> HO_Prepared : Handover Request Ack
    HO_Prepared --> UE_Ctx_Suspended_Src : Handover Command<br/>(源侧停止调度)
    UE_Ctx_Suspended_Src --> UE_Ctx_Active_Tgt : UE接入目标 + HO Notify
    UE_Ctx_Active_Tgt --> UE_Ctx_Released_Src : UE Context Release
    UE_Ctx_Released_Src --> [*]

    state PS_Resource {
        [*] --> UL_Src : N3→源gNB
        UL_Src --> UL_Tgt : N4 Modification<br/>(UL Tunnel切目标)
        UL_Tgt --> [*]
    }

关键时序点：在UE_Ctx_Suspended_Src到UE_Ctx_Active_Tgt的窗口内，下行数据同时存在"转发路径"与"新直连路径"的竞争，目标gNB需按PDCP SN去重——这正是RAN Status Transfer承载SN状态的意义。

八、N2 vs Xn：横向对比

维度	Xn切换	N2切换
协调中心	源gNB（直连目标gNB）	AMF（核心网协调）
信令跳数	少（gNB↔gNB）	多（gNB↔AMF↔gNB）
路径切换发起方	目标gNB（Path Switch Request）	AMF（Nsmf_PDUSession_Update）
是否需AMF参与准备阶段	否	是
跨AMF/无Xn场景	不支持	支持
RAN Status Transfer路径	直接经Xn	经N2穿越AMF
典型时延	低	较高（多一倍控制面往返）
规范章节	TS 23.502 4.9.1.2	TS 23.502 4.9.1.3

九、实战连接：抓包识别与故障排查

9.1 抓包识别要点

在Wireshark中，N2切换的特征信令链可按协议过滤：

NGAP层：ngap.procedureCode == 35（Handover Preparation）、ngap.procedureCode == 29（UE Context Release）、过滤消息名Handover Required/Handover Request/Handover Notify。
HTTP/2层：http2.headers.author含SMF、URI为/namf-comm/v1/.../n2-info或SMF侧nsmf-pdusession/v1/.../modify，body中的hoState字段取值PREPARING→COMPLETED是定位阶段的"路标"。
PFCP层（N4）：pfcp.msg_type == 51（Session Modification Request），关注F-TEID IE在切换前后的取值变化——UL TEID的目标侧改写即为换路时刻。
一个判别技巧：若在抓包中看不到任何XnAP（NG/Xn-C）Handover Request，却能连续看到NGAP Handover Required/Notify，即可确认为N2切换。

9.2 常见故障点

Handover Preparation Failure：目标gNB接纳失败。排查目标小区负载、PRB可用率、N2链路带宽；Check Cause是radio-resources-not-available还是transport-resource-unavailable。
切换后上行丢包：N4 Modification未及时下发，UL Tunnel仍指向源gNB。检查SMF收到Handover Notify后的Nsmf_PDUSession_Update是否携带了目标N3 TEID、UPF是否成功应答N4。
无损切换失效（重复包/乱序）：RAN Status Transfer丢失或PDCP SN未正确传递。排查AMF是否成功转发Uplink→Downlink RAN Status Transfer（无Xn时必经N2）。
末尾丢包（indirect forwarding尾包）：SMF的保护定时器设置过短，转发隧道过早删除。需调大Forwarding tunnel release timer。
安全上下文不匹配导致切换后鉴权失败：KgNB*推导依赖nhcc与KAMF，Handover Request中Security Context IE缺失或ncc错误会导致目标gNB派生错误密钥。

十、常见问题

Q1：N2切换中，AMF为什么要在Handover Request之前先调用SMF？ A：因为目标gNB做接纳判决需要完整的"N2 SM Information"（QoS Flow→DRB映射、上行N3 TEID、5QI参数），而这些参数由SMF掌握。若AMF直接向目标gNB发Handover Request而不预取会话信息，目标gNB会因信息不全而拒绝。此外，预调用还为可选的间接数据转发提前在UPF侧预留DL Forwarding TEID。

Q2：Direct Forwarding和Indirect Forwarding如何选择？ A：由SMF在切换准备阶段决策：若源/目标gNB间存在可用Xn-U接口，优先Direct（时延低、不占UPF资源）；否则用Indirect，数据经UPF中转。判断依据是AMF上报的目标gNB拓扑信息（TS 23.502 4.9.1.3 Step 8）。N2切换往往伴随无Xn场景，故Indirect更为常见。

Q3：RAN Status Transfer在N2和Xn切换中有何不同？ A：内容相同（都承载PDCP UL/DL SN状态，用于无损切换去重与补包），但传输路径不同：Xn切换经Xn-C接口直接传送；N2切换因无Xn，必须拆成"源gNB→AMF（Uplink RAN Status Transfer）"与"AMF→目标gNB（Downlink RAN Status Transfer）"两段，经AMF中转。这多一跳会增加状态同步时延，是N2切换整体时延高于Xn的原因之一。

Q4：N2切换完成后，源gNB何时真正释放资源？ A：在Handover Notify触发用户面换路、且AMF发出UE Context Release Command之后。源gNB收到该命令才释放UE Context与无线资源。若启用了间接转发，转发隧道由SMF另启动保护定时器延迟删除，与UE Context释放解耦，确保尾包送达。

Q5：Inter-AMF的N2切换（跨AMF）多了哪些信令？ A：目标AMF不持有UE Context，需先经Namf_Communication_UEContextTransfer从源AMF拉取完整上下文，再执行Handover Request；切换完成后由源AMF触发UE Context释放。这是TS 23.502 4.9.1.3.2a相对4.9.1.3.1（Intra-AMF）的核心增量。

参考来源

3GPP TS 23.502 V18.10.0 — Section 4.9.1.3 Inter NG-RAN node N2 based handover — N2切换业务流程主规范
3GPP TS 38.413 — NG Application Protocol (NGAP) — Handover Preparation/Execution/Completion与关键IE定义
3GPP TS 29.502 — Nsmf_PDUSession Service — Nsmf_PDUSession_Update的hoState流转
ShareTechnote — 5G NGAP — NGAP能力与切换过程图解
Techplayon — 5G SA Inter gNB Handover (N2/NGAP) — N2切换完整call flow实战
free5GC — Introduction of Xn and NG (N2) based handover — 开源核心网实现视角下的切换差异

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