在移动网络里，真正压垮核心网的往往不是大流量，而是小到几十字节的心跳信令。2012年1月25日早晨，NTT docomo东京网络大面积瘫垮，250万用户约四个半小时打不出电话、上不了网——事后指向的“主犯”，是一款Android免费VoIP应用的心跳机制。本文以这次经典事故为轴，结合3GPP R12/R13的省电规范与一线运维实践，讲清楚信令风暴的形成机理、三个关键定时器的调参方法，以及一套从KPI突变到锁定终端的排查打法。
## 目录
- 一、凌晨事故：250万用户的四个半小时
- 二、元凶不是流量，是心跳
- 三、规范出招：PSM与eDRX的来路
- 四、三个定时器：参数表与调参思路
- 五、运维实战：从KPI突变到锁定终端
- 六、NB-IoT时代：风暴变小了吗
- 七、经验清单：给同行的话
## 一、凌晨事故：250万用户的四个半小时
先把这起事故的公开事实摆出来。据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只是最先被击穿的那一个。
## 三、规范出招：PSM与eDRX的来路
风暴之后，业界达成的共识是：不能只靠网络扩容硬扛，要让终端学会“该睡就睡、睡得沉一些”。这直接催生了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机制下终端的状态流转，可以直观看到三个定时器各守哪一道门：
```mermaid
flowchart TD
A[连接态
数据传输中] -->|数据传完
释放连接| B[可达窗口
T3324计时]
B -->|有下行需求
网络寻呼| A
B -->|T3324超时| C[PSM深度休眠
关闭接收机]
C -->|T3412超时| D[周期性TAU
位置更新]
D --> A
C -->|应用主动发起| E[重新附着
业务请求]
E --> A
```
## 五、运维实战：从KPI突变到锁定终端
讲完原理，回到运维最关心的问题：风暴来了怎么发现、怎么定位、怎么处置。以一线实践中的通用打法（综合docomo事故复盘思路与后续NB-IoT网络的运维经验）梳理成一条标准链路。
**第一步，盯住三个控制面KPI，而不是业务面KPI。** 流量曲线对信令风暴几乎失明——心跳风暴发生时，业务流量可能只涨了几个百分点，但RRC连接建立次数、TAU次数、寻呼拥塞率已经翻倍。这三个指标要在网管上设独立于流量告警的门限，且以“环比突增”而非“绝对门限”为主：风暴的早期特征不是绝对值高，而是斜率陡。
**第二步，分域收窄。** 确认是控制面过载后，按“无线侧RRC建立成功率、核心网服务请求处理时延、特定APN的会话建立次数”三个维度切开。某一款应用的批量终端通常落在同一个APN或同一批IMSI号段上，APN维度是最快的切入口。
**第三步，抽样抓信令，对比心跳间隔。** 在信令跟踪口对可疑号段抽样，提取终端的接入时间序列。如果一批终端的接入间隔高度一致（比如整齐的每300秒一次），基本可以断定是同一款应用的固定心跳。2012年docomo能在几天内把矛头指向一款具体应用，靠的正是这个特征——同款应用的心跳指纹是唯一的。
**第四步，处置要“限流”而不是“拉黑”。** 确定应用后，直接禁止该类终端接入会引发应用层的疯狂重试，等于亲手把风暴推到第二波。一线做法是按号段分时限流、降低接入优先级，同时联系应用方修改心跳间隔与抖动策略。docomo选择与Google谈判而不是简单封禁，除了商业原因，技术上也是因为封禁根本治不了风暴。
**第五步，把结论沉淀成参数基线。** 每次风暴处置完，要把“该类业务推荐的T3324/T3412组合、心跳间隔下限、抖动要求”写进入网规范，新终端入库测试时逐项核对。这就是把一次故障变成一道闸门。
排查流程的整体逻辑如下图：
```mermaid
flowchart TD
A[控制面KPI斜率突变] --> B[确认过载类型
RRC建连或TAU激增]
B --> C[APN与号段维度
切分收敛范围]
C --> D[信令跟踪抽样
提取接入时间序列]
D --> E{心跳间隔
是否高度一致}
E -->|是| F[锁定应用与终端群]
E -->|否| G[排查参数变更
与网络侧异常]
F --> H[分时限流
联系应用方整改]
G --> H
H --> I[灰度恢复
沉淀参数基线]
```
这套打法里最容易被忽视的是告警治理的前提：控制面KPI告警必须与流量告警分开建门限。很多省份的告警模板是从流量模板复制来的，门限天然按吞吐量设计，控制面的缓慢劣化在业务流量曲线上完全不可见——等到用户投诉爆发，风暴已经刮了几个小时。docomo那次事故从8:30持续到13:00，中间四个半小时里网络并非毫无感知，而是缺少能把“信令异常”从告警海里单独捞出来的机制。
## 六、NB-IoT时代：风暴变小了吗
时间过去十多年，场景从智能手机换成了物联网终端，风暴的风险非但没有消失，反而换了个更隐蔽的形态。
规模上，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把省电变成了标准能力；而运维要做的事始终没变——让终端的每一次醒来，都是必要的醒来。** 参数表上的三个定时器，说到底就是在回答一个问题：全网几十亿台终端，谁该睡、谁该醒、什么时候醒。把这张时间表管好，核心网的心脏就不会被心跳击穿。
## 七、经验清单：给同行的话
最后，把本文可带走的东西压缩成七条：
1. **信令风暴的早期特征在控制面KPI的斜率里，不在流量曲线里。** RRC建立、TAU、寻呼三个指标单独建门限，盯环比突变。
2. **升级窗口与信令高负荷重叠，是最危险的组合。** docomo事故发生在“为了解决信令问题”的升级当天——割接评估要加一条：当前控制面负荷余量是否支撑升级期行为变化。
3. **T3324/T3412/eDRX没有普适最优值，只有与业务模型的匹配值。** 调参前先回答：这个应用能容忍多大的下行时延。
4. **心跳必须抖动。** 同周期终端会在整点共振，入网规范要写死随机偏移要求。
5. **批量参数变更必须灰度分批**，网络下发的定时器值等于同时改写全网终端的行为。
6. **处置风暴用限流，慎用封禁**——封禁触发的重试是第二波风暴的燃料。
7. **省电指标以网络授予值为准**，终端申请的定时器和网络实际下发的定时器可能不是同一个数。
信令风暴这个题目，2012年在日本以断网的方式登场，此后十几年换着面孔反复出现：智能手机时代是话痨应用，物联网时代是配错的定时器。技术一直在进步，但那句老话没有过时——**压垮核心网的，从来都是你以为不值一提的小包。**
## 参考来源
1. [Android Signaling Storm Rises in Japan — Light Reading](https://www.lightreading.com/smartphones-devices/android-signaling-storm-rises-in-japan) — Michelle Donegan对docomo 2012年1月断网事故的一线报道：250万用户、约4.5小时、CEO山田隆持发布会表态、升级当日出事的细节均出自此文
2. [NTT DoCoMo Asks Google To Limit Android Data Use — Slashdot](https://tech.slashdot.org/story/12/01/30/2124236/ntt-docomo-asks-google-to-limit-android-data-use) — 佐证事故与Android VoIP应用心跳信令的关联，以及docomo要求Google调整应用连接间隔的诉求
3. [Report: Docomo looks to address Android app traffic — Mobile World Live](https://www.mobileworldlive.com/google/report-docomo-looks-to-address-android-app-traffic/) — 源自《日经新闻》的交叉印证，docomo要求Google修改Android平台信令行为
4. [MME Administration Guide, StarOS Release 21.1 — Cisco](https://www.cisco.com/c/en/us/td/docs/wireless/asr_5000/21-1/MME/b_21_1_MME_Admin/b_21_1_MME_Admin_chapter_0101001.html) — T3324（0~11160秒）与T3412 ext（上限35712000秒）的工程取值范围，PSM由3GPP R12引入的说明
5. [Power Saving in cellular LPWAN — Arkessa](https://www.arkessa.com/news-blog/power-saving-in-cellular-lpwan/) — T3412 extended上限413天的规范出处（3GPP TS 24.008）解读
6. [Power saving methods for LTE-M and NB-IoT devices — Rohde & Schwarz白皮书](https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/premiumdownloads/premium_dl_brochures_and_datasheets/premium_dl_whitepaper/Power-saving-methods-for-LTE-M-and-NB-IoT-devices_wp_en_3609-3820-52_v0100.pdf) — PSM与eDRX适用场景的系统对比
7. [eDRX and PSM for IoT — Onomondo](https://onomondo.com/blog/edrx-and-psm-for-lte-low-power-iot/) — eDRX由3GPP R13引入及其工作方式的通俗解读
---
> 本文由「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 等场景全覆盖。
