Notifications and "keep-alives" from mobile apps - the battery issue

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.