基于3GPP TS 23.502 Section 4.3.5 / TS 23.501 Section 5.6.9的深度机制解析
在5G网络中，一个看似简单的"手机移动后数据如何继续传输"问题，背后隐藏着IP地址连续性、UPF锚点位置、信令开销、用户体验中断时间四者之间的复杂博弈。3GPP定义的SSC（Session and Service Continuity）三模式正是这一博弈的精妙产物。
传统4G EPS中，PDN连接的锚点PGW在会话生命周期内固定不变——这是LTE时代"尽力而为"的设计哲学。但5G面对URLLC工业控制（要求亚毫秒切换）、VoNR语音（要求零中断）、以及MEC边缘计算（要求UPF本地化）三种截然不同的场景，单一模式已无法胜任。
核心矛盾：UPF锚点越靠近UE，用户面时延越低；但UE移动时锚点越需要重定位，信令开销和业务中断越大。
TS 23.501 Section 5.6.3定义的三种SSC模式，本质上是三种不同的博弈策略：
图表 1
SSC模式并非UE随意选择，而是经过URSP→订阅数据→SMF决策的三层博弈链：
TS 23.501 Section 5.6.9定义了SSC模式选择的完整决策树。UE在发起PDU Session Establishment前，首先检查PCF下发的URSP（UE Route Selection Policy）中的SSCMSP规则。
URSP规则结构（TS 24.526 Section 4.1.2）：
| URSP组件 | 说明 | 示例 |
|---|---|---|
| Traffic Descriptor | 匹配条件 | App-ID=com.voip.5g, DNN=ims |
| Route Selection Descriptor | 路由选择 | SSC Mode=3, DNN=internet, S-NSSAI=1 |
| SSCMSP | SSC模式偏好 | 优先SSC Mode 3，允许降级到Mode 1 |
关键IE解析：SSCMSP中包含一个有序的SSC模式列表（按优先级排序）。例如，工业URLLC应用可能配置 [Mode 3, Mode 1]，表示优先选择先建后断，如果网络不支持则降级为锚点固定。
SMF收到PDU Session Establishment Request后，从UDM获取会话管理订阅数据（Nudm_SDM_Get）。订阅数据中包含：
SessionManagementSubscription:
- DNN: internet
Allowed SSC Modes: [1, 2, 3] ← 运营商允许的SSC模式集合
Default SSC Mode: 1 ← 默认SSC模式
Subscribed Default QoS: ...
Session-AMBR: ...
如果UE请求的SSC模式不在Allowed SSC Modes中，SMF将拒绝该PDU Session建立请求，并返回Cause Value #65（"SSC mode not supported for the DNN and S-NSSAI"）。
SMF综合以下因素做出最终SSC模式决策：
图表 2
SSC Mode 1保证PDU Session Anchor（PSA UPF）在整个会话生命周期内不变，IP地址/Prefix保持不变。当UE远离锚点UPF时，SMF通过插入I-UPF（Intermediate UPF）来优化数据路径。
TS 23.502 Section 4.3.5.4 定义了SSC Mode 1下I-UPF插入/移除流程。
图表 3
| IE名称 | 方向 | 说明 | 长度 |
|---|---|---|---|
| N2 SM Information | AMF→SMF | 包含Target gNB ID、TAI | 可变 |
| UL PDR (Packet Detection Rule) | SMF→I-UPF | 上行检测规则，含F-TEID | ~50 bytes |
| DL PDR | SMF→PSA-UPF | 下行检测规则，更新为指向I-UPF | ~50 bytes |
| F-TEID | I-UPF→SMF | 隧道端点标识（TEID + IP） | 8-12 bytes |
| N2 SM Container | SMF→AMF | 携带I-UPF的UL Tunnel信息 | 可变 |
Mode 1的设计哲学是"IP连续性优先"。对于IMS语音、长TCP连接等场景，IP地址变更会导致通信中断。代价是当UE远离锚点时，数据需要绕行I-UPF，增加用户面时延。典型实测数据：
| UE距离PSA | 插入I-UPF前RTT | 插入I-UPF后RTT | 增加 |
|---|---|---|---|
| 同城（<50km） | 8ms | 12ms | +4ms |
| 省内（~200km） | 15ms | 28ms | +13ms |
| 跨省（~500km） | 25ms | 55ms | +30ms |
SSC Mode 2采用"Break-Before-Make"策略：当网络决定需要重定位UPF时，先释放旧PDU Session，再建立新PDU Session。UE会获得新的IP地址。
TS 23.502 Section 4.3.5.3 定义了SSC Mode 2的完整流程。
图表 4
SSC Mode 2的关键性能指标是业务中断时间（Service Interruption Time），从旧PDU Session释放到新PDU Session建立的间隔：
| 阶段 | 典型时延 | 影响因素 |
|---|---|---|
| 旧Session Release信令 | 15-30ms | RAN-AMF-SMF间N2/N4 |
| UE回退等待（T3582） | 0-8000ms | UE实现、运营商配置 |
| 新Session Establishment | 80-150ms | SMF-UDM-UPF-N4全链路 |
| RAB建立+UPF激活 | 20-40ms | gNB资源分配 |
| 总中断时间 | 115-8220ms | 最坏情况不可接受 |
实测数据（基于某运营商2025年实验室测试）：
Mode 2的设计哲学是"UPF最优位置优先"。适用于对IP连续性不敏感但需要最低用户面时延的场景，如CDN视频下载、大文件传输。代价是业务中断不可忽略。
SSC Mode 3是三种模式中最复杂但最优雅的设计——"Make-Before-Break"。SMF在释放旧PDU Session前，先通过新UPF建立新PDU Session，UE同时维持两个PDU Session的短暂共存期。
TS 23.502 Section 4.3.5.2 定义了SSC Mode 3的完整UPF重定位流程。
图表 5
SSC Mode 3中SMF与New UPF之间的N4 Session Establishment包含以下关键IE：
图表 6
| IE | 含义 | Mode 3特有行为 |
|---|---|---|
| N19 Tunnel Info | 旧UPF→新UPF转发隧道 | 仅Mode 3需要，用于转发缓存数据 |
| New IP Prefix | 新分配的IP地址 | Mode 3在PDU Session Mod中下发 |
| Old PDU Session ID | 旧会话标识 | 用于区分新旧会话共存期 |
| Buffering Flag | 缓存指示 | 旧UPF在释放前缓存下行数据 |
| SSC Mode=3 | NAS IE | UE据此理解需要双Session共存 |
| Active/Standby Flag | 激活/待命标识 | 新PDU Session初始可能为Standby |
基于ETRI在IEEE论文（DOI: 10.1109/ICOIN50984.2021.9289255）中提出的SSC可视化监控系统和实际运营商部署数据：
| 指标 | SSC Mode 1 | SSC Mode 2 | SSC Mode 3 |
|---|---|---|---|
| UPF重定位触发条件 | N/A（不重定位） | 网络判断最优 | 网络判断最优 |
| 业务中断时间 | 0ms | 120-8220ms | <10ms |
| 信令消息数（重定位） | 12（I-UPF插入） | 18（释放+重建） | 24（先建+后断） |
| N4 Session交互次数 | 2（新I-UPF建+PSA改） | 2（旧释放+新建） | 4（新建+旧缓存+激活+旧释放） |
| IP地址变化 | 否 | 是 | 是（但有无缝过渡） |
| UPF资源占用（过渡期） | 2个UPF | 1个UPF | 3个UPF（旧+新+I-UPF可选） |
| 用户面RTT（重定位后） | 可能增加30-50ms | 最优（本地UPF） | 最优（本地UPF） |
SMF基于以下条件判断是否需要触发SSC Mode 2/3的UPF重定位：
在5G核心网抓包中识别SSC模式的关键方法：
Wireshark过滤规则：
# 识别SSC Mode 3重定位（PDU Session Modification含新IP）
nas-5gs.nm.type == 0x0d && nas-5gs.sm.pdu_session_type
# 识别SSC Mode 2释放+重建序列
nas-5gs.nm.type == 0x0a && nas-5gs.sm.cause == 36
# 紧接着
nas-5gs.nm.type == 0x01
# N4 Session Establishment (新UPF)
pfcp.msg_type == 50
# N4 Session Release (旧UPF)
pfcp.msg_type == 54
关键判据： - Mode 1：只看到N4 Session Modification（修改DL FAR），无新PDU Session - Mode 2：先看到PDU Session Release（Cause #36），再看到新PDU Session Establishment - Mode 3：先看到PDU Session Modification（含新IP），旧PDU Session稍后才Release
现象：UE收到新IP地址后无法建立新数据通道，旧Session已被释放，导致完全断网。
根因分析： 1. SMF向新UPF的N4 Session Establishment超时（UPF负载过高） 2. N19 Tunnel建立失败（旧UPF→新UPF的转发隧道未建立） 3. UE未正确处理"双IP共存"——某些芯片在收到新IP后立即释放旧IP
排错命令：
# 检查N4 Session状态
show smf pdu-session <session-id> n4-status
# 查看N19 Tunnel状态
show upf tunnel n19 --session <session-id>
现象：UE移动后业务中断长达数秒，用户感知明显卡顿。
根因：UE侧T3582定时器配置过长（默认8秒），或SMF未在PDU Session Release Command中指示"立即重建"。
解决方案：SMF在Release Command中设置Cause Value #36时，同时在N1 SM Container中包含"Reactivation Request"指示，UE应立即发起重建而非等待定时器超时。
现象：用户面时延持续增加，RTT超过50ms。
根因：UE长距离移动后，SMF不断插入新I-UPF，数据路径变为 UE→I-UPF-1→I-UPF-2→...→PSA，形成"意大利面条"路径。
解决方案：SMF应配置最大I-UPF级联深度（典型值：2-3个），超过阈值后应切换为SSC Mode 3进行完整重定位。
从运营商TCO（Total Cost of Ownership）角度，三种模式在UPF资源占用、信令负载、用户体验之间形成经典博弈：
图表 7
| 博弈维度 | Mode 1 | Mode 2 | Mode 3 |
|---|---|---|---|
| UPF资源效率 | 最高 | 中 | 过渡期最低 |
| 信令开销 | 最低 | 中 | 最高 |
| 业务中断 | 零 | 显著 | 近零 |
| 用户面时延优化 | 无（可能恶化） | 完全 | 完全 |
| IP连续性 | 保证 | 不保证 | 不保证（但平滑过渡） |
| 适用Slice | eMBB/IMS | eMBB/URLLC | URLLC/V2X |
| 运营商部署率 | 94%（T-Mobile US 2025） | ~4% | ~2% |
3GPP Release 19在TS 23.502中引入了Enhanced SSC概念，主要增强点包括：
Q: SSC Mode 3中UE如何知道应该使用新IP还是旧IP？
A: TS 24.501 Section 6.4.1.3规定，SMF在PDU Session Modification Command中携带新IP地址时，UE应在确认新数据路径可用后（通过Router Solicitation/Advertisement或Echo Request验证），再切换到新IP。旧IP在收到PDU Session Release Command后才释放。实际中，上层应用通过Socket API的地址变更通知来感知IP切换。
Q: 为什么运营商95%以上使用SSC Mode 1？Mode 3不是最优吗？
A: 三个原因：(1) Mode 3信令复杂度是Mode 1的2倍，SMF处理能力需要相应提升；(2) 过渡期需要同时占用旧UPF和新UPF资源，资源成本增加50-100%；(3) 大多数消费者业务（视频、网页、社交媒体）对用户面时延不敏感，Mode 1的"锚点固定+I-UPF插入"策略已足够。Mode 3主要部署在URLLC专网、工业互联网等高价值场景。
Q: SSC Mode和EPS中的PGW重定位有什么关系？
A: 5G SSC三模式是4G PGW重定位机制的自然演进。4G只支持"SSC Mode 2等效"（先断后建），且没有标准化UE侧策略。5G引入Mode 1和Mode 3是重大架构进步，Mode 3的"Make-Before-Break"在4G时代是运营商的"梦想功能"。
Q: SSCMSP和URSP的关系是什么？
A: SSCMSP（SSC Mode Selection Policy）是URSP（UE Route Selection Policy）的一个子组件。URSP决定"这个应用应该走哪条路"（DNN、Slice、SSC Mode等），SSCMSP专门负责"这个应用应该用哪种SSC模式"。SSCMSP由PCF通过Npcf_UEPolicy_Update下发到UE。
Q: 在实际抓包中如何区分Mode 2的"释放+重建"和正常去注册后的重建？
A: 关键区别在PDU Session Release Command中的Cause Value。Mode 2重定位使用Cause #36（"Regular deactivation"）且可能同时携带"Reactivation Request"指示（TS 24.501 Section 9.11.2.9），正常去注册使用Cause #30（"Session is deactivated due to network deterministic behaviour"）或#31（"Session is deactivated due to mobility management event"）。
本文由「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 等场景全覆盖。
