<!-- title: 5G边缘PSA锚点SSC3重选拆解 -->
<!-- domain: slicing-mec -->

# 5G边缘MEC服务连续性与PDU会话锚点（PSA）SSC Mode 3重选信令全链拆解

## 一、问题背景：为什么边缘计算需要"换锚点"

在5G边缘计算（MEC）部署中，应用服务器（EAS）下沉到靠近用户的边缘数据中心，用户面流量需经一个靠近UE的本地UPF——即 **PDU会话锚点（PDU Session Anchor, PSA）**——通过N6接口接入边缘DN。这个PSA是UE与DN之间N6隧道的终结点，UE的IP地址就由它分配并保持。

核心矛盾由此产生：**UE是会移动的，但PSA一旦确定在会话生命周期内通常不动。** 当UE从边缘站点A覆盖区移动到边缘站点B覆盖区时，如果PSA仍锚定在A，则所有流量要绕回A，造成" trombone（长号管）"效应——时延劣化、回传带宽浪费，MEC的"低时延本地化"价值瞬间归零。

解决这个矛盾有两条路径，二者机制完全不同：

- **UL CL（上行分类器）/ BP（分支点）插入**：保持原PSA不变，仅插入一个分支UPF把部分流量就近分流到本地DN。UE的IP地址不变。这是"不换锚点"的方案（此前已专门拆解）。
- **PSA重选（PSA Change）/ PSA重定位**：直接把锚点从A搬到B。由于N6终结点和IP分配点都变了，**UE的IP地址必然改变**。这就是本文聚焦的 **SSC Mode 3** 机制。

为什么不能直接换IP了事？因为很多应用（尤其长连接、TCP会话、媒体流）对IP突变敏感。3GPP的设计哲学是：用 **"make-before-break（先建后拆）"** 的SSC Mode 3，在网络侧先建好指向新锚点B的新PDU会话，确认用户面打通后，再拆除旧锚点A的会话，最大限度缩短切换窗口，让"IP变更"对应用的冲击降到可接受范围。这套机制的规范定义在 **TS 23.501 第5.6.9节（SSC模式）与第5.6.4节（PDU会话锚点）**，流程定义在 **TS 23.502 第4.23节（5GC对边缘计算的支持）**。

## 二、SSC三种模式与PSA锚点的关系

3GPP定义了三种会话与服务连续性（SSC）模式，直接决定"锚点能不能换、怎么换"：

```mermaid
flowchart LR
    subgraph M1["SSC Mode 1：永远不换锚点"]
        A1["PSA 固定"] --> A2["IP 地址不变<br/>UE移动无影响"]
    end
    subgraph M2["SSC Mode 2：先拆后建 break-before-make"]
        B1["释放旧 PDU 会话"] --> B2["UE 重建新会话<br/>新 PSA + 新 IP"] --> B3["存在中断窗口"]
    end
    subgraph M3["SSC Mode 3：先建后拆 make-before-break"]
        C1["先建立新 PDU 会话<br/>新 PSA + 新 IP"] --> C2["用户面打通"] --> C3["再释放旧会话"]
    end
```

| 对比维度 | SSC Mode 1 | SSC Mode 2 | SSC Mode 3 |
|---------|-----------|-----------|-----------|
| PSA锚点 | 全程不变 | 可变（拆旧建新） | 可变（先建新后拆旧） |
| UE IP地址 | 不变 | 变更 | 变更 |
| 时序模型 | — | break-before-make | make-before-break |
| 中断窗口 | 无 | 有（重建期间） | 极短（新旧并存期间） |
| 典型场景 | IMS/VoNR、固定IP业务 | 可容忍中断的尽力而为业务 | **边缘MEC锚点跟随、AR/VR低时延连续业务** |
| 规范出处 | TS 23.501 5.6.9.1 | TS 23.501 5.6.9.2 | TS 23.501 5.6.9.3 |

需要强调：**SSC模式是按PDU会话粒度决定的，不是按UE粒度。** UE在建立PDU会话时通过NAS消息携带期望的SSC模式，SMF综合以下三方面最终裁决：UE请求的SSC模式、UDM签约中该DNN/S-NSSAI支持的SSC模式列表与默认模式、以及UE策略（URSP中的SSC模式选择策略 **SSCMSP**，定义于TS 23.503）。这是协议设计中"UE提议、网络决策"原则的典型体现。

## 三、SSC Mode 3核心设计：make-before-break

