I've written before about the issues of power management in smartphones using Web 2.0 and other applications. Web services and widgets that use Javascript to pull down content in the background, presence clients checking for buddies' status updates. Social networking apps looking for new data, and so on.
The problem is exacerbated with smartphones that allow full multi-tasking, as they may have multiple applications pinging the network. This isn't too bad with 2G GPRS/EDGE, because of the way the radio channels are set up. But with 3G, and especially HSPA, there's a problem, because the radio has two "active" states (lets say "full" and "standby"), with different levels of power consumption, as well as a third state which could be called "off".
(If you want the full technical explanation on DCH and FACH channels, Martin Sauter has a great overview here)
Keeping the radio in the either fully-active or standby-active state is a battery killer.
This doesn't just impact "over-the-top" third party apps either. At the moment, it applies equally to "through-the-middle" operator services like RCS too. In theory, the operator should be able to control this a bit better, as it knows the various timings for the states on its network, and should in theory be able to configure the application to work around this.
But this would then need the application to be aware of the network state, and/or vice versa. And it would be complicated where the user had multiple operator clients running on the device (say, both email and presence).
As per normal, the handset, network and application areas of the industry don't really talk to each other. As with other themes in the industry, there's still the brick wall when you suggest that applications should be "bearer aware".
One option is to have some sort of "notification broker" that bundles up all the "keep alive" messages and sends them together, at times that optimise for battery life on the device and/or impact of the sheer number of these short messages on the network.
The next question is who controls the notification broker. And whether it's in the OS, a higher-level client, or even the radio. I think this may turn out to be a future battleground for the industry.
One thing to ponder on: Apple has been working on a push notification engine, although it's been delayed. And it also doesn't like background applications running on the iPhone.
It wouldn't surprise me to see an operator-sponsored approach as well. Possibly it already exists in some of the more "controlled" OS/app stacks like DoCoMo's. But I suspect that this will be more about protecting the network, rather than the handset battery - one solution optimising simultaneously for both seems unlikely.
This has huge implications for application developers, Internet players, handset vendors and operators.
I suspect the optimum solution would be a full two-sided version run by the carriers, used for internal apps like their own presence, but also with a completely open and standardised API for 3rd-party developers and hosted MVNOs. It might even be a new source of revenue. The other option is one run by the OS vendors - but even then, it would be preferable to have some sort of coordination with both operators and each other.
One to watch in 2009, I think.
Dean Bubley's Disruptive Wireless: Thought-leading wireless industry analysis
While I cannot confirm if Martin Sauter's description is valid for that specific network, I know that way too many networks are configured that way. As a result, user experience is as bad as described, or even worse depending on the keep-alive interval.
ReplyDeleteFirst thing that should be done is to reconfigure T1 and T2 timers (these define how long the device is kept in Cell_DCH and Cell_FACH) for something more reasonable.
Next step is to deploy URA_PCH or Cell_PCH state in the radio network, which allows for even greater savings in UE power consumption. URA_PCH or Cell_PCH do not reduce UE power consumption as such, but is linked to the T1 and T2 timer values. Operators use long times T1 and T2 timers to improve user experience, as transition from Idle to Cell_DCH is slow. As transition from Cell_PCH or URA_PCH is much faster, significantly shorter T1 and T2 times are possible without compromising user experience. To get the power savings, T1 and T2 need to be optimized again when URA_PCH or Cell_PCH is deployed. Considering that the UE power consumption in Cell_PCH and URA_PCH is roughly the same as in Idle (i.e. only a tiny fraction of power consumption in Cell_DCH or Cell_FACH) it should be clear that there is significant opportunity for UE power savings.
I feel that network operators should pay more attention to the impact of network timers and configuration on UE power consumption in order to improve consumer experience also in this respect. Going further, HSPA Rel-7 features UL Gating (or DTX) and Downlink Discontinuous Reception (or DRX) should be deployed as soon as possible. For more information, GSA has a document on these with title "HSPA evolution for the mobile handset always on experience".
Regards,
/sami
I've looked quite a bit the keep-alive challenge from both applications and network point of views and come to the temporary conclusion that it's an issue not worth fighting yet.
ReplyDeleteNot because it wouldn't be a problem - it's a huge problem for "always-on" applications - but because the players that would need to co-operate to solve this are, as you pointed out, not even talking to each other currently, let alone co-operating.
An additional lack of incentive is that the mobile network could be optimized to support the handset data connections much better than they currently are. But with 95% of the data traffic coming from PC dongles, it's perfectly understandable that operators don't bother to do this.
What we need is heightened awareness of this issue, and unfortunately it seems that it only comes through user experience crisis. But even that needs to be played carefully: once mobile applications that require an always-on connection to the Internet actually become widespread and users realize that they kill their battery, there are two options: Either the users merely stop using the services in which case everybody loses, or the users are aware why this happens and complain loudly enough for the relevant parties to hear and act to resolve the problem.
I for one won't be holding my breath.
Dead on. By the way, this is exactly what we sell to mobile operators today for existing J2ME/BREW handsets. www.vocel.com In J2ME, it leverages push-registry to kickstart the client only when it's needed. Much more efficient.
ReplyDelete-Todd Allen
This comment has been removed by the author.
ReplyDeleteDean, is battery life making the term 'mobile' redundant? Just a thought?
ReplyDeletehttp://smsisthenewblack.co.uk/2008/12/31/12-days-of-christmas-is-battery-life-making-the-term-'mobile'-redundant/
Operators have a perfect push mechanism in place with SMS. It's virtually free and is tuned to the 9's. It would require integration into the stack but as an app developer I just need a callback or a special socket/port that "returns" when data is available.
ReplyDeleteIn push setups the contents of the message are not that important. It's an optimization. What you care about is the signal that new data is available to be fetched.
I think Apple's delay with push is related just as much to getting it right technically as it is with eco-system questions.
@Sami, appreciate the network level details. From a dev standpoint there is a huge difference with how carriers deal with an open socket with keep alives. Some drain steadily and slowly while others don't seem to cost a bit (Verizon comes to mind).
The only device managing really well the battery life with a real push mechanism, real time notifications / keep-alives is the BlackBerry.
ReplyDeleteIs that a radio implementation secret (bandwidth optimization)? a device sleep mode secret (holster sleep)?
I do not know, but what is sure is that I have my email pushed in real time, my IM clients always on. Facebook, Gmail, Myspace apps real time notifications, and my battery on the new curve 8900 lasts 5 full days!