首页 › protocols › 5G N2切换端到端信令全链拆解

5G N2切换端到端信令全链拆解:从Handover Required到路径切换完成

一、N2切换机制概述

在5G网络中,当UE处于RRC_CONNECTED状态从源gNB移动到目标gNB覆盖区域时,源gNB根据测量报告决定是否触发切换。当源gNB与目标gNB之间不存在Xn接口、或Xn接口不可用、或策略不允许Xn切换时,源gNB将发起N2切换(NGAP Handover)——由核心网AMF作为中介协调源侧与目标侧的切换准备与执行。

N2切换的核心特征是所有切换信令必须经过AMF中转:源gNB通过NGAP将切换请求发送给AMF,AMF再向目标gNB发送Handover Request。相比Xn切换的"RAN直连、核心网旁路"模式,N2切换引入了额外的信令时延(约20-40ms),但提供了更强的核心网控制能力和AMF重定位支持。

本文基于 3GPP TS 23.502 V18.10.0 Section 4.9.1、TS 38.413 V18.x Section 8.4、TS 24.501 相关章节,深入拆解N2切换从准备阶段(Preparation)到执行阶段(Execution)的完整信令链路。

二、N2切换触发条件与决策逻辑

2.1 触发条件

N2切换在以下场景被触发:

触发场景 说明 典型Cause值
无Xn接口 源gNB与目标gNB间无Xn连接 handover-desirable-for-radio-reason
Xn接口故障 Xn链路中断或拥塞 ho-target-not-reachable-via-Xn
负载均衡 网络策略要求经核心网调度 load-balancing
AMF重定位 UE移动到新AMF服务区 handover-desirable-for-radio-reason
Inter-RAT 5G→4G跨系统切换 inter-RAT-handover

2.2 决策流程

flowchart TD
    A[UE发送Measurement Report] --> B{源gNB评估测量结果}
    B -->|信号质量下降| C{Xn接口是否可用?}
    C -->|是| D[选择Xn切换路径]
    C -->|否| E[选择N2切换路径]
    B -->|负载均衡触发| F{策略是否允许Xn切换?}
    F -->|是| D
    F -->|否| E
    D --> G[Xn Handover Preparation]
    E --> H[N2 Handover Required → AMF]
    H --> I{目标gNB是否在同AMF服务区?}
    I -->|是| J[Intra-AMF N2 Handover]
    I -->|否| K[Inter-AMF N2 Handover + AMF Relocation]

三、N2切换准备阶段完整信令流

3.1 准备阶段时序图(Intra-AMF场景)

sequenceDiagram
    participant UE
    participant S_gNB as 源gNB
    participant AMF
    participant SMF
    participant UPF
    participant T_gNB as 目标gNB

    Note over UE,T_gNB: === N2切换准备阶段 (Preparation Phase) ===

    UE->>S_gNB: Measurement Report
    Note right of UE: 包含邻区RSRP/RSRQ测量结果

    S_gNB->>AMF: NGAP Handover Required
    Note right of S_gNB: IE: AMF UE NGAP ID, RAN UE NGAP ID,<br/>Handover Type, Cause, Target ID,<br/>PDU Session Resource List,<br/>Source-to-Target Transparent Container,<br/>Direct Forwarding Path Availability

    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Request
    Note right of AMF: 每个PDU Session一条请求<br/>包含: Target ID, N2 SM Info

    SMF->>UPF: N4 Session Modification Request
    Note right of SMF: 请求分配UL CN Tunnel Info<br/>用于目标gNB的上行隧道

    UPF-->>SMF: N4 Session Modification Response
    Note left of UPF: 返回: UL CN Tunnel Info,<br/>Data Forwarding Info

    SMF-->>AMF: Nsmf_PDUSession_UpdateSMContext Response
    Note left of SMF: 包含N2 SM Information:<br/>QoS Flow列表、UL CN Tunnel Info、<br/>Data Forwarding可用性指示

    Note over AMF: AMF等待所有SMF响应<br/>或超时后继续

    AMF->>T_gNB: NGAP Handover Request
    Note right of AMF: IE: AMF UE NGAP ID (新分配),<br/>Source-to-Target Transparent Container,<br/>N2 SM Information List,<br/>N2 MM Information (Security Context),<br/>Mobility Restriction List

    Note over T_gNB: 目标gNB执行准入控制<br/>检查无线资源、QoS保障能力

    T_gNB-->>AMF: NGAP Handover Request Acknowledge
    Note left of T_gNB: IE: Target-to-Source Transparent Container,<br/>Admitted PDU Session List + N2 SM Info,<br/>Failed PDU Session List,<br/>Data Forwarding Tunnel Info

    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Request
    Note right of AMF: 传递目标gNB的N3 AN Tunnel Info<br/>及Data Forwarding信息

    SMF->>UPF: N4 Session Modification
    Note right of SMF: 配置DL Data Forwarding Tunnel<br/>(直传或经UPF间传)

    UPF-->>SMF: N4 Session Modification Response

    SMF-->>AMF: Nsmf_PDUSession_UpdateSMContext Response
    Note left of SMF: 返回DL Data Forwarding Tunnel Info

    AMF->>S_gNB: NGAP Handover Command
    Note right of AMF: IE: Target-to-Source Transparent Container,<br/>Handover Type, PDU Session Resource List,<br/>DL Forwarding Tunnel Info

