O.k., here are some follow-up thoughts after my previous post on background applications that generate keep-alive IP packets which have a negative effect on radio interface efficiency. The “efficiency” issue here is that the ratio between the amount of data transferred and air interface radio signaling is very unfavorable for small bursts of data, especially in cellular broadband networks such as UMTS. So Dan asks in a comment to the post why mobile e-mail (push or pull) could be counted in the “wasteful” category. All right, here we go, this is my take on it:
There are two kinds of mobile e-mail delivery:
The first is push e-mail to mobiles, such as on the Blackberry. Here the server is likely to only communicate with the mobile device when there is an e-mail to deliver. I haven't tested it personally yet so I don't make a definite statement here. But I assume even if some keep-alive messaging is necessary, for example in cases when no e-mails are delivered for some time, it should not be that much. Also, IMAP push which is supported by more and more phones these days should also not generate keep-alive messaging.
Second is pull e-mail, which I use for example as I don't like the IMAP (push) implementation of my e-mail program. My polling timer is set to 10 minutes, so my N95 checks for e-mail 6 times per hour. Definitely more wasteful than push if there are less than 6 e-mail per hour. In case you receive more e-mails per hour however, it can even be more efficient than push.
So is mobile e-mail wasting air interface resources? I guess that depends on the definition. If the definition is that an application is wasteful that only transfers little data per radio bearer setup, then I guess the answer is yes. But then, small screen web browsing, like for example with Opera Mini, would have to be categorized as quite wasteful, too. Many pages I view are compressed to less than 20 kB. Ouch, that hurts, as it's one of my favorite applications…
So my own definition of “wasteful” would be:
Exchange of IP packets for frequent keep-alive messaging that do not contain data.
That excludes e-mail push, Opera Mini use and, depending on configuration and number of emails per hour, e-mail pull.
That still leaves us with a lot of other applications, especially when connecting the PC to the cellular network, that keep babbling away and provoke lots of bearer reconfigurations. But as I said in the previous post on this topic: For battery driven devices, always-on applications are quite likely to be optimized over time to talk less to increase the battery lifetime.
The information I have is that on average, a Blackberrie device will use 10x more signalling load than a traditional phone or USB dongle for web surfing.
This is only 1 of the potential issues but it can start to explain why operators need to look into this issue ASAP.