首页 › core-network › 5G N2切换信令流深度解读

5G N2切换信令流程深度解读：从 Handover Required 到 Path Switch 的每一条消息

在Xn接口不可用（跨厂商、跨安全域、未配置Xn链路）或核心网需要主导移动性控制时，NG-RAN之间的切换必须走基于N2的切换（N2-based Handover），完整流程定义在 TS 23.502 §4.9（Mobility Procedures）。这是5G系统中链路最长、涉及网元最多（源gNB / AMF / 目标gNB / SMF / UPF）、也是现网故障率最高的移动性流程之一。本文聚焦其中最典型的intra-AMF、锚点UPF不变的N2切换（TS 23.502 §4.9.1，Figure 4.9.1-1），逐条拆解NGAP/N4/SBI消息及其关键IE，并对比Xn切换的Path Switch流程。注意：§4.9下各子条目编号在Rel-15/16/17间略有调整（AMF变更的N2切换、Handover Cancel、Xn切换分别位于§4.9后续小节），查阅时建议以目录为准。

一、为什么需要N2切换：设计意图

NR的切换有两条路径：

Xn切换：源gNB直接通过Xn接口把UE上下文交给目标gNB，核心网只在最后收一条 Path Switch Request（TS 23.502 §4.9中Xn切换小节）。快，但前提是两个gNB之间有Xn。
N2切换：所有控制信令经AMF中转（NGAP over SCTP），核心网全程参与。

N2切换“绕远路”不是设计冗余，而是刻意为之，它解决了Xn切换做不到的四件事：

无Xn也能切：跨厂商对接、跨PLMN/跨安全域场景，Xn往往不建；N2链路（gNB↔AMF的SCTP）则必然存在。
CN强制执行移动性限制：AMF持有UE的Mobility Restriction上下文（允许TAI列表、允许/禁止的NSSAI、漫游与接入限制）。切换目标由AMF把关，目标RAN也二次校验——RAN侧无法绕过（这一点是安全要求，见TS 33.501对切换中移动性限制的强制性规定）。
支持锚点UPF重定位：目标侧如果需要更近的数据面（如MEC场景），N2切换可以在切换过程中插入新的中间UPF，通过SMF的N4流程完成会话迁移——Xn切换做不到这个。
QoS会话级准入：每个PDU Session、每条QoS Flow由目标gNB逐条准入，接纳不了的在 PDUSessionResourceFailedToModifyList/To Release List 中显式返回，而不是静默降级。

一句话总结：Xn切换是“RAN自治”，N2切换是“CN托管”。

二、主流程：intra-AMF、UPF不变的N2切换（TS 23.502 §4.9.1）

2.1 完整信令时序图

sequenceDiagram
    autonumber
    participant UE as UE
    participant SgNB as 源gNB
    participant AMF as AMF(不变)
    participant TgNB as 目标gNB
    participant SMF as SMF
    participant UPF as UPF(锚点不变)

    Note over UE,SgNB: Uu口: 测量报告 → 源gNB判决切换（RAN内部行为）
    SgNB->>AMF: NGAP Handover Required
    Note right of AMF: 校验Target ID与移动性限制<br>决定执行N2切换、锚点UPF不变
    AMF->>TgNB: NGAP Handover Request<br>(5G-TMSI / MobilityRestrictionList / NASC<br>PDUSessionResourceSetupListHOReq)
    TgNB->>TgNB: 会话级准入+QoS资源预留<br>生成RRC重配(reconfigurationWithSync)
    TgNB->>AMF: NGAP Handover Request Acknowledge<br>(PDUSessionResourceAdmittedList<br>+TargetToSourceTransparentContainer)
    AMF->>SgNB: NGAP Handover Command<br>(TargetToSourceTransparentContainer<br>+PDUSessionResourceHandoverList:前转端点)
    SgNB->>UE: RRCReconfiguration(reconfigurationWithSync)
    UE->>TgNB: 随机接入目标小区(PRACH)
    UE->>TgNB: RRCReconfigurationComplete
    Note over SgNB,TgNB: 数据前转(直接/间接)启动
    TgNB->>AMF: NGAP Handover Notify<br>(UserLocationInformation: 新TAI+Cell ID)
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext<br>(目标gNB的DL NG-U UP TNL Info)
    SMF->>UPF: PFCP Session Modification<br>(FAR: Outer Header Creation → 目标gNB)
    UPF-->>SMF: PFCP Session Modification Response
    SMF-->>AMF: Nsmf_PDUSession_UpdateSMContext Response
    UPF->>TgNB: 下行数据切换新隧道(首包前发End Marker)
    AMF->>SgNB: NGAP UE Context Release Command
    SgNB-->>AMF: NGAP UE Context Release Complete