3.2 关键消息IE逐层拆解

3.2.1 Handover Required(源gNB → AMF)

这是N2切换的起始消息,源gNB通过此消息告知AMF需要准备切换。其ASN.1结构定义在 TS 38.413 Section 9.2.3.1:

HandoverRequired ::= SEQUENCE {
    protocolIEs ProtocolIE-Container { {HandoverRequired-IEs} }
}

HandoverRequired-IEs NGAP-PROTOCOL-IES ::= {
    { AMF UE NGAP ID }           |  -- 必选:AMF侧UE标识
    { RAN UE NGAP ID }           |  -- 必选:RAN侧UE标识
    { Handover Type }            |  -- 必选:切换类型
    { Cause }                    |  -- 必选:触发原因
    { Target ID }                |  -- 必选:目标标识
    { Direct Forwarding Path Availability } |  -- 可选:直传路径可用性
    { PDU Session Resource List } |  -- 必选:PDU会话资源列表
    { Source to Target Transparent Container }  -- 必选:源到目标透传容器
}
IE名称 存在性 长度 说明
AMF UE NGAP ID Mandatory 40bit AMF分配的UE NGAP标识,关联现有UE上下文
RAN UE NGAP ID Mandatory 40bit 源gNB分配的UE NGAP标识
Handover Type Mandatory Enum intra5gs / inter5gs / intraLTE / interRAT
Cause Mandatory Choice radioNetwork/transport/nas/protocol/misc
Target ID Mandatory Choice target-ngran-node / target-eNB / targetRAN-node
Direct Forwarding Path Availability Optional Enum direct-path-available / not-available
PDU Session Resource List Mandatory List 每项含pduSessionID + handoverRequiredTransfer
Source to Target Transparent Container Mandatory OCTET STRING 对AMF透传,目标gNB解析RRC上下文

设计意图:AMF不解析Transparent Container内部的RRC相关信息,仅做路由转发。这种"透传设计"将无线层面的复杂性封装在RAN内部,AMF只需要关注PDU Session级别的资源管理。

3.2.2 Handover Request(AMF → 目标gNB)

AMF收到Handover Required后,需要从SMF获取每个PDU Session的N2 SM Information,然后向目标gNB发送Handover Request(TS 38.413 Section 9.2.3.2):

IE名称 说明
AMF UE NGAP ID AMF为目标gNB新分配的UE NGAP ID
RAN UE NGAP ID 预留给目标gNB填写
Source to Target Transparent Container 从Handover Required透传
PDU Session Resource Setup List 每项含PDU Session ID + N2 SM Info
N2 MM Information 安全上下文、移动性限制列表
UE Security Capabilities UE支持的加密/完整性算法
Security Key 用于目标gNB的AS安全密钥
Mobility Restriction List 禁止区、服务区限制信息

3.2.3 Handover Request Acknowledge(目标gNB → AMF)

目标gNB完成准入控制后返回此消息(TS 38.413 Section 9.2.3.3):

IE名称 说明
AMF UE NGAP ID AMF分配的标识
RAN UE NGAP ID 目标gNB分配的标识
Target to Source Transparent Container 含RRC Reconfiguration,供UE切换使用
PDU Session Resource Admitted List 成功准入的PDU Session + N3 AN Tunnel Info
PDU Session Resource Failed List 准入失败的PDU Session + 失败原因
Data Forwarding Tunnel Info DL数据转发隧道地址(直传或间接)

关键点:Target-to-Source Transparent Container中包含目标gNB为UE生成的RRC Reconfiguration消息,源gNB将其封装在HO Command中转发给UE。这是N2切换特有的"预配置"机制——目标gNB在UE到达之前就准备好了完整的RRC配置。

