Seybold's Take: Apps should not overtax the network's signaling system
The developer community needs to heed this warning. At the Open Mobile Summit in the UK earlier this month, some of Europe's largest wireless operators called for action to prevent mobile applications from overloading their networks with signaling traffic. The issue, according to them and others I have discussed this with, is that many smartphone applications use the signaling channel to ping the network frequently for updates, email or other types of content customers want to have in a timely fashion.
The signaling channel used in most commercial wireless networks is the brain of the network. It is the channel that talks to and listens to mobile devices so the network knows where devices are and what cell they are presently attached to so the devices can receive calls, make calls, send and receive SMS and connect to the broadband network for data access. It is also used to send and receive SMS traffic in some networks, but its main function, after keeping tabs on device locations, is to signal the network when the device wants to use the network for voice, SMS, or data calls. If the signaling channel has been overloaded, requests for calls will never reach the network thus the device will never be connected to the network.
This problem has been an issue for a long time. In the U.S., the FCC requires that each network operator report on the number of dropped calls it has in a given period of time. If a device cannot gain access to the network via the signaling channel, however, that cannot be counted as a dropped call because the network never knew a call was being requested. One operator at the Open Mobile Summit mentioned that South Korea's KT wireless service voice call success rate had dropped to 10 percent of all calls due to the signaling channel being blocked by a single misbehaving application that constantly requested updates.
The issue in this case is that many applications are very chatty and query the Internet or data source far too often. The suggested remedy is for the developer community to work with the wireless network operators to try to build applications that will update information less frequently. This type of access is referred to as polling or pull. That is, the device or the application sends out a request over the signaling channel to find out if any data has been updated and if so, for the data store to send the updates to the device. The theory, of course, is that customers want to have the latest available data.
An application that uses this type of polling or pull technique--for example, to enable the tracking of stocks during the day--would generate a huge amount of traffic on the signaling channel. Wireless is a shared resource and all of those within a single cell sector share a fixed amount of data capacity. Therefore, the more applications polling the network for updates on a regular basis, the more traffic there is being generated on the signaling channel. Thus the more applications that use the signaling channel, the more likely there is to be congestion on that channel.
In many cases, the signaling channel can and does become congested prior to the actual spectrum available for voice and data services becoming congested. If many people within a given cell sector are all vying for signaling channel access to request a line to make voice calls, check stocks or emails, or for other purposes, those who have just signed on in that sector may or may not even be recognized by the network as being in that sector. If they are, when they go to use their devices they may be unable to get onto the signaling channel to request access. This is one of the many choke points in a wireless network. Others include the amount of capacity in a given cell sector, the capability of the network to backhaul the request and the data and even the amount of connectivity a network operator has to the Internet.
Choke points are those points along the route of voice or data that can prevent a call from going through or an Internet connection from being made. Developers need to be aware that these choke points exist and not build applications assuming that every time a customer needs updated data it will be available to him/her, especially if the request for the update is being made on the signaling channel.
What should developers do to minimize the impact of their application on a network's signaling channel? The first thing is to look at other ways to update your customers' information. Can you do it with push technology that does not use the signaling channel? If you cannot, then look at how often the data really needs to be updated. Don't assume that you have infinite bandwidth, and understand that you are sharing it with many others. Write your applications accordingly.
In summary, write your applications so they are not as chatty across the signaling channel. If your application is to be a success, you certainly do not want it being tagged as a data hog that causes problems for others. Consider a manual update or push technology rather than pull. Look at how often you really need to update a customer's data; perhaps you are updating every 2 minutes when every 5 minutes would be sufficient.
As a developer you have two choices: Work with the network operators to help them maintain adequate capacity on their signaling channels or ignore them, figuring that others will do it. You may find that your application is no longer selling because those who use it cannot get onto the signaling channel often enough to retrieve the updates they want and need. A well-behaved program that limits the amount of signaling channel activity it requires will win you kudos with network operators and will keep your customers happy at the same time.
Andrew M. Seybold is an authority on technology and trends shaping the world of wireless mobility. A respected analyst, consultant, commentator, author and active participant in industry trade organizations, his views have influenced strategies and shaped initiatives for telecom, mobile computing and wireless industry leaders worldwide. www.andrewseybold.com.