在移动网络里，真正压垮核心网的往往不是大流量，而是小到几十字节的心跳信令。2012年1月25日早晨，NTT docomo东京网络大面积瘫垮，250万用户约四个半小时打不出电话、上不了网——事后指向的“主犯”，是一款Android免费VoIP应用的心跳机制。本文以这次经典事故为轴，结合3GPP R12/R13的省电规范与一线运维实践，讲清楚信令风暴的形成机理、三个关键定时器的调参方法，以及一套从KPI突变到锁定终端的排查打法。
先把这起事故的公开事实摆出来。据Light Reading当时的一线报道（记者Michelle Donegan，2012年1月31日刊发），以及Slashdot、Mobile World Live（消息源为《日经新闻》）的交叉印证：
| 时间（2012年） | 事件进展 |
|---|---|
| 1月25日 早晨约8:30 | docomo东京网络大面积异常，用户无法拨打语音电话、无法上网 |
| 1月25日 上午~午后 | 故障持续约四个半小时，波及约250万用户，13:00前后恢复 |
| 1月25日 当天背景 | docomo恰在当日完成一次网络升级，目的是应对激增的智能手机信令；新系统激活后数小时内未能扛住信令负荷 |
| 1月27日 | CEO山田隆持在发布会上公开表态：将与Google就Android应用的信令行为交涉，并推动通过GSMA联合各家运营商共同应对 |
| 后续数年 | 智能手机信令问题进入标准视野，3GPP在R12/R13陆续引入PSM与eDRX省电机制 |
这起事故有几个值得咂摸的细节。
第一，事故发生在“为了解决信令问题”的升级当天。 这不是巧合，而是运维里最凶险的组合：网络本已在信令高负荷边缘运行，升级窗口本身就是风险峰值，新系统上线后的行为与预期存在偏差，几个变量叠加，刀刃恰好落在最薄处。做过割接的人都知道，最怕的不是旧系统烂，而是“旧系统烂+新系统生+业务洪峰”三件事撞在同一天。
第二，压垮网络的不是带宽，而是信令。 一款免费VoIP应用为了保持在线，以固定间隔向服务器发送心跳包。单个心跳的数据量只有几十字节，带宽上不值一提；但每一次心跳，都要把终端从空闲态唤醒——建立无线连接、完成信令交互、传输几十字节、再释放连接。真正消耗无线资源和核心网控制面的，是这一整套“为了几十字节而进行的仪式”。
第三，运营商最后选择了“找应用方谈判”这条少见的路。 2012年那场发布会上，docomo要谈的对象不是设备商，而是Google——因为它定义在Android平台上的应用行为，直接决定了日本最大移动网络的信令负荷。这个细节说明：信令风暴的治理，从来不只是网络内部的事，它横跨终端、应用、操作系统、标准组织四层。
要理解信令风暴，得先看移动终端的两种基本形态。
连接态：终端与网络之间存在无线承载，随时可传数据，耗电高，占用的无线资源也多。空闲态：终端释放无线连接，只保留在核心网的注册信息，网络知道它大概在哪个跟踪区，但不知道它具体连在哪个小区。
问题就出在两种形态之间的往返。应用层的心跳，在网络上表现为一个固定的循环：
终端空闲 → 心跳触发 → 随机接入 → RRC连接建立 → 服务请求 →
核心网建立承载 → 发送几十字节 → 连接释放 → 回到空闲 → 等下一次心跳
每一次循环，无线侧要经历随机接入、RRC建立、安全激活、承载建立、释放，核心网侧要走服务请求流程、更新承载、回收资源。整个流程的信令报文有几十条，而“有效载荷”只有几十字节。业内当时的复盘普遍给出同一个量级判断：信令开销与业务开销的比例，在这种小包高频场景下可以达到数百倍——网络消耗的是“开场和散场”的成本，观众只看了一眼海报就走了。
单台终端如此，一台基站下成千上万台终端同时如此，控制面的处理能力就成了瓶颈。更麻烦的是信令风暴的自增强特性：当控制面过载、信令响应变慢时，应用层的心跳定时器并不会变慢，终端只会更密集地重试接入，进一步推高负荷——过载导致重试，重试加剧过载，这就是风暴这个词的准确含义。
2012年前后，这不是docomo一家的烦恼。Light Reading当年的一系列报道标题本身就构成一部编年史：《NSN：Android与RIM是信令坏小子》《愤怒的小鸟挠动了信令》《运营商敦促对“话痨应用”采取行动》《O2如何消除信令噪音》《苹果削减iPhone信令闲聊》。全球运营商在同一时期被同一种问题围攻，docomo只是最先被击穿的那一个。
风暴之后，业界达成的共识是：不能只靠网络扩容硬扛，要让终端学会“该睡就睡、睡得沉一些”。这直接催生了3GPP的两项关键机制。
PSM（Power Saving Mode，省电模式），由3GPP R12引入。据Cisco MME管理文档的说明，其核心设计是：终端在数据传完后不立即进入传统空闲态，而是先停留在一个“可达窗口”，窗口期内网络随时可以寻呼到它；窗口一关，终端进入深度休眠，关闭接收机，网络不再寻呼，直到终端自己醒来做周期性位置更新，或应用主动发起业务。
这个设计的精妙之处在于把“在线”拆成了两截：可达窗口（由T3324定时器控制）和深度休眠（时长约等于T3412减去T3324）。应用若能接受“下行消息有延迟、上行随时可以”，就能把可达窗口压到极短、把休眠拉到极长——终端既省了电，网络也省了信令，因为休眠期内终端完全安静，不产生任何周期性信令。
eDRX（扩展非连续接收），由3GPP R13引入。它走的是另一条路：不关闭寻呼侦听，但把两次侦听之间的间隔拉长。传统空闲态的寻呼周期是秒级，eDRX允许把间隔配置成分钟级乃至更长——终端睡得更沉，醒来的次数更少，代价是下行消息的时延显著变大。Onomondo的技术文档给出的直观描述是：设备睡个长觉，只在约定的短暂窗口醒来扫一眼寻呼信道，没有自己的消息就继续睡。
两项机制一起，构成了此后蜂窝物联网终端省电与信令治理的标准底座。Rohde & Schwarz在面向LTE-M与NB-IoT的省电白皮书中，对两种机制的适用场景给出过系统对比，结论可以概括为一句话：对下行实时性有要求的选eDRX，能容忍大时延、追求极致省电的选PSM，两者也可以组合使用。
落到运维和优化实操层面，整个省电体系就是三个定时器的事。下表汇总了关键参数（规范出处为3GPP TS 24.008等，取值范围依据Cisco MME管理指南与Arkessa的技术文章）：
| 参数 | 规范出处 | 作用 | 取值范围 | 调参影响 |
|---|---|---|---|---|
| T3412（周期性TAU） | TS 24.008 GPRS Timer | 终端空闲态下两次周期性位置更新的间隔 | 分钟级到数小时 | 调短→位置更精准、信令更频繁；调长→信令省、寻呼范围大 |
| T3412 ext（扩展TAU） | TS 24.008 GPRS Timer 3 | 面向物联网的长睡眠场景 | 上限35712000秒，约413天 | 配合PSM使用，让水表电表级终端一年只醒几次 |
| T3324（可达窗口） | TS 24.008 Active Timer | 终端进入PSM前保持可被寻呼的时长 | 0至11160秒（约3.1小时） | 调短→省电但下行可达性差；调长→反之 |
| eDRX周期 | 3GPP R13（TS 23.682相关） | 两次寻呼侦听窗口的间隔 | 秒级到小时级 | 决定下行时延与功耗的平衡点 |
调参的核心逻辑，是把这三条旋钮与应用的业务模型对齐。几个一线原则：
第一，先看业务模型，再定参数。 抄表类应用（月度上报）适合PSM拉满：T3324给几十秒甚至归零，T3412 ext给到天级、周级；车载防盗类应用（要求分钟级下行）只能选短周期eDRX，接受更高的耗电与信令开销。参数没有绝对好坏，错配才是事故之源——把实时类应用的可达窗口压得过短，表面上看全网信令很安静，实际是应用的下行命令全部失效。
第二，心跳类应用必须做“抖动”。 大量终端如果采用相同的心跳周期，会在整点形成同频共振——几万台终端在同一秒醒来发起接入。运维上要求应用层把心跳间隔加随机偏移，把同一时刻的并发接入摊开。docomo事故里“升级后数小时内扛不住”的背景，就包含了存量终端行为与新系统容量预期错配的成分。
第三，参数下发要分批、要验证。 T3324、T3412通常由网络在附着/TAU接受消息中下发，终端按网络给的值执行。网络侧改这组参数，等于全网终端的行为同时改变——必须灰度：先小范围区域试点，观察RRC建立次数、TAU次数、寻呼拥塞率的变化，再逐步推开。这条纪律与软件发布的灰度原则完全同构。
第四，注意网络侧与终端侧的协商结果。 终端请求的定时器值与网络最终下发的值可能不同，省电指标不达标时要核对“网络实际授予值”，而不是只看终端申请值。IoT开发社区近年反复强调这一点：电池寿命测算必须基于网络授予的定时器，而非应用希望的那个值。
下面这张图梳理了PSM机制下终端的状态流转，可以直观看到三个定时器各守哪一道门：
flowchart TD
A[连接态<br/>数据传输中] -->|数据传完<br/>释放连接| B[可达窗口<br/>T3324计时]
B -->|有下行需求<br/>网络寻呼| A
B -->|T3324超时| C[PSM深度休眠<br/>关闭接收机]
C -->|T3412超时| D[周期性TAU<br/>位置更新]
D --> A
C -->|应用主动发起| E[重新附着<br/>业务请求]
E --> A
讲完原理，回到运维最关心的问题：风暴来了怎么发现、怎么定位、怎么处置。以一线实践中的通用打法（综合docomo事故复盘思路与后续NB-IoT网络的运维经验）梳理成一条标准链路。
第一步，盯住三个控制面KPI，而不是业务面KPI。 流量曲线对信令风暴几乎失明——心跳风暴发生时，业务流量可能只涨了几个百分点，但RRC连接建立次数、TAU次数、寻呼拥塞率已经翻倍。这三个指标要在网管上设独立于流量告警的门限，且以“环比突增”而非“绝对门限”为主：风暴的早期特征不是绝对值高，而是斜率陡。
第二步，分域收窄。 确认是控制面过载后，按“无线侧RRC建立成功率、核心网服务请求处理时延、特定APN的会话建立次数”三个维度切开。某一款应用的批量终端通常落在同一个APN或同一批IMSI号段上，APN维度是最快的切入口。
第三步，抽样抓信令，对比心跳间隔。 在信令跟踪口对可疑号段抽样，提取终端的接入时间序列。如果一批终端的接入间隔高度一致（比如整齐的每300秒一次），基本可以断定是同一款应用的固定心跳。2012年docomo能在几天内把矛头指向一款具体应用，靠的正是这个特征——同款应用的心跳指纹是唯一的。
第四步，处置要“限流”而不是“拉黑”。 确定应用后，直接禁止该类终端接入会引发应用层的疯狂重试，等于亲手把风暴推到第二波。一线做法是按号段分时限流、降低接入优先级，同时联系应用方修改心跳间隔与抖动策略。docomo选择与Google谈判而不是简单封禁，除了商业原因，技术上也是因为封禁根本治不了风暴。
第五步，把结论沉淀成参数基线。 每次风暴处置完，要把“该类业务推荐的T3324/T3412组合、心跳间隔下限、抖动要求”写进入网规范，新终端入库测试时逐项核对。这就是把一次故障变成一道闸门。
排查流程的整体逻辑如下图：
flowchart TD
A[控制面KPI斜率突变] --> B[确认过载类型<br/>RRC建连或TAU激增]
B --> C[APN与号段维度<br/>切分收敛范围]
C --> D[信令跟踪抽样<br/>提取接入时间序列]
D --> E{心跳间隔<br/>是否高度一致}
E -->|是| F[锁定应用与终端群]
E -->|否| G[排查参数变更<br/>与网络侧异常]
F --> H[分时限流<br/>联系应用方整改]
G --> H
H --> I[灰度恢复<br/>沉淀参数基线]
这套打法里最容易被忽视的是告警治理的前提：控制面KPI告警必须与流量告警分开建门限。很多省份的告警模板是从流量模板复制来的，门限天然按吞吐量设计，控制面的缓慢劣化在业务流量曲线上完全不可见——等到用户投诉爆发，风暴已经刮了几个小时。docomo那次事故从8:30持续到13:00，中间四个半小时里网络并非毫无感知，而是缺少能把“信令异常”从告警海里单独捞出来的机制。
时间过去十多年，场景从智能手机换成了物联网终端，风暴的风险非但没有消失，反而换了个更隐蔽的形态。
规模上，NB-IoT单基站可接入的终端数比手机时代高出一到两个数量级，水表、气表、烟感、井盖成片上线。这些终端的业务模型本该是“长睡偶醒”——PSM机制下，配合T3412 ext最长约413天的休眠上限（这是TS 24.008编码允许的理论极值，实际网络会配置得短得多），理论上一年只需要唤醒几次。但现实中大量物联网模块出厂时省电参数配置粗糙：T3324给得太长、PSM根本没启用、或应用仍按秒级心跳保活——表面上它们是“低频小包”业务，信令行为上却是一群不知疲倦的智能手机。
下行实时性的业务诉求也在跟省电机制打架。智能门锁远程开锁、POS机远程唤醒这类应用，要求网络随时能找到终端，这与PSM的“休眠期不可达”正面冲突。这类终端只能留在可达窗口或选择短周期eDRX，成为网络里信令面最贵的一批用户。运营商在物联网入网规范里逐行业定义“可达性等级”，本质就是为这批终端定价。
对一线运维来说，NB-IoT时代的信令治理新增了两件事：一是入库参数核查——新行业终端批量入网前，核对模块的PSM/eDRX能力与默认配置，把“没开省电的伪低频终端”挡在网络外面；二是按行业分组监控——水电表、车载、门锁各自建立信令基线，某行业的基线漂移单独告警，避免不同行业互相稀释门限。
回顾2012年那场事故到今天的演进，可以看到一条清晰的脉络：docomo用一次4.5小时的断网证明了“应用行为就是网络负荷”；3GPP用PSM与eDRX把省电变成了标准能力；而运维要做的事始终没变——让终端的每一次醒来，都是必要的醒来。 参数表上的三个定时器，说到底就是在回答一个问题：全网几十亿台终端，谁该睡、谁该醒、什么时候醒。把这张时间表管好，核心网的心脏就不会被心跳击穿。
最后，把本文可带走的东西压缩成七条：
信令风暴这个题目，2012年在日本以断网的方式登场，此后十几年换着面孔反复出现：智能手机时代是话痨应用，物联网时代是配错的定时器。技术一直在进步，但那句老话没有过时——压垮核心网的，从来都是你以为不值一提的小包。
本文由「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 等场景全覆盖。