3.3 数据转发路径决策

N2切换支持两种数据转发模式,其决策逻辑如下:

flowchart TD
    A[AMF评估数据转发需求] --> B{源gNB与目标gNB间<br/>是否有IP连通性?}
    B -->|是| C{Direct Forwarding Path<br/>Availability = available?}
    B -->|否| F[选择间接转发 Indirect]
    C -->|是| D[选择直接转发 Direct]
    C -->|否| F
    D --> G[源gNB → 目标gNB<br/>直接转发DL数据]
    F --> H{是否需要新UPF?}
    H -->|是| I[SMF选择Intermediate UPF<br/>建立N4会话]
    H -->|否| J[使用现有UPF<br/>配置转发隧道]
    I --> K[源UPF → 中间UPF → 目标gNB]
    J --> K
转发模式 路径 优点 缺点
直接转发 源gNB → 目标gNB(Xn或直接IP) 时延低,无需UPF参与 需要IP连通性和安全关联
间接转发 源gNB → 源UPF → 目标UPF → 目标gNB 适用于无直连路径 额外UPF处理时延

四、N2切换执行阶段信令流

4.1 执行阶段时序图

sequenceDiagram
    participant UE
    participant S_gNB as 源gNB
    participant AMF
    participant SMF
    participant UPF as PSA UPF
    participant T_gNB as 目标gNB

    Note over UE,T_gNB: === N2切换执行阶段 (Execution Phase) ===

    S_gNB->>UE: RRC Reconfiguration (HO Command)
    Note right of S_gNB: 包含目标gNB生成的RRC配置<br/>Target Cell ID, C-RNTI, RACH资源

    S_gNB->>AMF: NGAP Uplink RAN Status Transfer
    Note right of S_gNB: PDCP SN状态、HFN<br/>保障数据连续性

    Note over S_gNB,T_gNB: DL数据转发开始<br/>(Direct或Indirect)

    Note over UE: UE断开源gNB<br/>同步到目标gNB

    UE->>T_gNB: RACH Preamble (如需)
    T_gNB-->>UE: RACH Response
    UE->>T_gNB: RRC Reconfiguration Complete

    T_gNB->>AMF: NGAP Handover Notify
    Note right of T_gNB: 通知AMF: UE已成功到达目标侧

    Note over AMF: AMF触发路径切换

    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Request
    Note right of AMF: 指示路径切换到目标gNB

    SMF->>UPF: N4 Session Modification
    Note right of SMF: 切换DL隧道到目标gNB<br/>释放源gNB隧道

    UPF->>S_gNB: End Marker Packets
    Note left of UPF: 在旧N3隧道上发送End Marker<br/>标记数据流边界

    UPF->>T_gNB: DL Data (新路径)
    Note left of UPF: 开始通过新N3隧道发送下行数据

    UPF-->>SMF: N4 Session Modification Response

    SMF-->>AMF: Nsmf_PDUSession_UpdateSMContext Response

    AMF->>S_gNB: NGAP UE Context Release Command
    Note right of AMF: 释放源gNB上的UE上下文

    S_gNB-->>AMF: NGAP UE Context Release Complete

    Note over UE,T_gNB: === N2切换完成 ===

4.2 执行阶段关键机制

4.2.1 RAN Status Transfer

源gNB在发送HO Command后,需要通过Uplink RAN Status Transfer消息(TS 38.413 Section 8.7.2)向目标gNB传递PDCP状态信息:

在Intra-AMF场景中,AMF直接将Uplink RAN Status Transfer转发为Downlink RAN Status Transfer给目标gNB。在Inter-AMF场景中,源AMF通过N14接口将状态信息传递给目标AMF。

4.2.2 End Marker机制

PSA UPF在切换N3隧道后,需要在旧路径上发送End Marker包(GTP-U End Marker)。这遵循 TS 29.281 Section 5.1:

4.3 Inter-AMF N2切换的特殊信令

当UE移动到不同AMF服务区域时,需要触发AMF重定位(AMF Relocation)。这涉及 N14接口信令:

