Facilitating energy efficiency on mobile devices

I’ve recently read the Bartendr paper (386f5adade0bd7d0970b5ff555d643c6). It explores an algorithm for increased energy efficiency on mobile devices, based on prediction of good conditions for transmitting data to the cellular network.

The Bartendr  approach to communication scheduling is based on the fact that mobile devices consume more power when the signal is weak to compensate for the low SNR of the transmission channel. Applications should preferably communicate when the signal is strong which is indicative of a good transmission channel.
By anticipating good or bad channel conditions it is possible to determine the periods of time that are favorable for energy-saving communication. Since the signal strength is highly correlated with the user’s location relative to the cellular antennas, moving along a certain route the user experiences changes in signal strength. By learning the signal strength profile as a function of location along a certain route, it is possible to anticipate the time windows that are favorable for energy-saving communication.

While the algorithm was evaluated in simulation as well as on an actual device by incorporating the scheduling decisions into the test application, currently there is no practical framework for an actual implementation of Bartendr, or a similar scheme since it requires changes in the related software architecture. This post discusses several architectural changes that are needed in order to accommodate such schemes.

While it is possible for mobile applications to use timer mechanisms to run callbacks asynchronously at specific times, it requires the application to be aware of the right times to schedule the execution.
We can imagine how it would simplify things for the developer to simply push a synchronization request into a queue from which tasks are popped according to a power efficient schedule, maintained by the operating system. This could be a nice feature for a mobile operating system.
It would also be great to have something like a Strategy design pattern implemented for scheduling – allowing plugging-in a different schedule algorithm according to the user’s choice.