Institutionen för datavetenskap
Department of Computer and Information Science
Examensarbete
Estimating Application Energy Consumption
Through Packet Trace Analysis
av
Joakim Eriksson and Samuel Nilsson
LIU-IDA/LITH-EX-G--14/078—SE
2014-09-02
Linköpings universitet
SE-581 83 Linköping, Sweden
Linköpings universitet
581 83 Linköping
Linköpings universitet Institutionen för datavetenskap
Examensarbete
Estimating Application Energy Consumption
Through Packet Trace Analysis
av
Joakim Eriksson and Samuel Nilsson
LIU-IDA/LITH-EX-G--14/078—SE
2014-09-02
Handledare: Simin Nadjm-Tehrani
Examinator: Nahid Shahmeri
Link¨
oping University
Sweden
Estimating Application Energy
Consumption Through Packet Trace
Analysis
Joakim Eriksson
Samuel Nilsson
Students in the 5 year Information Technology program complete a semester-long software development project during their sixth semester (third year). The project is completed in mid-sized groups, and the students implement a mobile application intended to be used in a multi-actor setting, currently a search and rescue scenario. In parallel they study several topics relevant to the technical and ethical considerations in the project. The project culminates by demonstrating a working product and a written report documenting the results of the practical development process including requirements elicitation. During the final stage of the semester, students create small groups and specialise in one topic, resulting in a bachelor thesis. The current report represents the results obtained during this specialization work. Hence, the thesis should be viewed as part of a larger body of work required to pass the semester, including the conditions and requirements for a bachelor thesis.
The advancement of mobile clients and applications makes it possible for people to always stay connected, sending and receiving data constantly. The nature of the 3G technology widely used, however, causes a high battery drain in cellular phones and because of that a lot of tools for measuring mobile phones energy consumption has been developed. In this report we look into the trace-driven tool EnergyBox and find out how we can use it to estimate the energy consumption of 3G transmissions for an application we’ve developed ourselves. We begin with identifying the types of traffic our application generates and identify which parts of it make up our applications background traffic. Different combinations of the identified traffic types are looked into in order to decide which ones that need to be present in the packet traces for an estimation of our applications energy footprint for 3G transmission. Further, answers are sought to how long the time span should be for which the packet traces are collected and how many of them are needed in order to draw a conclusion about our application’s energy footprint. We conclude that all traffic types responsible for our application’s background traffic need to be present in the analyzed packet traces, and data suggests that collecting more than 10 one minute packet traces does not improve accuracy significantly (less than 1%). Without user interaction, our application generates traffic, which transmitted over 3G, drains as much as an average of 930mW, meaning that a Samsung Galaxy S4 battery with a capacity of 9.88Wh would last for a maximum of 10 hours and 30 minutes (excluding other energy consuming sources inside the handset).
Contents
1 Introduction 1
1.1 Motivation . . . 1
1.2 Purpose and vision . . . 1
1.3 Problem to solve . . . 1
1.4 Limitations . . . 2
1.5 Approach . . . 2
2 Background 3 2.1 The tested application . . . 3
2.2 Application traffic . . . 3 3 Theory 5 3.1 3G States . . . 5 3.2 EnergyBox . . . 5 3.3 Background traffic . . . 6 3.4 Related work . . . 6 4 Methodology 7 4.1 Hardware Setup . . . 7 4.2 Selecting Traces . . . 7 4.3 Isolation . . . 8 4.3.1 Emulator isolation . . . 8
4.3.2 Traffic type isolation . . . 8
4.4 Number and length of traces . . . 8
4.4.1 Comparing traces of different length . . . 9
4.4.2 Trace length . . . 9 4.4.3 Number of traces . . . 9 4.5 Generating traffic . . . 9 4.6 EnergyBox validation . . . 10 5 Results 11 5.1 EnergyBox validation . . . 11 5.2 Length of traces . . . 12 5.3 Number of traces . . . 12 6 Discussion 15 6.1 Methodology . . . 15 6.2 Results . . . 15 6.2.1 Traffic combinations . . . 16
6.2.2 Number and length of traces . . . 16
6.2.3 Impact of the 3G energy consumption . . . 16
1
Introduction
Today, the 3rd Generation (3G) protocols are better fitted for transmitting signals over wider distances, although they carry the disadvantage of having a generally high battery discharge at the mobile device end when compared to WiFi [3]. This introduces a problem: If users today are more prone to use their applications connecting through energy-inefficient mediums, it greatly increases the amount of energy drained from batteries in cellular phones and tablets. This thesis will focus on estimating the energy consumption of 3G transmissions for applications in a mobile handset. When using 3G, we will from here on refer to the 3G Universal Mobile Telecommunications System (UMTS).
1.1
Motivation
The increase of 3G usage forces the application developers, in this report us as developers of an application used in a search and rescue scenario, to take into consideration the energy-efficiency of our connection handling at the application layer of the OSI-model. In our earlier work on developing an application used for a search and rescue scenario, we have developed an application quite oblivious to how connection handling impacts the application’s energy consumption. How do application developers know then if the application is energy-efficient? In this report we look into if measurement and simulation tools can be used to answer this question.
Today there are several hardware kits that can be used to measure the exact amount of energy discharged when an application transmits over 3G. The process of acquiring these exact metrics, however, requires a lot of time as well as human resources. This has driven people to develop software solutions for estimating the energy consumption. One such tool is EnergyBox proposed by Vergara et al. [1]. Given a packet trace, EnergyBox can estimate the energy consumed for a transmission both through 3G and WiFi, and is claimed to be as accurate as 94 − 99% of the physically measured values for 3G. What is unknown here, however, is what kind of traffic these packet traces should include, as well as how many we need in order to draw conclusions regarding our application’s energy-efficiency.
1.2
Purpose and vision
The purpose of this project is to find out how to generate application traces representative for our application, and how EnergyBox can be used to estimate the energy footprint of our application when transmitting over 3G. This will hopefully give us insight into how energy-efficient our application is.
1.3
Problem to solve
The main problem to solve is how to generate representative application traces and how to make a fair estimation of the energy footprint for our application when transmitting over 3G, based on these traces. To find a solution to this problem the following questions must be answered:
• How is EnergyBox used to estimate our application’s energy consumption? – How is the traffic we wish to measure isolated from the rest of the system? – Which traces should be measured?
2 – How many traces are needed in order to draw a conclusion about the
energy-efficiency of our application? – How are these traces generated?
• Does EnergyBox give as good results as its authors claim?
1.4
Limitations
We will restrict ourselves to only trace 3G traffic. WiFi transmissions are not as energy consuming (due to the sleep/wake-up mechanics) as 3G and thus do not have as big an impact on application energy consumption.
1.5
Approach
The first thing we will do is to decide which traffic we are going to investigate, that is which traces we are going to collect. Thereafter we will ensure that EnergyBox is as accurate as the authors claim for the traffic we have decided to investigate. Subsequently we will collect traces and analyze how many and how long traces are needed to draw a fair conclusion about the applications energy consumption, and also conclude how energy-efficient our application is. This approach will hopefully give us answers on our qwuestions in section 1.3.
2
Background
This section will describe our application which all the traces will be generated from. It will also define what flow of traffic our application generates.
2.1
The tested application
In our earlier work we have developed an application for Android to be used in a search and rescue scenario. It consists of a client, a web server and a media server. At the moment the application makes it possible to upload and download shared information created by the users. Up- and downloading this information is done by the client on request by the user. The application also supports Voice over IP (VoIP). In addition to these functional properties the client also regularly uploads information about its battery level and GPS status to the web server. The latter is generating traffic even though the user doesn’t interact with the application. The thought behind sending the GPS status to the web server is simple, we want to make it easy for the commanders in charge of an operation to monitor the progress of the users who are out working in the field. Using the same logic, each client also sends updates to the web server about its battery level so that commanders can account for communication limitations due to low battery devices (in a search and rescue scenario, the ability to recharge the client battery might not be present). In future versions of the application, we also figured that the web server could use this battery information to adapt the traffic destined for low-battery clients in order to save energy on the client side (for example, by block incoming calls that are not marked as ”absolutely crucial” for clients where the battery is almost depleted).
2.2
Application traffic
In the current version of our application no traffic is generated unless the client requests it. The VoIP function uses the Session Initialization Protocol (SIP) in order to initiate, change and end the interactive audio sessions. The SIP protocol sends what is called SIP Options packets every 10 seconds to the media server to request information about the capabilities of a caller. During an active session the Real-Time Transport Protocol (RTP) is used to transmit the audio. Both SIP and RTP use the User Datagram Protocol (UDP) as transport layer protocol.
The battery level and GPS status updates are performed every 15 seconds and use the Hypertext Transfer Protocol (HTTP) as the application layer protocol and the Transmission Control Protocol (TCP) as transmission layer protocol. Both the battery level updates and the GPS status updates are sent together. Sending and requesting the user created information from the remote server uses the same protocols. Beyond the mentioned protocols both previously mentioned features use the Domain Name System (DNS) protocol in order to find the correct IP addresses.
The list below shows our application’s different traffic, the port number that is used and a short description of each of them:
• DNS queries - DNS protocol - Port No. 53 - Initiated by the system to find IP-adresses when needed by the application. This traffic is needed by the application for all other communication to work.
• SIP Options packets - SIP protocol - Port No. 5060 - Sent by the client auto-matically every 10 seconds, the server responds with an options message.
4 • Battery level and GPS status updates - HTTP protocol - Port No. 1337 - Sent by the client automatically every 15 seconds, server responds with a keep connection-alive message.
• Shared information - HTTP protocol - Port No. 1337 - User initiated request to a web server resulting in a bulk of data received by the client.
• An active VoIP session - RTP protocol - Port No. 5060 - Initiated by the client on request by the user resulting in a constant flow of RTP packets.
The first three bullets form what we call our application’s background traffic, i.e. traffic that is generated without user interaction once the application is started. The last two bullets form the user-generated traffic, i.e. traffic that is never generated without explicit user interaction. The background traffic is delay-tolerant meaning it can be postponed several seconds without a significant impact on the user experience. The timers for how often the SIP Options packets or Battery level and GPS status updates are sent and requested can all be changed in our application. DNS-queries only need to be made as often as when the IP-adress is not stored but needed.
3
Theory
This section will provide important information and terminology used in the rest of the report.
3.1
3G States
A handset using 3G transmits in four different transmission states when connected to a Radio Resource Controller (RRC) at the base station end: The shared state (FACH), the dedicated state (DCH), the standby state (PCH) and Idle. In the dedicated state the client has allocated uplink and downlink channels which provides high data rates. In the shared state the client uses a shared upload link and monitors the download link. In this state the client can transmit smaller data packets at lower transmission rates. When in the idle state the client does not have any network activity but listens for incoming packets. In the standby state there are no resources allocated for transmission but the client checks whether there are downlink packets available or not in predetermined time intervals, which makes the state energy-efficient compared to other states. Transitions from lower to higher states are triggered when the Radio Link Control (RLC) data buffers (which contain data waiting to be transmitted) exceed a certain threshold. There are two thresholds for both uplink and downlink, depicting when to change to what state shown in Table 1.
State transition Uplink threshold Downlink threshold PCH→FACH 0 bytes 0 bytes
PCH→DCH X bytes Y bytes FACH→DCH Z bytes W bytes
Table 1: The idea behind 3G RLC buffer thresholds. There are no set values for X, Y, Z and W since they can differ between network operators, which in turn determines the settings for each handset connected to them.
The dedicated and shared states have inactivity timers set at the operator (base station) end, meaning if no data is sent or received for the period of time in which these are set to, the state in the handset is reset to PCH [4]. Overall the average energy consumed in each state does not depend on whether data is sent or not[1], merely staying in each state is what consumes the significant portion of energy. This means that if you send just enough data to enter the DCH-state (X bytes), a big proportion of the period in this state will be spent, not transmitting, but waiting for the inactivity timer to expire causing an energy consuming overhead denoted as an energy tail by Balasubramian et. al [3].
3.2
EnergyBox
EnergyBox [1] estimates the energy consumption of data transmissions over 3G and WiFi. EnergyBox takes as input a packet trace. By simulating the 3G state transitions and calcu-lating the average power levels for each state (given certain handset and operator settings), the total energy consumption from a given packet trace can be calculated for transmission over 3G. Since the average power for each state differs for each 3G module (embedded in a handset), EnergyBox needs to be configured with the correct power parameters before use. Luckily, Vergara et al. [1] use the Ericsson F337 broadband module, which is the module that is part of the Ericsson’s Developer’s Kit used in this work and thus we will be able to use the numbers they have gathered. The output of the tool is a graph showing the RRC
6 states over time as well as the total amount of Joules consumed. EnergyBox[1] is claimed by its authors to be as accurate as 94-99% for a range of different traces compared to physical power measurements when estimating 3G transmission energy.
3.3
Background traffic
Earlier work by Vergara et al. [2] describes a Quality of Service (QoS) traffic class back-ground traffic that affects the 3G energy footprint. They mention that typically, backback-ground traffic requires small bandwidth, is asymmetric and tolerates some delay which matches the description of what we labeled as our application’s background traffic. Even though small amounts of data is transmitted it can cause high radio energy consumption [5].
3.4
Related work
E.J. Vergara et al. [1] uses and evaluates EnergyBox on several different applications with different QoS requirements. The evaluations are done by collecting a packet trace while simul-taneously making physical measurements, followed by comparing the results obtained from feeding the resulting packet trace to EnergyBox with the ones from the physical measure-ments. A percentage is calculated by dividing the two, and is the number used to compare accuracy for different traces derived from using different applications. A similar setup for physical measurements of the 3G energy consumption is also used in several other works as in Vergara and Nadjm-Tehrani [6] as well as Asplund et al. [7].
The authors of EnergyBox [1] also show how it can be used in a case study in order to decide under which circumstances it is more energy-efficient to use either the HTTP protocol or MQTT protocol for a location sharing service. In other work by Vergara et al. [2] EnergyBox is employed to help estimate the efficiency of implementing traffic shaping algorithms in order to reduce 3G energy consumption and also utilized in another of their studies [8] as part of a bigger energy study.
4
Methodology
This section will go into detail regarding what we do in order to answer the questions from the problem formulation in section 1.3.
4.1
Hardware Setup
Our setup is shown in figure 1 and consists of Computer 1(CP1) running Linux Ubuntu 12.04. CP1 is connected to a Ericsson Developer Starter Kit(EDK, model KRY 901214/01) for 3G connectivity via the USB-port. Computer 2 (CP2) is connected via USB to another part of the EDK in order to measure the exact power values over the transceiver. CP1 can be any arbitrary computer able to run emulators efficiently and handle network connectivity via USB. CP2 can be any arbitrary computer with an USB port able to run NI LabVIEW1.
Figure 1: Brief overview of the measurement setup.
4.2
Selecting Traces
We mentioned that our application generates five different types of traffic in section 2.2, where three of them make up our application’s background traffic. Section 3.3 mentions how, even though it takes up small amounts of bandwidth, background traffic has a large impact on the 3G energy footprint. We will therefore investigate the footprint of different isolated combinations of the background traffic. In this report we will from now on refer to three traffic types investigated, as listed below:
1. DNS + SIP Options packet requests/repsonse 2. DNS + Battery level and GPS status updates 3. DNS + SIP Options + Battery/GPS status updates
Since DNS queries are needed in order to generate all other traffic in our application, it needs to be included in all combinations in the list. Due to the nature of our application, DNS queries are sent very seldom in comparison to how often the other two types of background
8 traffic are generated and thus, we will not investigate the 3G energy footprint of only DNS isolated.
4.3
Isolation
The application traffic is isolated in two steps. First, the emulator is isolated from the computer’s operating system, and second, the traffic types we wish to investigate (mentioned in section 4.2) are isolated separately. This section will go into detail on how both these steps are done.
4.3.1 Emulator isolation
Since the application is run inside an emulator, the first step is to isolate the emulator traffic from the rest of the system. This is done by configuring the firewall IPTables so that it only allows traffic generated from processes started by a member of a specific group of users (we hereon refer to this group as the Traffic Generating Group, TG-Group)[9]. Hereafter the emulator is started in a shell through the TG-Group, which only task is to run the emulator. Since the process is started in the separate TG-Group, we assure that no other non-kernel level processes generate traffic. Ubuntu Linux will however still automatically generate some network traffic that bypasses the earlier mentioned configurations. In order to remove that traffic the following settings in Ubuntu are changed to stop the respective traffic, according to the official Ubuntu Documentation [10]:
• Time Synchronisation (NTP-protocol traffic flow): Time and Date set to manual con-figuration through System Settings to remove this traffic.
• Ubuntu Crash reports (continual DNS-queries and HTTP-traffic flow): Canonical error reports turned off through System Settings to remove this traffic.
These basic configurations will be active during all the tests. 4.3.2 Traffic type isolation
The second step is isolating our applications different traffic types. Section 4.2 mentions which traffic we wish to isolate and why. To isolate each traffic type we configure IPTables to only allow outgoing traffic through the port number used by each type. When we isolate two traffic types we allow the port numbers used by each of them. In addition to these port numbers we also allow DNS for all firewall configurations, since all the traffic types require it as described in section 4.2.
The emulator used communicates with the rest of the computer through a certain set of port numbers, so when configuring IPTables to disallow all traffic except a chosen few, it is vital to make sure that these specific ports associated with the emulator remain open for traffic flow. If the specific ports are blocked, the emulator will not start at all. The emulator’s communication with the rest of the system is never transmitted over the network, and thus does not show up in the packet traces (it is just vital for the emulator to be able to run on the system).
4.4
Number and length of traces
This section will describe how answers are sought to the questions regarding the number and length of traces needed in order to draw a fair conclusion about our applications energy
footprint. A subproblem emerges when having to compare traces of different length and thus, this section also describes our approach to this.
4.4.1 Comparing traces of different length
In order to be able to compare traces of varying lengths we will calculate the average power for each packet trace. The power is calculated by dividing EnergyBox’s output E (Joules) by the time ∆t (seconds) for which it simulates the 3G state transitions:
P = E
∆t (1)
This value P will now represent the average power needed for transmission of each packet trace generated, and is the metric used when comparing the traffic types’ energy footprints. 4.4.2 Trace length
For each traffic type mentioned in section 4.2 we will gather packet traces collected under varying time intervals ∆t. We choose to collect what we consider to be short and long traces in order to compare the two. We choose 1 minute to be an appropriate length for short traces and 10 minutes for long traces.
We collect five 1 minute traces and five 10 minute traces of each traffic type and calculate the standard deviation σ for the mentioned kind of length and traffic type. Using five traces, equation number 2 gives us the formula for the standard deviation σ, where µ is the mean power of all the traces and Pi is the estimated power value for each trace i. The standard
deviation will later on be used to compare how much the values of the average power can fluctuate depending on the trace length.
σ = v u u u t 5 P i=0 (Pi− µ)2 5 (2) 4.4.3 Number of traces
We wish to see how many packet traces collected during the same time interval ∆t that are needed in order for the average power to start approaching a specific value. We will do this by plotting the set Pavg described in equation 3 where Pi is the average power estimated
for each trace i. This way we will be able to see how much closer the results get to the last average value PN depending on how many traces are collected.
Pavg∈ { P1 1 , P1+ P2 2 , P1+ P2+ P3 3 , ..., P1+ ... + PN N } (3)
Our N will be 20 and the length of each trace will for convenience be set to one minute.
4.5
Generating traffic
For each trace to be collected, we will make configurations as described in earlier methodology sections (depending on traffic type) and then start the application through an emulator. As mentioned in section 4.2 all trace types tested are of background traffic type which means we need no input interaction, so we will let our application sit idle and start packet capture through Wireshark.
10
4.6
EnergyBox validation
In order to verify that EnergyBox is as good a tool as it is claimed to be, a simple test will be done to ensure the measurement validity in our work.
This is where CP2 is used (mentioned in section 4.1). Just as earlier, our application is run in the emulator on CP1. While it is running the packet trace is collected via Wireshark. The new part here is that parallel to what was done earlier, CP2 is now recording the exact power consumed by the 3G transceiver each millisecond. In doing this, the exact power measurements for a given packet trace is known, and thus EnergyBox’s output for that given trace can be compared to the exact values. For a given function P = F (t), the Energy E between t1 and t2 is computed through:
E =
t2
Z
t1
F(t) dt (4)
Assuming a trace length of T seconds and a sampling frequency of f , the measured values will consist of f · T values each denoted by Fi. Since the power in our case is measured
each millisecond, f = 1kHz. Through retrieving the measured values, we have a discrete approximation to equation 4, thus the approximate energy Ea can be calculated as:
Ea= f ·T X i=0 Fi f (5)
The capture of both the packet trace and the measured values is started manually, leading to a slight difference in start- and end points in time. In order to synchronise the start- and end points, the beginning of both outputs will be cut off at the first transition from the PCH-state to any of either the FACH- or DCH-state. The end part of the measured values is cut off to match the timestamp where EnergyBox stops its integration, leading to both data captures matching the same time interval ∆t. The Energy derived from computing the sum Ea in equation 5 during ∆t will hereby be referred to as the measured energy value
Emeasured.
When sampling the measured values, Vergara et al. [1] use a physical low pass filter with a cutoff frequency of 16Hz during the sampling of the measured values. We do not use a physical filter, instead a mathematical moving average filter is applied in Matlab with a cutoff frequency of 16Hz. We will collect 5 traces, each collected during 5 minutes each.
Vergara et al. [1] mention both Energy Accuracy and Time Accuracy as evaluation techniques for EnergyBox. Time accuracy refers to how accurately EnergyBox models the appropriate 3G state compared to the expected states derived from measured power val-ues and energy accuracy refers to how accurately EnergyBox’s output matches the energy Emeasuredthat can be derived from the measured values. If EnergyBox was to model the 3G
state transitions improperly it would directly affect its output in Joules. Thus, for our evalu-ation, we will only calculate the energy accuracy since a value within 94 − 99% would imply that EnergyBox models the 3G state transitions accurately. The accuracy for EnergyBox’s output E (Joules) will be computed as:
Accuracy = min(EEnergyBox, Emeasured) max(EEnergyBox, Emeasured)
5
Results
Before performing our application-related experiments and presenting the results, EnergyBox was validated (even though mentioned last in Methodology section 4.6). All tables in this section mention traffic types. We would like to remind the reader that these traffic types are described in section 4.2.
5.1
EnergyBox validation
In this section the results from the EnergyBox validation will be presented. Figure 2 shows a chunk of a plot of the states simulated by EnergyBox and associated with their specific power values as well as the measured values with a mathematical moving average filter applied. The data is aligned as described in section 4.6, showing graphically how EnergyBox’s simulation typically differs from the measured values. The results from calculating the energy and accuracy are presented in table 2.
Traffic Type EnergyBox [J] Measured Values [J] Accuracy
1 244.6 241.9 98.9 %
1 257.1 253.1 98.4 %
1 246.1 247.0 99.6 %
2 186.4 187.3 99.5 %
3 280.7 267.5 95.3 %
Table 2: Results from validating EnergyBox.
0
5
10
15
20
25
0
0.5
1
1.5
2
Time (s)
Power (W)
Figure 2: The power estimated (red, from EnergyBox) and the power measured (blue, from the Ericsson Developer’s Kit) over time respectively. This picture is a 25 second snippet of a time span of five minutes.
12
5.2
Length of traces
Table 3 shows the results from measuring the three traffic types based on 1 and 10 minute packet traces respectively.
Type Length [min] P1[mW] P2[mW] P3[mW] P4[mW] P5[mW] Pavg[mW]
1 1 848 813 820 866 830 835 1 10 859 858 867 870 844 860 2 1 654 652 681 608 650 649 2 10 647 640 645 645 636 643 3 1 939 897 921 959 939 930 3 10 944 919 918 928 930 928
Table 3: Power values Pi collected for each traffic type and trace length calculated from
EnergyBox’s output Ei for each trace i, as well as the average power over all five traces.
The standard deviation for the different trace lengths is shown in table 4. Traffic type Length [min] Standard deviation [mW]
1 1 19.30 1 10 9.05 2 1 23.41 2 10 4.03 3 1 20.75 3 10 9.39
Table 4: The standard deviation for short and long traces for each traffic type chosen to be investigated. The value is calculated from five traces per length.
5.3
Number of traces
This section will present three plots (one for each trace type), showing the average power value depending on the number of traces for each traffic type as described in section 4.4.3. In figure 3, 4 and 5 the y-axis represents the average power for a set of packet traces (Pavgfrom
equation 3) and the x-axis represents the number of traces used for calculation of the average power (N from equation 3). Please notice that the y-axis (power) range differs between the plots.
0 2 4 6 8 10 12 14 16 18 20 820 825 830 835 840 845 850 855 860 865 Number of traces Average power [mW]
Figure 3: The average power depending on the number of traces collected for traffic type 1 (DNS + SIP Options packets). The blue circles show the average power (Pavg) calculated for
a specific number of traces (N ). The red line is a reference line showing the average power of the 20 traces collected.
0 2 4 6 8 10 12 14 16 18 20 22 656 658 660 662 664 666 668 670 672 Number of traces Average power [mW]
Figure 4: The average power depending on the number of traces collected for traffic type 2 (DNS + Battery level- and GPS status updates). The blue circles show the average power (Pavg) calculated for a specific number of traces (N ). The red line is a reference line showing
14 0 2 4 6 8 10 12 14 16 18 20 900 920 940 960 980 1000 1020 Number of traces Average power [mW]
Figure 5: The average power depending on the number of traces collected for traffic type 3 (DNS + SIP Options requests + Battery level- and GPS status updates). The blue circles show the average power (Pavg) calculated for a specific number of traces (N ). The red line
is a reference line showing the average power of the 20 traces collected.
One can observe that for all three trace types investigated, a sample collected during 10 minutes proved more precise than a sample collected during 1 minute. As for the appropriate number of traces to collect, calculating the average over 10 samples only differs by 4.8-6.7mW (depending on trace type) from doing the same over 20 samples.
6
Discussion
This section serves two purposes. First it’s used to discuss how our methodology might have an impact on the results as well as provide alternate approaches. Second, we try to make sense of the results and how to interpret them.
6.1
Methodology
The hardware setup and traffic isolation could have had an impact on the results. Section 4.3 mentions how we we remove certain traffic generated by the Linux core by changing system settings in Linux. Anyone using the methodology described in sections 4.1 and 4.3 runs the risk of having traffic not generated by their application in the collected packet traces if a system configuration setting is missed. We need to use such a setup however due to the use of the Ericsson Developer’s Kit. Vergara et al. [1] use a similar hardware setup as described in section 4.1 and isolation strategy (no details to how firewalls are configured are disclosed) as we do for evaluation of EnergyBox. However, when gathering packet traces for their case study they use an alternative method configuring the firewall directly on a smartphone using an IPTables based firewall whilst generating packet traces using TCPdump, which completely removes the risk of having extra generated traffic from the computer that the emulator is running on. Although we could have used TCPdump for packet capture when we did not aim to validate EnergyBox, we chose to have the same hardware setup during all of our tests. In the same work [1], a validation technique for EnergyBox similar to the one we describe in section 4.6 is used, however, while measuring the voltage drop over the transceiver the signal passes through a physical low-pass filter while we only apply a mathematical moving average filter afterwards. Also, our methodology only tests the accuracy for five packet traces which could give us a higher or lower value than it would have done with several more tests. Calculating the variance from the accuracies measured for EnergyBox, they show a variance of 2.34 percentage points from the mean value of 98.26%. This still puts us well within the promised span of 94 − 99%, although anyone using EnergyBox should validate EnergyBox’s output for their specific traffic type/traffic pattern at least once to see that their numbers are approximately close to reality.
The number of traces from which we calculate the standard deviation and the average values were not decided from any statistical theories, but only from what we though would be appropriate. This is also true for how we decided the length defining short and long traces. Now with more statistical knowledge, we’ll make sure to reconsider a larger amount of data for future works for a better and more thorough analysis with higher precision.
Even though the traces were collected from the same geographical place, the network conditions may vary. This may cause variations in the results due to packet retransmissions and higher data buffer occupancy which may affect the RRC states.
6.2
Results
This section discusses the results in order to answer the questions from section 1.3. First we discuss if it is needed to estimate the power consumption of combinations of traffic. Thereafter, we dive into discussions regarding the appropriate length and number of traces to be collected, as well as the impact of our application’s 3G energy consumption.
16 6.2.1 Traffic combinations
Table 3 shows that, regardless of the length of a trace collected, summing together the power values of traffic type 1 and traffic type 2 does not give a similar value to the power for both types of traffic allowed simultaneously (traffic type 3). This is due to the fact that the data transmissions from both these traffic types are probably sometimes sent at the same time during which the radio is already in a high power state and no extra energy needs to be consumed. To clarify this, table 5 shows the mean power summed together for traffic types 1 and 2 (obtained individually from table 3) against the mean power of traffic type 3.
Traffic type 1 + 2 3 1 + 2 3 Pavg added 1484 mW 930 mW 1503 mW 928 mW
Trace Length 1 min 1min 10 min 10 min
Table 5: The mean power of traffic types 1 and 2 added up (from table 3) in comparison to traffic type 3, the combination of 1 and 2 allowed simultaneously.
6.2.2 Number and length of traces
Table 4 showed the standard deviation for each traffic type and trace length. These numbers tell us the following: for a packet trace with the length of one minute, it is normal for its derived power value to land within 19.30 − 23.41mW from the mean value (depending on the traffic type). For the 10 minute traces, it’s normal for a collected trace’s derived power value to land within 4.03 − 9.39mW (depending on trace type) from the mean value. Please note that for the 10 minute traces, the standard deviation for traffic type 1 and 3 is 9.05 − 9.39mW, while it’s only 4.03mw for traffic type 2. This can be explained by traffic type 2 mainly utilizing the TCP-protocol for transmission (only DNS queries utilize UDP), while traffic type 1 consists of only UDP-protocol transmissions and traffic type 3 utilizes both.
As for the number of traces, from figure 3 it can for example be derived that the mean power from 10 one-minute traces containing traffic type 1 only deviates by 6.65mW from the mean power calculated from 20 one-minute traces, meaning that using 10 traces instead of 20 decreases the accuracy by only 0.8%. Using the same reasoning for traffic type 2, decreasing the number of traces from 20 to 10 decreases accuracy by only 0.73% and doing the same for traffic type 3 only decreases the accuracy by 0.57%. Calculating the mean power from 10 one-minute traces gives us 933mW, which is only 0.33% off from the average from five ten minute traces. Hence, we believe that despite the statistical concerns, the choice of the length of traces is appropriate for the level of accuracy we aim for.
6.2.3 Impact of the 3G energy consumption
In order to interpret the resulting energy consumption for our application’s background traffic, we will look at the battery time of what is today a commercial state-of-the-art handset battery, such as a Samsung Galaxy S4 battery with a capacity of 9.88Wh [11]. With an average power consumption of 928-930mW (taken from row 5 and 6 of table 3), such a battery would last for roughly 10 hours and 30 minutes, and that is if the application is not even interacted with at all as well as excluding all other energy consuming processes that will be present in a handset. For a Samsung Galaxy S2 battery with a capacity of 6.11Wh [12], the battery time would be a maximum of roughly 6 hours and 30 minutes following the same reasoning. For an average user (speaking for ourselves), having to re-charge the
handset at least every 10 hours is too often. As for an application that is supposed to be used in a search and rescue scenario where there are often limited power resources, such a high power drain can be deemed as unacceptable. And this is only for the background traffic with no actual data transfer considered!
18
7
Conclusion
Based on our limited tests, EnergyBox seems to estimate the energy consumed well for the type of traffic that our application generates. We have seen that looking at isolated parts of our application separately and summarizing their power consumption is not the same as the power consumed when the traffic is allowed in an interleaved manner, which indicates that it is important to investigate combinations of traffic. The time span of a trace collected decides how much the derived power for a single trace can deviate from the more accurate estimation of the mean power, but our results suggest that the choice of transport layer protocol for the traffic also has an impact on how long the traces should be.
For our application, calculating the mean power from merely 10 one-minute traces con-taining all components of the background traffic is enough since collecting more traces does not change the power value more than 0.33%. In the case of deciding the 3G energy foot-print for our application, measuring the background traffic gives us a power value of 928mW-930mW, such a value means that a Samsung Galaxy S4 battery would be able to power the 3G transmissions for a maximum of 10 hours and 30 minutes.
We think estimating the 3G energy footprint of our application’s background traffic is a good start to deciding the whole application’s 3G energy footprint, it tells us that even without user interaction our application will drain the handset’s battery very quickly. In our case, developing an application oblivious to how much transmission over wireless channels might consume energy proved disastrous for the handset’s battery time. For example, we send background data every 10 and 15 seconds which proved very inefficient, so we might want to increase these intervals significantly. No matter what approach a developer might take to improve the 3G energy efficiency of their application, EnergyBox has helped us conclude that for us, actions need to be taken. Using EnergyBox and relying on it’s estimations was especially easier than resorting to physical measurements which were tedious to make (and special equipment is needed). If we were to make changes to the connection handling of our application, EnergyBox would hopefully prove helpful once again to help decide how much of an improvement (if at all) said changes were.
References
[1] Jon Vergara, Ekhiotz, Nadjm-Tehrani, Simin and Prihodko, Mihails, EnergyBox: Disclos-ing the wireless transmission energy cost for mobile devices, Sustain. Comput.: Inform. Syst., http://dx.doi.org/10.1016/j.suscom.2014.03.008, 2014.
[2] Jon Vergara, Ekhiotz, Sanjuan, Joseba and Nadjm-Tehrani, Simin, Kernel Level Energy-Efficient 3G Background Traffic Shaper for Android Smartphones. Wireless Communi-cations and Mobile Computing Conference (IWCMC), 9th International, IEEE, 2013. [3] Balasubramanian, Niranjan, Balasubramanian, Aruna and Venkataramani, Arun, Energy Consumption in Mobile Phones: A Measurement Study and Implications for Network Ap-plications. Proceedings of the 9th ACM SIGCOMM conference on Internet measurement conference, IMC, 2009.
[4] Perl, Pekka H. J., Barbuzzi, Antonio, Boggia, Gennaro and Pentikousis, Kostas, Theory and Practice of RRC State Transitions in UMTS Networks. GLOBECOM Workshops, IEEE, 2009.
[5] Qian, Feng, Wang, Zhaoguang, Gerber, Alexandre, Mao, Z. Morley, Sen, Subhabrata and Spatscheck, Oliver, Profiling Resource Usage for Mobile Applications: A Cross-layer Approach. MobiSys ’11 Proceedings of the 9th international conference on Mobile systems, applications, and services, ACM, 2011.
[6] Jon Vergara, Ekhitotz and Nadjm-Tehrani, Simin, Energy-aware Cross-layer Burst Buffering for Wireless Communication. Proceedings of the 3rd International Conference on Future Energy Systems: Where Energy, Computing and Communication Meet, e-Energy 2012.
[7] Asplund, Mikael, Jon Vergara, Ekhiotz, Nadjm-Tehrani, Simin and Thomasson, Anton, Software-related Energy Footprint of a Wireless Broadband Module. The 9th ACM In-ternational Symposium on Mobility Management and Wireless Access (MobiWac), 2011. [8] Jon Vergara, Ekhiotz and Nadjm-Tehrani, Simin, Watts2Share: Energy-Aware Traffic Consolidation. IEEE Intenational Conference on Green Computing an Communications (GreenCom), 2013.
[9] Andreasson, Oskar. Iptables Tutorial, http://web.guicar.com:83/Manuali/Firewall/ http___iptables-tutorial.frozentux.net_iptables-tutorial.html.pdf, 2008. (Accessed 2014-05-15).
[10] Ubuntu Community Help Wiki. AutomaticConnections, https://help.ubuntu.com/ community/AutomaticConnections (Accessed 2014-04-28)
[11] Samsung, Galaxy S4 Standard Battery (2600mAh) http://www.samsung.com/us/ mobile/cell-phones-accessories/EB-B600BUBESTA (Accessed 2014-06-07).
[12] Samsung, Galaxy SII Standard Battery (1800 mAh) http://www.samsung.com/us/ mobile/cell-phones-accessories/EB625152VABSTD (Accessed 2014-06-07)