sequenceDiagram
    participant S_gNB as 源gNB
    participant S_AMF as 源AMF
    participant T_AMF as 目标AMF
    participant SMF
    participant T_gNB as 目标gNB

    S_gNB->>S_AMF: Handover Required
    Note right of S_AMF: 源AMF发现Target ID<br/>不在自己服务区

    S_AMF->>T_AMF: Namf_Communication_CreateUEContext Request
    Note right of S_AMF: N14接口:传递完整UE上下文<br/>SUPI, PDU Session列表,<br/>安全上下文, 移动性限制

    T_AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Request
    Note right of T_AMF: 通知SMF AMF已变更<br/>传递T-AMF ID

    SMF-->>T_AMF: Nsmf_PDUSession_UpdateSMContext Response
    Note left of SMF: 返回N2 SM Information

    T_AMF->>T_gNB: Handover Request
    T_gNB-->>T_AMF: Handover Request Acknowledge

    T_AMF->>S_AMF: Namf_Communication_CreateUEContext Response
    Note right of T_AMF: N14接口:返回Target-to-Source<br/>Transparent Container

    S_AMF->>S_gNB: Handover Command

    Note over S_gNB,T_gNB: UE执行切换...

    T_gNB->>T_AMF: Handover Notify
    T_AMF->>S_AMF: N1N2MessageTransfer (Notification)
    S_AMF->>S_gNB: UE Context Release Command

Inter-AMF切换与Intra-AMF切换的核心差异:

维度 Intra-AMF Inter-AMF
AMF数量 同一AMF 源AMF + 目标AMF
额外接口 无 N14接口
UE上下文传递 不需要 Namf_Communication_CreateUEContext
RAN Status Transfer AMF直接转发 经N14接口转发
SMF通知 同一AMF直接调用 目标AMF调用SMF
切换时延 ~40-60ms ~60-100ms

五、N2切换状态机

从UE、gNB和AMF三个视角看N2切换的状态转换:

stateDiagram-v2
    state "UE状态" as UE {
        [*] --> RRC_CONNECTED: 已建立连接
        RRC_CONNECTED --> HO_Executing: 收到RRC Reconfig(HO)
        HO_Executing --> RRC_CONNECTED: RRC Reconfig Complete
        HO_Executing --> RRC_Reestablishment: 切换失败/RLF
    }

    state "源gNB状态" as S_gNB {
        [*] --> Serving: 正常服务UE
        Serving --> HO_Preparing: 发送Handover Required
        HO_Preparing --> HO_Executing: 收到Handover Command
        HO_Executing --> Data_Forwarding: 开始数据转发
        Data_Forwarding --> Resource_Releasing: 收到UE Context Release
        Resource_Releasing --> [*]
    }

    state "AMF状态" as AMF_State {
        [*] --> Idle: 无HO活动
        Idle --> Preparation: 收到Handover Required
        Preparation --> Waiting_SMF: 调用SMF UpdateSMContext
        Waiting_SMF --> Sending_HORequest: 所有SMF响应/超时
        Sending_HORequest --> Waiting_HOAck: 等待目标gNB
        Waiting_HOAck --> Forwarding_Setup: 收到HO Request ACK
        Forwarding_Setup --> HO_Command_Sent: 转发隧道就绪
        HO_Command_Sent --> Waiting_HONotify: 等待Handover Notify
        Waiting_HONotify --> Path_Switching: 收到Handover Notify
        Path_Switching --> Cleanup: 路径切换完成
        Cleanup --> Idle
    }

六、抓包识别与故障排查

6.1 抓包过滤器

在wireshark/tshark中识别N2切换信令:

# NGAP Handover Required
tshark -r capture.pcap -Y "ngap.procedureCode == 9 && ngap.initiatingMessage"

# NGAP Handover Request (AMF → 目标gNB)
tshark -r capture.pcap -Y "ngap.procedureCode == 14 && ngap.handoverType"

# NGAP Handover Request Acknowledge
tshark -r capture.pcap -Y "ngap.procedureCode == 14 && ngap.successfulOutcome"

# NGAP Handover Command
tshark -r capture.pcap -Y "ngap.procedureCode == 9 && ngap.successfulOutcome"

# NGAP Handover Notify
tshark -r capture.pcap -Y "ngap.procedureCode == 15"

# NGAP Uplink/Downlink RAN Status Transfer
tshark -r capture.pcap -Y "ngap.procedureCode == 22 || ngap.procedureCode == 23"

# 所有NGAP切换相关消息
tshark -r capture.pcap -Y "ngap.procedureCode >= 9 && ngap.procedureCode <= 23"

6.2 关键故障场景

