5G系统架构中,Session and Service Continuity(SSC)机制是解决UE移动性与UPF锚点位置之间矛盾的核心方案。TS 23.501 Section 5.6.9定义了三种SSC模式,每种模式对应不同的业务连续性需求与网络资源优化策略:
| 维度 | SSC Mode 1 | SSC Mode 2 | SSC Mode 3 |
|---|---|---|---|
| 锚点策略 | PSA固定不变 | 先断后建(Break-before-make) | 先建后断(Make-before-break) |
| IP连续性 | IP地址/前缀保持 | IP地址改变 | IP地址改变(过渡期共存) |
| 适用PDU类型 | 所有类型 | 所有类型 | 仅IP类型(IPv4/IPv6/IPv4v6) |
| UE支持要求 | 必须支持 | 可选 | 可选 |
| 典型场景 | IMS语音、静态IP | 大流量下载、非实时应用 | 工业控制、低时延业务 |
| 设计意图 | 保证上层业务连续性 | 优化UPF路由路径 | 兼顾路由优化与业务不中断 |
设计意图解析: - SSC Mode 1的设计核心是"锚点不可变"——无论UE如何移动,PSA UPF保持不变,可能需要插入I-UPF中继流量,牺牲路由效率换取IP连续性。IMS语音(VoNR)要求IP地址不变,因此必然选择SSC Mode 1。 - SSC Mode 2采用"先断后建"策略,适用于对短暂中断容忍的场景。网络先释放旧PDU会话,UE立即重建新会话并选择新的PSA UPF。这是一种"推倒重来"的设计。 - SSC Mode 3是最复杂也最优雅的设计——通过"先建后断"实现无缝迁移。在旧PDU会话仍保持连接的同时,建立新的PDU会话锚定到新的PSA UPF,确保业务零中断。
SSC模式选择并非UE单方面决定,而是一个UE提议、网络裁量的协商过程。TS 23.501 Section 5.6.9.3定义了完整的决策链:
flowchart TD
A[应用发起连接请求] --> B{UE是否有SSCMSP策略?}
B -->|是| C[根据URSP中的SSCMSP确定SSC模式]
B -->|否| D{UE是否有本地配置?}
D -->|是| E[根据本地配置选择SSC模式]
D -->|否| F[不指定SSC模式发起PDU会话请求]
C --> G[UE在PDU Session Establishment Request中携带SSC模式]
E --> G
F --> G
G --> H{SMF校验订阅数据}
H --> I{UE请求的SSC模式在允许列表中?}
I -->|是| J[SMF接受请求的SSC模式]
I -->|否| K[SMF拒绝并返回允许的SSC模式列表]
K --> L[UE使用允许的SSC模式重新请求]
J --> M[SSC模式确定,建立PDU会话]
SSCMSP策略下发路径:
SSCMSP(Session and Service Continuity Mode Selection Policy)作为URSP规则的一部分由PCF生成,通过以下路径推送到UE: 1. PCF通过Npcf_UEPolicyControl服务生成URSP规则(含SSCMSP组件) 2. AMF通过N1 NAS消息下发给UE 3. UE根据应用特征匹配URSP规则中的Traffic Descriptor,确定对应的SSC模式
SMF决策的强制约束(TS 23.501 Section 5.6.9.3): - 当UE订阅中配置了静态IP地址/前缀时,SMF必须分配SSC Mode 1 - SSC Mode 3不得分配给Unstructured或Ethernet类型的PDU会话 - 当UE未指定SSC模式时,SMF使用订阅中的默认SSC模式 - SMF从UDM获取的信息包括:每个(DNN, S-NSSAI)组合的允许SSC模式列表和默认SSC模式
TS 23.501 Section 6.3.3.3定义了SMF选择UPF时考虑的完整参数集。这是一个多维度的决策空间:
| 参数类别 | 具体参数 | 来源 | 说明 |
|---|---|---|---|
| 负载与容量 | UPF动态负载 | N4上报/NWDAF | 实时CPU/内存/会话数 |
| UPF相对静态容量 | NRF注册 | 同DNN下UPF间的容量比 | |
| 位置与拓扑 | UPF位置信息 | SMF本地配置 | 地理位置与服务区域 |
| UE位置信息 | AMF上报 | Cell ID/TAI | |
| 用户面拓扑信息 | N4/AMF | N3/N9终止点信息 | |
| DNAI | PCC规则 | 数据网络接入标识 | |
| 会话属性 | DNN | PDU会话请求 | 数据网络名称 |
| S-NSSAI | PDU会话请求 | 网络切片标识 | |
| PDU Session Type | PDU会话请求 | IPv4/IPv6/Ethernet等 | |
| SSC mode | 协商结果 | 决定是否允许锚点迁移 | |
| 订阅与策略 | UE订阅信息 | UDM | 允许的SSC模式、静态IP |
| 本地运营商策略 | SMF配置 | 路由优化策略 | |
| 能力匹配 | UPF功能集 | NRF/N4 | 是否支持UL-CL/BP等 |
| 接入技术 | AMF | 3GPP/Non-3GPP | |
| 高级特性 | ATSSS能力 | UE/UPF | 多路径分流能力 |
| 冗余传输 | PCC/订阅 | RSN、双GTP-U路径 | |
| XR/低时延需求 | AF请求 | 用户面时延要求 | |
| NWDAF分析 | NWDAF | 服务体验/DN性能预测 |
DNAI(Data Network Access Identifier)是UPF选择与重选过程中的关键参数,它标识了UPF接入数据网络的具体位置:
flowchart LR
subgraph AF请求
A1[AF提供DNAI]
A2[AF订阅UP路径事件]
end
subgraph PCF策略
B1[PCC规则中包含DNAI]
B2[业务路由策略]
end
subgraph SMF选择
C1[根据DNAI匹配UPF]
C2[考虑UPF服务区域]
C3[评估UPF负载]
end
subgraph UPF部署
D1[UPF1: DNAI-1]
D2[UPF2: DNAI-2]
D3[UPF3: DNAI-3]
end
A1 --> B1
B1 --> C1
C2 --> C1
C3 --> C1
C1 --> D1
C1 --> D2
C1 --> D3
DNAI在锚点迁移中的信令传递: - PCF通过Npcf_SMPolicyControl服务将DNAI包含在PCC规则中下发给SMF - SMF根据DNAI选择匹配的UPF作为PSA - 当需要锚点迁移时,SMF通过Nsmf_PDUSession_SMContextStatusNotify将target DNAI信息传递给AMF,用于后续SMF重选 - AMF临时存储target DNAI,在新的PDU会话建立时传递给新SMF,不用于AMF重选场景的上下文转移
TS 23.502 Section 4.3.5.1定义了SSC Mode 2的锚点变更流程。当PDU会话只有一个PSA且不涉及multi-homing或UL-CL时使用此流程:
sequenceDiagram
participant UE
participant RAN
participant AMF
participant SMF1 as SMF(旧)
participant SMF2 as SMF(新)
participant UPF1 as UPF1(旧PSA)
participant UPF2 as UPF2(新PSA)
participant UDM
participant PCF
Note over SMF1: Step 1: SMF判决PSA需要变更
SMF1->>SMF1: 检测到UPF1不再最优<br/>(UE移出服务区/AF请求/负载均衡)
alt UPF1无法连接target DNAI
SMF1->>AMF: Nsmf_PDUSession_SMContextStatusNotify<br/>(target DNAI信息, SMF重选指示)
AMF->>AMF: 存储target DNAI用于后续SMF选择
end
Note over SMF1,UE: Step 2: 释放旧PDU会话
SMF1->>AMF: Namf_Communication_N1N2MessageTransfer<br/>(N1: PDU Session Release Command,<br/>Cause=#39 "reactivation required")
AMF->>RAN: N2 PDU Session Release Command
RAN->>UE: NAS PDU Session Release Command<br/>(Cause: re-establishment to same DN required)
UE->>RAN: NAS PDU Session Release Ack
RAN->>AMF: N2 PDU Session Release Response
AMF->>SMF1: Nsmf_PDUSession_UpdateSMContext
SMF1->>UPF1: N4 Session Release Request
UPF1->>SMF1: N4 Session Release Response
Note over UE,UPF2: Step 3: UE立即重建PDU会话
UE->>UE: 生成新PDU Session ID
UE->>RAN: NAS PDU Session Establishment Request<br/>(新PDU Session ID, SSC mode 2,<br/>相同DNN/S-NSSAI)
RAN->>AMF: N2 + NAS消息转发
alt AMF存有target DNAI
AMF->>AMF: 使用target DNAI选择新SMF
AMF->>SMF2: Nsmf_PDUSession_CreateSMContext<br/>(含target DNAI)
AMF->>AMF: 删除存储的target DNAI
else 无target DNAI
AMF->>SMF1: Nsmf_PDUSession_CreateSMContext<br/>(可能选择相同SMF)
end
SMF2->>UDM: Nudm_SDM_Get(订阅数据)
SMF2->>PCF: Npcf_SMPolicyControl_Create
SMF2->>SMF2: 根据target DNAI选择UPF2作为新PSA
SMF2->>UPF2: N4 Session Establishment Request
UPF2->>SMF2: N4 Session Establishment Response
SMF2->>AMF: Nsmf_PDUSession_CreateSMContext Response<br/>(N2 SM Info: CN Tunnel Info)
AMF->>RAN: N2 PDU Session Establishment Request
RAN->>UE: RRC Reconfiguration(N3 Tunnel Info)
UE->>RAN: RRC Reconfiguration Complete
RAN->>AMF: N2 PDU Session Establishment Response<br/>(AN Tunnel Info)
AMF->>SMF2: Nsmf_PDUSession_UpdateSMContext<br/>(AN Tunnel Info)
SMF2->>UPF2: N4 Session Modification Request<br/>(AN Tunnel Info)
UPF2->>SMF2: N4 Session Modification Response
Note over UE,UPF2: 新PDU会话建立完成<br/>UE获得新IP地址
| 信令消息 | 关键IE | 取值/含义 | 设计意图 |
|---|---|---|---|
| PDU Session Release Command | Cause | #39 "Reactivation required" | 通知UE此释放是为了重建,不是异常 |
| PDU Session Release Command | PDU Session ID | 旧会话标识 | 明确要释放的会话 |
| Nsmf_PDUSession_SMContextStatusNotify | Target DNAI | 目标数据网络接入点 | 引导AMF选择能服务该DNAI的SMF |
| Nsmf_PDUSession_SMContextStatusNotify | SMF selection expected | Boolean | 指示AMF需要重新选择SMF |
| PDU Session Establishment Request | New PDU Session ID | 全新标识 | 与旧会话区分 |
| Nsmf_PDUSession_CreateSMContext | Target DNAI | AMF存储的DNAI | 传递给新SMF用于UPF选择 |
SSC Mode 2的设计存在一个关键时序问题:旧会话释放与新会话建立之间的间隙。
UE侧行为(TS 23.502 Section 4.3.5.1 Step 3): - UE收到Cause为"reactivation required"的PDU Session Release Command后,立即生成新PDU Session ID并发起PDU Session Establishment - "立即"意味着UE不需要等待任何定时器超时
网络侧行为: - AMF收到SMF的target DNAI后存储,不传递给其他AMF(AMF relocation时丢失) - 新SMF使用target DNAI选择新UPF,确保锚点迁移到目标位置
TS 23.502 Section 4.3.5.2定义了SSC Mode 3的第一个实现方案——通过建立独立的第二个PDU会话实现无缝迁移:
sequenceDiagram
participant UE
participant RAN
participant AMF
participant SMF1 as SMF1(旧)
participant SMF2 as SMF2(新)
participant UPF1 as UPF1(旧PSA)
participant UPF2 as UPF2(新PSA)
participant AF
participant PCF
Note over SMF1: Step 1: SMF判决PSA/SMF需要变更
alt UPF1无法连接target DNAI
SMF1->>AMF: Nsmf_PDUSession_SMContextStatusNotify<br/>(target DNAI, SMF Context ID)
AMF->>AMF: 存储target DNAI和SM Context ID
end
alt AF运行时协调使能
SMF1->>AF: Early Notification(源DNAI)
AF->>SMF1: Notification Response
alt AF返回否定响应
SMF1->>SMF1: 终止锚点迁移
end
end
Note over SMF1,UE: Step 2: 触发UE建立新会话
SMF1->>AMF: Namf_Communication_N1N2MessageTransfer<br/>(PDU Session ID, SMF Reallocation指示,<br/>N1: PDU Session Modification Command<br/>Cause=reactivation required,<br/>PCO: PDU Session Address Lifetime)
AMF->>UE: NAS PDU Session Modification Command
UE->>UE: 将Address Lifetime传递给上层
UE->>AMF: NAS PDU Session Modification Command ACK
AMF->>SMF1: Nsmf_PDUSession_UpdateSMContext(N1 ACK)
Note over UE: Step 4: UE发起建立新PDU会话
UE->>UE: 生成新PDU Session ID
UE->>RAN: NAS PDU Session Establishment Request<br/>(新PDU Session ID + Old PDU Session ID)
RAN->>AMF: N2 + NAS转发
alt SMF重选
AMF->>SMF2: Nsmf_PDUSession_CreateSMContext<br/>(含target DNAI, SM Context ID)
else 不重选
AMF->>SMF1: Nsmf_PDUSession_CreateSMContext<br/>(含Old PDU Session ID)
end
SMF2->>SMF1: Nsmf_PDUSession_ContextRequest<br/>(请求AF Coordination Info)
SMF1->>SMF2: Nsmf_PDUSession_ContextResponse<br/>(AF Coordination Info, notification correlation id)
SMF2->>SMF2: 选择UPF2作为新PSA
SMF2->>UPF2: N4 Session Establishment
UPF2->>SMF2: N4 Session Establishment Response
alt AF订阅Late Notification
SMF2->>AF: Late Notification(源DNAI, UE IP)
end
SMF2->>AMF: CreateSMContext Response(N2 SM Info)
AMF->>RAN: N2 PDU Session Setup
RAN->>UE: RRC Reconfiguration
UE->>RAN: RRC Complete
RAN->>AMF: N2 Response(AN Tunnel Info)
AMF->>SMF2: UpdateSMContext(AN Tunnel Info)
SMF2->>UPF2: N4 Session Modification
Note over UE: Step 5: 新旧会话并存期
UE->>UE: 新流量使用新IP地址/前缀<br/>可主动迁移旧流量到新会话
Note over SMF1: Step 6: 旧会话释放
alt UE主动释放(在timer到期前)
UE->>SMF1: PDU Session Release Request(旧会话)
else Timer超时后SMF释放
SMF1->>UE: PDU Session Release Command(旧会话)
end
SMF1->>UPF1: N4 Session Release
| IE/参数 | 携带位置 | 功能 | 设计意图 |
|---|---|---|---|
| SMF Reallocation requested indication | Namf_Communication_N1N2MessageTransfer | 指示AMF是否需要选择新SMF | 支持跨SMF的锚点迁移 |
| PDU Session Address Lifetime | PCO(PDU Session Modification Command) | 旧会话保持时间 | 给上层应用迁移时间窗口 |
| Old PDU Session ID | NAS PDU Session Establishment Request | 标识要替换的旧会话 | SMF关联新旧会话 |
| SM Context ID | Nsmf_PDUSession_SMContextStatusNotify | 引用SMF中的AF协调信息 | 跨SMF传递AF上下文 |
| AF Coordination Information | Nsmf_PDUSession_ContextResponse | AF订阅信息、notification correlation id | 保持AF通知连续性 |
| PDU Session Release timer | SMF内部 | 等于Address Lifetime值 | 超时后强制释放旧会话 |
TS 23.502 Section 4.3.5.3定义了SSC Mode 3的第二个实现方案——利用IPv6多归属(Multi-homing)在同一个PDU会话内实现锚点迁移。此方案仅适用于IPv6类型PDU会话:
flowchart TD
subgraph 阶段1_锚点准备["阶段1: 新PSA准备"]
A1[SMF决定分配新PSA] --> A2[SMF选择UPF2作为新PSA]
A2 --> A3[N4建立: UPF2配置为PSA]
A3 --> A4[分配新IPv6前缀 IP@2]
A4 --> A5[通知PCF新前缀<br/>PCF更新BSF绑定]
end
subgraph 阶段2_BP插入["阶段2: Branching Point插入"]
B1[SMF选择BP UPF] --> B2[N4配置BP<br/>UL转发规则: 按源IPv6前缀分流]
B2 --> B3[提供AN Tunnel Info和CN Tunnel Info]
B3 --> B4[N4修改PSA1/PSA2<br/>建立N9隧道: BP↔PSA1, BP↔PSA2]
end
subgraph 阶段3_路径切换["阶段3: N3路径切换"]
C1[SMF发送N2 SM Info给AMF<br/>含BP的CN Tunnel Info] --> C2[AMF→RAN: N2 Request]
C2 --> C3[RAN→AMF: N2 Response<br/>含新AN Tunnel Info]
C3 --> C4[SMF更新BP: AN Tunnel Info]
end
subgraph 阶段4_UE通知["阶段4: IPv6前缀通知"]
D1[SMF通过新PSA发Router Advertisement<br/>携带新前缀IP@2] --> D2[SMF通过旧PSA发Router Advertisement<br/>旧前缀IP@1: preferred_lifetime=0<br/>valid_lifetime=T]
D2 --> D3[UE开始用IP@2发起所有新流量<br/>可主动迁移旧流量]
end
subgraph 阶段5_旧锚点释放["阶段5: 旧锚点释放"]
E1[valid_lifetime定时器超时] --> E2[SMF释放旧IPv6前缀IP@1]
E2 --> E3[N4修改BP: 释放N9隧道<br/>BP↔旧PSA]
E3 --> E4[N4释放旧PSA UPF1]
E4 --> E5[可选: 释放BP<br/>UPF2直接作为唯一PSA]
end
阶段1_锚点准备 --> 阶段2_BP插入
阶段2_BP插入 --> 阶段3_路径切换
阶段3_路径切换 --> 阶段4_UE通知
阶段4_UE通知 --> 阶段5_旧锚点释放
Branching Point的核心功能: - BP UPF充当分流节点,连接(R)AN和多个PSA - 上行方向:根据IPv6源地址前缀决定转发到PSA1或PSA2 - 下行方向:根据AN Tunnel Info转发到(R)AN - 当BP与PSA1或PSA2合设时,相应N4步骤可合并
Router Advertisement的双报文机制: - 通过新PSA发送RA:携带新IPv6前缀IP@2(完整preferred/valid lifetime) - 通过旧PSA发送RA:旧前缀IP@1的preferred_lifetime设为0(立即停止新连接),valid_lifetime设为T(保持已有连接T秒) - UE收到后必须将旧前缀的valid lifetime更新为信令值,无论剩余时间多少
TS 23.502 Section 4.3.5.4定义了通过UL-CL(Uplink Classifier)插入实现SSC锚点变更的方案。与BP不同,UL-CL基于业务流过滤器而非IPv6前缀进行分流:
| 对比维度 | Branching Point | UL-CL |
|---|---|---|
| 分流依据 | IPv6源地址前缀 | 业务流过滤器(Packet Filter Set) |
| 适用PDU类型 | 仅IPv6 | IPv4/IPv6/IPv4v6 |
| UE可见性 | UE通过RA感知前缀变化 | UE可能不感知(对UL-CL模式透明) |
| 多归属支持 | 原生支持IPv6 multi-homing | 不涉及multi-homing |
| 典型部署 | 边缘计算本地分流 + 锚点迁移 | 本地数据网络接入 + 业务流级路由 |
当AF订阅了UP路径管理事件后,SMF在锚点迁移过程中执行双阶段通知:
sequenceDiagram
participant SMF
participant AF
participant NEF
Note over SMF: 锚点迁移开始
rect rgb(230, 245, 255)
Note over SMF,AF: Early Notification(新PSA选定后,配置前)
SMF->>AF: Nsmf_EventExposure_Notify<br/>(Event: "Early Notification",<br/>Source DNAI, Target DNAI)
alt AF acknowledgment required
AF->>SMF: Notification Response
alt 否定响应
SMF->>SMF: 终止锚点迁移流程
end
end
end
Note over SMF: 配置新PSA、更新N4规则
rect rgb(255, 240, 230)
Note over SMF,AF: Late Notification(UP路径激活后)
SMF->>AF: Nsmf_EventExposure_Notify<br/>(Event: "Late Notification",<br/>Source DNAI, Target DNAI,<br/>UE IP address @ Source DNAI)
alt AF acknowledgment required
AF->>SMF: Notification Response
end
end
Early Notification的设计意图:允许AF在新锚点配置前执行应用层状态迁移(如将应用服务器上下文从源DNAI位置迁移到目标DNAI位置)。如果AF判断无法完成迁移(如应用服务器资源不足),可返回否定响应终止网络侧的锚点迁移。
Late Notification的设计意图:通知AF新的UP路径已激活,AF可以开始将流量导向新位置。携带UE IP address @ Source DNAI用于AF关联新旧路径。
在SSC Mode 3多PDU会话方案中,如果涉及SMF重选,旧SMF需要将AF协调信息传递给新SMF:
当UE移出当前SMF的服务区域,或当前SMF无法服务target DNAI时,需要插入I-SMF(Intermediate SMF)。TS 23.501 Section 5.34定义了I-SMF的架构:
| 场景 | 触发条件 | SMF行为 |
|---|---|---|
| UE移出SMF服务区 | UE接入的(R)AN不在SMF服务区域内 | AMF插入I-SMF控制本地UPF |
| SMF无法服务target DNAI | PCC规则中的DNAI超出SMF控制范围 | SMF通过AMF触发SMF重选 |
| HR漫游本地分流 | VPLMN需要本地UPF锚点 | V-SMF作为I-SMF角色 |
TS 23.501 Section 5.34.4.3定义了SMF与I-SMF之间的N4信息交互模型:
这种分层设计使得SMF无需知道I-SMF控制多少个本地UPF,实现了控制面的解耦。
| 过滤条件 | 识别目标 | 关键特征 |
|---|---|---|
nas-5gs.pdu_session_type == 1 |
IPv4 PDU会话 | 检查SSC模式IE |
nas-5gs.sm_cause == 39 |
SSC Mode 2触发释放 | Cause #39 "Reactivation required" |
pfcp && pfcp.msg_type == 50 |
N4 Session Establishment | 新PSA建立 |
pfcp && pfcp.msg_type == 52 |
N4 Session Modification | UL-CL/BP规则更新 |
icmpv6.type == 134 |
IPv6 Router Advertisement | SSC Mode 3前缀通知 |
ngap && ngap.procedureCode == 35 |
PDU Session Resource Setup | N2会话建立 |
故障1:SSC Mode 2释放后UE未重建 - 现象:UE收到Release Command后不发起PDU Session Establishment - 排查: - 检查UE是否支持SSC Mode 2(UE Capability) - 检查Cause值是否为#39(而非其他错误码) - 确认URSP规则是否正确引导UE重建 - 根因:部分终端实现中,UE上层未正确处理"reactivation required"指示
故障2:SSC Mode 3 Address Lifetime定时器不一致 - 现象:旧会话被过早释放或长期不释放 - 排查: - 比对SMF的PDU Session Release timer与PCO中的Address Lifetime值 - 检查UE是否正确将Address Lifetime传递给上层 - 确认UE上层是否在超时前主动触发旧会话释放 - 根因:UE上层应用未及时迁移流量到新IP地址
故障3:IPv6 RA报文丢失导致双前缀状态不一致 - 现象:UE未收到新前缀的RA或旧前缀的deprecated RA - 排查: - 抓取N3接口的ICMPv6 RA报文 - 确认RA通过正确的PSA发送(新前缀通过新PSA,旧前缀通过旧PSA) - 检查BP的上行转发规则是否正确(源前缀→对应PSA) - 根因:BP的N4规则配置错误导致RA报文被转发到错误的PSA
故障4:Target DNAI在AMF重选后丢失 - 现象:AMF relocation后新SMF无法选择正确的UPF - 排查: - 确认target DNAI是否在AMF上下文转移中被排除 - TS 23.502明确规定target DNAI不用于AMF relocation - 根因:协议设计限制,target DNAI仅在SMF重选时有效
Q: SSC Mode 1下能否发生任何UPF变更?
A: SSC Mode 1保证主PSA不变,但TS 23.501 Section 5.6.9.2.1明确指出:当IPv6 multi-homing或UL-CL应用于SSC Mode 1的PDU会话时,额外的(additional)PSA可以被分配或释放。这些额外PSA不改变主锚点,UE也不期望额外IPv6前缀在PDU会话生命周期内保持。因此SSC Mode 1并非"完全没有UPF变更",而是主锚点不变、额外锚点可变。
Q: SSC Mode 2和SSC Mode 3在漫游场景下的差异是什么?
A: 在Home Routed漫游中,V-SMF控制VPLMN的UPF(包括UL-CL/BP/本地PSA),H-SMF控制HPLMN的PSA。SSC Mode 2/3的锚点迁移可能仅涉及VPLMN本地PSA的变更(由V-SMF控制),不触发HPLMN PSA的变更。HR-SBO(Home Routed Session Breakout)场景下,V-SMF需要在L-PSA建立时提供HR-SBO指示、SUPI和HPLMN DNN/S-NSSAI信息。
Q: 为什么SSC Mode 3不适用于Ethernet PDU会话类型?
A: SSC Mode 3依赖IP地址/前缀的分配和迁移机制(IPv6 Router Advertisement的preferred/valid lifetime、PCO中的Address Lifetime),这些机制都是IP层特有的。Ethernet PDU会话没有IP地址概念,MAC地址由UE自行使用而非网络分配,无法通过前缀生命周期控制迁移时序。Ethernet PDU会话的锚点迁移使用Section 4.3.5.8定义的专用流程,通过Ethernet Context(MAC地址+VLAN标签)的迁移实现。
Q: SSC Mode选择后能否在PDU会话生命周期内改变?
A: 不能。TS 23.501 Section 5.6.9.1明确规定:"The SSC mode associated with a PDU Session does not change during the lifetime of a PDU Session"。如果需要不同的SSC行为,必须释放当前PDU会话并建立新会话。这一限制简化了SMF和UPF的状态机设计。
Q: SSC Mode 3的两种实现方案(多PDU会话 vs IPv6 Multi-homing)如何选择?
A: 方案选择取决于多个因素: - PDU会话类型:IPv6 Multi-homing方案仅适用于IPv6类型;多PDU会话方案适用于所有IP类型 - SMF是否需要重选:如果需要跨SMF迁移,只能使用多PDU会话方案 - UPF能力:Multi-homing方案要求UPF支持Branching Point功能 - 策略偏好:多PDU会话方案对UE可见(两个独立PDU会话),Multi-homing方案对上层更透明(同一PDU会话内的前缀变更)
本文由「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 等场景全覆盖。
