Author: Ignacio Berberana and Francisco Javier Lorca
In Nokia’s Siemens Networks blog news we have found a very interesting entry. It is about a non- identified European operator that chose to offer Blackberry terminals without any plan of associated data (basically addressed to users who might find appealing a QWERTY keyboard mainly because they send lots of short messages. The unexpected success of this offer was an unstoppable signaling- traffic growth that even threatened to collapse the network. The heart of the matter lies apparently in the fact that Blackberries are programmed to try to establish frequently a connection to data network and thus update e-mails. Those attempts to establish connection were rejected by the network, which triggered new attempts, by the terminal, which were rejected again, and so on. Problems could be controlled with a range of commercial (offering low-cost data plans for problematic terminal users) as well as technical measures (setting up the SGSNs to ignore that mobile’s signaling). According to NSN, the final solution is simple: always sell a Blackberry with a data plan.
In the same page of NSN, there is a very interesting document (available here) which put forward the signaling problems caused by smartphones.
In many regards the key factor is in the standardized functionality of 3GPP Release 8, known as Fast Dormancy. It is necessary to get a further insight into the beginnings of 3G networks in order to explain what is all about. Initially, networks were designed having in mind laptop data devices ( dongles), where there are no battery limits, and therefore there were put into practice only three of the five RRC states which were supposed from the beginning:
“Idle” (inactive state whereby the terminal sends very little information to the network), “Cell_FACH” (for low-volume data) and “ Cell_DCH” ( for high-volume data). The battery consumption peaks in Cell_DCH, it is reduced in Cell_FACH and is minimum in Idle. When the terminal has to send/receive a high-volume information, it goes to Cell_DCH state, after an idle period, it moves to Cell_FACH state which finally comes back to Idle. For an altogether full Idle transition -> Cell_DCH -> Cell_FACH -> Idle , the elapsed time takes several seconds( additional to the time spent in communication), the network signaling consumption is quite high ( up to 30 RRC messages). The associated battery life is high as well (due to Cell_DCH and Cell_FACH states) but this wasn’t a big deal.
When smartphones were created, this scheme did represent a problem for battery. To reduce it, the standard consider two RRC additional states called Cell_PCH and URA_PCH, whereby the battery life is minor and the necessary signaling for the change of states. However these states have been slightly put into practice (according to NSN, only their network equipment have them from the beginning).
Instead, many smartphone manufacturers make use of a Release 8 function called Fast Dormancy, whereby it is the very terminal which switches off once the communication is finished ( go to Idle). This saves a lot of battery, in exchange of incrementing the signaling consumption: every time a smartphone have small connections (last presence application for status, messaging, mail server consultation, it involves a full connect/disconnect process).
From mid-2010, iPhone uses a modified version from Fast Dormancy, by which connection is released only when the screen is off. However, other manufacturers make use of this solution which can lead to serious problems of congestion in Nodes B and RNCs. There is even a GSMA document called Fast Dormancy Best Practices which highlights this idea.
Currently, the so-called “Network Controlled Fast Dormancy” has been standardized in 3GPP, therefore the terminal must use the Cell_PCH/URA_PCH scheme in the respective networks, and the reminder in Fast Dormancy.
The result is a two-folded lesson: on the one hand, there are a lot of elements that are involved in the congestion and imobile network benefits, so that data traffic is the less important. On the other hand, it might be useful to make terminal and application developers aware of the actual difference between mobile and fixed connectivity. Used to be “always online”, many applications are not aware of the load involved for a mobile network.