SSC Mode 3的灵魂是 **先建后拆**。这条原则解决了"换IP"与"服务连续"之间的张力：

1. **网络决定换锚点**：SMF基于UE位置变化、AF（边缘应用功能）经PCF/NEF下发的重选请求、或本地策略判定当前PSA不再最优，决定将锚点从PSA1迁到PSA2。
2. **触发UE建立新会话**：SMF向UE发送指令，触发UE为相同的DNN+S-NSSAI发起一次**全新的PDU会话建立**。这条新会话由SMF选择新的PSA2并分配新IP。
3. **新旧并存**：在新会话建立完成、用户面到PSA2打通之前，旧会话（PSA1）一直保持服务，业务不中断。
4. **拆除旧会话**：新会话就绪后，SMF才释放旧PDU会话，回收PSA1资源。

由于新旧会话对应同一DNN但拥有不同IP，**边缘应用层（EAS）必须感知并迁移会话上下文**——这正是TS 23.548（R18 EdgeApp）与ME平台协同要做的事。可以说，SSC Mode 3是"传输层先迁、应用层后迁"的协同机制。

```mermaid
stateDiagram-v2
    [*] --> 稳态PSA1: 建立PDU会话 锚定PSA1
    稳态PSA1 --> 触发重选: SMF判定PSA不再最优<br/>(UE移动/AF请求/策略)
    触发重选 --> 新会话建立中: SMF触发UE建立新会话
    note right of 新会话建立中
        选择PSA2 + 分配新IP
        旧会话PSA1仍服务
    end note
    新会话建立中 --> 新旧并存: 新用户面打通
    新旧并存 --> 释放旧锚点: 确认新会话可用
    释放旧锚点 --> 稳态PSA2: 回收PSA1资源
    稳态PSA2 --> [*]: 会话正常释放
```

## 四、网络触发PSA重选完整信令时序图

下面拆解网络触发的SSC Mode 3 PSA重选完整信令流（对应TS 23.502 4.23节"PSA change"流程与4.3节PDU会话管理流程的结合）：

```mermaid
sequenceDiagram
    autonumber
    participant UE
    participant RAN as (R)AN
    participant AMF
    participant SMF
    participant PSA1 as 旧锚点UPF/PSA1
    participant PSA2 as 新锚点UPF/PSA2
    participant PCF
    participant AF as 边缘AF/ME平台

    Note over UE,PSA1: 阶段0：当前PDU会话锚定PSA1
    AF->>PCF: 影响业务流/触发重选请求(NEF或直接)<br/>含UE位置/目标DNAI
    PCF->>SMF: SM Policy Assoc Mod<br/>含"PSA重选"指示/目标DNAI
    Note over SMF: SMF评估：当前位置已远离PSA1<br/>决定换锚点(SSC mode 3)
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer<br/>(N1 SM容器: PDU Session Modification Command)
    AMF->>(R)AN: N2 SM信息(转发给UE)
    (R)AN->>UE: DL NAS Transport:<br/>PDU SESSION MODIFICATION COMMAND<br/>(含SSC mode 3重选指示)
    Note over UE: UE收到触发，对同一DNN+S-NSSAI<br/>发起新PDU会话建立
    UE->>(R)AN: UL NAS Transport:<br/>PDU SESSION ESTABLISHMENT REQUEST<br/>(新PDU Session ID, SSC mode 3, DNN, S-NSSAI)
    (R)AN->>AMF: N2消息(含N1 SM容器)
    AMF->>SMF: Nsmf_PDUSession_CreateSMContext<br/>(新会话)
    Note over SMF: SMF选择新锚点PSA2(就近边缘UPF)
    SMF->>PSA2: N4 Session Establishment<br/>(分配N3/N9/N6, UE新IP)
    SMF->>AMF: Nsmf_PDUSession_CreateSMContext响应<br/>(含N2 SM: 接入PSA2的用户面隧道)
    AMF->>(R)AN: N2 PDU Session Resource Setup
    (R)AN->>UE: RRC Reconfiguration(新DRB/隧道)
    UE-->>PSA2: 用户面双向打通(新IP)
    Note over UE,PSA2: 新PDU会话就绪，新旧并存
    SMF->>UE: (经AMF/RAN)释放旧PDU会话
    SMF->>PSA1: N4 Session Release
    AF->>AF: 边缘应用上下文迁移到EAS2(新DNAI)
    Note over UE,PSA2: 锚定完成，UE用新IP访问边缘应用
```

