# 5G N2切换信令流与数据转发三模式博弈 ## 一、N2切换的定位与触发条件 在5G系统中，当UE处于CM-CONNECTED状态进行小区间移动时，源gNB需要根据测量报告决定是否触发切换。按照TS 23.502 Section 4.9.1的定义，**N2切换（NG-RAN节点间N2切换）**是在源gNB与目标gNB之间不存在Xn接口、或Xn接口不可用、或Xn切换失败后回退的场景下使用的核心网控制切换流程。 与Xn切换相比，N2切换的显著差异在于**所有切换信令必须经由AMF中转**，控制面路径为：`Source gNB → AMF → SMF → UPF → Target gNB`，用户面数据转发也必须通过核心网UPF中继（间接转发），而非gNB之间的直接隧道。 **N2切换的典型触发场景**： | 触发场景 | 说明 | |----------|------| | 无Xn接口 | 不同厂商gNB之间、跨部署区域场景 | | Xn切换失败回退 | Xn切换准备阶段失败后，源gNB发起N2切换 | | 跨AMF区域 | UE移动到不同AMF服务区域 | | 不同PLMN | 跨运营商切换（需N2接口支持） | | 跨接入技术 | 5G NR到LTE的跨RAT切换（Inter-RAT） | 按照TS 38.300 Section 9.3.2的定义，源gNB在以下条件下选择N2切换而非Xn切换： 1. 目标小区所属gNB不在源gNB的Xn邻居列表中 2. 源gNB已尝试Xn切换但收到Xn HANDOVER PREPARATION FAILURE 3. 网络OAM配置强制特定场景使用N2切换（如跨切片场景） ## 二、N2切换完整信令流解析（TS 23.502 Section 4.9.1.3） N2切换分为三个阶段：**准备阶段（Preparation）**、**执行阶段（Execution）**和**完成阶段（Completion）**。以下按照TS 23.502 Section 4.9.1.3.1（无AMF变更、无UPF变更）和Section 4.9.1.3.2（无AMF变更、有UPF变更）两个典型场景进行拆解。 ### 2.1 完整信令时序图 ```mermaid 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: Phase 1: 准备阶段 (Preparation) UE->>S_gNB: Measurement Report S_gNB->>S_gNB: 切换决策：选择N2切换 S_gNB->>AMF: N2 HANDOVER REQUIRED
Target ID, Source-to-Target
Transparent Container,
PDU Session Resource List AMF->>SMF: Nsmf_PDUSession_UpdateSMC Request
N2 SM Info, Target ID,
PDU Session ID SMF->>UPF: N4 Session Modification Request
更新下行隧道信息
请求Data Forwarding Info UPF-->>SMF: N4 Session Modification Response
Data Forwarding Info
(N3 DL TEID for forwarding) SMF-->>AMF: Nsmf_PDUSession_UpdateSMC Response
N2 SM Information
(PDU Session Resource Setup
Transfer IE) AMF->>T_gNB: N2 HANDOVER REQUEST
Target ID, N2 SM Info,
Source-to-Target Container T_gNB->>T_gNB: 分配无线资源
建立DRB T_gNB-->>AMF: N2 HANDOVER REQUEST ACK
Target-to-Source Container,
PDU Session Resource
Admitted List,
Data Forwarding Info AMF->>SMF: Nsmf_PDUSession_UpdateSMC Request
Data Forwarding Info Response SMF->>UPF: N4 Session Modification Request
建立数据转发隧道
(Indirect Forwarding) UPF-->>SMF: N4 Session Modification Response SMF-->>AMF: Nsmf_PDUSession_UpdateSMC Response
确认转发隧道建立 AMF->>S_gNB: N2 HANDOVER COMMAND
Target-to-Source Container,
Data Forwarding Info
(N3 UL TEID) Note over UE,T_gNB: Phase 2: 执行阶段 (Execution) S_gNB->>UE: RRC Reconfiguration
HO execution command S_gNB->>UPF: 数据转发开始
DL数据通过N3隧道转发 UE->>T_gNB: RACH / 随机接入
同步到目标小区 UE->>T_gNB: RRC Reconfiguration Complete T_gNB->>AMF: N2 HANDOVER NOTIFY
PDU Session Resource
Notify List Note over UE,T_gNB: Phase 3: 完成阶段 (Completion) AMF->>SMF: Nsmf_PDUSession_UpdateSMC Request
通知切换完成 SMF->>UPF: N4 Session Modification Request
切换DL数据路径到目标gNB
更新N3隧道端点 UPF-->>SMF: N4 Session Modification Response
路径切换完成 SMF->>SMF: 启动间接数据转发定时器
(Indirect Forwarding Timer) SMF->>AMF: Nsmf_PDUSession_UpdateSMC Response AMF->>S_gNB: N2 UE CONTEXT RELEASE
释放源侧资源 Note over SMF: 定时器到期后
释放数据转发资源 ``` ### 2.2 准备阶段关键IE解析 **步骤1：Handover Required（TS 23.502 Section 4.9.1.3.1 Step 1）** 源gNB向AMF发送**NGAP HANDOVER REQUIRED**消息（TS 38.413 Section 8.7.1），核心IE如下： | IE名称 | 含义 | 取值示例 | |--------|------|----------| | Target ID | 标识目标gNB | Target gNB ID + TAC | | Source-to-Target Transparent Container | 源gNB给目标gNB的透传信息 | 包含UE History、RLF Report、RRM Config等 | | PDU Session Resource Handover List | 需要切换的PDU Session列表 | 每个条目包含PDU Session ID + N2 SM Info | | Handover Type | 切换类型 | intra5GS(0) | | Cause | 切换原因 | ho-radio(16), ho-load(17)等 | 其中**N2 SM Information**（由源gNB打包在PDU Session Resource中）包含： - **PDU Session ID**：标识需要切换的会话 - **QoS Flow Information**：当前会话中所有激活的QoS Flow及其参数 - **Source-to-Target Transparency**：包含当前N3 UL TEID、QoS参数等 **设计意图**：将UE上下文信息完整透传给目标侧，避免通过核心网多次查询，减少切换准备时延。Source-to-Target Container在5G中比4G的ENB间透传信息更加丰富，新增了UE Radio Capability ID、UE History Information等字段。 **步骤2-3：SMF/UPF资源准备** AMF收到HANDOVER REQUIRED后，根据PDU Session ID查找对应的SMF，向每个SMF发送**Nsmf_PDUSession_UpdateSMC Request**。SMF执行以下判断逻辑： ``` IF 目标gNB在当前PSA UPF的服务范围内: 无需UPF变更，使用现有UPF → 向UPF请求数据转发信息 ELSE: 需要UPF变更 → 选择目标侧新PSA UPF → 建立N9隧道连接新旧UPF END IF ``` SMF向UPF发送**N4 Session Modification Request**，其中关键字段： | N4 IE | 含义 | |-------|------| | Create Forwarding Rules | 创建数据转发规则 | | FAR ID | 标识转发动作规则 | | Forwarding Parameters | 包含数据转发的目标地址和TEID | | Apply Action | 指示UPF执行转发（FORW）或缓存（BUFF） | ### 2.3 执行阶段关键操作 **Handover Command下发**：AMF向源gNB发送**N2 HANDOVER COMMAND**，其中包含： - **Target-to-Source Transparent Container**：目标gNB为UE准备的RRC Reconfiguration消息 - **Data Forwarding Information**：N3上行数据转发隧道信息（UL TEID + UPF IP地址） 源gNB收到后执行： 1. 将Target-to-Source Container封装在**RRC Reconfiguration**消息中下发给UE 2. 开始将下行数据通过N3转发隧道发送给UPF进行缓存或转发 3. 停止向UE发送新数据 **UE侧执行**：UE收到RRC Reconfiguration后： 1. 断开与源gNB的连接 2. 在目标gNB发起随机接入（RACH） 3. 完成同步后发送**RRC Reconfiguration Complete** ## 三、数据转发三模式博弈 N2切换中最核心的技术决策是**数据转发模式的选择**。按照TS 23.502 Section 4.9.1的定义，存在三种模式：直接转发、间接转发和无转发。 ```mermaid graph TB subgraph 直接转发模式 S1[源gNB] -->|Xn/N3隧道| T1[目标gNB] end subgraph 间接转发模式 S2[源gNB] -->|N3隧道| UPF[I-UPF/PSA UPF] UPF -->|N3隧道| T2[目标gNB] end subgraph 无转发模式 S3[源gNB] -->|丢弃数据| X[数据丢失] UPF2[PSA UPF] -->|直接发送| T3[目标gNB] end style X fill:#ff6666 ``` ### 3.1 三种模式对比 | 维度 | 直接转发 | 间接转发 | 无转发 | |------|---------|---------|--------| | **定义** | 源gNB直接向目标gNB转发数据 | 通过UPF/I-UPF中继转发 | 不转发，数据在源侧丢弃 | | **适用场景** | N2切换中较少使用（Xn可用时优先Xn） | N2切换最常用模式 | URLCC低延迟业务、MNPs等 | | **转发路径** | Source gNB → Target gNB | Source gNB → UPF → Target gNB | 无转发路径 | | **隧道类型** | N3或Xn-U GTP-U隧道 | N3 + N9 GTP-U隧道 | 不适用 | | **额外资源消耗** | 需要gNB间直连隧道 | 需要UPF建立转发规则 | 无额外资源 | | **数据丢失风险** | 低 | 低 | 中高（切换期间下行数据丢失） | | **延迟影响** | 最小 | 略高（多一跳UPF） | 取决于重传机制 | | **SMF复杂度** | 低 | 高（需管理转发定时器） | 最低 | | **TS 23.502章节** | 4.9.1.3.1 General | 4.9.1.3.1 Step 9a/9b | 4.9.1.3.1 Step 4c | ### 3.2 间接数据转发隧道建立（核心机制） 在N2切换中，间接数据转发是最关键的机制。SMF通过**N4 Session Modification**向UPF下发转发规则，建立一条从源gNB经过UPF到达目标gNB的数据转发隧道。 **转发规则建立的PFCP信令流**： ```mermaid sequenceDiagram participant SMF participant I_UPF as I-UPF/PSA UPF SMF->>I_UPF: N4 Session Modification Request
PFCP Session Modification Request
{Create FAR: Apply Action=FORW,
Forwarding Parameters:
Outer Header Creation=
Target gNB IP + N3 TEID} I_UPF->>I_UPF: 创建转发规则
匹配UL TEID→DL TEID I_UPF-->>SMF: N4 Session Modification Response
PFCP Session Modification Response
{F-SEID, Created FAR} ``` **PFCP转发规则的关键参数**： | PFCP IE | 参数 | 说明 | |---------|------|------| | Create FAR | Apply Action = FORW | 指示UPF执行转发而非缓存 | | Forwarding Parameters | Outer Header Creation | 封装GTP-U头：目标IP + TEID | | Forwarding Parameters | Network Instance | 指定转发网络实例 | | Match FAR | Apply Action = FORW | 匹配上行数据转发规则 | | Update FAR | Destination Interface = Access | 指向无线接入侧接口 | **设计意图**：间接数据转发的设计考虑了以下因素： 1. **通用性**：不依赖gNB之间的Xn直连接口，适用于任何N2切换场景 2. **可控性**：SMF通过N4接口精确控制转发隧道的建立和释放，由**间接数据转发定时器（Indirect Data Forwarding Timer）**管理资源生命周期 3. **计费完整性**：数据经由UPF转发，确保计费功能（CHF）可以准确统计切换期间的数据流量 ### 3.3 间接数据转发定时器博弈 SMF在完成阶段启动一个**间接数据转发定时器**，该定时器到期后释放转发隧道资源。这个定时器是一个关键的运营商可配参数： | 定时器配置 | 影响 | |-----------|------| | 定时器过短 | 数据转发隧道提前释放，可能导致正在传输的数据包丢失 | | 定时器过长 | UPF转发资源被长时间占用，浪费隧道和缓存资源 | | 典型值 | 运营商通常配置为**5-30秒**，具体取决于网络拓扑和数据转发路径长度 | 按照TS 23.502 Section 4.9.1.3.1 Step 14的描述，当定时器到期时，SMF向参与转发的UPF发送N4 Session Modification Request释放转发规则，同时通知源gNB通过AMF释放源侧资源（如果尚未释放）。 ## 四、UPF重定位场景（TS 23.502 Section 4.9.1.3.2） 当目标gNB不在当前PSA UPF的服务区域内时，SMF需要选择新的PSA UPF，这引入了更复杂的信令交互。在此场景下，可能涉及**I-SMF（Intermediate SMF）**的插入或变更。 ### 4.1 UPF重定位时的N4会话管理 ```mermaid graph LR subgraph 源侧 S_gNB[源gNB] S_UPF[源PSA UPF] end subgraph 目标侧 T_gNB[目标gNB] T_UPF[目标PSA UPF] end subgraph 核心网 SMF[SMF] end S_gNB -->|N3 Old| S_UPF S_UPF -->|N9| T_UPF T_UPF -->|N3 New| T_gNB S_gNB -.->|N3 转发| S_UPF SMF -.->|N4| S_UPF SMF -.->|N4| T_UPF ``` **关键步骤差异**： 1. **SMF选择新PSA UPF**：基于目标gNB位置、DNAI（DN Access Identifier）、UE IP地址保持策略等 2. **建立N9隧道**：在旧PSA UPF与新PSA UPF之间建立GTP-U隧道，保证数据连续性 3. **双N4会话管理**：SMF同时管理新旧UPF的N4会话，直到切换完全完成 4. **路径切换**：SMF通过N4 Session Modification将DL数据路径从旧UPF切换到新UPF ### 4.2 I-SMF插入/变更场景 当目标gNB与源gNB位于不同I-SMF服务区域时，涉及I-SMF的插入或变更（TS 23.502 Section 4.23.7）： | 场景 | 信令路径 | 复杂度 | |------|---------|--------| | 同AMF、同SMF、同UPF | 最简单：SMF直接管理 | 低 | | 同AMF、同SMF、不同UPF | SMF选择新UPF，建立N9隧道 | 中 | | 同AMF、不同I-SMF | 需插入目标I-SMF，通过N16a接口协调 | 高 | | 不同AMF | 需AMF重定位，通过N14接口转发 | 最高 | ## 五、N2切换NGAP信令深度解析 ### 5.1 HANDOVER REQUIRED消息结构（TS 38.413 Section 8.7.1.2） ``` HANDOVER REQUIRED ::= { protocolIEs { id: AMF UE NGAP ID, id: RAN UE NGAP ID, id: Handover Type, -- intra5GS/inter5GS id: Cause, -- 切换原因 id: Target ID, -- 目标gNB标识 id: Direct Forwarding Path Availability, -- 直接转发可用性 id: PDU Session Resource Handover List, { -- PDU Session列表 PDU Session ID, Handover Request Transfer, -- N2 SM Info SN Transfer Information -- 安全上下文（加密/完整性保护） }, id: Source to Target Transparent Container -- 透传容器 } } ``` **关键字段说明**： | IE | 详细说明 | |----|---------| | **Direct Forwarding Path Availability** | 指示源gNB是否支持直接数据转发。若存在且为true，SMF可选择直接转发 | | **SN Transfer Information** | 包含PDCP SN状态（UL/DL COUNT值），确保PDCP层安全上下文连续性 | | **Source to Target Transparent Container** | 包含CellGroupConfig、RRCReconfiguration、UE Capability等 | ### 5.2 HANDOVER REQUEST消息结构（TS 38.413 Section 8.7.1.3） AMF向目标gNB发送HANDOVER REQUEST，核心IE： | IE | 含义 | |----|------| | UE Aggregate Maximum Bit Rate | UE聚合最大比特率 | | PDU Session Resource Setup List | 需要建立的PDU Session资源列表 | | Handover Request Transfer | N2 SM Info（含QoS参数、隧道信息） | | Security Key | 新的安全密钥（K~gNB~或NH） | | UE Security Capabilities | UE支持的安全算法 | | Source to Target Transparent Container | 来自源gNB的透传信息 | **设计意图**：AMF在此消息中携带**新的安全密钥**，确保目标gNB使用独立的安全上下文。密钥推演遵循TS 33.501定义的密钥层级：`KAMF → KgNB → KRRCenc/KRRCint/KUPenc`。 ## 六、故障处理与定时器管理 ### 6.1 切换失败场景状态转换图 ```mermaid stateDiagram-v2 [*] --> HO_Preparation: 源gNB发送
HANDOVER REQUIRED HO_Preparation --> HO_Execution: AMF发送
HANDOVER COMMAND HO_Preparation --> HO_Preparation_Failure: 目标gNB拒绝
或定时器超时 HO_Preparation_Failure --> [*]: 源gNB维持连接
释放切换资源 HO_Execution --> HO_Completion: 目标gNB发送
HANDOVER NOTIFY HO_Execution --> HO_Execution_Failure: UE未接入目标
或定时器超时 HO_Execution_Failure --> HO_Recovery: 源gNB发起
RRC Reestablishment HO_Execution_Failure --> RRC_Connection_Release: 源gNB释放连接
UE发起Registration HO_Completion --> [*]: 释放源侧资源
数据路径切换完成 HO_Recovery --> [*]: 恢复到源gNB
或发起新切换 ``` ### 6.2 关键定时器 | 定时器 | 定义位置 | 用途 | 典型值 | 超时处理 | |--------|---------|------|--------|---------| | T~NG-HO~Prep~ | AMF本地 | 切换准备阶段保护 | 5-10s | 向源gNB发送HANDOVER PREPARATION FAILURE | | T~NG-HO~Exec~ | 源gNB本地 | 切换执行阶段保护 | 5-10s | 向AMF发送HANDOVER FAILURE | | Indirect Forwarding Timer | SMF本地 | 间接数据转发资源保护 | 5-30s | 释放UPF转发隧道 | | N4 Session Modification Timer | SMF本地 | N4操作响应等待 | 3-5s | 重试或标记会话异常 | | RRC Reconfiguration Timer | gNB本地 | UE响应RRC重配等待 | 1-2s | 触发RRC连接释放 | ### 6.3 故障处理流程 **准备阶段失败**（TS 23.502 Section 4.9.1.3.1 Step 4a）： - 目标gNB资源不足时，返回HANDOVER FAILURE给AMF - AMF转发HANDOVER PREPARATION FAILURE给源gNB - 源gNB可选择：尝试其他目标小区、降低QoS需求重试、维持当前连接 **执行阶段失败**： - UE在目标gNB随机接入失败 - 源gNB检测到T~NG-HO~Exec~超时 - 源gNB向AMF发送HANDOVER FAILURE - SMF释放已建立的转发隧道和目标侧资源 - UE可能发起RRC Reestablishment回到源gNB或发起新Registration ## 七、抓包识别与故障排查 ### 7.1 抓包识别关键点 在NGAP（N2接口）抓包中，N2切换的信令特征： | 消息 | 方向 | 过滤条件 | |------|------|---------| | HANDOVER REQUIRED | gNB→AMF | `ngap.procedureCode == 22 && ngap.messageType == 0` | | HANDOVER REQUEST | AMF→gNB | `ngap.procedureCode == 22 && ngap.messageType == 1` | | HANDOVER REQUEST ACK | gNB→AMF | `ngap.procedureCode == 22 && ngap.messageType == 2` | | HANDOVER COMMAND | AMF→gNB | `ngap.procedureCode == 22 && ngap.messageType == 3` | | HANDOVER NOTIFY | gNB→AMF | `ngap.procedureCode == 22 && ngap.messageType == 4` | | UE CONTEXT RELEASE | AMF→gNB | `ngap.procedureCode == 41` | **Wireshark过滤表达式**： ``` # 捕获所有N2切换相关信令 ngap.procedureCode == 22 || (ngap.procedureCode == 41 && ngap.cause.radioNetwork == 20) # 捕获特定UE的N2切换 ngap.procedureCode == 22 && ngap.AMF_UE_NGAP_ID == ``` ### 7.2 常见故障点与排错思路 | 故障现象 | 可能原因 | 排错方法 | |----------|---------|---------| | HANDOVER REQUIRED后无HANDOVER REQUEST | AMF找不到目标gNB、SMF故障 | 检查AMF日志中的Target ID解析、NRF中gNB注册信息 | | HANDOVER REQUEST ACK中PDU Session Resource未获接纳 | 目标gNB资源不足 | 检查目标gNB负载、QoS参数是否超出目标小区能力 | | 间接数据转发隧道建立失败 | UPF N4会话修改失败 | 检查SMF→UPF的PFCP消息、UPF资源可用性 | | UE在目标侧随机接入失败 | 目标gNB参数配置错误 | 检查SSB配置、PRACH参数、TAC一致性 | | 切换后数据面不通 | UPF路径切换未完成 | 检查N4 Session Modification是否成功、N3/N9隧道是否建立 | | 切换后QoS降级 | QoS Flow映射失败 | 检查目标gNB的QoS Flow到DRB映射是否正确 | ## 八、N2切换与Xn切换的深度对比 | 对比维度 | Xn切换 | N2切换 | |----------|--------|--------| | **信令路径** | gNB↔gNB（Xn接口直连） | gNB→AMF→SMF→UPF→gNB | | **控制面时延** | 较低（~10-20ms） | 较高（~30-80ms） | | **数据面中断** | 几乎无中断 | 短暂中断（数据转发延迟） | | **适用条件** | 需要Xn接口 | 无条件限制 | | **AMF参与** | 仅通知（Notified） | 深度参与（控制协调） | | **SMF参与** | 切换后更新 | 切换前即参与 | | **UPF变更** | 可能需要 | 通常伴随 | | **安全密钥更新** | gNB间直接传递 | 经由AMF分发 | | **标准章节** | TS 23.502 Section 4.9.1.2 | TS 23.502 Section 4.9.1.3 | **运营商成本博弈分析**：N2切换虽然时延更高，但在以下场景中运营商仍然需要大量使用： 1. **异厂商组网**：不同基站厂商之间Xn接口兼容性差，N2切换是唯一选择 2. **跨区域切换**：跨TA区域切换通常需要核心网参与 3. **切片间切换**：不同网络切片的gNB可能无法建立Xn接口 4. **成本控制**：减少Xn接口规划复杂度，统一使用N2切换降低运维成本 ## 常见问题 **Q1: N2切换中直接转发和间接转发可以同时使用吗？** A: 不可以。按照TS 23.502 Section 4.9.1.3.1的规定，SMF根据源gNB在HANDOVER REQUIRED中携带的**Direct Forwarding Path Availability** IE来决定使用哪种转发模式。如果源gNB指示直接转发可用，SMF可以选择直接或间接转发；如果指示不可用，SMF必须使用间接转发。在实际部署中，由于N2切换通常发生在无Xn接口的场景，直接转发极少使用。 **Q2: N2切换中UPF如何保证数据不丢失？** A: UPF通过三层机制保障数据完整性：(1) **数据缓存**：SMF在N4 Session Modification中设置Apply Action=BUFF，使UPF在路径切换前缓存下行数据；(2) **数据转发**：通过间接转发隧道将源侧未确认的数据转发到目标gNB；(3) **PDCP SN传递**：源gNB在SN Transfer Information中携带PDCP UL/DL COUNT值，目标gNB据此进行重复检测和按序递交。 **Q3: N2切换的端到端时延主要消耗在哪里？** A: 主要时延分布在三个阶段：(1) **AMF中转时延**（~5-15ms）：AMF需要解析每个PDU Session并分别联系SMF；(2) **SMF/UPF资源准备时延**（~10-30ms）：SMF与UPF之间的N4交互、转发隧道建立；(3) **UE接入时延**（~5-15ms）：UE在目标gNB的RACH和RRC完成过程。对于URLLC业务，N2切换的总时延（~30-80ms）可能无法满足端到端1ms要求，需要依赖RRC_INACTIVE状态下的RNA更新机制来规避切换。 **Q4: 间接数据转发定时器设置过短会有什么影响？** A: 定时器过短会导致UPF在数据转发尚未完成时就释放转发隧道。具体表现为：(1) 正在转发中的下行数据包被UPF丢弃；(2) 目标gNB收到的PDCP SDU不连续，需要UE侧PDCP重排序；(3) 对于TCP业务可能导致重传超时，吞吐量下降。建议根据网络拓扑和数据转发路径的实际RTT来配置定时器，通常设置为数据转发路径RTT的3-5倍。 **Q5: N2切换与4G的S1切换有什么区别？** A: 核心区别在于：(1) **数据转发路径不同**：4G S1切换通过S-GW转发，5G N2切换通过UPF转发，UPF可编程性更强；(2) **会话管理不同**：4G中bearer粒度管理，5G中PDU Session + QoS Flow粒度管理；(3) **切片支持**：5G N2切换原生支持切片感知，可触发I-SMF变更；(4) **安全机制**：5G使用基于KAMF的密钥层级推演，支持前向安全，4G使用KeNB。总体而言，5G N2切换的灵活性更高，但信令复杂度也相应增加。 ## 参考来源 1. [3GPP TS 23.502 V18.10.0](https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/18.10.00_60/ts_123502v181000p.pdf) — Section 4.9.1.3: Inter NG-RAN node N2 based handover 2. [3GPP TS 38.413 V18.6.0](https://www.3gpp.org/DynaReport/38413.htm) — Section 8.7: NGAP Handover Procedures 3. [Ericsson: Indirect vs. direct data forwarding](https://www.ericsson.com/en/blog/2020/4/indirect-direct-data-forwarding-5g-3gpp) — 数据转发模式深度对比分析 4. [free5GC: Xn and N2 Handover Introduction](https://free5gc.org/blog/20251105/20251105/) — 开源5GC中的切换实现分析 5. [ETH Zurich: Comprehensive Formal Analysis of 5G Handover](https://people.inf.ethz.ch/rsasse/pub/5G-handover-WISEC21.pdf) — 5G切换协议的形式化安全分析 --- > 本文由「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 等场景全覆盖。