在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切换分为三个阶段:准备阶段(Preparation)、执行阶段(Execution)和完成阶段(Completion)。以下按照TS 23.502 Section 4.9.1.3.1(无AMF变更、无UPF变更)和Section 4.9.1.3.2(无AMF变更、有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: Phase 1: 准备阶段 (Preparation)
UE->>S_gNB: Measurement Report
S_gNB->>S_gNB: 切换决策:选择N2切换
S_gNB->>AMF: N2 HANDOVER REQUIRED<br/>Target ID, Source-to-Target<br/>Transparent Container,<br/>PDU Session Resource List
AMF->>SMF: Nsmf_PDUSession_UpdateSMC Request<br/>N2 SM Info, Target ID,<br/>PDU Session ID
SMF->>UPF: N4 Session Modification Request<br/>更新下行隧道信息<br/>请求Data Forwarding Info
UPF-->>SMF: N4 Session Modification Response<br/>Data Forwarding Info<br/>(N3 DL TEID for forwarding)
SMF-->>AMF: Nsmf_PDUSession_UpdateSMC Response<br/>N2 SM Information<br/>(PDU Session Resource Setup<br/>Transfer IE)
AMF->>T_gNB: N2 HANDOVER REQUEST<br/>Target ID, N2 SM Info,<br/>Source-to-Target Container
T_gNB->>T_gNB: 分配无线资源<br/>建立DRB
T_gNB-->>AMF: N2 HANDOVER REQUEST ACK<br/>Target-to-Source Container,<br/>PDU Session Resource<br/>Admitted List,<br/>Data Forwarding Info
AMF->>SMF: Nsmf_PDUSession_UpdateSMC Request<br/>Data Forwarding Info Response
SMF->>UPF: N4 Session Modification Request<br/>建立数据转发隧道<br/>(Indirect Forwarding)
UPF-->>SMF: N4 Session Modification Response
SMF-->>AMF: Nsmf_PDUSession_UpdateSMC Response<br/>确认转发隧道建立
AMF->>S_gNB: N2 HANDOVER COMMAND<br/>Target-to-Source Container,<br/>Data Forwarding Info<br/>(N3 UL TEID)
Note over UE,T_gNB: Phase 2: 执行阶段 (Execution)
S_gNB->>UE: RRC Reconfiguration<br/>HO execution command
S_gNB->>UPF: 数据转发开始<br/>DL数据通过N3隧道转发
UE->>T_gNB: RACH / 随机接入<br/>同步到目标小区
UE->>T_gNB: RRC Reconfiguration Complete
T_gNB->>AMF: N2 HANDOVER NOTIFY<br/>PDU Session Resource<br/>Notify List
Note over UE,T_gNB: Phase 3: 完成阶段 (Completion)
AMF->>SMF: Nsmf_PDUSession_UpdateSMC Request<br/>通知切换完成
SMF->>UPF: N4 Session Modification Request<br/>切换DL数据路径到目标gNB<br/>更新N3隧道端点
UPF-->>SMF: N4 Session Modification Response<br/>路径切换完成
SMF->>SMF: 启动间接数据转发定时器<br/>(Indirect Forwarding Timer)
SMF->>AMF: Nsmf_PDUSession_UpdateSMC Response
AMF->>S_gNB: N2 UE CONTEXT RELEASE<br/>释放源侧资源
Note over SMF: 定时器到期后<br/>释放数据转发资源
步骤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) |
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的定义,存在三种模式:直接转发、间接转发和无转发。
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
| 维度 | 直接转发 | 间接转发 | 无转发 |
|---|---|---|---|
| 定义 | 源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 |
在N2切换中,间接数据转发是最关键的机制。SMF通过N4 Session Modification向UPF下发转发规则,建立一条从源gNB经过UPF到达目标gNB的数据转发隧道。
转发规则建立的PFCP信令流:
sequenceDiagram
participant SMF
participant I_UPF as I-UPF/PSA UPF
SMF->>I_UPF: N4 Session Modification Request<br/>PFCP Session Modification Request<br/>{Create FAR: Apply Action=FORW,<br/>Forwarding Parameters:<br/>Outer Header Creation=<br/>Target gNB IP + N3 TEID}
I_UPF->>I_UPF: 创建转发规则<br/>匹配UL TEID→DL TEID
I_UPF-->>SMF: N4 Session Modification Response<br/>PFCP Session Modification Response<br/>{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)可以准确统计切换期间的数据流量
SMF在完成阶段启动一个间接数据转发定时器,该定时器到期后释放转发隧道资源。这个定时器是一个关键的运营商可配参数:
| 定时器配置 | 影响 |
|---|---|
| 定时器过短 | 数据转发隧道提前释放,可能导致正在传输的数据包丢失 |
| 定时器过长 | UPF转发资源被长时间占用,浪费隧道和缓存资源 |
| 典型值 | 运营商通常配置为5-30秒,具体取决于网络拓扑和数据转发路径长度 |
按照TS 23.502 Section 4.9.1.3.1 Step 14的描述,当定时器到期时,SMF向参与转发的UPF发送N4 Session Modification Request释放转发规则,同时通知源gNB通过AMF释放源侧资源(如果尚未释放)。
当目标gNB不在当前PSA UPF的服务区域内时,SMF需要选择新的PSA UPF,这引入了更复杂的信令交互。在此场景下,可能涉及I-SMF(Intermediate SMF)的插入或变更。
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
关键步骤差异:
当目标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接口转发 | 最高 |
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等 |
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。
stateDiagram-v2
[*] --> HO_Preparation: 源gNB发送<br/>HANDOVER REQUIRED
HO_Preparation --> HO_Execution: AMF发送<br/>HANDOVER COMMAND
HO_Preparation --> HO_Preparation_Failure: 目标gNB拒绝<br/>或定时器超时
HO_Preparation_Failure --> [*]: 源gNB维持连接<br/>释放切换资源
HO_Execution --> HO_Completion: 目标gNB发送<br/>HANDOVER NOTIFY
HO_Execution --> HO_Execution_Failure: UE未接入目标<br/>或定时器超时
HO_Execution_Failure --> HO_Recovery: 源gNB发起<br/>RRC Reestablishment
HO_Execution_Failure --> RRC_Connection_Release: 源gNB释放连接<br/>UE发起Registration
HO_Completion --> [*]: 释放源侧资源<br/>数据路径切换完成
HO_Recovery --> [*]: 恢复到源gNB<br/>或发起新切换
| 定时器 | 定义位置 | 用途 | 典型值 | 超时处理 |
|---|---|---|---|---|
| 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连接释放 |
准备阶段失败(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
在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 == <UE_ID>
| 故障现象 | 可能原因 | 排错方法 |
|---|---|---|
| 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切换的灵活性更高,但信令复杂度也相应增加。
本文由「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 等场景全覆盖。
