Energy is a budget on when a device may act, not only on how much it does

A mobile device spends its battery in bursts whose cost outlasts the work. Balasubramanian, Balasubramanian and Venkataramani (2009) measured a typical 3G transfer. Nearly sixty per cent of its energy is tail energy, spent in a high-power state after the bytes have moved. That measurement sets the thesis of this sixth of ten units: energy is a budget on when a device may act, not only on how much it does. The cost attaches to the wake, so the schedule of sensing and transmission is a first-class design variable. The units before it made the sensing work; this one pays for it.

The budget is set by the pattern of use, not the volume of data

Balasubramanian, Balasubramanian and Venkataramani (2009) measured 3G, GSM and WiFi transfers. They found that a few hundred bytes sent intermittently can cost more than a megabyte sent at once. After a transfer the radio lingers in a high-power state for a fixed tail time. On 3G that tail was nearly sixty per cent of the energy of a typical transfer. The tail lasted six seconds on GSM against twelve on 3G. Their protocol, TailEnder, deferred and batched delay-tolerant traffic. It cut modelled energy by 35 per cent for email, 52 per cent for news feeds and 40 per cent for web search.

Huang and colleagues (2012) found the pattern survives the change of radio. Measuring a commercial 4G LTE network, they reported a tail timer of about 11.6 seconds. The average tail energy was 48.2 per cent for LTE against 7.2 per cent for WiFi. One packet cost 12.76 joules on LTE, 7.38 on 3G and 0.04 on WiFi.

Most of the cost is incurred below the interface

Carroll and Heiser (2010) measured the power of each subsystem of an Openmoko Neo Freerunner separately. They validated the breakdown against an HTC Dream and a Nexus One. The battery is shared by components the interface does not command, from the panel and its backlight to the radio and the storage. Pathak and colleagues (2011) made the consequence precise for software. They traced system calls and built a finite-state model of the device. That model showed utilisation-based models miss power behaviour programmed into the device drivers, including states entered without useful work.

Yoon and colleagues (2012) built AppScope, which attributes energy to individual applications by monitoring hardware use at the kernel level. Its overhead was about 35 milliwatts and 2.1 per cent of processor utilisation. Zhang and colleagues (2010) reached the same objective with PowerBooter and PowerTutor. These learn a component model from the phone's own battery sensors and need no external meter.

The workload the budget must cover is a distribution

Falaki and colleagues (2010) logged 255 users and found diversity of an order of magnitude or more on every measure. Users made between 10 and 200 interactions a day, and received between 1 and 1000 megabytes a day. The spread is wide enough to hold the user with a shared phone and a metered connection. Chen and colleagues (2015) measured drain across 1,520 smartphones in the wild. They found the cost of the same workload varying with hardware, operating system and app updates.

Continuous sensing turns an occasional cost into a constant one

Sensing is where the pattern matters most, because the device must act even when nothing is happening. Priyantha, Lymberopoulos and Liu (2011) built LittleRock. It connects the phone's sensors to a separate low-power microcontroller, so the application processor can sleep while the sensor stream is processed. They evaluated it with a pedometer. Continuous tracking is not a heavier version of occasional sensing. It changes which costs dominate.

The environment is a variable the design does not control

Ding and colleagues (2013) analysed traces from 3,785 smartphones over at least one month. They found poor signal strength, on 3G and WiFi, routinely experienced across space and time. Weak signal raises the transmit power needed for the same data. A model that included signal strength predicted energy better than one that ignored it. The same code, run in a different place, draws on a different budget.

Because energy is measurable, it can be a design constraint

Zhang and colleagues (2010) put a power model in the developer's hands. Yoon and colleagues (2012) attributed energy to applications at the kernel level. Both did so without laboratory instruments. Groza and colleagues (2024) built a framework that identifies and corrects energy code smells, bad source patterns that raise power use. They reported a 4 to 30 per cent decrease in battery drain after one or more fixes. Caiazza, Luconi and Vecchio (2024) studied machine-to-machine communication. They found that HTTP/3 frequently needed more energy than HTTP/1.1 and HTTP/2, by roughly 9 to 12 per cent. A browsing-like pattern reversed the ranking. A protocol version, not only a line of code, is an energy decision.

An early measurement study shows why the instrument changes the decision

Kansal and Zhao (2008) profiled two designs for one job, reading a file as it stood and reading it compressed. The compressed path used far more processor time, 44.25 per cent against 4.37, and finished sooner, in 14.9 seconds against 22.4. It also used less energy, 402.85 joules against 502.08. The disk was busy for 0.965 seconds instead of 19.2 (Kansal and Zhao, 2008). A developer reading only the processor would have rejected the faster and cheaper design. The measurement is a desktop demonstration rather than a phone result, but the mistake it prevents is this unit's subject.