这条流程的精妙之处在于 **步骤9**——SMF并不直接建立新会话，而是通过一条 `PDU SESSION MODIFICATION COMMAND` 把"重选决定"告知UE，把"建立新会话"的发起权交还给UE。这与SSC Mode 2用释放触发重建（5GSM cause #39 "Reactivation requested"）形成对照。如此设计的原因是：新会话的DNN、S-NSSAI、SSC模式、URSP匹配都应由UE侧按标准流程发起，保证与正常PDU会话建立完全一致，避免引入旁路状态机。

## 五、逐消息关键IE解析

下表汇总SSC Mode 3重选链路上的核心Information Element：

| 信令消息 | 关键IE | 含义与作用 | 规范出处 |
|---------|-------|-----------|---------|
| AF→PCF影响请求 | Target DNAI / UE location | 边缘AF指明UE应迁往的目标数据网络接入标识 | TS 23.502 4.23.5 |
| PCF→SMF策略更新 | URSP/会话策略含重选触发 | 传递"网络决定换PSA"的策略意图 | TS 23.503 |
| PDU SESSION MODIFICATION COMMAND（N1） | SSC mode 3重选指示 | 触发UE对同一DNN/S-NSSAI建立新会话 | TS 23.501 5.6.9.3 / TS 24.501 |
| PDU SESSION ESTABLISHMENT REQUEST（UE→网络） | SSC mode、DNN、S-NSSAI、PDU Session Type | UE请求新会话，必须携带SSC mode 3 | TS 23.502 4.3.2.2 |
| Nsmf_PDUSession_CreateSMContext | DNN、S-NSSAI、UE位置、Old PDU Session ID | SMF据此选PSA2并关联旧会话上下文 | TS 23.502 4.3.2.2 |
| N4 Session Establishment（→PSA2） | N3/N9/N6 F-TEID、UE IP、QoS | 在新锚点建立用户面并分配新IP | TS 29.244 |
| PDU Session Release（→UE，旧会话） | Old PDU Session ID | 释放锚定PSA1的旧会话 | TS 23.502 4.3.4 |

一个常被忽略的细节：IPv6场景下SSC Mode 3的"先建后拆"还有变体——多归属（Multi-Homing）+ 分支点（BP）。TS 23.501 5.6.4允许为一个IPv6 PDU会话增加额外PSA并分配额外IPv6前缀，旧前缀逐步回收，实现更平滑的锚点迁移。但纯SSC Mode 3（单锚点切换）仍是IP地址整体变更。

## 六、与UL CL的对比：何时换锚点，何时只分流

PSA重选与UL CL插入是边缘MEC用户面的两把"刀"，必须按场景选用：

```mermaid
flowchart TB
    Start{"边缘流量优化决策"} --> Q1{"UE原PSA是否<br/>仍可最优服务?"}
    Q1 -- "是(仅需本地分流)" --> ULCL["插入 UL CL / BP<br/>保持PSA不变, IP不变"]
    Q1 -- "否(锚点已远离)" --> SSC{"SSC模式?"}
    SSC -- "Mode 1" --> Keep["无法换锚点<br/>只能插入UL CL缓解"]
    SSC -- "Mode 2" --> BBM["break-before-make<br/>拆旧建新, 有中断"]
    SSC -- "Mode 3" --> MBM["make-before-break<br/>先建后拆, MEC首选"]
    ULCL --> Done1["业务无感, 适用会话内分流"]
    MBM --> Done2["IP变更, 应用需迁移上下文"]
```

| 对比维度 | UL CL/BP插入 | SSC Mode 3 PSA重选 |
|---------|-------------|------------------|
| 是否更换锚点 | 否 | 是 |
| UE IP地址 | 不变 | 变更 |
| 触发 | UE位置进入边缘区/AF分流规则 | UE离开旧边缘区、锚点失效 |
| 规范 | TS 23.502 4.23.2 | TS 23.502 4.23.3 / 4.23.5 |
| 应用影响 | 无感 | 需配合应用上下文迁移 |
| 代价 | 多一个分流UPF | 新建PDU会话、IP变更 |

经验法则：**能用UL CL解决就别换PSA**；只有当原锚点物理上已无法就近服务（UE跨大区移动、回传代价过高）时，才启动SSC Mode 3重选。R18（TS 23.548 EdgeApp）进一步把"锚点迁移"与"EAS迁移"通过边缘使能层（EES/EEC/ECS）协同，让应用层感知DNAI变化并平滑切换。

