Regardless of the network, the consequences of a signaling storm event can be very devastating in terms of continuity and quality of the service to be delivered, because the same “structure” that is supposed to support your service, goes mad and attacks vital network functions, disabling your nodes with huge amounts of messages, consuming network resources like bandwidth, spectrum, CPU process capacity, among others; troubleshooting for these events is rarely trivial and network recovery times tend to be long after such events. For cellular networks, like every other network that carries a service this is an evident risk, and the industry has made an effort to present this risk usually in a very polarized way, normally splitting the problem between the RAN and the CORE, even sometimes declaring that the increase in signaling is good when you have it at the CORE and bad if you have it in the RAN, this simplification is good because it makes it easy to approach the problem, but it’s not accurate. Neither is accurate to centralize the blame on just one cause; probably you have heard that the main reason for signaling storm events is the massive adoption of smartphones, well this is mainly true, but leaves out several other causes that make the problem worse. So the intention in this blog entry is to try and widen the perspective on signaling storm events, and to present it in a different way.
Not just two sides
Signaling storms can be caused by many different reasons and cellular networks are exposed to the risk in different ways depending on a myriad of factors, like the current technology deployment status or future strategies of service offerings. Incredibly the status of the network current and future in terms of technology and service, play a key role determining the level of exposure the network has to the problem. Following I’ll mention just a few of the many sides:
Level of penetration of smartphones.
The predominant smartphone OS (even more important the previous one).
The status of deployment of new generation of RAN technology and the pace the MNO implements it.
The application of advance features in the CORE and RAN (or the lack of it).
The mods users apply on devices.
Level of popularity of certain apps.
Lack of optimization of the RAN network.
Obsolesce of CORE equipment in terms of CPU power and buffer capacity.
The presence of malicious SW and mobile virus.
The level of implementation of Quality models and differentiated service.
Early mesh implementations of Diameter failing to scale to meet the business needs.
So, I’m presenting an Emergency Pocket Guide
Given the current state of declining ARPU for cellular operators, and the pressure to monetize on the shift of mobile phones usage, is only normal to be critic about what preventions or measures must be taken to protect your network from the storm; as presented earlier, a two-sided approach is not wise, and the first step to be taken, as almost every emergency pocket guide advices, is to find out what’s your position in reference to the threat, what’s the level of exposure to the problem. But make no mistake; the threat is real and networks inevitably are getting more exposed to the problem, but from this to believe that one piece of equipment in the core or one feature on the RAN will cover all your problems lies a big road. So following the same spirit of an emergency pocket guide to the home to prepare against emergencies I present my version to prepare your network against the threat of the Signaling Storm.
Hi,We have deployed a couple of ASR9001's recently and while we're still adjusting to the XR os we're fairly comfortable with it. Having said that, we're experiencing a strange issue where I don't know if it's a bug or a config issue. The ASR9k...
Wanted to see what other ISP's were using on the edge for IP routing. We currently use some 7600's, and my initial thoughts are to move those functions (BGP upstream peering) to ASR1K's, but we'd also be happy with a 9K in that role, as we already h...
Hi, I executed upgrade in ASR9010 with RSP A9K-RSP440-TR and A9K-RSP880-SE, in the previous version (IOS XR 6.1.4 and IOS XR 5.3.3) When I showed the show redundancy the Redundancy node status was NSR-Ready, but with IOS XR 6.4.2 the status is: NSR-not-co...
Topology BriefThree isolated IGP domains AGG-A, AGG-B, CORE running ISIS level 2 onlySegment routing is enabled on all IGP domainsCORE10 (SRPCE) running BGP-LS all border routers to learn topology from all three domainsFor reachability between PE/PCC to S...