Lots of people in mobile testing talks about monitoring mobile energy consumption and related defects. I am also a person who keen on reducing mobile energy consumption. However during my past experience, whenever we raise a defect on energy consumption people don’t take them serious. They always say this is a job of a mobile device and OS should manage energy not our app/AUT.
Recently I found a white paper from Young-Woo Kwon and Eli Tilevich who discussing a concept call Cloud Offloading witch actually focusing on reducing mobile application energy consumption and allow mobile application user to be mobile more time by reducing recharging frequency I will point following key highlights of this paper in order to increase your interest and you may download the paper from www.google.co.in/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CB0QFjAAahUKEwjzvKjG_ejGAhVQ1I4KHT1HCpY&url=http%3A%2F%2Fpeople.cs.vt.edu%2Ftilevich%2Fpapers%2Ficsm2013.pdf&ei=pYesVbPWEtCouwS9jqmwCQ&usg=AFQjCNG-0olac3mfTIju7kq1YFwSE963nA&sig2=LOzJAuqhaZ9DcJSq3hD91g&bvm=bv.98197061,d.c2E
Recently I found a white paper from Young-Woo Kwon and Eli Tilevich who discussing a concept call Cloud Offloading witch actually focusing on reducing mobile application energy consumption and allow mobile application user to be mobile more time by reducing recharging frequency I will point following key highlights of this paper in order to increase your interest and you may download the paper from www.google.co.in/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CB0QFjAAahUKEwjzvKjG_ejGAhVQ1I4KHT1HCpY&url=http%3A%2F%2Fpeople.cs.vt.edu%2Ftilevich%2Fpapers%2Ficsm2013.pdf&ei=pYesVbPWEtCouwS9jqmwCQ&usg=AFQjCNG-0olac3mfTIju7kq1YFwSE963nA&sig2=LOzJAuqhaZ9DcJSq3hD91g&bvm=bv.98197061,d.c2E
What is cloud offloading
“Cloud offloading, this optimization partitions mobile applications, so that their energy intensive functionality is executed in the cloud, without draining the battery”
Problem Definition
After discovering that the network conditions in place can significantly affect how much energy is spent to transfer the same data, we have created guidelines for mobile application designers to transmit data in a fashion that consumes the least amount of energy for a given mobile network. Because transferring the same data over WiFi, 3G, or 4G networks consumes different amounts of energy, an optimal offloading mechanism should be adaptive, transferring varying amounts of state depending on the network conditions in place.
Figure 1 shows an Cloud Offloading Energy Consumption Graph (CO-ECG), a novel program analysis data structure that we introduced to model how much energy will be consumed under different offloading scenarios.
Figure 1 shows an Cloud Offloading Energy Consumption Graph (CO-ECG), a novel program analysis data structure that we introduced to model how much energy will be consumed under different offloading scenarios.
In this particular CO-ECG, component A consumes approximately 100 joules during a typical execution, thus becoming a viable candidate to be offloaded to the cloud. Because component A calls components C and B, which in turn calls components D and E, its energy consumption is the sum of the energy consumed by all the successor components in the graph. We assume that the energy spent on executing the offloaded functionality in the cloud is free, as it does not exhaust any battery power of the mobile device. If component A is offloaded, then transmitting the necessary data to it across the network enabling it to execute remotely would consume between 30 and 150 joules depending on the type of the
network available to transmit the data. In other words, under some network conditions, offloaded execution will end up using more energy than executing component A on the mobile device. Because the type of network available is only known at runtime, the offloading decisions must be dynamic to be able to optimize the amount of consumed energy under all runtime conditions.
network available to transmit the data. In other words, under some network conditions, offloaded execution will end up using more energy than executing component A on the mobile device. Because the type of network available is only known at runtime, the offloading decisions must be dynamic to be able to optimize the amount of consumed energy under all runtime conditions.
Approach Overview
Figure 2 shows the workflow of AMCO. The approach consists of two major parts—a program analysis-guided partitioning transformation and an adaptive runtime system. The AMCO programming model is straightforward: the programmer marks the components suspected of being energy hotspots. In AMCO, components can be defined at any level of program granularity, with the smallest being individual methods and the largest a collection of packages. To mark hotspot components, AMCO provides a special Java annotation @ OffloadingCandidate; this information can also be specified through an XML configuration file. Based on this input, an analysis engine first checks whether the specified component can be offloaded as well as any of its subcomponents (i.e., successors in the call graph).
