当一张网突然“集体失聪”

2015年5月25日傍晚，英国春季银行假日。伦敦、曼彻斯特、格拉斯哥、北爱尔兰部分地区，O2的用户发现手机上信号格还在，但电话打不出、短信发不出、数据也不通——整张网像被人按下了静音键。商务大臣萨吉德·贾维德（Sajid Javid）发推喊话："No signal O2. Please sort it out."。当晚23时35分（英国夏令时），O2发言人对媒体确认服务恢复正常，并承诺“将开展全面调查以确定根因”。

八年多过去，这份根因报告始终没有出现在公开渠道。但“全网级信号失踪”这个命题，恰恰是核心网与无线运维工程师绕不开的终极考题：业务面好好的，控制面先崩了——信令风暴（Signaling Storm）。本文以这起O2事件为引子，结合近年来arXiv与ACM上的信令风暴实证研究，以及笔者一线的排查经验，把“信令异常排查”这条Round 4最硬核的实战线讲透：原理、案例、方法论、工具链、防御体系，一次讲完。

目录

• 一、信令风暴：一张移动网的哮喘病
• 二、事故现场：O2英国银行假日断网复盘
• 三、论文拆解：谁在制造信令风暴
• 四、一线排障六步法与工具链
• 五、防御纵深：从接入限流到数字孪生
• 六、经验教训清单
• 参考来源

一、信令风暴：一张移动网的哮喘病

普通用户眼里，移动网就是“流量”；工程师眼里，移动网是用户面和控制面两条腿走路。你发一条微信，肉眼可见的只有那几百字节的消息，但它身后拖着一条完整的信令链条：

1. 手机在空闲态被推送消息唤醒，网络先要寻呼；
2. 终端发起RRC连接建立（随机接入、RRC请求、竞争解决、安全激活）；
3. NAS层发服务请求，核心网为它建立承载；
4. 数据跑完，连接释放，终端回到空闲态。

一条小数据，前面要垫五六条信令。控制面的处理能力——寻呼容量、RRC建立次数/秒、MME/AMF的NAS消息吞吐——是按典型用户行为模型规划的稀疏资源。当大量终端同时敲门，控制面就成了整张网的第一块多米诺骨牌：RACH信道拥塞、寻呼堆积、MME过载，最后演变成“信号满格但什么都不敢”的怪象——因为广播信号还在，专属连接根本建立不起来。

这就是信令风暴的病理：它不是流量太大，而是“敲门”太频繁。2026年6月发表的一篇针对5G信令风暴攻击的研究在引言里给出了行业共识性判断：设计不良的即时通讯类应用（IM App）是移动网络信令风暴最常见的来源之一——推送心跳、状态轮询、断线重连，每一个都可能在错误的时间以错误的频率制造海量RRC/NAS信令。这不是厂商甩锅终端，而是控制面天然脆弱的数学现实：控制面信令的“单条成本”远高于用户面数据的“单字节成本”。

下面这张表是笔者按一线经验整理的示意对照（数量级感受用，非精确统计，具体网络差异很大）：

记住这个表格，后面看O2事件和论文时，你会发现所有角色都能对号入座。

二、事故现场：O2英国银行假日断网复盘

先把事件时间线摆出来，以下信息均来自《卫报》、伦敦标准晚报等公开报道，笔者按运维复盘格式重新整理：

timeline
    title O2英国2015年5月25日信号中断时间线
    section 5月25日
        傍晚起 : 伦敦曼彻斯特格拉斯哥等地用户陆续失去信号
        当晚 : 客服初期建议重启手机 : 商务大臣发推敦促恢复
        23时35分 : O2确认服务恢复正常
    section 5月26日
        上午 : 媒体报道O2致歉 : 承诺开展根因调查
        事后 : 完整根因报告未见于公开渠道