补充：若采用间接转发，AMF在准备阶段（步骤2之前）会先发起一次 Nsmf_PDUSession_UpdateSMContext，请求SMF/UPF分配转发隧道端点，该端点随后出现在Handover Command的前转IE中。

2.2 逐条消息与关键IE解析

① Handover Required（源gNB → AMF，NGAP，TS 38.413）

这是整个切换的起点，源gNB只在已经选定唯一目标后发送。关键IE：

IE	说明
Handover Type	`intra5gs`（5GS内切换）；跨系统迁移时为 `fivegsToEps` 等
Cause	触发原因（radio-network / handover-desirable-for-radio-reasons 等），主要用于统计与定位
Target ID	Global RAN Node ID（PLMN ID + gNB ID）+ Selected TAI。AMF据此执行移动性限制校验
Direct Forwarding Path Availability	源gNB声明“我与目标gNB之间存在直接前转路径”——这直接决定后续走直转还是间转
Source NG-RAN node → Target NG-RAN node Transparent Container	源侧打包的无线侧上下文（测量结果、UE能力摘要等），对AMF完全透明

② Handover Request（AMF → 目标gNB，NGAP）

注意命名陷阱：NGAP的 Handover Request 是AMF发给目标gNB的；XnAP里也有一个 Handover Request，是源gNB发给目标gNB的，两者内容完全不同。本消息的关键IE：

AMF UE NGAP ID / RAN UE NGAP ID：NG连接两端标识，均为36-bit（BIT STRING SIZE(36)），RAN侧ID由gNB分配、AMF侧ID由AMF分配，二者共同唯一标识一条UE关联的逻辑NG连接；
FiveG-TMSI：目标gNB据此可触发寻呼兜底（UE失联场景）；
Mobility Restriction List：允许的TAI列表、允许的S-NSSAI、漫游/接入限制——目标gNB必须据此二次校验，违反即失败；
NASC（NAS Security Parameters from NG-RAN）：AMF传递给目标gNB的NAS安全参数容器，用于切换后重激活NAS层保护；
PDUSessionResourceSetupListHOReq：逐会话携带 PDU Session ID + S-NSSAI + PDUSessionResourceSetupRequestTransfer，Transfer内含UPF侧UL NG-U UP TNL Information（GTP-U F-TEID）与QoS Flow Setup Request List（5QI/QFI/GFBR等）。因为锚点UPF不变，UPF的UL端点原样交给目标gNB——目标gNB一旦收到UE的RRC重配完成，即可立即上行发数，无需等任何CN流程。

③ Handover Request Acknowledge（目标gNB → AMF）

PDUSessionResourceAdmittedList：逐会话的 PDUSessionResourceAdmittedTransfer，核心内容是目标gNB自己的DL NG-U UP TNL Information（目标gNB为接收下行分配的GTP-U F-TEID）——这就是稍后SMF改写UPF FAR的“新下行地址”；
PDUSessionResourceFailedToModifyList：接纳失败的会话清单；
Target to Source Transparent Container：目标gNB生成的RRCReconfiguration消息本体（含reconfigurationWithSync），CN不拆不碰、原样经Handover Command回传给源gNB。这个“透明容器”模式是S1AP时代（MME Transparent Container）的直接继承，保证核心网保持无线无感（radio-agnostic）。

④ Handover Command（AMF → 源gNB）

IE结构图：