The budget also has to be shown, and a fixed percentage misleads

Oliver and Keshav (2011) studied 20,100 BlackBerry users and built the Energy Emulation Toolkit. It evaluates an application's energy demands against real user traces rather than a single figure. By classifying users on charging behaviour, they predicted energy level a day ahead at 72 per cent accuracy, which a fixed percentage indicator cannot do.

The contested question: where does the leverage lie, and does one model transfer?

Two positions are held, and they disagree about where a designer can intervene. The first holds that the leverage is in the pattern, controlled by the application and transport layers. Balasubramanian and colleagues (2009) show scheduling cutting modelled energy by 35 to 52 per cent while moving the same data. Groza and colleagues (2024) show code correction cutting drain by 4 to 30 per cent. Caiazza and colleagues (2024) show a protocol version changing the energy of the same request. On this view the budget is a scheduling problem: fewer wakes for the same work.

The second holds that the dominant costs sit below the application and vary with conditions it does not set. Pathak and colleagues (2011) show driver-level power behaviour that application accounting misses. Ding and colleagues (2013) show signal strength changing the cost of the same transfer. Falaki and colleagues (2010) and Chen and colleagues (2015) show the workload and platform varying so widely that one model does not hold. On this view the application has limited leverage, and a budget measured once transfers poorly.

What would settle it is a study. It would hold the application workload fixed while varying device, network and environment. It would attribute energy to each layer and report per condition. The literature holds each ingredient separately. It has the transport measurement (Balasubramanian et al., 2009) and the below-application attribution (Pathak et al., 2011; Yoon et al., 2012). It also has the environmental effect (Ding et al., 2013) and the cross-device variation (Chen et al., 2015). It does not hold the joint experiment.

Rated by kind, the pattern side rests on measurement studies and on modelled savings (Balasubramanian et al., 2009; Groza et al., 2024; Caiazza et al., 2024), so the figures report what a change saved on a test bed rather than in a deployed product. The below-application side rests on attribution studies and on large traces (Pathak et al., 2011; Ding et al., 2013; Falaki et al., 2010; Chen et al., 2015), which is accumulated observation. While the dispute is open, a designer budgets per wake rather than per byte, and re-measures on the deployment device and network. The strongest objection is that neither side can show its leverage without the joint experiment.

Where this is heading

The direction of travel is from measuring phones to measuring choices. Zhang and colleagues (2010) and Yoon and colleagues (2012) made per-component and per-application energy visible to developers. Groza and colleagues (2024) turn that into a development habit through named energy smells. Caiazza and colleagues (2024) extend it to a protocol version. Priyantha and colleagues (2011) show the phone can be arranged so that continuous sensing need not wake the main processor. Chen and colleagues (2015) show in-the-wild models are needed because the platform keeps moving. What has not changed since Balasubramanian and colleagues (2009) is that the cost follows the wake.

Sources