## 七、抓包识别与故障排查（实战）

### 抓包如何识别SSC Mode 3重选

在5GC信令抓包（NGAP/5G-NAS/PFCP）中，SSC Mode 3重选有三个特征指纹：

1. **先看到一条对老PDU Session ID的 `PDU SESSION MODIFICATION COMMAND`**，而非Release。5G-NAS层（NAS-5GS消息类型0x2C）携带SSC mode 3相关指示。
2. **紧接着出现一条 `PDU SESSION ESTABLISHMENT REQUEST`**，DNN和S-NSSAI与旧会话一致，但PDU Session ID是新的。用Wireshark/TShark过滤：`nas_5gs.message_type == 0xc1`（Establishment Request）。
3. **PFCP层面看到针对新UPF的 `N4 Session Establishment`（消息类型0x32）**，分配新的N3 F-TEID与新UE IP；稍后才出现旧UPF的 `N4 Session Release`（0x36）。

### 常见故障点

- **UE收到重选指示后不重建新会话**：多为UE实现问题或URSP/SSCMSP策略缺失。排查UE侧是否正确解析SSC mode 3指示。
- **新会话建立后旧会话不释放**：SMF状态机异常，导致旧PSA1资源泄漏、UE双IP并存。需检查SMF的make-before-break定时器与释放触发逻辑。
- **应用未感知IP变更**：EAS侧未对接EdgeApp使能层，IP一变长连接全断。这是"传输迁了、应用没迁"的典型割裂。
- **PSA2选择错误**：SMF仍选了远离UE的UPF，重选毫无意义。检查DNAI映射与UPF拓扑配置。
## 常见问题

**Q1：SSC Mode 3和SSC Mode 2都是"换IP换锚点"，到底差在哪？**
A：核心差在时序。Mode 2是break-before-make，先拆旧会话再由UE重建，存在明显中断窗口；Mode 3是make-before-break，先建好新会话（新PSA+新IP）再拆旧的，新旧并存期间业务不断。对时延敏感的边缘MEC业务，Mode 3是标配。

**Q2：既然要换IP，那SSC Mode 3怎么保证应用不中断？**
A：靠三层协同——传输层先建后拆保证连接窗口极短；UE侧新会话就绪后无缝切换；应用层通过TS 23.548 EdgeApp使能层感知DNAI变化，由ME平台迁移会话上下文到新EAS。三层到位才谈得上"无感"。

**Q3：UL CL已经能本地分流了，为什么还要SSC Mode 3换锚点？**
A：UL CL不换锚点、不分新IP，只在原会话上插分支UPF就近分流，适合"原锚点仍可用、只需本地化"的场景。当UE远离原PSA、回传代价过高或锚点失效时，必须用SSC Mode 3把锚点整体搬走。

**Q4：IPv6的SSC Mode 3有什么特殊处理？**
A：IPv6支持多归属（Multi-Homing）+分支点（BP）变体：可为一个PDU会话增加额外PSA并分配额外IPv6前缀，旧前缀逐步回收，比纯单锚点切换更平滑。规范见TS 23.501 5.6.4。

**Q5：SSC模式由谁决定，UE说了算吗？**
A：UE提议、网络决策。UE在PDU会话建立请求中携带期望SSC模式，SMF综合UDM签约（DNN/S-NSSAI支持的SSC模式列表与默认值）和UE策略（URSP中的SSCMSP，TS 23.503）最终裁决。

## 参考来源

1. [3GPP TS 23.501 V18.x — System architecture for the 5G System](https://www.3gpp.org/dynareport/23501.htm) — 第5.6.4节（PDU会话锚点）、第5.6.9节（SSC模式）
2. [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.23节（5GC对边缘计算的支持）、第4.3.2.2节（PDU会话建立）
3. [3GPP TS 23.503 — Policy and Charging Control Framework](https://www.3gpp.org/dynareport/23503.htm) — SSCMSP（SSC模式选择策略）、URSP
4. [3GPP TS 23.548 — Application enablement for Edge Computing in 5GC (EdgeApp)](https://www.3gpp.org/dynareport/23548.htm) — R18边缘使能层与锚点/应用协同
5. [ShareTechnote — 5G PDU Session Establishment](https://www.sharetechnote.com/html/5G/5G_PDUSessionEstablishment.html) — SSC三种模式说明
6. [Cisco UCC 5G SMF Configuration Guide — Session and Service Continuity Mode](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) — SMF 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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)