flowchart TD
    A["NGAP: Handover Command<br>(AMF → 源gNB)"] --> B["AMF UE NGAP ID / RAN UE NGAP ID<br>(36bit, NG连接两端标识)"]
    A --> C["PDUSessionResourceHandoverList<br>逐会话: PDU Session ID + HandoverTransfer"]
    C --> C1["DL Forwarding UP TNL Information<br>前转目的端点:<br>直转=目标gNB地址 / 间转=UPF转发端点"]
    C --> C2["QoS相关参数(5QI/QFI等)"]
    A --> D["PDUSessionResourceToReleaseList<br>目标不接纳、需随切换释放的会话"]
    A --> E["Target To Source Transparent Container<br>目标gNB生成的RRC重配(对CN透明)"]
    A --> F["Criticality Diagnostics (可选)"]

源gNB把Transparent Container拆出，包进空口的 RRCReconfiguration 下发给UE。对UE而言，N2切换与Xn切换的空口体验完全一致——UE不知道、也不需要知道下面走的是哪条路径。

⑤ 空口阶段：UE收到 reconfigurationWithSync（含目标小区PCI、频点、PRACH资源、新C-RNTI），发起非竞争随机接入，成功后回 RRCReconfigurationComplete。此后UE的上下文只存在于目标gNB。

⑥ Handover Notify（目标gNB → AMF）

极简消息，核心IE只有一个：User Location Information（新TAI + 新小区标识）。它的语义是“UE确实到了”，AMF以此为锚点更新UE位置、触发后续计费与策略。收到Notify之前，AMF不会把数据面切过去——这是防止“UE没来、数据先走”造成黑洞的关键时序设计。

⑦ Nsmf_PDUSession_UpdateSMContext（AMF → SMF，SBI，TS 29.502）

AMF把目标gNB的DL TNL Info封装为 N2 SM Information，经 POST /nsmf-pdusession/v1/sm-contexts/{ref}/modify 交给SMF。SMF随后下发 PFCP Session Modification Request（TS 29.244），核心动作是改写FAR：Outer Header Creation 从源gNB的TEID替换为目标gNB的TEID。UPF回复Response后，下行数据面正式切换，并按惯例先向新隧道发一个End Marker包——源gNB收到End Marker即可停发前转数据，这保证了切换期不乱序不重复。

⑧ UE Context Release（AMF → 源gNB）

删除源侧UE上下文与AN资源。若使用了间接转发，源gNB会启动一个前转保护定时器，定时器到期才真正拆除转发隧道，容忍迟到的在途数据；UPF侧的间接转发资源由SMF在后续的会话修改/释放中清理。

2.3 源gNB侧的切换状态机

stateDiagram-v2
    [*] --> Connected: UE处于CM-CONNECTED<br>存在UE关联NG连接
    Connected --> Preparing: 发出Handover Required(N2)<br>或XnAP HO Request(Xn)
    Preparing --> Prepared: 收到Handover Command(N2)<br>或XnAP HO Request Ack(Xn)
    Preparing --> PreparationFailed: HandoverPreparationFailure<br>或目标侧HandoverFailure
    Preparing --> Cancelled: 源侧发起Handover Cancel
    Prepared --> TargetConfirmed: UE完成RACH<br>+RRCReconfigurationComplete
    TargetConfirmed --> [*]: Handover Notify(N2)<br>或Path Switch(Xn)<br>+源上下文释放
    PreparationFailed --> Connected: 保留在源小区
    Cancelled --> Connected

两条失败/取消支路的细节：

HandoverPreparationFailure（AMF→源gNB）：准备阶段被拒，典型Cause包括 Handover Target not allowed（AMF移动性限制校验失败）、No Radio Resources Available in Target Cell、TAC not allowed、NSSAI not supported 等。
HandoverFailure（目标gNB→AMF）：目标gNB在收到Handover Request后自身失败（如资源不足、目标TAI非法），AMF收到后向源gNB回HandoverPreparationFailure闭环。
Handover Cancel / Handover Cancel Acknowledge：源gNB在收到Command前决定放弃（如UE已回源小区、定时器超时），AMF需先向目标gNB释放已建立的UE上下文（UE Context Release），再向源gNB确认取消——顺序不能反，否则目标侧残留僵尸上下文。

三、对照流程：Xn切换与Path Switch