影响评估：这是语音、短信、数据“三料全断”的接入层故障，且发生在银行假日傍晚的话务高峰。对比一下就能理解严重性——三年后的2018年12月，O2又因爱立信设备过期证书瘫痪4G数据网（本专栏已有专文复盘），但那次语音尚通；而2015年5月25日这次，用户连电话都打不出来。两起事件形态完全不同，检索资料时注意别混为一谈。

处置过程：从公开信息看，O2的处置是标准的“舆情三板斧”——让用户重启、官微道歉、承诺调查。工程侧的动作我们无从得知，但23时35分恢复意味着当晚就完成了止血。

最有意思的是“消失的根因”：ITPro当时的报道引述O2说法，把问题初步归因于英国的基站问题（phone mast issues），随后承诺的"full investigation"没有以公开白皮书的形式落地。作为复盘者，我必须诚实地说：这起事件的官方根因，至今不可考。这不是O2一家的问题，而是运营商行业的通病——“三无故障”：无根因公告、无量化影响报告、无整改白皮书。监管通报只有一句“已恢复”，工程师能学到的尽调材料近乎为零。

所以这篇文章的写法必须换轨：案例负责给你“病征”，论文和一线方法论负责给你“病理与诊断流程”。这正是资深运维和普通网管的分水岭——没有现成答案时，你靠什么定位？

三、论文拆解：谁在制造信令风暴

信令风暴在学术界不是新鲜话题，但高质量实证研究并不多。笔者挑了三篇来源可靠、方法各异的研究，讲清楚每篇“说了什么、数据从哪来、哪些可信”。

第一篇：海量M2M接入的RACH过载仿真（arXiv:1601.05098）。这篇论文用ns-3的LENA LTE模块模拟智慧城市场景下海量机器类终端（M2M）同时接入。结论很直白：默认配置的LENA模块会低估M2M流量对蜂窝网的冲击，同时证实了行业长期担心的事——海量终端同步发起接入时，RACH（随机接入信道）会过载。换句话说，IoT设备不需要“攻击”网络，只要它们的上报周期同步（比如整点批量唤醒），就足以把接入层敲穿。数据来源是系统级仿真，这是它的局限，但RACH过载的机制推演是扎实的。

第二篇：移动网络风暴综述（ACM，DOI 10.1145/2642687.2642688）。这篇的立论更狠：移动网络天生易受信令攻击与信令风暴影响——恶意软件和移动僵尸网络可以通过过量信令打满控制面，而M2M业务的周期性特征会让风暴概率进一步放大。注意区分：这是作者的分析框架与预警观点，不是某次具体事故的取证报告。但它给出了运维视角最重要的一个提醒——信令风暴既是故障问题，也是安全问题，两条线在网优部门和专业安全部门的交接缝里，最容易漏防。

第三篇：5G RRC风暴攻击的实验验证（arXiv:2608.16441）。这是三篇里工程含金量最高的：作者用开源的OpenAirInterface（OAI）在软件无线电+商用手机组成的真实测试床上实现了信令风暴攻击，验证了其可行性，并在gNB侧实现了轻量级缓解方案——通过监控“可疑的半开连接”（发起RRC建立但不完成后续流程的终端）直接在基站上止损。仿真论文告诉你“理论上会炸”，这篇告诉你“真机上真能炸、还能防”。对一线工程师，它的价值在于把“半开连接监控”这个防御思路具体化了。

再把2026年的两篇新研究补进来：ScienceDirect上那篇针对3GPP体系信令风暴的系统性综述，梳理了成因、量化模型与对策全集，适合当工具书；同年6月那篇关于5G RRC非活动定时器滥用的研究，则揭示了一个新攻击面——恶意操纵非活动定时器制造隐蔽性信令风暴。四篇合起来，信令风暴的成因图谱就齐了：

flowchart LR
    A["信令风暴成因图谱"] --> B["终端侧失控"]
    A --> C["网络侧短板"]
    A --> D["恶意攻击"]
    B --> B1["海量IoT同步心跳上报"]
    B --> B2["IM应用设计不当：高频寻呼唤醒"]
    C --> C1["RACH资源规划不足"]
    C --> C2["过载控制依赖手动静态配置"]
    D --> D1["僵尸网络信令洪泛"]
    D --> D2["RRC半开连接攻击与定时器滥用"]

