In this work, the Android Dev Phone 1 (Dev 1) [25] is taken as the DUT. The goal of this chapter is to go through the two-phase calibration procedures for the correct energy estimation of Battery Use on Dev 1.
5.1 Power Table Reconstruction on Dev 1
Power consumption of eight hardware components is measured in the thesis and classified into the two categories, system-basic and process-related. The measurement procedures for each hardware component are summarized as follows.
System-basic
Wi-Fi basic: The Wi-Fi basic power is easy to be obtained by switching on and off the Wi-Fi module with Android Setting application.
Radio basic: The Airplane mode, which closes every wireless interface including the phone radio, is utilized to switch the radio between on and off state.
Screen backlight: In the Android Linux, the sysfs file system [26], which is able to set values into the kernel variables, is used to configure the screen brightness. Because of the linearity of backlight power, as shown in Fig. 4, the power difference between the maximum and minimum screen brightness is measured and denoted as btmax
P . Power consumption of other brightness levels is calculated with the linear interpolation.
Screen basic: The power consumed by LCD panel is obtained by measuring the power difference between the screen on and off state. In practice, there are two tricks of the screen basic power measurement. First, the screen backlight shall be turned off with the manner mentioned above for distinguishing the screen basic power from the backlight power. Second, in order to avoid the system coming into suspend mode when screen is closed,
24
the partial wakelock [27], which is a power management feature of Android system, should be acquired. The wakelock acquirement also can be done through the sysfs file system.
CPU idle: In the Battery Use, it is defined as the power consumed while screen is closed. With power button on the Dev 1, it is easy to turn off the screen.
Phone call: The power of making a call can be measured by the average power during the call and excluding the other basic power.
Process-related
GPS working: For the purpose of getting the GPS working power, the Android application, GPSTest, is created to activate the GPS hardware resource.
CPU working: CPU_busy which contains the infinite for-loop is used to stress the CPU hardware resource separately.
Table 4 compares the power tables from three sources. The default power table is the raw data from Android source code and the reconstructed table is rebuilt with our manner. The most energy consuming hardware is the radio component during the phone calls. Moreover, the screen backlight under maximum brightness level and the working GPS consume more power than the busy CPU..
Table 4. Power table values comparison.
Category Energy Item Power Weight Coefficient Default (mA)
25
5.2 Wi-Fi Formulas Creation on Dev 1
Form the evaluation results, the estimation errors of test scenarios involving Wi-Fi networking always exceed predefined error ratio threshold (10%). As the result, the original Wi-Fi estimation formula is recognized as the faulty formula. Therefore, the goal is to create the new estimation formula for the Wi-Fi module on Dev 1.
(a) Power consumption while receiving a packet in PS. (b) Power consumption in PS and AM.
Fig. 7. Power consuming behavior of Wi-Fi interface.
From observations on Dev 1, the energy consumed by the Wi-Fi module correlates closely with operation modes and packet transmission time (T ) standing tx for receiving time and sending time. In Fig. 7, the power consumption is captured from the power line of battery while receiving packets. The length of power pulse, in Fig. 7(a), closely depends on the time receiving a packet. Fig. 7(b) depicts dramatic difference in power consumption between power saving mode (PS) and active mode (AM) under the same data rate. The obviously difference is that, in AM, the Wi-Fi module consumes an active energy from active power (P ) inherently. ac
In the experiment, T is taken as the energy predictor for the Wi-Fi module. tx The general regression equation of the module is formulated as
tx
wifi c c T
Eˆ 0 1 .
In order to produce different lengths of packet transmission time, user datagram
0
1 501 1001 1501 2001 2501
Power (A)
Time (0.5 mS) Power Saving
Recv Time Active Mode
Pac
Beacon & PS-Poll ACK
26
protocol (UDP) packets in different sizes are transmitted with several data rates, e.g.
54 Mbps and 11 Mbps. The linear regression analysis is launched for sending and receiving packets in the two operation modes individually. The results are shown in Fig. 8 and summarized in Table 5. In Fig. 8, the high correlation coefficient (r) of each line proves the liner property between transmission time and energy consumption of the Wi-Fi module.
(a) Regression of receiving and sending in PS. (b) Regression of sending packet in AM.
Fig. 8. Linear regression of Wi-Fi module in operation modes.
In AM, because the receiving power approximately equals P , receiving the ac packet consumes no additional energy on the Wi-Fi module excluding active energy.
Therefore the receiving energy of AM is omitted from the regression analysis and estimated simply with Wi-Fi active energy wifiac
Eˆ shown in Table 5. The value of P is retrieved as 165.81 mA by measuring the power difference between the two ac
modes.
In Fig 8(a), because the sending slope is two times steeper than the receiving slope, it implies that sending one byte consumes more energy than receiving two bytes in PS. Moreover, additional energy for listening to the beacons and sending the polling control packet [19] (PS-Poll) makes the constant coefficient of the receiving line bigger than the sending line. Finally, the comparison between the sending line in
27
Fig. 8(a) and (b) suggests that sending packets consumes less energy in AM than in PS.
Table 5. Linear regression results summarization.
Mode Energy Estimation Function (uAh)
PS recv ˆwifips_recv70.22337 recv0.155057
Eˆ _ / ˆ _ : The sending/receiving energy estimation in PS.
send recv T
T / : The sending/receiving time of a packet.
wifiac
Eˆ : The estimated energy consumed by Pac.
Tac: The time duration while Wi-Fi module works in AM
send ac
Eˆwifi _ : The sending energy estimation in AM
With per-process traffic logging, the estimated transmission energy, e.g.
send ps
Eˆwifi _ , easily relates to the corresponding processes transmitting the packets.
Because the policy of switching into AM is related to packet count, the estimated active energy wifiac
Eˆ is shared propositionally according to the sending and receiving packet counts of processes.
5.3 Wi-Fi Power Daemon Implementation on Dev 1
For logging networking traffic, the socket layer of Android Linux kernel is modified slightly. In the layer, a list of recorders, which count traffic volume for each process, is created. In fact that some of the networking traffic does not consume the resource of the Wi-Fi module in the case of inter process communication (IPC). Thus, for excluding the IPC traffic from statistic, the packets with the local address, e.g.
127.0.0.1, are filtered out by a blacklist. The translation between the traffic volume and desired transmission time is achieved through the data rate information retrieved
28
directly from the Wi-Fi driver.
AppApp
Socket TCP/UDP
IP Data Link Wi-Fi Driver Wi-Fi Power
Daemon
proc
Traffic Info
Pkt Count Info
Data Rate Info
Log Info
Network Traffic Kernel Space User Space Log File
Fig. 9. Wi-Fi power daemon implementation.
In the Wi-Fi driver, the policy of switching the operation modes is the count of the packets transmitting through the Wi-Fi module. If the packet count is more than fifteen in a second, the Wi-Fi module automatically switches into AM. If the packet count is less than eight in a second, the module will return to PS from AM. Therefore, in order to predict the operation modes for Wi-Fi module, the packet count information is captured from the data link layer.
In our implementation, as shown in Fig. 9, Wi-Fi power daemon is created in C language to reduce the performance overhead of Java virtual machine; the proc [28]
files are created for shipping the information from kernel space to user space. The Wi-Fi power daemon calculates the energy consumption of the Wi-Fi module for each process and logs the results into a file once per second. In order to integrate the logs of Battery Use and Wi-Fi power daemon, a log parser is created to combine the two logs with the timestamps labeled on each energy record.
29