# 切换不断流：会话锚点搬家记 ## 一、切换成功了，业务为什么还是断了？ 做网络优化的人几乎都遇到过这种投诉：后台看指标，切换成功率99.8%，漂亮得很；用户那边却在地铁上掉了一次视频通话。你翻遍空口日志，A3事件、测量报告、切换命令，每一步都教科书般完美。那业务为什么还是断了？ 因为**切换和业务连续，根本不是同一层的事**。 切换解决的是空口问题：手机从一个基站搬到另一个基站，无线信号不断。但你的业务数据并不只跑在空口上——它还要穿过一条从基站通向核心网的隧道，最后从一台叫UPF的设备走出去，进入互联网。这条路的终点站，才是真正的要害：**你的IP地址，是锚在这台UPF上的**。 基站换了，只要锚点UPF不变，你的IP就不变，业务无感。可一旦网络决定把锚点也换掉——比如你从广东漫游到了北京——你的IP就要换，所有绑定这个IP的连接（TCP、UDP会话、登录状态）全部作废。业务断不断，取决于锚点动不动，而不是基站动不动。 这一篇要讲的，就是移动性管理拼图中最后一块没被讲透的部分：**会话与业务连续性**，行话叫SSC（Session and Service Continuity）。它回答一个核心问题：当人移动、当业务下沉、当网络重构时，**IP层的连续性该怎么保**。 ## 二、先讲类比：你的收货地址 把网络想象成快递系统。 你网购时填的收货地址，决定了包裹怎么送到你手上。在5G里，这个“收货地址”不是你家，而是**锚点UPF**。所有发往你手机的数据包，先 according 地址找到锚点UPF，再由它通过隧道转交给当前为你服务的基站，最后从空口落到你手机上。 ``` 所有数据包 → 锚点UPF（收货地址） → 隧道 → 当前基站 → 手机 ``` 现在你搬家了（换了基站、换了城市），有两种思路： **思路一：不换地址。** 人搬到哪，快递先寄到老地址，再由老地址的人转寄给你。数据包永远先到原来的锚点UPF，再由它跨千里转发过来。IP不变，业务无感——但你人在广东，数据却要先飞到北京的锚点再绕回来，白白多跑两千公里，时延和带宽都吃亏。 **思路二：换地址。** 在北京给你登记一个新收货地址，以后包裹直达。路径最优了——但所有按旧地址给你发货的商家（TCP连接、视频流、游戏服务器）都找不到你了，业务要全部重来一遍。 这就是移动性管理的根本两难：**路径最优与业务连续，不可兼得**。而不同业务对这两者的偏好天差地别——工业机械臂一毫秒都断不得，宁可绕路；刷网页的人不在乎IP换不换，只要快。 于是5G的架构师们没有硬选一个答案，而是把“什么叫连续”定义成了三种模式，让网络按业务需求挑。这就是SSC mode 1、2、3的由来。 ## 三、技术底座：PDU会话与锚点 在讲三种模式之前，先把“锚点”这个概念钉死。 5G里手机上网的基本单位不是“连接”，而是**PDU会话**。每建立一个PDU会话，核心网的会话管理功能（SMF）就要做一件关键决策：**从一堆UPF里挑一台当“锚点”**。这台锚点UPF承担三件事： 1. **分配IP地址**——你手机的IP不是基站给的，是锚点UPF代表网络分配的； 2. **终结隧道**——基站与锚点UPF之间是一条GTP-U隧道（N3接口），数据包被封在隧道里跑； 3. **对外出口**——数据从这里离开运营商网络，进入互联网或企业内网。 ```mermaid flowchart TD UE["手机UE"] --> gNB["基站gNB"] gNB -->|"N3隧道 GTP-U封装"| UPF["锚点UPF"] UPF --> DN["数据网络DN"] NOTE["IP地址锚定在这里"] -.-> UPF ``` 这张图的关键在于那条虚线：**IP地址锚在UPF上，而不是基站上**。基站只管无线那一段，你的IP跟它毫无关系。所以基站换一百次，只要锚点UPF不动，IP就纹丝不动——这就是为什么你在市内坐高铁刷手机，IP地址看起来“很稳定”。 反过来，只要锚点一换，IP必换。理解了这一点，三种SSC模式就只是三个不同的“搬家策略”而已。 ## 四、三种模式：三种对“连续”的定义 ### SSC mode 1：锚点终身制 会话建立时锚定在哪台UPF上，就终身不离不弃，直到会话释放。IP全程不变。 - **好处**：业务绝对连续。TCP连接、UDP流、登录态，全都稳如泰山。 - **代价**：人走远了，数据就得绕路。你在广东，锚点在北京，每个数据包都要跨省旅行一圈，时延增加、浪费骨干网带宽。 这套模式服务的是**“连续压倒一切”的业务**：工业远程控制、电网差动保护、远程驾驶。这些场景丢一个包都可能出人命，多几十毫秒时延反而是小事。 但绕路问题总得有个补丁。业界的办法是：锚点不动，但在靠近手机的“路边”再插一台UPF，做一个**上行分类器（UL CL）**或**分支点**——它像个岔路口，把发往本地服务器（比如园区里的边缘服务器）的流量就地分流，只有发往远方的流量才绕回北京锚点。锚点还是那个锚点，IP还是那个IP，但本地业务不用再跨省了。这是mode 1在边缘计算时代依然能活下来的关键设计。 ### SSC mode 2：先建后拆（make-before-break） 网络决定换锚点时，**先把新锚点的会话完整建好、通路打通，然后才释放旧锚点的会话**。新旧两条路短暂并存，无缝交接。 类比：先租好新房子、搬完家，再退旧房。中间没有一天睡大街。 ```mermaid sequenceDiagram participant UE as 手机UE participant AMF as AMF participant SMF as SMF participant NU as 新UPF participant OU as 旧UPF Note over SMF: 决定重定位锚点 SMF->>NU: 创建新锚点 会话B SMF-->>UE: 触发建立新PDU会话B UE->>AMF: 请求建立会话B AMF->>SMF: 转发请求 SMF->>NU: 完成建立 分配新IP SMF-->>UE: 会话B就绪 SMF->>OU: 释放旧锚点 会话A Note over UE,OU: 新路打通后才拆旧路 ``` 注意图里那个决定性的细节：**释放旧会话A的指令，排在会话B完全就绪之后**。这就是“先建后拆”四个字的全部含义。切换的空口那部分（老读者熟悉的Xn切换、N2切换）照常发生，真正讲究的是IP层的这次换锚。 - **好处**：中断窗口被压缩到两条路交接的一瞬，理论上业务近乎无感。 - **代价**：IP还是变了。TCP连接依然要断开重连——mode 2保住的是**网络层的衔接**，没法替应用层保住绑定旧IP的四元组。 - **典型用户**：语音、视频通话、云游戏。这些业务能接受连接重建，但不能接受“没有网络”的空窗期。 ### SSC mode 3：先拆后建（break-before-make） 允许先把旧会话断掉，再建新锚点的会话。中间有一段真正的离线时间。 但直接断掉太野蛮，所以mode 3加了一层温柔：**网络在释放旧会话之前，会提前通知UE“这个会话快没了”**，UE收到通知就立刻去申请新会话，新旧动作尽量紧凑衔接，把离线窗口压到最短。类比：房东提前一个月通知你退租，你从容找新房，虽然中间还是要搬一天家。 - **好处**：网络实现最简单，资源释放最干脆，不给网络留双会话并存的负担。 - **代价**：必然有一个真实的业务中断窗口。 - **典型用户**：网页浏览、文件下载、后台同步。这些业务断个一两秒，用户根本察觉不到。另外，当UE在**不同接入方式之间搬家**（比如从5G挪到WiFi再挪回来）时，IP本来就必然变化，mode 3是最自然的选择。 用一个简单的公式对比mode 2和mode 3的中断窗口： $$T_{\text{中断}}^{\text{mode2}} = T_{\text{路径交接}} \quad\text{（新旧并行，只算交接时间）}$$ $$T_{\text{中断}}^{\text{mode3}} = T_{\text{释放}} + T_{\text{新建会话}} \quad\text{（串行，两段相加）}$$ 前者是毫秒级，后者是秒级。差了一个数量级，但网络付出的复杂度也差了一个数量级。 三种模式放在一起看： | 维度 | SSC mode 1 | SSC mode 2 | SSC mode 3 | |---|---|---|---| | 锚点UPF | 终身不变 | 换，先建后拆 | 换，先拆后建 | | UE的IP | 不变 | 变 | 变 | | 业务中断 | 无 | 毫秒级衔接 | 秒级离线窗口 | | 上层TCP | 完全不断 | 因IP变化需重连 | 因IP变化需重连 | | 类比 | 老家地址终身不变 | 先租新房再退旧房 | 房东通知后再搬家 | | 网络复杂度 | 低（加UL CL中） | 高（双会话并存） | 低 | | 典型业务 | 工控/远程驾驶 | 语音/云游戏 | 浏览/下载 | ## 五、谁来拍板：一场三方协商 既然三种模式差异这么大，那一次PDU会话建立时，到底谁决定用哪种？ 答案是**三方博弈，网络终裁**： 1. **UE先申请**：手机在建立PDU会话时，会告诉网络“我支持哪几种mode、我偏好哪种”。这是请求，不是命令。 2. **网络再裁决**：SMF结合本地策略、DNN（接入点名）、切片配置，从UE支持的列表里挑一个，在应答里明确告知“这个会话就用mode X”。UE没申请的，网络不能硬给；UE申请的，网络可以不给。 3. **运营配置打底**：某条DNN或某个切片可以在运营侧直接配死默认mode——比如企业专线切片直接锁mode 1，不给你商量的余地。 ```mermaid flowchart TD Q{"业务能不能容忍换IP"} -->|"完全不能"| M1["SSC mode 1 锚点不动"] Q -->|"能换 但怕空窗"| M2["SSC mode 2 先建后拆"] Q -->|"能换 也能忍中断"| M3["SSC mode 3 先拆后建"] M1 --> P["UL CL分流补救绕路"] M2 --> P2["边缘计算就近落地的主力"] M3 --> P3["普通上网与跨接入搬家"] ``` 还有一个容易被忽略的点：mode 2/3的锚点重定位**不是只有移动才触发**。边缘计算场景下，应用功能（AF，比如某个云游戏平台）可以主动请求网络“把这台手机的锚点挪到我园区里的UPF来”，为的是让时延从30毫秒掉到5毫秒。人在原地没动，锚点照样搬家。**SSC机制的本质是“锚点重定位的工程化流程”，移动只是触发条件之一**。 | 角色 | 提供什么 | 原理上的角色 | |---|---|---| | UE | 请求/支持的mode列表 | 提出偏好，无决定权 | | SMF与运营策略 | 最终选定的mode | 终审法官 | | DNN/切片配置 | 默认mode模板 | 事前规则 | | AF应用侧 | 锚点重定位请求 | 业务驱动的触发者 | ## 六、现网里它长什么样 ### 为什么市内IP不变，跨省就变 现在你能完整解释这个日常现象了：市内移动，切换只在基站间发生，锚点UPF岿然不动，IP当然不变（这就是mode 1的实际运行图景）。而当你跨省漫游，运营商往往出于路由效率和合规考虑，让目标省份的SMF重新给你选一个本地锚点——锚点一换，IP跟着换。很多人以为“IP变了是基站的事”，其实是核心网在千里之外给你换了一次锚。 ### 边缘计算为什么把SSC推上主角 5G前传后传那几篇文章里讲过，UPF正在从省中心大机房下沉到园区、工厂、变电站。下沉之后，一个新问题立刻浮出水面：**下沉的UPF是临时的，你不会永远待在这个园区**。离开园区时，业务锚点必须迁回省中心——这一迁就是一次标准的mode 2锚点重定位。可以说，没有SSC机制，边缘计算就只能是“进得去出不来的陷阱”：人在园区里时延5毫秒，一出大门业务直接断。SSC mode 2就是那座让业务“进得来也出得去”的桥。 ### 调试视角：三个真实的坑 **坑一：切换全绿，业务照断。** 排查思路要跳出空口：如果trace里看到旧PDU会话释放、新PDU会话建立，且两次分配的IP不同——这是锚点重定位了，空口背了锅。看会话释放原因和前后IP是否一致，一眼定位。 **坑二：ping得通，业务断。** 用户投诉“网络明明是通的，APP却要重新登录”。ping走的是新IP的ICMP，当然通；断的是绑在旧IP上的TCP长连接和登录态。IP变了就是变了，这不是故障，是mode 2/3的固有行为。要怪只能怪应用没用上支持连接迁移的传输协议。 **坑三：双会话并存引发的计费困惑。** mode 2交接的那一小段时间里，手机身上同时挂着两个PDU会话、两个IP。做话单核对和流量对账的人如果不知道这一点，会对“凭空多出来的短会话”百思不解。那不是异常，是先建后拆的痕迹。 **坑四：NAT残留。** 企业出口的防火墙/NAT设备上，旧IP的会话表项还没老化，新IP的会话又进不来白名单，出现“换锚后头几秒部分站点打不开”。这种问题在无线侧查一万遍日志也查不出来，得去传输和IT侧找。 ### 常见误解澄清 - **误解：切换成功 = 业务连续。** 错。切换只保证L1/L2无线链路搬家成功，L3的IP连续性由SSC机制独立负责，两者可能一成一败。 - **误解：SSC mode是手机说了算。** 错。手机只有申请权，SMF结合运营策略有终裁权。 - **误解：mode 2能保证所有业务无感。** 错。mode 2保的是网络衔接，IP一换，普通TCP照样断。真要做连接级迁移，得靠应用层/传输层自己的本事（比如QUIC的连接迁移设计），SSC只是把“地基”铺平。 ## 常见问题 **Q: SSC mode和切换（handover）到底是什么关系？** A: 两个不同层面的接力赛。切换是空口层的事——手机把无线连接从一个基站挪到另一个基站；SSC是核心网的事——决定数据出口（锚点UPF和IP）动不动。切换成功了，锚点若同时被换，业务照样断一次；反过来，锚点不动时哪怕切换失败重连，IP还在，业务也能快速恢复。排查业务中断时，先分清这两层各自的状态。 **Q: 为什么我的IP在市内不变，一出省就变了？** A: 市内移动只触发基站间切换，锚点UPF不变，IP自然不变（典型的mode 1运行状态）。跨省时运营商会出于路由效率重新选择本地锚点，锚点换则IP换。这不是故障，是网络在“路径最优”与“业务连续”之间做的一次重新定价。 **Q: mode 2和mode 3都要换锚点，网络凭什么给某个会话选2不选3？** A: 看业务对“空窗期”的容忍度。语音、云游戏这类实时业务宁可让两条路短暂并存（资源开销大）也不能接受离线，给mode 2；浏览、下载断了无感，就用实现简单的mode 3。而UE申请了哪些mode、DNN/切片配了什么默认值，划定了网络实际可选的范围。 **Q: 现网怎么查一个会话用的是哪种SSC mode？** A: 从信令面入手：PDU会话建立的应答消息里会明确携带网络选定的SSC mode；核心网侧的会话追踪和话单里也有对应字段。工程上更快的办法是看行为特征——会话全程IP不变的是mode 1；出现“新会话先建、旧会话后释”且时间上有重叠的是mode 2；旧释新建且中间有离线窗口的是mode 3。 **Q: 现在很火的QUIC连接迁移，和SSC是什么关系？** A: 分工不同的两层。SSC在网络层解决“锚点和IP要不要换、怎么换”的问题；QUIC连接迁移在传输层解决“IP换了之后，连接能不能不断”的问题——它用连接ID代替四元组来标识连接，IP变了连接还活着。两者配合才是完整的连续性方案：SSC把换锚的空窗压到最短，QUIC把换IP的断连抹平。只靠任何单层，都做不到真正的业务无感。 ## 参考来源 1. [ShareTechnote 5G技术站](https://www.sharetechnote.com/) — 站内检索"SSC Mode"，含PDU会话锚点与三种模式的信令级讲解，本次编写环境未能联网逐页核验，读者可自行检索验证 2. [EventHelix 5G信令流程图集](https://www.eventhelix.com/5G/) — PDU Session建立与释放的时序图演示，适合对照本文第六节流程理解 3. [Wikipedia: 5G条目](https://en.wikipedia.org/wiki/5G) — 5G网络架构的权威概述性定义 4. 3GPP系统架构规范（规范编号略，按本文科普定位不作展开） — SSC mode与锚点重定位机制的原始定义处，进阶读者可到3GPP官网按"session and service continuity"检索 --- > 本文由「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 等场景全覆盖。