四、一线排障六步法与工具链

讲了病理，讲诊断。以下是笔者亲历的一次全网性信令异常排查（细节已脱敏，数字为示意，不指向任何具体运营商）：凌晨两点，网管告警刷屏——RRC建立成功率从99%跌到七成，寻呼量飙到日常三倍，客服工单同步起来：“电话打不通”。当时的第一反应不是查基站，而是先问一个问题：用户面还好吗？答案是用户面流量平稳。用户面平稳+控制面过载，八成是信令风暴，排查就此定轨。

多年经验沉淀下来，我把它总结为六步法：

第一步，定界：画影响面三角。时间、地理、业务三个维度各拉一条线。地理上是全网散点还是成片？业务上是全断还是只断语音？散点+全业务断，指向控制面；成片+单业务断，多半是局部资源问题。这一步五分钟，能省后面五小时。

第二步，看KPI三线交叉。把RRC建立尝试次数、NAS注册/服务请求量、寻呼量三条曲线拉到同一张图上。信令风暴的指纹是“三线同涨而用户面不涨”——流量没多，敲门的人多了三倍。如果三条线里只有寻呼暴涨，要怀疑核心网侧的群呼或重复寻呼；只有RRC建立暴涨，先看无线侧。

第三步，抓信令拿证据。核心网侧开信令跟踪，S1/N2口抓包，用Wireshark或tshark过滤NAS层的注册/服务请求及其拒绝原因值。原因值是金子：#7（服务未授权）、#15（无可用小区）、#18（网络故障）各自的占比变化，直接告诉你终端在抱怨什么。

第四步，聚类找聚集性。把异常信令按IMSI、IMEI（终端型号）、APN、小区、时间片做五维聚合。真凶几乎总有聚集性——某个型号的某批终端、某个App的某个版本、某个APN下的某类卡。当年我参与的那次排查，最后就是靠IMEI前八位聚合，把问题收敛到一个型号的物联网模组固件升级上。

第五步，止血：接入类控制。定位到信令源后，先限流再修复。3GPP在TS 22.011里定义了接入类控制（ACB）及增强方案（EAB等）作为标准化的接入控制框架，核心网侧也有过载控制机制。要说明的是：标准允许多种实现，具体参数和行为以各厂家官方文档为准。止血的顺序永远排在“根治”前面——先让网络活下来，再去追终端的责。

第六步，复盘固化。把本次信令曲线存为基线，把“三线同涨”做成自动告警规则，把熔断阈值写进预案并演练。下次同类故障，响应时间从小时级压到分钟级。

flowchart TD
    A["全网性信号异常告警"] --> B{"影响范围判定"}
    B -->|"个别基站"| C["单站排障：告警与天馈传输"]
    B -->|"成片区域"| D["检查RAN侧资源与邻区"]
    B -->|"全网散点"| E["怀疑控制面或终端侧"]
    E --> F["核心网信令跟踪：NAS注册与寻呼"]
    F --> G{"信令量是否异常放大"}
    G -->|"是"| H["五维聚合定位信令源"]
    G -->|"否"| I["检查网元负荷与过载控制"]
    H --> J["确认终端型号与App版本聚集性"]
    J --> K["接入类控制限流并联络终端厂商"]
    K --> L["复盘：固化信令基线与熔断预案"]

工欲善其事，必先利其器。这六步对应的工具链大致如下：

五、防御纵深：从接入限流到数字孪生

排查是事后功夫，防御才是日常。信令风暴的防御体系，我按“终端—无线—核心网—行业新动向”四层来讲。

终端与应用侧：风暴的源头九成在终端行为。推送通道收敛（避免每个App各建一条长连接各养一套心跳）、IoT终端错峰上报、固件升级灰度发布——这些是成本最低的防御。GSMA的物联网安全指南系列对此有专门要求，核心思想就一句：把终端的信令行为当作网络安全边界的一部分来管理。

