在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切换在以下场景被触发:
| 触发场景 | 说明 | 典型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 |
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]
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
这是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级别的资源管理。
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 | 禁止区、服务区限制信息 |
目标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配置。
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处理时延 |
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切换完成 ===
源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。
PSA UPF在切换N3隧道后,需要在旧路径上发送End Marker包(GTP-U End Marker)。这遵循 TS 29.281 Section 5.1:
当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 |
从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
}
在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"
| 故障现象 | 可能原因 | 排查思路 |
|---|---|---|
| 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知道可以进行最终的重排序并向上层交付所有数据。
本文由「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 等场景全覆盖。
