核心网池化给了运营商冗余，却没给均衡：权重因子只管新用户的首选分配，存量用户靠身份标识“粘”在原网元上，日子一久，一个池子就会变成一边烧、一边闲的跷跷板。本文以2018年北海道地震当夜的话务拥塞为引子，拆解AMF/MME池负载分配的真实机制、四种典型失衡根因、三层过载闸门的设计，以及重均衡操作背后的信令代价，最后给出一张一线可直接落地的巡检清单。
2018年9月6日凌晨3点08分（日本时间），北海道胆振地方发生6.7级地震，震中附近的安平町观测到震度7——这是继2016年熊本地震之后，日本时隔两年再次观测到震度7。地震随即引发全岛范围大停电，北海道电力辖区约295万户用户同时失电，铁路、机场、供水系统接连瘫痪。
对通信网来说，比停电更棘手的是随后的话务洪峰。大灾当夜，所有人都想给家人报平安：基站备电还在撑着，话务量却瞬间冲上去。据当时日本媒体报道，docomo、au、SoftBank等移动运营商先后宣布网络出现话务拥塞（日方称「輻輳」），并启动了呼出限制——只优先保障110、119等紧急呼叫，同时开放171灾害留言电话，让用户把“我平安”的信息录进留言信箱，把反复重拨的呼叫量压下来。
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还是它。只有重新附着、跨池移动这类少数场景，才会触发一次重新选择。
把两半拼起来，结论就出来了：权重只管增量，不管存量；而任何一个稳定运行的网络，存量永远是大头。
flowchart TD
A["AMF池<br/>权重一比一"] --> B["新用户首注<br/>按权重分发"]
A --> C["老用户带GUTI<br/>粘回原节点"]
C --> D["存量慢慢偏斜<br/>实际变成六比四"]
B --> D
D --> E["热点AMF<br/>CPU逼近告警线"]
E --> F["AMF宣告过载<br/>OVERLOAD START"]
F --> G["无线侧接入控制<br/>拒绝非紧急请求"]
G --> H["NAS退避<br/>终端按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信令链——鉴权、安全模式、注册更新，一环不少。分批不当，这就是一次计划内的信令风暴：你亲手把过载的负载，变成了过载的信令。标准文本对重均衡的谨慎措辞，就是提醒这件事。
一线的重均衡纪律，我总结为四条：
写了这么多机制，落到日常就是一张清单。这套东西不花哨，但每一条背后都站着一次真实的教训。
每月例行： - 比对“权重 vs 实际”：把各AMF的权重因子和实际驻留用户数、CPU均值拉到同一张表里。经验上，池内任意两台的实际负载占比偏差持续超过15~20个百分点，就该立项查因，别等它恶化。 - 核对过载与降级告警：本周期内出现过OVERLOAD START的节点，即使自愈了也要写复盘。
割接/扩容后24小时： - 复核NG-SETUP权重与新容量一致，确认配置更新已下发生效； - 核对新增TA的AMF归属映射； - 容灾倒换过的节点，确认回切完成、容量口径恢复。
年度演练： - 单AMF过载注入演练：验证三层闸门逐级生效，重点验证紧急呼叫在全流程中始终可达； - AMF倒换与重均衡分批演练：把分批粒度、限速参数、熔断阈值在演练里定稿。
持续盯着的核心KPI： 池内各节点CPU峰值差、重注册率异动、过载告警次数、attach/注册成功率。任何一项的趋势拐点，都比单日的绝对值更值得警觉。
回到北海道那个凌晨。地震震不垮设计良好的通信网，真正考验它的是震后那一小时的洪峰——而运营商撑住底线的手段，恰恰是那些平时看着“多余”的闸门和预案。
池化是架构送给我们 redundancy 的礼物，但均衡从来不在礼盒里。权重写在配置里，漂移长在时间里；冗余是设计出来的，均衡是运维挣来的。 每月那一次“权重 vs 实际”的比对、每一次扩容后对权重表的复核、每一场把重均衡磨熟了的演练，都是把“半个池子在烧、半个池子闲着”的剧本，提前撕掉的过程。
最好的过载闸门，是永远不必拉下的那一道。
本文由「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 等场景全覆盖。