无线侧：RACH资源规划要按“最坏同步接入规模”校核，而不是按均值；对IoT终端善用3GPP定义的节电与延后接入机制（PSM、eDRX、扩展等待时间等），让“能不醒就不醒、要醒就错峰”成为默认姿态。arXiv 1601.05098的仿真结论反向提醒我们：规划工具如果低估海量接入，规划出来的余量就是幻觉。

核心网侧：过载控制（overload control）要有分级熔断——先限新接入、再限低优先级业务、最后才轮到全量拒绝。这里必须重申前文的边界声明：3GPP允许多种实现，各网元过载响应的具体行为以所在网络的设备文档与实测为准，切不可照抄别人的参数表。

行业新动向是2026年的这篇Spillway（ACM，DOI 10.1145/3789240.3829205）。它的批评很扎心：现有防御依赖手动、静态配置的本地过载控制，无视异构网元之间的串行依赖——你限了MME的流，上游基站的重试洪峰会换个地方决堤。Spillway的思路是给核心网建数字孪生，在孪生体上自动演练并优化全局过载控制策略，应对大规模设备同步重连引发的级联、亚稳态过载。要分清：这是论文作者的主张与原型验证，代表方向，不等于任何现网的既成事实。但方向我认——信令风暴的防御正在从“各网元自保”走向“全网协同调度”，而协同的载体大概率是数字孪生。

六、经验教训清单

把全文收拢成七条，建议打印贴在网管终端旁边：

1. 用户面平稳+控制面过载=信令风暴的第一指纹，先定轨再细查，别在无线参数里大海捞针。
2. 影响面三角（时间/地理/业务）是排查的第一张图，五分钟定界，胜过五小时蛮干。
3. 信令有聚集性：IMSI、IMEI、APN、小区、时间片五维聚合，真凶几乎必现原形。
4. 止血永远先于根治：接入类控制是保命手段，日常就要把阈值和预案演练好，别等风暴来了现翻手册。
5. 信令风暴既是故障也是安全事件：僵尸网络和恶意App那条线，网优部门和安部门必须共管。
6. 警惕“三无故障”：像O2 2015年5·25这样根因永不公开的事故在行业里是常态——外部学不到的，就用自己网络的基线数据补课，每次故障后的曲线归档比检讨书值钱。
7. 关注防御的范式迁移：从本地静态过载控制到数字孪生驱动的全局协同（Spillway代表的路线），2026年之后的新建核心网值得把这类能力写进采购需求。

回看2015年那个银行假日之夜：用户看到的是转圈的手机，我们看到的应该是一张控制面如何被“敲门声”压垮的解剖图。故障会过去，根因报告可能永远缺席，但方法论沉淀下来，就是下一个凌晨两点你拉开椅子坐下时，最先想到的那六步。

参考来源

1. O2 'back to normal' after signal meltdown — The Guardian — 2015年5月25日O2信号中断的一手报道：影响范围、恢复时间、官方回应与商务大臣发推施压。
2. O2 says sorry for bank holiday signal outage — Evening Standard — 同一事件的并行报道，交叉验证时间线与伦敦受影响情况。
3. M2M Massive Access in LTE: RACH Performance Evaluation in a Smart City — arXiv:1601.05098 — ns-3仿真证明海量M2M同步接入可致RACH过载，且默认仿真模块低估冲击。
4. Experimental Validation and Mitigation of RRC Storm Attacks in 5G — arXiv:2608.16441 — 基于OpenAirInterface真实测试床的RRC信令风暴攻击验证与gNB侧缓解方案。
5. Storms in mobile networks — ACM — 信令攻击与风暴的分析框架：恶意软件、僵尸网络与M2M周期流量的控制面风险。
6. Spillway: 数字孪生驱动的核心网过载防御 — ACM — 2026年新研究：批评现有手动静态过载控制，提出数字孪生自动化全局熔断。

本文由「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 等场景全覆盖。