Xn切换中核心网只做“事后记账”，这条记账流程就是 Path Switch（NGAP过程，目标gNB → AMF）：

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

    SgNB->>TgNB: XnAP Handover Request(源→目标,经Xn直连)
    TgNB-->>SgNB: XnAP Handover Request Acknowledge
    SgNB->>UE: RRCReconfiguration(reconfigurationWithSync)
    UE->>TgNB: RACH + RRCReconfigurationComplete
    SgNB->>TgNB: XnAP SN Status Transfer + 数据前转
    TgNB->>AMF: NGAP Path Switch Request<br>(RAN UE NGAP ID / AMF UE NGAP ID / UserLocationInformation)
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext(目标gNB新DL TNL)
    SMF->>UPF: PFCP Session Modification(切换下行FAR)
    SMF-->>AMF: 响应(含UPF侧UL NG-U UP TNL更新)
    AMF-->>TgNB: NGAP Path Switch Request Acknowledge<br>(PDUSessionResourceSwitchedList<br>可选SecurityContext: NH/NCC)
    AMF->>SgNB: NGAP UE Context Release Command
    SgNB-->>AMF: NGAP UE Context Release Complete

两个工程要点：

PathSwitchRequestAcknowledge中的SecurityContext（NH/NCC）：AMF可能借此下发新的Next Hop参数与Next Hop Chaining Counter（TS 33.501的横向密钥推导），目标gNB据此刷新 K_gNB，避免密钥随切换次数累积退化。若UE的NCC已耗尽且未刷新，会出现切换后完整性校验失败——这是排查“切过去就掉话”时容易被忽略的一类原因。
PathSwitchRequestFailure：AMF在标识不匹配（如AMF UE NGAP ID对不上）、安全上下文异常时返回，目标gNB需回退处理。

AMF变更的N2切换（TS 23.502 §4.9后续小节）在主流程上多了一层：源AMF通过 Namf_Communication_UEContextTransfer / CreateUEContext 把MM上下文与N2 SM信息搬运给目标AMF，由目标AMF向目标gNB发Handover Request、由源AMF向源gNB发Handover Command，Handover Notify发给目标AMF，SMF更新由目标AMF发起。UE全程无感，不需要执行Registration（若进入注册区之外的TA，切换完成后UE再自主触发Mobility Registration Update，TS 24.501）。

四、三路对比：N2切换 / Xn切换 / EPS S1切换

维度	5G N2切换	5G Xn切换	EPS S1切换
切换判决与准备	经AMF中转（NGAP）	源gNB直连目标gNB（XnAP）	经MME中转（S1AP）
核心网参与深度	全程：准备+接纳+数据面切换	末端记账（Path Switch）	全程（与N2切换同构）
CN可见的UE状态	无变化（CM-CONNECTED延续）	无变化	无变化（ECM-CONNECTED延续）
UPF/SGW重定位	支持（SMF经N4插入新中间UPF）	通常不变（需另走会话修改）	支持（MME触发SGW重定位）
数据前转	直接/间接，IE显式协商	Xn直转为主	直接/间接（与N2同构）
对UE的空口呈现	RRCReconfiguration	RRCReconfiguration	RRCConnectionReconfiguration
典型触发场景	无Xn/跨厂商/跨安全域/需换锚点	同厂商宏站邻区、Xn已建	4G同构场景（N2切换的蓝本）

可以看出N2切换在消息框架上是EPS S1切换的直系演进，但把“会话级准入”（PDU Session粒度的admitted/failed清单）做成了显式信令——这是5G切片化带来的必然要求。

五、实战：抓包识别与故障排查

5.1 抓包识别

N2信令：NGAP over SCTP，端口 38412。Wireshark原生解码NGAP，过滤器 sctp.port == 38412 后按消息名过滤 Handover Required / Handover Command / Handover Notify。同一界面能同时看到XnAP Handover Request和NGAP Handover Request时，先看传输层区分归属。
数据面切换：PFCP over UDP 8805，过滤器 pfcp，盯 Session Modification Request 中的 FAR → Outer Header Creation（新旧TEID/IP对比）。
SBI信令：HTTP/2（常见7777端口），过滤器 http2，看 :path 含 /nsmf-pdusession/v1/sm-contexts/.../modify 的请求体中N2 SM Info。
空口/终端侧：NR RRC的 RRCReconfiguration 携带 reconfigurationWithSync 即切换命令；N2/Xn切换期间UE侧NAS无任何消息——如果在终端日志切换窗口看到Registration Request，说明切换失败后走了重选/重建立恢复路径，本身就是异常信号。

