## 概述 核心网池化给了运营商冗余，却没给均衡：权重因子只管新用户的首选分配，存量用户靠身份标识“粘”在原网元上，日子一久，一个池子就会变成一边烧、一边闲的跷跷板。本文以2018年北海道地震当夜的话务拥塞为引子，拆解AMF/MME池负载分配的真实机制、四种典型失衡根因、三层过载闸门的设计，以及重均衡操作背后的信令代价，最后给出一张一线可直接落地的巡检清单。 ## 目录 - 一、凌晨三点，半个海岛在拨电话 - 二、池化给了冗余，没给均衡 - 三、失衡的四种典型姿势 - 四、最后一道闸：过载控制的三层设计 - 五、重均衡：补墙，别掀屋顶 - 六、把失衡管起来：一张巡检清单 - 七、写在最后 - 参考来源 ## 一、凌晨三点，半个海岛在拨电话 2018年9月6日凌晨3点08分（日本时间），北海道胆振地方发生6.7级地震，震中附近的安平町观测到震度7——这是继2016年熊本地震之后，日本时隔两年再次观测到震度7。地震随即引发全岛范围大停电，北海道电力辖区约295万户用户同时失电，铁路、机场、供水系统接连瘫痪。 对通信网来说，比停电更棘手的是随后的**话务洪峰**。大灾当夜，所有人都想给家人报平安：基站备电还在撑着，话务量却瞬间冲上去。据当时日本媒体报道，docomo、au、SoftBank等移动运营商先后宣布网络出现话务拥塞（日方称「輻輳」），并启动了呼出限制——只优先保障110、119等紧急呼叫，同时开放171灾害留言电话，让用户把“我平安”的信息录进留言信箱，把反复重拨的呼叫量压下来。 ```mermaid timeline title 2018年9月6日 北海道地震当夜 凌晨三点零八分 : 胆振6.7级强震 : 观测到震度7 震后数分钟 : 全岛大停电 : 约二百九十五万户失电 清晨 : 报平安话务洪峰 : 据日媒报道多家运营商宣布话务拥塞 当天上午 : 启动呼出限制 : 优先保障紧急呼叫与留言业务 随后数日 : 供电与网络逐步恢复 : 各项限制陆续解除 ``` 这套“限呼保急”的动作，就是核心网**过载控制**的实战登场。它像保险丝：洪峰来临时熔断一部分普通业务，保住全网不崩。 但干过一线的都知道，把核心网压垮的，多数时候并不是地震这种极端洪峰，而是一种安静得多的病：**流量没涨，池子里的一台网元却在过载**。CPU曲线缓慢爬升、过载告警半夜响起，而同池的兄弟节点闲得发慌。查一遍话务统计，全网总量纹丝不动——问题不在总量，在**分布**。 ## 二、池化给了冗余，没给均衡 要理解池子为什么会失衡，得先回到池化设计的初衷。 4G时代的S1-flex架构（3GPP TS 23.401）允许一个eNB同时连接池内多个MME：任何一台宕机，它承载的UE重新附着即可落到别的节点上，用户几乎无感。5G把这套思想发扬光大：TS 23.501定义了AMF集（AMF Set），同池的AMF共享GUAMI资源池，gNB通过NG接口连接池内全部AMF，单点故障被彻底打散。 问题出在**分配**环节。很多人以为“池化=自动均衡”，这是运维上最常见、也最贵的误解之一。真实的机制分两半看： **前半段：权重因子只管“新来的”。** gNB与AMF之间建立NG-SETUP（4G里是S1 SETUP）时，AMF会携带一个静态参数宣告自己的容量配比——4G里叫Relative MME Capacity，取值0到255的相对容量值；5G里叫Weight Factor，并且按PLMN携带，后续标准版本还扩展了按切片（S-NSSAI）粒度的权重。gNB只对**新注册**的UE按这个权重做分发：权重1:1，新用户就一台一半。 **后半段：老用户根本不看权重。** UE注册成功后拿到S-TMSI（5G里是5G-S-TMSI），这个临时身份里编码着为它服务的AMF（GUAMI）。之后无论终端怎么在注册区内移动、怎么在连接态和空闲态之间反复横跳，它都会被“粘”在原来的AMF上——连接态走N2切换，目标AMF还是它；空闲态驻留不变，AMF还是它。只有重新附着、跨池移动这类少数场景，才会触发一次重新选择。 把两半拼起来，结论就出来了：**权重只管增量，不管存量；而任何一个稳定运行的网络，存量永远是大头。** ```mermaid flowchart TD A["AMF池
权重一比一"] --> B["新用户首注
按权重分发"] A --> C["老用户带GUTI
粘回原节点"] C --> D["存量慢慢偏斜
实际变成六比四"] B --> D D --> E["热点AMF
CPU逼近告警线"] E --> F["AMF宣告过载
OVERLOAD START"] F --> G["无线侧接入控制
拒绝非紧急请求"] G --> H["NAS退避
终端按T3346静默"] ``` 新用户的分配瞬间是均衡的，但每一台UE都带着“惯性”：入网时落在哪台AMF，之后几个月甚至几年就赖在那台AMF上。权重在NG-SETUP那一刻就定格了，而网络是活的——用户在流动、终端在新增、区域在开发。静态的权重，配上带粘性的存量，**漂移是必然的，均衡才是偶然的**。 ## 三、失衡的四种典型姿势 漂移不发生则已，一发生几乎都能对号入座到下面四种姿势。这四种，我在历次故障复盘里全都见过。 **姿势一：扩容不改权重。** 池子扩容，两台新AMF上线，NG-SETUP成功、链路正常、告警全绿——但权重表没更新，gNB手里的分配依据还是老三台的容量比。新设备闲成摆设，老设备继续烧。这种失衡最冤：设备花了钱，容量没吃到。它还有个变种：新增节点上线时用默认权重值入网，谁也没想到要改。 **姿势二：TAC映射偏斜。** 新城区入网、新线路开通，一片新跟踪区（TA）入网时默认路由到了池内某台AMF；或者规划时把场馆、景区单独划成TA，演唱会一开场，整个TA几万用户齐刷刷挤向同一台节点。TA规划的人不会想到，自己画的那条边界线，就是核心网负载的天平。 **姿势三：粘性累积。** 物联网卡、POS机、电表水表，这些终端常年不掉线、永不重新附着，入网那天选中的AMF，就是它们一辈子的归宿。运行三五年后，存量分布与权重早已面目全非。这类失衡没有单点故障，只有慢性恶化——直到某天容量评估发现“按权重算早就该扩容了，怎么这台还是烧”。 **姿势四：半池状态。** 池子升级升了一半、容灾倒换后忘了回切、某台节点降容运行——池内实际上并存着两套容量逻辑。此时看监控，负载分布“不合理”但“有原因”，最怕的是没人知道那个原因，只当它又是一种漂移。 | 根因 | 典型现象 | 排查抓手 | 处置动作 | | --- | --- | --- | --- | | 扩容不改权重 | 新节点CPU个位数，老节点高位 | 比对NG-SETUP权重与现网容量配置 | 更新权重并执行配置更新，观察增量走向 | | TAC映射偏斜 | 特定区域话务总是落在同一台 | 拉TA与AMF映射表，叠加话务分布 | 调整新TA归属或权重，大话务区提前扩容 | | 粘性累积 | 偏差逐年缓慢扩大，无触发事件 | 统计各AMF驻留用户数与入网时间分布 | 先改权重止血，存量靠自然更替消化 | | 半池状态 | 升级或倒换后负载“突然”偏了 | 核对升级窗口、倒换记录、降容标记 | 完成回切或统一容量口径，消除双轨 | 四种姿势的共同点值得写进每一个值班手册：**失衡没有告警**。设备都活着、链路都正常、KPI都达标，直到某一天热点节点的CPU撞上阈值，过载闸门“咣当”落下，用户感知劣化，大家才知道池子早就歪了。 ## 四、最后一道闸：过载控制的三层设计 失衡发展到极端，就是北海道地震当夜那种局面：请求量远超处理能力。这时唯一的任务是保命——让网元活着，让紧急呼叫通着。3GPP为此设计了层层设防的过载控制体系，一线要把每一层都当成独立的保险丝来理解。 **第一层：无线接入控制。** 洪峰最先冲击的是随机接入。5G的统一接入控制（UAC）按业务类别分档放行：普通数据业务可以被禁止接入，紧急呼叫类永远放行。这一层挡的是“别让所有人都涌进来”，是整个防线的最外圈。 **第二层：NAS退避。** 如果请求已经涌到了核心网门口，AMF拒绝时要带上退避定时器T3346（TS 24.501，4G对应TS 24.301）：终端收到拒绝后，在定时器超时前保持静默，不再重试。这一层防的是最阴险的次生灾害——**拒绝风暴的自我放大**：网元过载了拒绝请求，终端秒级重试，重试本身又成了新的负荷，雪球越滚越大。没有T3346这类退避机制，过载会在几秒钟内从“拥塞”恶化成“雪崩”。紧急呼叫同样豁免于退避限制。 **第三层：接口级过载通告。** AMF还可以主动喊话：通过S1-AP/NG-AP的OVERLOAD START消息告诉接入网“我过载了，你来分流”。4G时代这套动作是分级的——从拒绝全部RRC连接建立，到只拒绝非紧急业务，再到仅放行紧急与高优先级呼叫；5G更进一步，过载通告可以携带切片信息，**只对拥塞的那个S-NSSAI限流**，其他切片的业务不受牵连——这是切片时代过载控制最重要的进化：坏一个切片，不必陪葬全网。 | 层级 | 机制与参数 | 挡住什么 | 运维要点 | | --- | --- | --- | --- | | 无线接入 | UAC统一接入控制、RRC拒绝带等待时间 | 接入洪峰涌入小区 | 大话务预案预置分档策略，紧急类永不禁止 | | NAS层 | 拒绝携带T3346退避 | 终端重试的自我放大 | 校验退避时长配置，防止过短引发风暴 | | 接口层 | S1-AP/NG-AP OVERLOAD START | 到达核心网的信令请求 | 核对分级动作与切片粒度限流是否生效 | | 前置层 | 权重因子、容量比、临时扩容 | 让过载根本不发生 | 唯一的常态调节手段，闸门是保险丝 | 必须强调最后一行：**过载闸门是保险丝，不是调速旋钮**。它的设计目标是故障状态下保命，次数越少越好。如果把过载限流当成常态容量管理的手段，每次触发都在拿用户感知换网元安危——正确的顺序永远是先把容量和分布调对，让闸门永远用不上。 标准允许多种实现，各层参数的具体默认值与生效行为，以所用厂家官方文档为准。 ## 五、重均衡：补墙，别掀屋顶 池子歪了，怎么扶正？3GPP在TS 23.501里专门定义了负载重均衡（Rebalancing）机制：过载的AMF可以请求接入网，让它管辖的部分UE“另谋高就”——终端会收到带“需重新注册”指示的去注册请求，随后按新权重重新选择AMF。 听起来是 perfect solution，实际是一把双刃剑，锋利的那一面朝着自己。 想一下重均衡的物理本质：把N万台终端**成批地踢下线、逼它们重新走一遍注册流程**。每台UE的重注册都是一条完整的NAS信令链——鉴权、安全模式、注册更新，一环不少。分批不当，这就是一次**计划内的信令风暴**：你亲手把过载的负载，变成了过载的信令。标准文本对重均衡的谨慎措辞，就是提醒这件事。 一线的重均衡纪律，我总结为四条： 1. **先止血，再动存量。** 改权重只影响增量，零风险，永远第一个做；很多时候权重改完，配合终端的自然更替（换机、换卡、重新附着），几周后分布自己就回来了。 2. **确需重均衡，必须分批限速。** 按用户群切片分批，批与批之间留观察窗，全程限速——把“一次踢N万”拆成“一夜踢一小批”。 3. **夜间窗口加看门狗。** 挂上attach成功率、掉线率、信令量三道熔断线，任一越线立即中止。重均衡作业必须能一键停止，不能有“停不下来”的中间态。 4. **演练过了才算会。** 重均衡第一次操作绝不该发生在真实故障夜里。年度容灾演练里加上这一项，把分批参数在演练环境里磨出来。 ## 六、把失衡管起来：一张巡检清单 写了这么多机制，落到日常就是一张清单。这套东西不花哨，但每一条背后都站着一次真实的教训。 **每月例行：** - 比对“权重 vs 实际”：把各AMF的权重因子和实际驻留用户数、CPU均值拉到同一张表里。经验上，池内任意两台的实际负载占比偏差持续超过15~20个百分点，就该立项查因，别等它恶化。 - 核对过载与降级告警：本周期内出现过OVERLOAD START的节点，即使自愈了也要写复盘。 **割接/扩容后24小时：** - 复核NG-SETUP权重与新容量一致，确认配置更新已下发生效； - 核对新增TA的AMF归属映射； - 容灾倒换过的节点，确认回切完成、容量口径恢复。 **年度演练：** - 单AMF过载注入演练：验证三层闸门逐级生效，重点验证紧急呼叫在全流程中始终可达； - AMF倒换与重均衡分批演练：把分批粒度、限速参数、熔断阈值在演练里定稿。 **持续盯着的核心KPI：** 池内各节点CPU峰值差、重注册率异动、过载告警次数、attach/注册成功率。任何一项的趋势拐点，都比单日的绝对值更值得警觉。 ## 七、写在最后 回到北海道那个凌晨。地震震不垮设计良好的通信网，真正考验它的是震后那一小时的洪峰——而运营商撑住底线的手段，恰恰是那些平时看着“多余”的闸门和预案。 池化是架构送给我们 redundancy 的礼物，但均衡从来不在礼盒里。权重写在配置里，漂移长在时间里；**冗余是设计出来的，均衡是运维挣来的。** 每月那一次“权重 vs 实际”的比对、每一次扩容后对权重表的复核、每一场把重均衡磨熟了的演练，都是把“半个池子在烧、半个池子闲着”的剧本，提前撕掉的过程。 最好的过载闸门，是永远不必拉下的那一道。 ## 参考来源 1. [3GPP TS 23.501: System architecture for the 5G System](https://www.3gpp.org/dynareport/23501.htm) — AMF集、负载均衡与重均衡机制（Rebalancing）的标准定义 2. [3GPP TS 38.413: NG-RAN与5GC之间的NG-AP](https://www.3gpp.org/dynareport/38413.htm) — NG-SETUP权重因子、OVERLOAD START过载通告机制 3. [3GPP TS 24.501: 5G非接入层（NAS）协议](https://www.3gpp.org/dynareport/24501.htm) — NAS拥塞控制与T3346退避定时器 4. [2018 Hokkaido Eastern Earthquake - Wikipedia](https://en.wikipedia.org/wiki/2018_Hokkaido_Eastern_Earthquake) — 地震时间、震度与全岛停电规模 5. [3GPP TS 36.413: S1-AP协议](https://www.3gpp.org/dynareport/36413.htm) — S1 SETUP相对容量参数与4G过载动作分级 --- > 本文由「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 等场景全覆盖。