# 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切换做不到的四件事： 1. **无Xn也能切**：跨厂商对接、跨PLMN/跨安全域场景，Xn往往不建；N2链路（gNB↔AMF的SCTP）则必然存在。 2. **CN强制执行移动性限制**：AMF持有UE的Mobility Restriction上下文（允许TAI列表、允许/禁止的NSSAI、漫游与接入限制）。切换目标由AMF把关，目标RAN也二次校验——RAN侧无法绕过（这一点是安全要求，见TS 33.501对切换中移动性限制的强制性规定）。 3. **支持锚点UPF重定位**：目标侧如果需要更近的数据面（如MEC场景），N2切换可以在切换过程中插入新的中间UPF，通过SMF的N4流程完成会话迁移——Xn切换做不到这个。 4. **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 完整信令时序图 ```mermaid 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与移动性限制
决定执行N2切换、锚点UPF不变 AMF->>TgNB: NGAP Handover Request
(5G-TMSI / MobilityRestrictionList / NASC
PDUSessionResourceSetupListHOReq) TgNB->>TgNB: 会话级准入+QoS资源预留
生成RRC重配(reconfigurationWithSync) TgNB->>AMF: NGAP Handover Request Acknowledge
(PDUSessionResourceAdmittedList
+TargetToSourceTransparentContainer) AMF->>SgNB: NGAP Handover Command
(TargetToSourceTransparentContainer
+PDUSessionResourceHandoverList:前转端点) SgNB->>UE: RRCReconfiguration(reconfigurationWithSync) UE->>TgNB: 随机接入目标小区(PRACH) UE->>TgNB: RRCReconfigurationComplete Note over SgNB,TgNB: 数据前转(直接/间接)启动 TgNB->>AMF: NGAP Handover Notify
(UserLocationInformation: 新TAI+Cell ID) AMF->>SMF: Nsmf_PDUSession_UpdateSMContext
(目标gNB的DL NG-U UP TNL Info) SMF->>UPF: PFCP Session Modification
(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结构图： ```mermaid flowchart TD A["NGAP: Handover Command
(AMF → 源gNB)"] --> B["AMF UE NGAP ID / RAN UE NGAP ID
(36bit, NG连接两端标识)"] A --> C["PDUSessionResourceHandoverList
逐会话: PDU Session ID + HandoverTransfer"] C --> C1["DL Forwarding UP TNL Information
前转目的端点:
直转=目标gNB地址 / 间转=UPF转发端点"] C --> C2["QoS相关参数(5QI/QFI等)"] A --> D["PDUSessionResourceToReleaseList
目标不接纳、需随切换释放的会话"] A --> E["Target To Source Transparent Container
目标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侧的切换状态机 ```mermaid stateDiagram-v2 [*] --> Connected: UE处于CM-CONNECTED
存在UE关联NG连接 Connected --> Preparing: 发出Handover Required(N2)
或XnAP HO Request(Xn) Preparing --> Prepared: 收到Handover Command(N2)
或XnAP HO Request Ack(Xn) Preparing --> PreparationFailed: HandoverPreparationFailure
或目标侧HandoverFailure Preparing --> Cancelled: 源侧发起Handover Cancel Prepared --> TargetConfirmed: UE完成RACH
+RRCReconfigurationComplete TargetConfirmed --> [*]: Handover Notify(N2)
或Path Switch(Xn)
+源上下文释放 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）： ```mermaid 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
(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
(PDUSessionResourceSwitchedList
可选SecurityContext: NH/NCC) AMF->>SgNB: NGAP UE Context Release Command SgNB-->>AMF: NGAP UE Context Release Complete ``` 两个工程要点： 1. **PathSwitchRequestAcknowledge中的SecurityContext（NH/NCC）**：AMF可能借此下发新的Next Hop参数与Next Hop Chaining Counter（TS 33.501的横向密钥推导），目标gNB据此刷新 `K_gNB`，避免密钥随切换次数累积退化。若UE的NCC已耗尽且未刷新，会出现切换后完整性校验失败——这是排查“切过去就掉话”时容易被忽略的一类原因。 2. **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可视可控。 --- ## 参考来源 1. [3GPP TS 23.502（5G系统流程，DynaReport页）](https://www.3gpp.org/dynareport/23502.htm) — §4.9 Mobility Procedures：N2切换、Xn切换、Handover Cancel 官方流程定义 2. [3GPP TS 23.502 规范文本FTP归档](https://www.3gpp.org/ftp/Specs/archive/23_series/23.502/) — 各Release版本原文下载，建议按所研版本对照§4.9子条目编号 3. [3GPP TS 38.413（NG-RAN; NGAP，DynaReport页）](https://www.3gpp.org/dynareport/38413.htm) — HandoverRequired/HandoverRequest/HandoverCommand/PathSwitchRequest等消息与IE的ASN.1定义 4. [3GPP TS 29.502（Nsmf_PDUSession服务，DynaReport页）](https://www.3gpp.org/dynareport/29502.htm) — N2 SM Information与UpdateSMContext SBI接口 5. [ShareTechnote 5G/NR Handover专题](https://www.sharetechnote.com/html/5G/5G_Handover.html) — 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 等场景全覆盖。