5.2 常见故障点速查

现象	高概率原因	抓包证据	排查方向
反复HandoverPreparationFailure，Cause=Handover Target not allowed	目标TAI不在允许列表/漫游限制	HandoverRequired中的Target ID与AMF配置比对	核对AMF的Mobility Restriction数据与目标TAI规划
切换成功但只有DL中断（UL正常）	UPF的FAR没切过去	PFCP Modification缺失或Outer Header Creation仍是源gNB TEID	查SMF-N4链路、N2 SM Info是否携带目标DL TNL
部分业务切换后中断	目标不支持某S-NSSAI，会话被列入Failed To Modify	Handover Request Acknowledge的FailedToModifyList	核对目标gNB的切片支持配置
切换瞬断丢包大	前转路径不可用（无直转路径又未配间转）	HandoverRequired无Direct Forwarding Path Availability，且Handover Command无前转端点	使能间接转发或打通gNB间用户面
切换后立即掉话/完整性失败	NH/NCC未刷新，AS密钥推导异常	PathSwitch Ack或Handover链路中无SecurityContext IE	检查AMF的NCC管理与33.501密钥链
目标侧残留UE上下文	Handover Cancel时序错误	有Cancel Ack但无对目标的UE Context Release	核查AMF取消流程实现
## 常见问题

Q1: NGAP的Handover Request和XnAP的Handover Request是同一个东西吗？ A: 不是，只是重名。NGAP版是AMF→目标gNB，携带核心网侧完整UE上下文（5G-TMSI、Mobility Restriction List、NASC、逐会话N2 SM Info）；XnAP版是源gNB→目标gNB，经Xn直连、不经核心网，携带RAN侧上下文。判断方法看承载：SCTP 38412上是NGAP，Xn链路上是XnAP。

Q2: N2切换完成后UE需要做Registration或TAU吗？ A: 不需要立即做。N2切换保持CM-CONNECTED与NGAP UE关联，AMF变更场景下上下文由AMF间搬运，UE完全无感。只有当新TAI超出注册TA列表时，UE才在切换稳定后自主发起Mobility Registration Update（TS 24.501），这是NAS层独立流程，不阻塞业务。

Q3: 直接转发和间接转发怎么选？ A: 源gNB在Handover Required里用Direct Forwarding Path Availability声明有无直转路径；AMF/SMF据此决策。直转路径短、时延小，要求源目标gNB间有IP可达的用户面路径；间转经UPF中转，用于跨安全域、跨厂商、无直连路径的场景，代价是多一跳并需SMF分配转发端点。

Q4: Handover Notify和Path Switch Request分别在什么流程里出现？ A: 二者都是“UE已到目标小区”的CN通知，但Handover Notify用于N2切换（目标gNB→AMF，确认后AMF才切数据面）；Path Switch Request用于Xn切换（切换完成后目标gNB→AMF补账，AMF据此触发数据面切换并释放源侧）。抓包里同时看到两者属于异常，需检查是否存在切换路径回退。

Q5: 切换中QoS Flow会被降级或丢弃吗？ A: 会。目标gNB按会话/按流准入，接纳的进入PDUSessionResourceAdmittedList，不接纳的进入Failed To Modify List或To Release List，切换继续、被拒会话释放。目标侧也可按备选QoS参数接纳，实现“尽力保流”。这正是N2切换相比Xn切换更适合切片场景的原因——接纳决策在CN可视可控。

参考来源

3GPP TS 23.502（5G系统流程，DynaReport页） — §4.9 Mobility Procedures：N2切换、Xn切换、Handover Cancel 官方流程定义
3GPP TS 23.502 规范文本FTP归档 — 各Release版本原文下载，建议按所研版本对照§4.9子条目编号
3GPP TS 38.413（NG-RAN; NGAP，DynaReport页） — HandoverRequired/HandoverRequest/HandoverCommand/PathSwitchRequest等消息与IE的ASN.1定义
3GPP TS 29.502（Nsmf_PDUSession服务，DynaReport页） — N2 SM Information与UpdateSMContext SBI接口
ShareTechnote 5G/NR Handover专题 — N2/Xn切换消息流程图解与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学通信知识星球海报-扫码加入