# 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）三类协议： ```mermaid 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
(Source→Target Transparent Container, Ho Type) AMF->>SMF: HTTP/2 Nsmf_PDUSession_Update
(PDU Session ID, HoPreparing) SMF->>UPF: PFCP N4 Session Modification
(建立DL Forwarding TEID, 可选) SMF-->>AMF: Nsmf_PDUSession_Update Response
(N2 SM Info: QoS Flow→DRB映射) AMF->>TgNB: NGAP Handover Request
(Security Ctx, Allowed NSSAI, N2 SM Info) TgNB->>TgNB: 接纳判决 + 分配DRB/TEID TgNB-->>AMF: NGAP Handover Request Acknowledge
(Target→Source Transparent Container,
Forwarding TNL Address) AMF->>SgNB: NGAP Handover Command
(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
(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
(User Location Info) AMF->>SMF: HTTP/2 Nsmf_PDUSession_Update
(HoComplete, Target N3 TEID) SMF->>UPF: PFCP N4 Session Modification
(切换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，
启动定时器释放转发隧道 ``` --- ## 四、三阶段信令与关键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对容器内容**不解释、不修改、不感知**，仅做字节搬运： ```mermaid flowchart TD A["源gNB
生成 RRC Handover Command
+ 无线参数 + UE能力"] --> B["Source→Target
Transparent Container
(Opaque Octet String)"] B --> C["AMF
透传 / 不解码"] C --> D["目标gNB
解码容器
生成 DRB/CellGroupConfig"] D --> E["Handover Request Ack
回填 Target→Source Container"] E --> F["AMF 透传"] F --> G["源gNB
把Target→Source Container
下发给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的"换路"窗口： ```mermaid 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
(源侧停止调度) 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
(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 常见故障点 1. **Handover Preparation Failure**：目标gNB接纳失败。排查目标小区负载、PRB可用率、N2链路带宽；Check Cause是`radio-resources-not-available`还是`transport-resource-unavailable`。 2. **切换后上行丢包**：N4 Modification未及时下发，UL Tunnel仍指向源gNB。检查SMF收到Handover Notify后的`Nsmf_PDUSession_Update`是否携带了目标N3 TEID、UPF是否成功应答N4。 3. **无损切换失效（重复包/乱序）**：RAN Status Transfer丢失或PDCP SN未正确传递。排查AMF是否成功转发Uplink→Downlink RAN Status Transfer（无Xn时必经N2）。 4. **末尾丢包（indirect forwarding尾包）**：SMF的保护定时器设置过短，转发隧道过早删除。需调大`Forwarding tunnel release timer`。 5. **安全上下文不匹配导致切换后鉴权失败**：`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）的核心增量。 --- ## 参考来源 1. [3GPP TS 23.502 V18.10.0 — Section 4.9.1.3 Inter NG-RAN node N2 based handover](https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/18.10.00_60/ts_123502v181000p.pdf) — N2切换业务流程主规范 2. [3GPP TS 38.413 — NG Application Protocol (NGAP)](https://www.sharetechnote.com/html/5G/5G_NGAP.html) — Handover Preparation/Execution/Completion与关键IE定义 3. [3GPP TS 29.502 — Nsmf_PDUSession Service](https://emanuelfreitas.github.io/3gpp-documentation/apis/html/TS29502_Nsmf_PDUSession.html) — Nsmf_PDUSession_Update的hoState流转 4. [ShareTechnote — 5G NGAP](https://www.sharetechnote.com/html/5G/5G_NGAP.html) — NGAP能力与切换过程图解 5. [Techplayon — 5G SA Inter gNB Handover (N2/NGAP)](https://www.techplayon.com/5g-sa-inter-gnb-handover-n2-or-ngap-handover/) — N2切换完整call flow实战 6. [free5GC — Introduction of Xn and NG (N2) based handover](https://free5gc.org/blog/20251105/20251105/) — 开源核心网实现视角下的切换差异 --- > 本文由「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 等场景全覆盖。