# 5G SSC三模式锚点迁移与UPF重选信令拆解 ## 1. SSC模式体系：从架构设计到信令实现 ### 1.1 三种SSC模式的设计哲学 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，确保业务零中断。 ### 1.2 SSC模式选择决策链 SSC模式选择并非UE单方面决定，而是一个UE提议、网络裁量的协商过程。TS 23.501 Section 5.6.9.3定义了完整的决策链： ```mermaid 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模式 ## 2. UPF选择：锚点决策的十六维参数空间 ### 2.1 UPF选择参数全景 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性能预测 | ### 2.2 DNAI在锚点选择中的核心角色 DNAI（Data Network Access Identifier）是UPF选择与重选过程中的关键参数，它标识了UPF接入数据网络的具体位置： ```mermaid 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重选场景的上下文转移 ## 3. SSC Mode 2：先断后建的锚点重选信令 ### 3.1 信令时序图 TS 23.502 Section 4.3.5.1定义了SSC Mode 2的锚点变更流程。当PDU会话只有一个PSA且不涉及multi-homing或UL-CL时使用此流程： ```mermaid 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不再最优
(UE移出服务区/AF请求/负载均衡) alt UPF1无法连接target DNAI SMF1->>AMF: Nsmf_PDUSession_SMContextStatusNotify
(target DNAI信息, SMF重选指示) AMF->>AMF: 存储target DNAI用于后续SMF选择 end Note over SMF1,UE: Step 2: 释放旧PDU会话 SMF1->>AMF: Namf_Communication_N1N2MessageTransfer
(N1: PDU Session Release Command,
Cause=#39 "reactivation required") AMF->>RAN: N2 PDU Session Release Command RAN->>UE: NAS PDU Session Release Command
(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
(新PDU Session ID, SSC mode 2,
相同DNN/S-NSSAI) RAN->>AMF: N2 + NAS消息转发 alt AMF存有target DNAI AMF->>AMF: 使用target DNAI选择新SMF AMF->>SMF2: Nsmf_PDUSession_CreateSMContext
(含target DNAI) AMF->>AMF: 删除存储的target DNAI else 无target DNAI AMF->>SMF1: Nsmf_PDUSession_CreateSMContext
(可能选择相同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
(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
(AN Tunnel Info) AMF->>SMF2: Nsmf_PDUSession_UpdateSMContext
(AN Tunnel Info) SMF2->>UPF2: N4 Session Modification Request
(AN Tunnel Info) UPF2->>SMF2: N4 Session Modification Response Note over UE,UPF2: 新PDU会话建立完成
UE获得新IP地址 ``` ### 3.2 关键IE解析 | 信令消息 | 关键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选择 | ### 3.3 "先断后建"的时序约束 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，确保锚点迁移到目标位置 ## 4. SSC Mode 3：先建后断的无缝锚点迁移 ### 4.1 双路径径：多PDU会话方案 TS 23.502 Section 4.3.5.2定义了SSC Mode 3的第一个实现方案——通过建立**独立的第二个PDU会话**实现无缝迁移： ```mermaid 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
(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
(PDU Session ID, SMF Reallocation指示,
N1: PDU Session Modification Command
Cause=reactivation required,
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
(新PDU Session ID + Old PDU Session ID) RAN->>AMF: N2 + NAS转发 alt SMF重选 AMF->>SMF2: Nsmf_PDUSession_CreateSMContext
(含target DNAI, SM Context ID) else 不重选 AMF->>SMF1: Nsmf_PDUSession_CreateSMContext
(含Old PDU Session ID) end SMF2->>SMF1: Nsmf_PDUSession_ContextRequest
(请求AF Coordination Info) SMF1->>SMF2: Nsmf_PDUSession_ContextResponse
(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地址/前缀
可主动迁移旧流量到新会话 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 ``` ### 4.2 关键IE与定时器 | 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值 | 超时后强制释放旧会话 | ### 4.3 IPv6 Multi-homed方案：单会话双锚点 TS 23.502 Section 4.3.5.3定义了SSC Mode 3的第二个实现方案——利用IPv6多归属（Multi-homing）在**同一个PDU会话**内实现锚点迁移。此方案仅适用于IPv6类型PDU会话： ```mermaid 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新前缀
PCF更新BSF绑定] end subgraph 阶段2_BP插入["阶段2: Branching Point插入"] B1[SMF选择BP UPF] --> B2[N4配置BP
UL转发规则: 按源IPv6前缀分流] B2 --> B3[提供AN Tunnel Info和CN Tunnel Info] B3 --> B4[N4修改PSA1/PSA2
建立N9隧道: BP↔PSA1, BP↔PSA2] end subgraph 阶段3_路径切换["阶段3: N3路径切换"] C1[SMF发送N2 SM Info给AMF
含BP的CN Tunnel Info] --> C2[AMF→RAN: N2 Request] C2 --> C3[RAN→AMF: N2 Response
含新AN Tunnel Info] C3 --> C4[SMF更新BP: AN Tunnel Info] end subgraph 阶段4_UE通知["阶段4: IPv6前缀通知"] D1[SMF通过新PSA发Router Advertisement
携带新前缀IP@2] --> D2[SMF通过旧PSA发Router Advertisement
旧前缀IP@1: preferred_lifetime=0
valid_lifetime=T] D2 --> D3[UE开始用IP@2发起所有新流量
可主动迁移旧流量] end subgraph 阶段5_旧锚点释放["阶段5: 旧锚点释放"] E1[valid_lifetime定时器超时] --> E2[SMF释放旧IPv6前缀IP@1] E2 --> E3[N4修改BP: 释放N9隧道
BP↔旧PSA] E3 --> E4[N4释放旧PSA UPF1] E4 --> E5[可选: 释放BP
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更新为信令值，无论剩余时间多少 ### 4.4 UL-CL方案：业务流级分流 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 | | 典型部署 | 边缘计算本地分流 + 锚点迁移 | 本地数据网络接入 + 业务流级路由 | ## 5. 锚点迁移中的AF协调机制 ### 5.1 Early/Late Notification双通知模型 当AF订阅了UP路径管理事件后，SMF在锚点迁移过程中执行双阶段通知： ```mermaid 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
(Event: "Early Notification",
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
(Event: "Late Notification",
Source DNAI, Target DNAI,
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关联新旧路径。 ### 5.2 AF Coordination Information的跨SMF传递 在SSC Mode 3多PDU会话方案中，如果涉及SMF重选，旧SMF需要将AF协调信息传递给新SMF： 1. 旧SMF通过Nsmf_PDUSession_SMContextStatusNotify将SM Context ID发给AMF 2. AMF在新PDU会话建立请求中将SM Context ID传给新SMF 3. 新SMF通过Nsmf_PDUSession_ContextRequest向旧SMF请求AF Coordination Information 4. AF Coordination Information包含：notification correlation id、"uplink buffering"指示等 5. 新SMF据此在新PSA配置上行缓冲，并正确发送Early/Late Notification ## 6. UPF服务区域与I-SMF机制 ### 6.1 I-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角色 | ### 6.2 UL-CL/BP在I-SMF架构下的N4规则生成 TS 23.501 Section 5.34.4.3定义了SMF与I-SMF之间的N4信息交互模型： - **SMF生成N4规则**：基于可用DNAI、PCC规则和计费要求，SMF生成N4信息 - **SMF指示规则执行位置**：N4信息中标记规则应在UL-CL/BP还是本地PSA执行 - **I-SMF翻译规则**：I-SMF将SMF生成的N4规则翻译为实际UPF可执行的规则 - **DNAI关联**：本地PSA的规则携带关联DNAI，I-SMF据此映射到具体UPF 这种分层设计使得SMF无需知道I-SMF控制多少个本地UPF，实现了控制面的解耦。 ## 7. 实战：抓包识别与故障排查 ### 7.1 Wireshark抓包识别SSC模式 | 过滤条件 | 识别目标 | 关键特征 | |---------|---------|---------| | `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会话建立 | ### 7.2 常见故障点 **故障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重选时有效 ## 8. 常见问题 **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会话内的前缀变更） ## 参考来源 1. [3GPP TS 23.501 V18.10.0](https://www.3gpp.org/DynaReport/23501.htm) — Section 5.6.9 SSC模式定义、Section 5.6.9.3 SSC模式选择、Section 6.3.3.3 UPF选择参数 2. [3GPP TS 23.502 V18.10.0](https://www.3gpp.org/DynaReport/23502.htm) — Section 4.3.5.1 SSC Mode 2锚点变更、Section 4.3.5.2 SSC Mode 3多PDU会话方案、Section 4.3.5.3 IPv6 Multi-homing方案、Section 4.3.5.4 UL-CL/BP插入 3. [TS 23.502 Section 4.3.5.1 — Change of SSC mode 2 PDU Session Anchor (iTECSpec)](https://itecspec.com/3gpp/23.502/s/4.3.5.1) — SSC Mode 2流程在线参考 4. [SSCMSP — Session and Service Continuity Mode Selection Policy (3GPP Explorer)](https://3gpp-explorer.com/glossary/sscmsp/) — SSC模式选择策略机制详解 5. [Session and Service Continuity Mode (Cisco UCC 5G SMF Guide, 2025-03)](https://www.cisco.com/c/en/us/td/docs/wireless/ucc/smf/2025-03/config-and-admin/ucc-5g-smf-config-and-admin-guide-release-2025-03/m_session-and-service-continuity-mode.html) — 厂商实现参考 --- > 本文由「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 等场景全覆盖。