# 5G SSC Mode 3 会话锚点重选（PSA Change）信令机制全链拆解 ## 一、为什么5GC需要SSC Mode 3这个"会话连续性"机制 在4G EPC时代，一个PDN连接在整个生命周期内锚定在同一个PGW（S5/S8接口的终点），UE的IP地址一旦分配就不变。这种"锚点固定+IP不变"的模型简单可靠，但在5G时代遇到了三重挑战： 第一，**UE移动性导致用户面路径次优**。当UE从北京移动到广州，数据仍要绕回北京锚定的UPF，时延和回传带宽浪费严重。第二，**边缘计算（MEC）要求锚点就近**。EAS部署在本地UPF后，UE移动出本地服务区后，业务必须跟随重定位。第三，**运营商负载均衡与故障自愈**需要灵活地重选用户面锚点。 3GPP在TS 23.501 §5.6.9定义了三种Session and Service Continuity（SSC）模式来应对不同场景。其中**SSC Mode 3**是最具工程复杂度的一种——它允许网络在**不重建PDU Session**的前提下，**改变PDU Session Anchor（PSA）UPF**，同时通过**IPv6多宿主（Multi-homing）**实现业务不中断的"先建后断"（make-before-break）迁移。本文聚焦TS 23.502 §4.3.5.3所定义的"IPv6 Multi-homed PDU Session"锚点重选流程，逐条拆解其信令链、关键IE、用户面分流机制与设计意图。 ## 二、SSC三种模式：先看清SSC Mode 3的定位 | 维度 | SSC Mode 1 | SSC Mode 2 | SSC Mode 3 | |------|-----------|-----------|-----------| | **PSA锚点是否可变** | 不可变，固定PSA | 可变 | 可变 | | **UE IP地址是否改变** | 不变 | 改变（重建后新IP） | 改变（multi-homing分配新前缀） | | **连续性实现方式** | 维持同一PSA与IP | 释放旧PDU Session → 建立新PDU Session | 双PSA并存，make-before-break | | **对UE是否可见** | 不可见 | 可见（PDU Session重建） | 可见（获得新IP前缀） | | **业务是否中断** | 不中断 | 有中断（重建期间） | 无中断（迁移期双路并存） | | **典型场景** | IMS VoNR、固定IP专线 | 简单业务，可容忍短暂中断 | MEC业务跟随、移动性优化锚点重定位 | | **TS 23.502章节** | — | §4.3.5.2（重建） | §4.3.5.3（multi-homing）、§4.3.5.6（additional PSA） | 关键认知：**SSC Mode 2是"断开再连"（break-before-make）**，UE要先释放旧PDU Session、用新IP建立新PDU Session；**SSC Mode 3是"先连后断"（make-before-break）**，新PSA先建立、新前缀先下发，业务在两个PSA并存期间平滑迁移，最后才释放旧PSA。一个PDU Session的SSC mode在建立后**生命周期内不变**（TS 23.501 §5.6.9.1）。 ```mermaid flowchart TD A[SMF决策: 是否需要重选PSA?] --> B{当前PDU Session的SSC mode?} B -->|SSC Mode 1| C[不可改变锚点
保持原PSA,通过中间UPF/UL CL优化路径] B -->|SSC Mode 2| D[释放旧PDU Session
UE用新IP建立新PDU Session] B -->|SSC Mode 3| E[触发PSA Change流程] E --> F{IPv6 multi-homing?} F -->|是, §4.3.5.3| G[插入Branching Point
分配新IPv6前缀
双PSA并存迁移] F -->|additional PSA场景 §4.3.5.6| H[改变additional PSA
更新multi-homing/UL CL] G --> I[业务迁移到新PSA后
释放旧PSA] H --> I ``` ## 三、SSC Mode 3 PSA Change的核心机制：双PSA + Branching Point 理解§4.3.5.3的关键，是理解**multi-homed PDU Session**（TS 23.501 §5.6.4.3）这个概念。一个IPv6 PDU Session可以同时锚定在**多个PSA UPF**上，每个PSA对应一个独立的IPv6前缀（/64）。过渡期，UE拥有两个IPv6前缀：旧前缀（old prefix，挂在PSA1）和新前缀（new prefix，挂在PSA2）。 为了在一个N3隧道上承载"两个前缀对应的两条上行流量"，SMF会在用户面插入一个**Branching Point（BP）**。BP本质上是I-UPF（Intermediate UPF）的一个function，由SMF通过N4下发规则来配置： - **上行（UL）方向**：BP根据源IPv6前缀，将上行数据分别转发给PSA1或PSA2（两份上行流并存）。 - **下行（DL）方向**：PSA1和PSA2的下行数据都汇聚到BP，再由BP经N3统一送给(R)AN→UE。 ```text graph LR UE[UE
拥有2个IPv6前缀] -->|N3| RAN[(R)AN] RAN -->|N9 UL分路| BP subgraph 过渡期双PSA并存 BP[Branching Point
I-UPF: N4分流规则] BP -->|旧前缀上行→| PSA1[PSA1 旧锚点
Prefix-A] BP -->|新前缀上行→| PSA2[PSA2 新锚点
Prefix-B] PSA1 -.下行汇聚.-> BP PSA2 -.下行汇聚.-> BP end PSA1 -->|N6| DN1[DN / Internet-A] PSA2 -->|N6| DN2[DN / Internet-B
或MEC本地DN] style PSA2 fill:#cfe8fc,stroke:#1976d2 style BP fill:#fff3cd,stroke:#856404 ``` **设计意图**：为什么不直接用UL CL？UL CL（上行分类器，TS 23.501 §5.6.4.2）和Branching Point在用户面功能上类似（都是分流），但用途不同——UL CL是把**部分业务流量**分流到local PSA实现MEC本地出局（主PSA不变），而BP是为SSC Mode 3的**make-before-break迁移**服务，目的是让两个PSA**临时共存**。换句话说：**UL CL是"分流"，BP是"迁移桥梁"**。 ## 四、完整信令时序图：TS 23.502 §4.3.5.3逐步拆解 下面是网络发起（SMF发起）的SSC Mode 3 PSA Change（IPv6 multi-homing变体）的完整信令流。前置条件：UE已有一个建立好的IPv6 PDU Session，锚定在PSA1。 ```mermaid sequenceDiagram autonumber participant UE participant RAN as (R)AN participant AMF participant SMF participant IUPF as I-UPF (BP) participant PSA1 as PSA1 (旧) participant PSA2 as PSA2 (新) Note over SMF: 触发: UE移动/DNAI变更/AF影响/负载均衡 SMF->>SMF: 选择new PSA2, 决定是否需要I-UPF(BP) rect rgb(232, 245, 233) Note over SMF,PSA2: 阶段A: 建立新锚点 (Make) SMF->>PSA2: N4 Session Establishment
(PDR/FAR/QER, N9 DL Tunnel Info) PSA2-->>SMF: N4 Session Establishment Response
(N9 UL Tunnel Info, Cause) SMF->>IUPF: N4 Session Establishment/Modification
(配置Branching Point分流规则:
UL按前缀分到PSA1/PSA2, DL汇聚) IUPF-->>SMF: N4 Response
(N3/N9 Tunnel Info) end Note over SMF,UE: 关键: PSA2在用户面发送ICMPv6 RA
(携带新IPv6前缀) PSA2->>IUPF: ICMPv6 Router Advertisement
(new IPv6 /64 prefix) IUPF->>RAN: 转发RA (N3下行) RAN->>UE: RA (携带new prefix) Note over UE: UE配置第二个IPv6前缀
上层应用绑定新前缀建新连接 rect rgb(227, 242, 253) Note over SMF,UE: 阶段B: N1 SM通知UE配置变更 SMF->>AMF: Namf_Communication_N1N2MessageTransfer
(N1 SM Container: PDU Session Modification Command) AMF->>RAN: N2 PDU Session Resource Modify
(含N1 SM Container) RAN->>UE: RRC Reconfiguration
(承载PDU Session Modification Command) end Note over UE: 应用层流量逐步迁移到new prefix/PSA2 rect rgb(255, 243, 224) Note over SMF,PSA1: 阶段C: 释放旧锚点 (Break) SMF->>IUPF: N4 Modification
(更新BP: 仅指向PSA2, 移除PSA1分支) SMF->>PSA1: N4 Session Release PSA1-->>SMF: N4 Session Release Response end UE->>SMF: UL NAS Transport
(PDU Session Modification Command Complete) Note over SMF: PSA Change完成
PDU Session锚定在PSA2 ``` ### 逐步解析关键信令与IE **步骤2-3（N4 Session Establishment toward PSA2）**：SMF选好new PSA2后，向其下发N4会话建立。关键N4规则包括： - **PDR（Packet Detection Rule）**：识别发往PSA2的下行数据（Source Interface = Core, 目的IPv6前缀=new prefix）。 - **FAR（Forwarding Action Rule）**：上行数据转发到I-UPF(BP)或(R)AN，下行数据转发到N6。 - PS2返回的**N9 UL Tunnel Info**（GTP-U F-TEID）用于BP→PSA2的上行隧道。 **步骤4-5（N4配置Branching Point）**：SMF向I-UPF下发"分支点"规则。BP收到N4规则后，建立针对两个前缀的两条上行N9隧道（→PSA1、→PSA2），并接收两条下行N9隧道。这是make-before-break的"双路并存"实现。 **步骤6-9（用户面RA下发新前缀）**：这是§4.3.5.3**最特殊**的一步——**新IPv6前缀不通过N1 SM信令携带，而是通过ICMPv6 Router Advertisement在用户面下发**。SMF通过N4指示PSA2（或I-UPF）构造并发送一个RA，携带新的/64前缀。UE的IPv6协议栈收到RA后，配置第二个前缀。这充分利用了IPv6 multi-homing的能力——一个PDU Session上可以有多个前缀共存。 **步骤10-12（N1 SM Modification Command）**：SMF通过AMF向UE发送PDU Session Modification Command（TS 23.502 §4.3.3.2）。该消息中的关键IE： | N1 SM IE | 含义 | 在PSA Change中的作用 | |----------|------|---------------------| | **PDU Session ID** | 标识被修改的PDU Session | 必须与原Session一致（非新建） | | **Operation Code** | 操作类型 | "modify existing" | | **QoS Rules / QoS Flow List** | QoS规则变更 | 可能新增/调整QFI到PSA2的映射 | | **5GSM Cause** | 修改原因 | 可指示SSC相关原因 | | **Session-AMBR** | 会话聚合最大比特率 | 跨两个PSA的速率约束 | 注意：**新前缀本身不在N1 SM容器里**，而是在用户面RA里。N1 SM消息主要起"通知UE网络已配置multi-homing锚点、QoS可能调整"的作用。 **步骤13-16（业务迁移+释放旧锚点）**：UE上层应用逐步将新建的连接绑定到new prefix（走PSA2）。当SMF判断迁移完成（基于定时器、UE报告或策略），更新BP规则使其仅指向PSA2，并向PSA1发起N4 Session Release。**旧的IPv6前缀此时失效**，PDU Session最终锚定在PSA2。 ## 五、触发场景：DNAI与AF影响是核心驱动力 SSC Mode 3 PSA Change最常见的触发是**DNAI（DN Access Identifier）变化**。DNAI标识UE访问DN的"接入点"位置，TS 23.501 §5.6.7定义了DNAI机制。 | 触发场景 | 触发源 | 信令路径 | |---------|--------|---------| | **UE移动出当前PSA服务区** | SMF基于UE位置 + UPF服务区 | SMF内部决策→§4.3.5.3 | | **AF请求流量引导到特定DNAI** | AF → NEF/PCF | AF影响（TS 23.503）→ PCF下发授权DNAI给SMF | | **负载均衡/运维** | OAM/SMF策略 | SMF内部决策→§4.3.5.3 | | **MEC EAS重定位联动** | AF (EAS deployment info) | AF influence → PCF → SMF选新DNAI的PSA | 当AF影响生效时，PCF通过**Npcf_SMPolicyControl_Update**响应（或SM Policy Association Modification）向SMF提供：authorized DNAI、traffic steering policy（如UL CL/BP插入指示）、对应的目标UPF候选。SMF据此决定PSA relocation，这正是边缘计算场景下SSC Mode 3与EAS重定位（TS 23.548）联动的关键链路。 ## 六、抓包识别与常见故障点 ### 抓包如何识别SSC Mode 3 PSA Change 在Wireshark/tshark中，该流程可通过以下特征识别： 1. **N4面**：会看到一条**新建的N4 Session Establishment**（指向一个新UPF，`cause=REQ_ACCEPTED`），紧接着对同一PDU Session的**旧UPF的N4 Session Release**——这是"先建后断"的标志。中间还应有对I-UPF的**N4 Modification**配置BP规则。 2. **N11面（AMF↔SMF）**：`Namf_Communication_N1N2MessageTransfer`携带`PDU Session Modification Command`，且**不携带"Release"语义**——区分于SSC Mode 2的重建。 3. **用户面（N3）**：抓到**ICMPv6 Router Advertisement**（type=134），且Source是UPF、Payload含新的/64前缀——这是multi-homing新前缀下发的铁证。 4. **N6/用户数据**：UE的两个前缀的流量一段时间内并存，随后旧前缀流量归零。 ### 常见故障点与排错 | 故障现象 | 可能原因 | 排错思路 | |---------|---------|---------| | **UE未获得新前缀，业务卡在旧PSA** | I-UPF/PSA2的RA下发规则（N4）未正确配置 | 查N4 Session Est是否含RA发送指示；查UE是否处理RA（IPv6 stack开关） | | **迁移期丢包严重** | BP分流规则错误，UL流量未正确分到两个PSA | 查N4 Modification中FAR的双隧道配置；核对N9 F-TEID | | **旧PSA过早释放导致业务中断** | SMF定时器过短或业务迁移判定的策略激进 | 调整SMF的迁移完成判定阈值；检查UE上报的迁移完成指示 | | **UE应用不迁移，停留在旧前缀** | 上层应用未实现基于前缀的重连逻辑（多宿主应用层支持缺失） | 这是UE/应用侧问题，需应用支持RFC 8157类多宿主迁移 | | **PSA Change后QoS不对** | N1 SM Modification未正确更新QFI→PSA2映射 | 核对PDU Session Modification Command的QoS Flow List | ## 七、SSC Mode 3 vs UL CL vs SSC Mode 2 三方对比 | 维度 | SSC Mode 3 PSA Change | UL CL本地分流 | SSC Mode 2重建 | |------|----------------------|-------------|---------------| | **目的** | 锚点迁移（make-before-break） | 业务分流到本地DN | 锚点更换（断后再连） | | **主PSA是否变** | 变（旧PSA1→新PSA2） | 不变 | 变（重建） | | **是否额外PSA** | 过渡期双PSA并存 | 主PSA + additional PSA | 单PSA | | **用户面function** | Branching Point | UL CL | 无（重建新隧道） | | **IP地址** | 变（multi-homing新前缀） | 不变 | 变（全新IP） | | **业务连续性** | 无中断 | 无中断 | 有中断 | | **典型场景** | MEC业务跟随、移动优化 | 固定锚点下的本地出局 | 简单业务 | ## 常见问题 **Q: SSC Mode 3 PSA Change和SSC Mode 2重建都会改变UE IP，区别到底在哪？** A: 区别在**连续性策略**。Mode 2是break-before-make——先释放旧PDU Session（旧IP失效），UE再用新IP建立新PDU Session，期间业务中断。Mode 3是make-before-break——先建立新PSA、下发新前缀，新旧两个PSA与两个前缀并存，业务逐步迁移后才释放旧PSA，全程不中断。Mode 3的实现成本高（需multi-homing支持、BP分流），但用户体验好得多。 **Q: 为什么新IPv6前缀要通过用户面RA下发，而不是放在N1 SM信令里？** A: 因为新前缀是IPv6协议栈层的资源，遵循IPv6 SLAAC（无状态地址自动配置）的既有机制。3GPP复用了标准的ICMPv6 Router Advertisement（RFC 4861）来下发/64前缀，这样UE的IPv6 stack无需为5G做特殊改造，只需把PDU Session当成一个支持多前缀的链路即可。这也保证了多宿主的标准化与跨厂商兼容。 **Q: Branching Point和UL CL看起来都是分流，实际部署会不会混淆？** A: 二者**用途不同**。UL CL用于在固定主PSA下把**部分业务**分流到本地出局（MEC本地分流，主PSA不变）。BP用于SSC Mode 3迁移期间让**两个PSA临时共存**（业务从旧PSA平滑迁到新PSA）。一个PDU Session里可以同时有UL CL和BP（如additional PSA场景，TS 23.502 §4.3.5.6），SMF通过N4的PDR/FAR规则区分。抓包看N4规则的Forwarding目标UPF数量和语义即可区分。 **Q: SSC Mode 3只支持IPv6吗？IPv4 PDU Session能用吗？** A: **multi-homing变体（§4.3.5.3）只支持IPv6**，因为multi-homing依赖多个IPv6前缀共存，IPv4单地址无法做到双锚点并存。对于IPv4 PDU Session，SSC Mode 3的锚点变更通常通过网络发起的PDU Session重建（或先释放再建立，类似Mode 2语义）实现，无法做到真正意义的make-before-break不中断。这也是为什么MEC/URLLC场景强烈推荐IPv6 PDU Session。 **Q: 抓包看到N4对旧UPF直接Release，怎么确认这不是Mode 2重建？** A: 看三个特征：① 在旧UPF Release**之前**，是否有针对**新UPF**的N4 Establishment（make-before-break标志，Mode 2重建不会有"先建"）；② PDU Session ID在全程是否**保持不变**（Mode 2重建会新建Session ID）；③ 是否抓到用户面ICMPv6 RA携带新前缀。三者俱全即为SSC Mode 3 PSA Change。 ## 参考来源 1. [3GPP TS 23.502 V18.10.0 — Procedures for the 5G System (5GS)](https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/18.10.00_60/ts_123502v181000p.pdf) — §4.3.5.3 Change of SSC mode 3 PDU Session Anchor with IPv6 Multi-homed PDU Session、§4.3.5.6 Change of additional PDU Session Anchor for IPv6 multi-homing 2. [TS 23.502 §4.3.5.3 条目解读 — iTecSpec](https://itecspec.com/3gpp/23.502/s/4.3.5.3) — multi-homed PDU Session锚点重选流程说明 3. [3GPP TS 23.501 — System architecture for the 5G System](https://www.3gpp.org/dynareport?code=23501.htm) — §5.6.4.3 Multi-homed IPv6 PDU Session、§5.6.9 SSC modes、§5.6.7 DNAI 4. [SSC Modes - Session and Service Continuity in 5G — Techplayon](https://www.techplayon.com/ssc-modes-session-and-service-continuity-in-5g/) — 三种SSC模式对比与适用场景 5. [5G SSC Mode Change / Session Continuity Handling Call Flow — 3GLTEInfo](https://www.3glteinfo.com/call-flows/5g-ssc-mode-change-session-continuity-handling/) — SSC模式变更与会话连续性呼叫流程工程化解析 --- > 本文由「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 等场景全覆盖。