## 概述 每年全国运营商要执行数万次网络割接，其中最凶险的一类是5G核心网软件升级：AMF、SMF上挂着数千万用户的注册上下文，一刀下去，轻则注册成功率抖动、投诉电话被打爆，重则整省用户掉网。本文回答一个核心网工程师最关心的问题：如何在用户完全无感知的情况下，把一个“活着的心脏”换掉。文章以3GPP TS 23.501定义的AMF管理机制（负载均衡、计划移除、NF Set与UDSF）为技术主轴，结合云原生滚动升级的Kubernetes官方实践，还原一次典型核心网割接之夜的完整时间线、关键动作、观察指标与回滚门限。 ## 目录 - 一、为什么割接是核心网运维的“大考” - 二、老式割接：停机窗口与心跳时刻表 - 三、5G核心网把割接规则改写了：NF Set、UDSF与无状态NF - 四、云原生时代：滚动升级与PDB的守护 - 五、割接之夜：一次典型升级的分解动作 - 六、最容易翻车的三件事 - 七、回滚门限写进预案，而不是写进士气 - 八、经验教训清单 ## 一、为什么割接是核心网运维的“大考” 通信行业把计划内的网络变更称为“割接”，这个词自带画面感：把业务从一个系统“割”下来，接到另一个系统上去。EPC时代做MME升级，通常要在凌晨两点申请一个四小时停机窗口，先做配置和用户数据的全量备份，然后整套设备断电换软件，天亮前必须回切验证完毕——任何一个环节超时，第二天早高峰就是全省用户的灾难。 这种模式的隐含假设是：**业务可以中断**。而5G核心网没有这个奢侈。一张省级5G网络的核心网，AMF上同时持有数百万到数千万条UE注册上下文，UPF上跑着在网的全部数据隧道。用户对“断网”的容忍度已经以秒计算：直播中断三秒就是刷屏投诉，物联表计掉线就是批量告警。运营商对核心网升级的要求已经从“少中断”变成了“零中断”——这正是割接成为运维大考的原因。 3GPP在设计5G系统架构时，其实已经预判了这种运维需求。TS 23.501从R15起就内置了一整套为“计划内维护”服务的机制：AMF Set、UDSF、AMF计划移除流程、负载再均衡。换句话说，标准层面核心网就是被设计成“可以在飞行中换发动机”的。但标准给了能力，不等于运维会用好——本文要讲的，就是这套能力如何落到凌晨三点的那张割接操作单上。 ## 二、老式割接：停机窗口与心跳时刻表 先看传统模式，因为它决定了今天很多操作习惯的来源。一次典型的EPC核心网版本升级包含以下动作： | 时间节点 | 动作 | 关键风险 | | --- | --- | --- | | T-72小时 | 版本预检、配置基线核对、许可证（License）确认 | 配置漂移未发现 | | T-24小时 | 预生产环境全流程演练、备份用户数据与配置 | 演练环境与现网差异 | | T-1小时 | 冻结变更、通知客服加派坐席、值守就位 | 通报缺位引发次生舆情 | | T+0 | 设备停机、加载新版本、恢复配置 | 加载失败、License未生效 | | T+2小时 | 拨测验证、话务观察 | 漏测信令场景 | | T+24小时 | 值守观察、关闭变更单 | 深夜指标劣化无人响应 | 这个流程的两个致命约束：一是**必须有停机窗口**，业务静默时段被打包消耗掉了；二是**回滚成本极高**，一旦新版本起不来，只能从备份恢复，动辄以小时计。所有凌晨值守过老割接的老运维都记得那种心跳时刻表：每个整点核对一次拨测结果，祈祷天亮前一切正常。 ## 三、5G核心网把割接规则改写了：NF Set、UDSF与无状态NF 5G核心网的SBA架构为不间断割接提供了三块基石，这三块全部写进了TS 23.501（参考ETSI发布的3GPP TS 23.501 Rel-17版本）。 **第一块基石：NF Set——天生冗余。** TS 23.501第5.21.3节定义了NF Set：一组同类型、支持相同网络切片的NF实例，彼此可互换，因为它们共享相同的上下文数据。一个AMF Set里的AMF可以地理上分散部署，却访问同一份UE上下文。这意味着割接的第一原则变成了：**永远不要割接“唯一的那个”**。升级某个AMF之前，先确认它所在Set内还有多少可用容量，冗余度够不够扛住它摘掉后的流量转移。 **第二块基石：UDSF——状态外置。** TS 23.501第4.2.5节引入了非结构化数据存储功能（UDSF），任何NF都可以把UE上下文这类非结构化数据存进去。规范附录C明确给出了计算与存储分离的指导原则，并指出“NF将稳定状态存入存储实体是一种好的实践”。割接时这就是护身符：旧AMF实例下电前把上下文写入UDSF，新实例拉起后按SUPI、5G-GUTI或AMF UE NGAP ID取回，用户的注册状态在实例层面无感迁移。部署UDSF的AMF计划移除流程，就是TS 23.501第5.21.2.2.1节专门为割接写的教科书；未部署UDSF的网络也有备选路径（5.21.2.2.2节），由旧AMF按GUAMI分组把UE上下文直接转发给同Set内的目标AMF。规范还特别要求：5G-S-TMSI必须在一个AMF Set内唯一，否则上下文定位会撞车——这条常被初建网络时忽略，直到割接之夜才爆雷。 **第三块基石：负载权重与再均衡——流量导控的双手。** TS 23.501第5.19.3节规定AMF负载均衡通过权重因子（Weight Factor）实现，经NGAP消息下发给基站，基站按权重比例把新用户分派给Set内各AMF。规范注释里有一句话对运维极具指导意义：**新装的AMF可以在初期被赋予远高于常规的权重因子，让它更快“吃满”负载**——这正是割接回填流量的标准手法。第5.19.4节的AMF负载再均衡则解决了另一半问题：割接前要把旧AMF上的存量用户“请”出去，AMF可请求基站把从CM-IDLE态返回的一批UE重定向到同Set内的其他AMF，以最小的网络冲击完成存量迁移。整个过程中，标准还规定面向UE的N3用户面连接保持不断——数据不中断，只有信令层面做了平滑交接。 把这三块基石串起来，5G核心网割接的标准剧本就成形了，下面这张时序图是计划移除流程的信令骨架： ```mermaid sequenceDiagram participant OLD as 旧AMF participant NRF as NRF participant RAN as 基站 participant UDSF as UDSF participant NEW as 新AMF OLD->>UDSF: 完成在途事务后写入UE上下文 OLD->>NRF: 注销并声明计划移除 OLD->>RAN: 通知GUAMI不可用 Note over OLD,RAN: N3用户面连接全程保持 RAN->>NEW: 后续N2消息按AMF Set重选 NEW->>UDSF: 按SUPI或5G-GUTI取回上下文 NEW->>RAN: 更新NGAP UE关联与GUAMI ``` ## 四、云原生时代：滚动升级与PDB的守护 当核心网彻底容器化之后，割接又多了一层IT行业的成熟方法论。Kubernetes官方文档对这类场景有明确定义：Pod的消失分为**非自愿中断**（硬件故障、节点宕机）和**自愿中断**（滚动升级、节点排水），运维要管理的正是后者。 核心工具是PodDisruptionBudget（PDB），Kubernetes在v1.21版本将其转正为稳定特性。PDB为每类应用设定“同时允许倒下多少副本”的底线：比如某AMF Deployment副本数为5，PDB要求始终至少4个可用，那么通过驱逐API执行的自愿中断一次最多干掉一个Pod。运维做节点维护用的`kubectl drain`命令，就会周期性重试被PDB拒绝的驱逐请求，直到该节点上的Pod全部安全迁出或超时。这套机制翻译成核心网语言就是：**割接的并发度被硬性约束住了**，再心急的工程师也一次只能动一个实例。 但Kubernetes文档同样警告了两个坑，每一个都对应一次真实的割接事故： 其一，**直接删除Deployment或Pod会绕过PDB**。这意味着手工执行`kubectl delete`这类“快捷操作”时，保护伞是不存在的——所以成熟的核心网割接必须全部走自动化编排（O&M系统或CI/CD流水线触发），把人手从操作面剥离出去。 其二，**滚动升级本身不计入PDB约束**。Kubernetes文档明确指出：因应用滚动升级而删除或不可用的Pod虽然会“消耗”PDB额度，但Deployment、StatefulSet这类工作负载自身执行滚动更新时不受PDB限制，升级中的失败处理由该工作负载的spec（如maxSurge、maxUnavailable）单独配置。换句话说，PDB保护的是节点排水这类平台级操作，而版本升级的步调控制要靠部署清单本身——两个阀门，都不能松。驱逐时Kubernetes还会遵守Pod的优雅终止宽限期（terminationGracePeriodSeconds），新实例AMF要等旧实例把最后一笔在途N1/N2事务处理完、上下文写入UDSF后才真正接管，这正是5.21.2.2.1节“完成在途事务后存储上下文”要求的容器化落地。 ## 五、割接之夜：一次典型升级的分解动作 下面以一次省级5G核心网AMF版本升级为例做全流程复盘（案例经过脱敏，数据为该类网络的典型量级），它同时用上了上面两套机制。整体流程如下： ```mermaid flowchart TD A["T-72小时 预检启动"] --> B["配置基线与参数备份"] A --> C["预生产环境全流程演练"] B --> D["T-1小时 低峰确认与冻结变更"] C --> D D --> E["下调旧AMF权重因子至0"] E --> F["AMF向NRF注销并声明计划移除"] F --> G["UE上下文写入UDSF"] G --> H["NGAP绑定逐UE释放 N3保持"] H --> I["新版本AMF实例逐台拉起"] I --> J["上调新AMF权重因子导流"] J --> K{"KPI连续15分钟达标"} K -->|达标| L["完成割接 值守T+24小时"] K -->|不达标| M["一键回滚至旧版本"] M --> N["回滚复盘 更新预案"] ``` **预检阶段（T-72小时）。** 核心动作是三查：查配置漂移——用配置管理工具比对现网与基线的每一处差异，重点盯TAC配置、AMF Set内5G-S-TMSI唯一性、寻呼DRX参数；查容量冗余——计算摘掉一台AMF后，Set内剩余实例的CPU、注册容量、UDSF吞吐是否留有20%以上余量；查License与证书——新版软件的功能授权、N2接口的TLS证书有效期，任何一样临期都是隐性炸弹。 **导流阶段（割接日低峰，通常凌晨1点后）。** 先通过O&M把待升级AMF的权重因子降到0：规范允许运营方在NGAP连接建立后调整权重（5.19.3节注释明确支持），基站随后不再把新注册用户分给它，而它上面的存量用户则按5.19.4节的再均衡机制，在各自下一次从CM-IDLE返回时被自然重定向到同Set的其他AMF。这个设计非常优雅——**存量迁移不是一次性倾倒，而是随用户活动自然摊开**，对网络的冲击被时间稀释了。实际操作中要盯着旧AMF的注册用户数曲线，等它降到千分位以下（例如从300万降到3000以内）再动手。 **切换阶段。** 触发AMF计划移除流程：AMF完成在途事务后把上下文写入UDSF，向NRF注销并声明计划移除，向基站通报其GUAMI不可用。若AMF在NGAP建立时带了“按UE粒度重绑或释放NGAP绑定”的指示，基站会启动定时器，逐UE释放与旧AMF的信令绑定而保持N3用户面；此后基站在同Set内重选AMF承接后续N2消息。随后新版本实例逐台拉起，健康检查通过后，把权重因子以梯度方式调高——先给20%，观察十分钟，再放到与容量匹配的常规值，让流量以可控斜率回流。 **观察阶段。** 关键KPI的观察门限示例（典型值）： | 观察指标 | 基线参考值 | 告警门限 | 回滚门限 | | --- | --- | --- | --- | | 注册成功率 | ≥99.5% | <99.0%持续5分钟 | <98.0%持续3分钟 | | PDU会话建立成功率 | ≥99.0% | <98.5%持续5分钟 | <97.5%持续3分钟 | | N2接口建立成功率 | ≥99.9% | <99.5%持续5分钟 | <99.0%持续3分钟 | | 寻呼成功率 | ≥98.5% | <97.5%持续10分钟 | <96.0%持续5分钟 | | 语音掉话率 | ≤0.3% | >0.5%持续15分钟 | >1.0%持续10分钟 | 连续15分钟全部达标，割接宣告完成；任何一项触及回滚门限，立即执行回滚脚本，整个过程要求在5分钟内完成。标准允许多种实现方式，具体流程与参数行为以所用厂家官方文档为准。 ## 六、最容易翻车的三件事 **第一件：注册风暴。** 割接后最常见的次生灾害是批量用户在同一时刻重注册，冲击UDM和AUSF。诱因通常是再均衡重定向的节奏失控，或新版AMF修改了5G-GUTI策略导致UE集中触发移动性注册更新。标准的解法藏在TS 23.501第5.19.7节——NAS级拥塞控制：AMF拒绝请求时给UE下发退避时间，且规范明确要求**退避时间值要刻意打散，避免海量UE在几乎同一时刻重试**。割接预案里必须预先配置好拥塞控制参数，而不是等压垮了再临时找。 **第二件：配置漂移。** 新版本拉起后行为异常，十有八九不是软件缺陷，而是新旧版本对配置项的理解发生了变化：某个默认值变了，某条切片配置的语义变了。防线只有一条——预检阶段的配置基线比对必须覆盖100%的参数项，任何“无法比对的差异”都要在演练环境里验证过才能放行。 **第三件：UDSF单点。** 计算存储分离把状态外置了，但外置得不够彻底就是灾难：UDSF集群自身容量不足、跨AZ部署失败、备份策略缺失，任何一项都会让“无状态割接”退化回“整网备份恢复”。同理，TS 23.501第5.21.2.3节定义的AMF自动恢复机制要求为每个GUAMI配置备份AMF——这是比割接更极端场景（实例无预警宕机）的兜底，割接演练时要顺带验证这条路径的可用性。 ## 七、回滚门限写进预案，而不是写进士气 割接之夜最危险的心态是“都升到一半了，再挺一挺”。所有重大核心网事故的复盘报告里都能找到这句话的影子——此前AT&T因网络扩容中错误配置下发引发的大面积断网，就是变更管控失效的典型教材。回滚的纪律只有三条： **门限数字化。** 回滚触发条件必须是可自动判定的量化指标（如上文表格），由网管系统自动比对并告警，不依赖任何人的临场判断。 **回滚可演练。** 回滚路径本身要在预生产环境演练过，一键脚本、数据结构兼容性、旧License恢复，一样都不能是“理论上可行”。值得注意的是，滚动升级架构下新旧版本往往要在Set内短暂共存，这要求版本升级方案本身就支持灰度共存——标准层面3GPP通过NF Set的可互换性提供了可能，工程层面则取决于升级方案的兼容性设计。 **时限刚性。** 割接窗口内若尚未完成切换，无论进度到哪一步，天亮前（早高峰前的固定时点）必须回到稳定态。切换未完成而流量高峰将至时，宁可整体回滚，绝不带着半新半旧的状态迎接早高峰。 ## 八、经验教训清单 把本文的方法论压成一张随身卡片： 1. **割接的第一原则是“永远不要割接唯一的那个”**——动手前确认NF Set冗余度，这是TS 23.501第5.21.3节给的架构保险。 2. **权重因子是导流的方向盘**：降到0摘流量，梯度上调回填流量；规范明确支持给新实例高权重加速导流（5.19.3节）。 3. **UDSF是零中断的核心**：稳定状态外置、在途事务处理完再切换（5.21.2.2.1节与附录C），同时严防UDSF自身成为新单点。 4. **PDB管平台操作，部署spec管版本升级**——两个阀门都要校准，且绝不用手工命令绕过保护（Kubernetes官方文档明确警告）。 5. **注册风暴靠退避时间打散**（5.19.7节），拥塞控制参数必须在预案中预置。 6. **回滚门限数字化、回滚路径必演练**——预案里写不进数字的门限，等于没有门限。 核心网运维二十年，工具从磁带备份进化到K8s滚动升级，但割接的灵魂从未变过：**敬畏流量，尊重时间**。标准已经把“零中断”的技术能力交到我们手上，剩下的，是把凌晨三点的每一个动作都变成肌肉记忆。 ## 参考来源 1. [ETSI TS 123 501 V17.8.0（3GPP TS 23.501 Rel-17）](https://www.etsi.org/deliver/etsi_ts/123500_123599/123501/17.08.00_60/ts_123501v170800p.pdf) — 5G系统架构规范，本文第5.19节（负载均衡/拥塞控制）、5.21节（AMF管理与NF Set）、附录C（计算存储分离）均出自该规范 2. [3GPP TS 23.501 §5.21.2.2.1 AMF planned removal procedure（在线规格阅读）](https://itecspec.com/3gpp/23.501/s/5.21.2.2.1) — AMF计划移除流程（UDSF部署场景）的条款级速查 3. [Kubernetes官方文档：Disruptions（Pod Disruption Budget）](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) — 自愿性中断、PDB机制、驱逐API与滚动升级约束的权威定义 --- > 本文由「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 等场景全覆盖。