• Balasubramanian, N., Balasubramanian, A. and Venkataramani, A. (2009). Energy consumption in mobile phones: a measurement study and implications for network applications. ACM IMC. doi:10.1145/1644893.1644927 Measured 3G, GSM and WiFi transfers and found nearly sixty per cent of a typical 3G transfer spent as tail energy after the bytes moved. Deferring and batching delay-tolerant traffic cut modelled energy by 35 to 52 per cent, making the schedule a design variable.
• Caiazza, C., Luconi, V. and Vecchio, A. (2024). Energy consumption of smartphones and IoT devices when using different versions of the HTTP protocol. Pervasive Mob. Comput. doi:10.1016/j.pmcj.2023.101871 Measured the three HTTP versions on a smartphone and found HTTP/3 needed more energy than HTTP/1.1 and HTTP/2 for machine-to-machine traffic, by roughly 9 to 12 per cent. A browsing-like pattern reversed the ranking, so the protocol version is an energy decision.
• Carroll, A. and Heiser, G. (2010). An Analysis of Power Consumption in a Smartphone. USENIX ATC. https://www.usenix.org/legacy/event/atc10/tech/full_papers/Carroll.pdf Measured each subsystem of an Openmoko Neo Freerunner separately, then validated the breakdown against an HTC Dream and a Nexus One. It locates system power in components the application does not command, so code-only accounting understates cost.
• Chen, X., Ding, N., Jindal, A., Hu, Y. C., Gupta, M. and Vannithamby, R. (2015). Smartphone Energy Drain in the Wild. ACM SIGMETRICS PER. doi:10.1145/2796314.2745875 Measured and modelled drain across 1,520 smartphones in the wild with a hybrid utilisation and state-machine model. The cost of the same workload varied with hardware, operating system and app updates, so the budget evolves with the platform.
• Ding, N., Wagner, D. T., Chen, X., Pathak, A., Hu, Y. C. and Rice, A. (2013). Characterising and modelling the impact of wireless signal strength on smartphone battery drain. ACM SIGMETRICS. doi:10.1145/2465529.2466586 Analysed traces from 3,785 smartphones over at least one month and found poor signal routinely experienced on 3G and WiFi, raising transmit power for the same data. Connectivity, not only computation, sets the energy cost of an interaction.
• Falaki, H., Mahajan, R., Kandula, S., Lymberopoulos, D., Govindan, R. and Estrin, D. (2010). Diversity in smartphone usage. ACM MobiSys. doi:10.1145/1814433.1814453 Logged usage from 255 users and found diversity of an order of magnitude or more on every measure, with 10 to 200 interactions a day. The workload a budget must cover is a wide distribution, not an average case.
• Groza, C., Dumitru-Cristian, A., Marcu, M. and Bogdan, R. (2024). A Developer-Oriented Framework for Assessing Power Consumption in Mobile Applications: Android Energy Smells Case Study. Sensors. doi:10.3390/s24196469 Presented a framework that detects and corrects energy code smells, bad source patterns that raise power use, and reported a 4 to 30 per cent drain decrease after fixes. Fixing all three smells cut reported capacity consumption by 36.35 per cent.
• Huang, J., Qian, F., Gerber, A., Mao, Z. M., Sen, S. and Spatscheck, O. (2012). A close examination of performance and power characteristics of 4G LTE networks. ACM MobiSys. doi:10.1145/2307636.2307658 Measured a commercial LTE network and found a tail timer of about 11.6 seconds and an average tail energy of 48.2 per cent against 7.2 per cent for WiFi. One packet cost 12.76 joules on LTE against 0.04 on WiFi, so the pattern persists across radio generations.
• Oliver, E. and Keshav, S. (2011). An empirical approach to smartphone energy level prediction. UbiComp. doi:10.1145/2030112.2030159 Studied 20,100 BlackBerry users and built the Energy Emulation Toolkit, which evaluates an application's energy demands against real user traces. Classifying users on charging behaviour, they predicted energy level a day ahead at 72 per cent accuracy.
• Pathak, A., Hu, Y. C., Zhang, M., Bahl, P. and Wang, Y. M. (2011). Fine-grained power modelling for smartphones using system call tracing. EuroSys. doi:10.1145/1966445.1966460 Built a finite-state power model triggered by system calls and showed utilisation-based models miss power behaviour programmed into device drivers. Much of the cost of an interface action is incurred below the application, where the developer cannot see it.
• Priyantha, B., Lymberopoulos, D. and Liu, J. (2011). LittleRock: Enabling Energy-Efficient Continuous Sensing on Mobile Phones. IEEE Pervasive Computing. doi:10.1109/mprv.2011.28 Connected the phone's sensors to a separate low-power microcontroller so the application processor can sleep while the sensor stream is processed, evaluated with a pedometer. Continuous sensing is a scheduling problem, not only a hardware one.
• Yoon, C., Kim, D., Jung, W., Kang, C. and Cha, H. (2012). AppScope: application energy metering framework for Android smartphones using kernel activity monitoring. USENIX ATC. https://www.usenix.org/conference/atc12/technical-sessions/presentation/yoon Attributed energy to individual applications by monitoring hardware use at the kernel level, with an overhead of about 35 milliwatts and 2.1 per cent of processor utilisation. It exposes energy spent by code the user never sees.
• Zhang, L., Tiwana, B., Qian, Z., Wang, Z., Dick, R. P., Mao, Z. M. and Yang, L. (2010). Accurate online power estimation and automatic battery behaviour based power model generation for smartphones. IEEE/ACM/IFIP CODES+ISSS. doi:10.1145/1878961.1878982 Presented PowerBooter, which learns a component power model from the phone's own battery sensors without external equipment, and PowerTutor for online estimation. Estimates were within 0.8 per cent on average over ten-second intervals.
• Kansal, A. and Zhao, F. (2008). Fine-grained energy profiling for power-aware application design. ACM SIGMETRICS Performance Evaluation Review. doi:10.1145/1453175.1453180 Profiled two designs for one job, reading a file as it stood and reading it compressed. The compressed path used far more processor time and less total energy, 402.85 joules against 502.08.