故障现象 可能原因 排查思路
Handover Required后无Handover Request AMF无法解析Target ID;目标gNB不可达 检查AMF日志中Target ID解析;验证NG接口状态
目标gNB返回Handover Failure 无线资源不足;QoS无法满足 检查目标gNB负载;对比Admitted QoS与请求QoS
Handover Command后UE不切换 RRC Reconfiguration损坏;目标小区同步失败 解码Transparent Container;检查目标小区PCI/SSB
Handover Notify超时 UE未成功接入目标gNB;RACH失败 检查目标gNB RACH日志;验证UE的TA信息
数据丢包 数据转发隧道配置错误;End Marker丢失 检查N3/N9隧道配置;验证Data Forwarding Info
切换后会话中断 SMF未完成路径切换;UPF隧道未更新 检查N4 Session Modification是否成功
## 七、N2切换与Xn切换深度对比
对比维度 Xn切换 N2切换
核心规范 TS 23.502 §4.9.1.2 TS 23.502 §4.9.1.3
信令路径 源gNB ↔ 目标gNB直连 源gNB → AMF → 目标gNB
AMF参与 仅Path Switch阶段 全程参与
SMF参与 仅Path Switch后 准备阶段即参与
时延 ~10-20ms ~40-100ms
数据转发 仅直接转发(Xn) 直接或间接(经UPF)
AMF重定位 不支持 支持N14重定位
准入控制 目标gNB自主 目标gNB + AMF协调
失败回退 回源gNB 回源gNB或重建
适用场景 同AMF、同厂家、Xn可达 跨AMF、跨厂家、Xn不可达

设计哲学差异:Xn切换追求效率——将切换控制权下放给RAN,核心网仅做路径更新;N2切换追求可控性——核心网全程掌控切换决策与资源分配,适合需要网络侧强控制的场景(如跨厂商、跨PLMN)。

常见问题

Q: N2切换中AMF何时决定进行AMF重定位? A: 源AMF收到Handover Required后,解析Target ID中的TAI(Tracking Area Identity)。如果该TAI不属于当前AMF的服务区域(基于配置的TA List),源AMF将执行AMF Selection Function选择新的目标AMF,并通过N14接口的Namf_Communication_CreateUEContext服务将UE上下文迁移到目标AMF。整个过程对UE透明——UE不会感知AMF的变化。

Q: Direct Forwarding Path Availability这个IE的作用是什么? A: 这个可选IE由源gNB在Handover Required中携带,告知AMF源gNB与目标gNB之间是否存在可用于数据直接转发的IP路径。如果标记为"direct-path-available",AMF和SMF会优先选择直接转发模式(数据直接从源gNB转发到目标gNB),从而减少数据转发时延。如果不存在或标记为不可用,则必须使用间接转发(经UPF中转)。

Q: N2切换中PDU Session部分失败如何处理? A: 目标gNB在Handover Request Acknowledge中会区分Admitted List和Failed List。对于准入失败的PDU Session,SMF可以决定:①保持该Session在源侧(不切换),②释放该Session,或③在切换完成后由SMF发起PDU Session Modification尝试重建。这个"部分成功"机制是N2切换相比Xn切换的重要区别——Xn切换中PDU Session资源是在Path Switch阶段统一处理的。

Q: 切换过程中如果UE发生Radio Link Failure(RLF)会怎样? A: 如果UE在切换执行阶段(收到HO Command后、发送RRC Reconfig Complete前)发生RLF,UE会尝试在目标gNB发起RRC Re-establishment。如果Re-establishment成功,目标gNB会继续向AMF发送Handover Notify完成切换流程。如果Re-establishment也失败,UE进入RRC_IDLE状态,需要重新发起Service Request或Registration流程恢复连接。

Q: N2切换的End Marker包为什么对数据连续性至关重要? A: 路径切换后,UPF从旧N3隧道切换到新N3隧道。但旧隧道上可能还有"在途"的数据包尚未到达源gNB。如果没有End Marker,源gNB和目标gNB都无法确定何时停止等待旧路径的数据。End Marker作为旧路径上的"结束标记",告诉源gNB"这是最后一个包了",源gNB将其转发给目标gNB后,目标gNB知道可以进行最终的重排序并向上层交付所有数据。

参考来源

  1. 3GPP TS 23.502 V18.10.0 — Section 4.9.1 Handover procedures, Section 4.9.1.3 N2-based Handover
  2. 3GPP TS 38.413 V18.x — Section 8.4 Handover Preparation, Section 9.2.3 NGAP Handover Messages
  3. free5GC Blog: Introduction of Xn and NG(N2) based handover — N2切换准备与执行阶段详细步骤
  4. 3GLTEInfo: 5G NR N2 Handover Procedure — N2切换信令流分析
  5. 3GLTEInfo: NGAP Handover Required Message — Handover Required IE结构详解

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