Optimizing Communication Energy Efficiency for a Multimedia Application

Full text

(1)Institutionen för datavetenskap Department of Computer and Information Science Master thesis. Optimizing Communication Energy Efficiency for a Multimedia Application by. Jens Green Olander LIU-IDA/LITH-EX-A--16/007--SE 2016-03-08. Linköpings universitet SE-581 83 Linköping, Sweden. Linköpings universitet SE-581 83 Linköping, Sweden. Linköpings universitet 581 83 Linköping. Linköpings universitet 581 83 Linköping.

(2)

(3) Linköping University Department of Computer and Information Science. Master thesis. Optimizing Communication Energy Efficiency for a Multimedia Application by. Jens Green Olander LIU-IDA/LITH-EX-A--16/007--SE. 2016-03-08. Supervisors: Robert Nissa Holmgren Spotify AB Ekhiotz Jon Vergara Department of Computer and Information Science Linköping University Examiner:. Simin Nadjm-Tehrani Department of Computer and Information Science Linköping University.

(4)

(5) Abstract Mobile devices have evolved rapidly in recent years and increased usage and performance are pushing contemporary battery technology to its limits. The constrained battery resources mean that the importance of energyefficient application design is growing and in this regard wireless network accesses are a major contributor to a mobile device’s overall energy consumption. Additionally, the energy consumption characteristics of modern cellular technologies make small volumes of poorly scheduled traffic account for a substantial share of a device’s total energy consumption. However, quantifying the communication energy footprint is cumbersome, making it difficult for developers to profile applications from an energy consumption perspective and optimize traffic patterns. This thesis examines the traffic patterns of the Android client of the popular multimedia streaming service Spotify with the intention to reduce its energy footprint, in terms of 3G energy consumption. The application’s automated test environment is extended to capture network traffic, which is used to estimate energy consumption. Automated system tests are designed and executed on a physical Android device connected to a 3G network, shedding light on the traffic patterns of different application features. All traffic between the Spotify client application and the backend servers is encrypted. To extract information about the traffic, the application code is instrumented to output supplementary information to the Android system log. The system log is then used as a source of information to attribute data traffic to different application modules and specific lines of code. Two simple traffic shaping techniques, traffic aggregation and piggybacking, are implemented in the application to provide more energyefficient traffic patterns. As a result, 3G energy consumption during normal music playback is reduced by 22-54%, and a more contrived scenario achieves a 60% reduction. The reductions are attained by rescheduling a small class of messages, most notably data tracking application usage. These messages were found to account for a small fraction of total traffic volume, but a large portion of the application’s overall 3G energy consumption..

(6)

(7) Contents Abstract. v. Contents. vii. List of Figures. ix. List of Tables. x. List of Listings 1 Introduction 1.1 Problem Statement 1.2 Contributions . . . 1.3 Methodology . . . . 1.4 Delimitations . . . . 1.5 Structure . . . . . . .. xi . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 1 1 2 2 3 3. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 2 3G Background 2.1 UMTS Architecture . . . . . . . . . . . . 2.2 RRC State Machine Model . . . . . . . . 2.3 Energy Consumption Characteristics 2.4 Related Work . . . . . . . . . . . . . . . . . 2.5 Traffic Shaping . . . . . . . . . . . . . . . 2.5.1 Delay-Tolerant Traffic . . . . . . 2.5.2 Implementations . . . . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 5 . 5 . 6 . 8 . 9 . 10 . 10 . 10. . . . . . . . . . .. 13 13 13 15 16 16 17 18 18 19 19. 3 Tools and Test Environment 3.1 The Spotify Application . . . . . . . . . . . . . . . . 3.1.1 Usage Patterns . . . . . . . . . . . . . . . . . . 3.1.2 The Spotify Android Client . . . . . . . . . . 3.1.3 Spotify Network Architecture . . . . . . . . 3.1.4 Test Automation . . . . . . . . . . . . . . . . . 3.1.5 Spotify Connect . . . . . . . . . . . . . . . . . . 3.2 Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Energy Profiling Using EnergyBox . . . . 3.2.2 Simplified RRC State Machine Model . . . 3.2.3 Low-Traffic State Promotion Avoidance . vii. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . ..

(8) 3.2.4 CPU Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4 Automated Energy Profiling 4.1 The Utility of Automated Energy Testing . . . . . . . . . . . . . . 4.1.1 Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Diversity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.3 Reproducibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Capturing Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Isolating and Capturing Spotify Traffic . . . . . . . . . . . 4.2.2 Method Tracing Through System Log Instrumentation 4.3 The Case for Additional Test Cases . . . . . . . . . . . . . . . . . . 4.4 Energy Quantification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Attributing Traffic to Root Causes . . . . . . . . . . . . . . . . . . . 4.6 EnergyBox Modifications . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.2 Identifying Performance Bottlenecks . . . . . . . . . . . . . 4.6.3 Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.4 Performance Improvements . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. 21 21 22 22 22 22 23 24 25 26 26 27 27 28 28 30. 5 Identifying Energy-Inefficient Traffic Patterns 5.1 Dissection of Spotify Features . . . . . . . . . . 5.1.1 Music Playback . . . . . . . . . . . . . . . . 5.1.2 Logging of Analytics Data . . . . . . . . 5.1.3 Spotify Connect Device Discovery . . . 5.1.4 Spotify Connect State Synchronization 5.1.5 Advertisements . . . . . . . . . . . . . . . . 5.1.6 Scrobbling . . . . . . . . . . . . . . . . . . . 5.2 Summary of Findings . . . . . . . . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. 33 33 34 36 38 39 39 41 41. . . . .. 43 43 44 47 48. 6 Reducing Energy Consumption 6.1 Approach . . . . . . . . . . . . . . . . . . . . . 6.2 Aggregation of Analytics Transmissions 6.3 Spotify Connect Device Discovery . . . . 6.4 Piggybacking Delay-Tolerant Traffic . .. . . . .. . . . .. . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . .. . . . .. 7 Conclusion and Discussion 53 7.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 7.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 7.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Bibliography. 57.

(9) List of Figures 2.1 UMTS network overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 RRC state machine for 3G. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 3.2 3.3 3.4. Focus time distribution for the different Spotify session types. Architecture of the Spotify system. . . . . . . . . . . . . . . . . . . . . Test setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simplified RRC state machine. . . . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . .. . . . .. . . . .. 6 7 15 16 17 20. 4.1 Hotspots in EnergyBox. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.2 Processing time of the different EnergyBox builds. . . . . . . . . . . . . . 32 5.1 5.2 5.3 5.4. Energy profiles of the different playback modes. Energy profile of track skipping. . . . . . . . . . . . Energy profile of device discovery. . . . . . . . . . . Energy profile of advertisments. . . . . . . . . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 36 38 38 40. 6.1 6.2 6.3 6.4 6.5. Energy impact of aggregating analytics transmissions. . Impact of aggregating analytics data on energy profile. Energy impact of device discovery. . . . . . . . . . . . . . . Energy impact of piggybacking. . . . . . . . . . . . . . . . . . Impact of piggybacking on energy profile. . . . . . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 46 46 47 50 51. ix. . . . .. . . . .. . . . .. . . . ..

(10) List of Tables 2.1 Empirical energy consumption values for some 3G devices. . . . . . .. 8. 3.1 Typical mobile session types for Spotify’s Android application. . . . . 14 4.1 Processing time of the different EnergyBox builds. . . . . . . . . . . . . . 32 5.1 Music playback test results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.2 Energy overhead of state synchronization. . . . . . . . . . . . . . . . . . . 39 5.3 Energy overhead of scrobbling. . . . . . . . . . . . . . . . . . . . . . . . . . . 41 6.1 6.2 6.3 6.4 6.5. Mappings of ID to test description. . . . . . . . . . . . . . . Energy impact of aggregating analytics transmissions Energy impact of device discovery . . . . . . . . . . . . . . Pickybacking signals. . . . . . . . . . . . . . . . . . . . . . . . Energy impact of piggybacking . . . . . . . . . . . . . . . .. x. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 43 45 48 48 49.

(11) List of Listings 1 2 3 4 5 6 7. EnergyBox stack trace. Streaming playback . . Synced playback . . . . Offline playback . . . . Skip sequence test . . . Ad break test. . . . . . . Disabled ad break test.. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. xi. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 29 35 35 35 37 41 41.

(12)

(13) Chapter 1 Introduction In recent years mobile data usage has skyrocketed [12]. Wireless communication is a major contributor to energy consumption in mobile devices and battery technology has not kept pace with this development. Battery lifetime is, however, perceived as a vital aspect to the user and it is currently a limiting factor of mobile services negatively impacting users’ quality of experience. The energy footprint of a mobile application is not only affected by the amount of data transmitted and received, but also the traffic patterns – the manner in which applications transmit and receive data. Around 60% of energy consumed by the 3G interface of a mobile device has been shown to be spent when the device is not transmitting or receiving data [38]. This is largely because mobile devices linger in a high-power state that provides high bandwidth for extended periods of time after transmitting or receiving even small amounts of data. Such energy inefficiencies often arise due to complex interactions between layers in the communication model, including the application layer, the transport layer, the network layer and the physical layer. Even though traffic patterns are an important issue to consider when designing software for mobile devices, their effects are often underestimated and ambiguous to the software developer without specific analysis. Tools like EnergyBox [46], which quantifies communication energy consumption using captured network traffic as input, can support the development of energyefficient traffic patterns. This thesis will profile the Spotify streaming multimedia application for Android devices from an energy consumption perspective, analyzing the energy footprint of its traffic patterns in the context of 3G communication.. 1.1. Problem Statement. This thesis aims to reduce the 3G communication energy consumption of the Spotify application for Android devices through modifications of the application’s traffic patterns. To solve this problem, the main goals of the thesis are: 1.

(14) 1. Introduction. 1. Extend the automated testing environment to facilitate energy consumption analysis. The testing environment is extended with additional tests and tools to capture packet trace and system log data, enabling the use of EnergyBox to estimate energy consumption. 2. Profile the application using packet traces and system logs. Collection of system logs and traffic data allows us to identify energyinefficient application features by finding correlation between system events and high energy consumption states. 3. Identify energy-inefficient traffic patterns. Having gathered data linking application features to energy consumption, we look at the traffic patterns these features produce and and identify potential energy savings. 4. Provide solutions for improving energy efficiency. Traffic patterns with improved energy efficiency are implemented in the application. The resulting energy consumption is then measured and compared to previous results.. 1.2. Contributions. The contributions of this thesis are: • A set of proof-of-concept changes to the Spotify Android application that implements simple traffic shaping techniques, reducing selected application features’ energy consumption over 3G networks by 22-54% during music playback. • Integration of EnergyBox in the Spotify testing environment. • EnergyBox performance improvements and improved command line support for Mac OS X.. 1.3. Methodology. In this thesis, we first conduct a literature survey examining works related to 3G energy consumption and the Radio Resource Control (RRC) protocol that determines the state of the radio interface of 3G devices. Understanding the RRC protocol is key to understanding the interactions between traffic patterns and energy consumption. The energy consumption modeling tool EnergyBox [46] that uses packet capture trace files to model RRC states is used to quantify the energy consumption of the 3G interface when the Spotify application is running. To acquire packet traces from the application, the existing test automation (TA) framework at Spotify is extended with functionality to capture such data. Correlating the RRC states inferred from captured packet traces with specific application features can be difficult since the communication channel between clients and the server backend is encrypted and multiplexed, exposing 2.

(15) 1.4. Delimitations. only a single endpoint for most traffic. Therefore, the Android system log was utilized to infer causual relationships between internal application events and generated traffic. The application was instrumented to log additional information and the captured log output was then synchronized with corresponding packet traces. Exploratory energy profiling and interviews with software developers at Spotify serves to guide the selection of potentially energy-inefficient features to focus on. Based on these findings, a set of application features are chosen for further study and measures to improve their energy efficiency are suggested. The suggested improvements are then implemented in the application. Their potential energy savings are quantified and validated by estimating the energy consumption using EnergyBox.. 1.4. Delimitations. Only communications using the third-generation UMTS W-CDMA 1 cellular system (referred to as ”3G” for simplicity) will be considered for the purposes of this thesis. 3G subscribers currently outnumber LTE (4G) subscribers fourto-one and is predicted be the most widespread mobile broadband standard until at least 2020 [12]. Because of distinctions between different modes of wireless communication, the effect of traffic patterns on energy consumption is highly dependent on the mode of communication. For example, traffic patterns that are efficient for 3G are not necessarily efficient for WiFi.2 The impact of traffic patterns on 3G communication is in general greater than on WiFi, making it a more interesting topic for study. Furthermore, only client-side application-layer techniques of modifying traffic patterns is considered. By delimiting ourselves to client-side modifications we greatly simplify implementation and evaluation of any changes, since the existing Spotify server-side services can be used. Only applicationlayer approaches are applicable for implementation in the Spotify application, since Android applications run in a sandboxed environment with restricted access to the rest of the system.. 1.5. Structure. The rest of the thesis is structured as follows: A background on 3G technology and its energy consumption implications are introduced in chapter 2. The tools and test environment used are described in chapter 3. Chapter 4 presents the automated energy profiling methodology and the modifications made to EnergyBox. A set of energy-inefficient features are identified in chapter 5, and the tests used to identify them are described in detail. Mitigations imple1. Universal Mobile Telecommunications System (UMTS) with Wideband Code Division Multiple Access (W-CDMA) [1]. 2 The wireless local area network technologies based on the IEEE 802.11 family of standards, commonly referred to as WiFi.. 3.

(16) 1. Introduction. mented to reduce energy consumption are presented in chapter 6, along with quantified energy consumption with and without these changes. Chapter 7 is the final part of the thesis, which summarizes and concludes the study.. 4.

(17) Chapter 2 3G Background This chapter aims to provide the necessary background to the current 3G technology of the UMTS W-CDMA cellular system. The UMTS W-CDMA cellular system is defined in a set of standards from the 3rd Generation Partnership Project (3GPP) [1]. An overview of UMTS is provided in Section 2.1. The state machine model of the RRC protocol, which controls the power levels of 3G devices, is explained in Section 2.2, Section 2.3 examines the characteristics of 3G energy consumption and Section 2.4 presents previous work related to the issues discussed in this thesis. The chapter is then concluded in Section 2.5 with a brief overview of some traffic shaping considerations and techniques.. 2.1. UMTS Architecture. The UMTS network essentially has four components: user equipment (UE), base stations (Node Bs), radio network controllers (RNCs) and the core network (CN) [38], shown in Figure 2.1. The functionality of the different components are summarized below: User equipment (UE) 3G device, such as a smartphone, connected wirelessly to the UMTS network. Node B Base station that communicates directly with UEs by handling the physical radio communications. Radio network controller (RNC) Handles packet scheduling, radio resource control and similar functions. Core network (CN) Connects the operator network to external networks so that the users of the network can communicate with the wider Internet. The RNC, and in particular the RRC protocol, is of special interest to this thesis because of its profound impact on 3G devices’ energy consumption and is the topic of the following section.. 5.

(18) 2. 3G Background. UEs. Node B. RNC. Node B. RNC. CN. UEs. Figure 2.1: UMTS network overview.. 2.2. RRC State Machine Model. UMTS networks operate under conditions that make it necessary to effectively make use of the available radio frequencies. The RRC protocol is responsible for this resource allocation [32, 37, 46]. UEs are assigned radio resources by the RNC using the RRC protocol. Radio resources are the set of physical transmission parameters necessary to transport information over radio and most notably includes a carrier frequency [15]. Although there has been several incremental updates to the 3G standards, the RRC state machine model has remained essentially the same [32, 46]. The RNC assigns a finite state machine to each UE that determines the activity level of the UE’s 3G interface. Each state is associated with a different performance and energy consumption level. The transitions between states are determined by a combination of traffic volume as well as inactivity timers and are controlled by the RNC [32, 38, 46]. There are four RRC states: CELL_DCH The UE is assigned a dedicated channel (DCH) in both uplink and downlink directions. A high data throughput is provided at the expense of a high energy consumption. CELL_FACH The UE is assigned a low bandwidth shared channel (forward access channel, FACH) in both uplink and downlink directions. Lowbandwidth transmissions are possible, but a promotion to CELL_DCH is required before transmitting at higher bandwidth. Both UE energy consumption and throughput is lower than in the DCH state. CELL_PCH/URA_PCH The UE listens to the paging channel (PCH) and broadcast channel (in CELL_PCH and URA_PCH states respectively) for 6.

(19) 2.2. RRC State Machine Model. downlink packets, but uplink transmissions are not possible [32]. Due to the similarity of these two states, many authors model them as a single PCH state [37, 46, 18]. This state maintains connection to the RNC for quicker state promotions compared to the following IDLE state [38]. IDLE In this state, there is no connection to the RNC and thus the UE cannot transmit data. A state promotion must be negotiated before downlink or uplink transmissions are possible. Figure 2.2 pictures the RRC state machine, including the states described above and the transitions described below. From this point on, the states will be referred to as DCH, FACH, PCH and IDLE. Buffer. Buffer B1. PCH. Buffer B2. FACH Timer T2. Timer. DCH Timer T1. IDLE. Buffer. Figure 2.2: RRC state machine for 3G, adapted from [46]. State promotions (PCH→FACH, FACH→DCH and PCH→DCH) are determined by buffer occupancy threshold values. Packets awaiting transmission are temporarily put in a buffer and an RRC state promotion is triggered when the buffer size reaches a threshold, the value of which is operator-configured depends on the active state. When the UE is in the PCH state and the buffer size surpasses the threshold B1 , a PCH→FACH promotion is triggered. The same goes for the threshold B2 and the FACH→DCH promotion. The buffer is emptied as the data it contains is transmitted. State demotions (DCH→FACH, FACH→PCH and PCH→IDLE) are controlled by inactivity timers set by the mobile operator. These timers are typically 2-10 seconds long [32] and trigger state demotions if no traffic is transmitted for the duration of the timer. If we define a period of inactivity as the period of time between the transfer of two temporally adjacent packets, then a period of inactivity of length T1 is required to trigger a DCH→FACH demotion and a period of length T2 to trigger a FACH→PCH demotion. The inactivity timers are reset when the UE sends or receives data, leaving the UE in DCH or FACH until the inactivity timers have expired. Some operators do however allow small amounts of traffic to pass without resetting timers to accommodate for faster state demotions [46]. There is some overhead when transitioning to another RRC state both in terms of latency and energy use. The UE and the RNC must negotiate allocation of radio resources when an RRC state promotion is triggered. This is 7.

(20) 2. 3G Background. a process that may incur up to three seconds of latency caused by the control messages that are exchanged, during which the ability to transmit other data is limited [38]. Because of this effect, setting short inactivity timers has some tradeoffs. Even though energy wasted waiting for inactivity timers to expire can be reduced by setting shorter inactivity timers, this causes the frequency of state transitions to increase, which incurs penalties in the form of latency and state transition energy [46]. The responsibility of balancing the tradeoffs associated with these static network parameters lies with the mobile operator, since UEs cannot change the parameter values.. 2.3. Energy Consumption Characteristics. 3G energy consumption depends largely on the RRC state of the 3G interface [46]. Each state is approximately associated with a power consumption level. DCH consumes the most energy, FACH consumes around 50-75% of DCH, while PCH and IDLE consume a negligible amount (around 1% of DCH) [32, 5]. Power consumption levels for some 3G devices are listed in Table 2.1. Power (mW) Device. Year. DCH. FACH. IDLE. Ref.. Google Nexus One HTC Dream HTC TyTN II Sony Xperia Arc S Ericsson F3307 broadband module. 2010 2008 2007 2010 2010. 600 570 800 612 1300. 450 401 460 416 500. 0 10 0 0 200. [38] [38] [38] [3] [46]. Table 2.1: Empirical energy consumption values for some 3G devices. Large data traffic volumes do not necessarily cause greater energy consumption than smaller volumes. This somewhat unintuitive characteristic is a consequence of the RRC inactivity timers which was been discussed in Section 2.1. Once enough data to trigger an RRC state promotion is sent or received, the device must first linger in the DCH state until the first inactivity timer expires. At this point, the device is demoted to FACH and remains in this state until the second timer expires. Only after both timers have expired is the device allowed transition to the low-energy PCH state. These artifacts of the RRC protocol are known as energy tails and are a major contributor to 3G energy consumption [5]. Consequently, tiny bursts of traffic has been shown to account for a large percentage of total energy consumption [44, 35]. In addition to energy tails, another source of energy consumption overhead is state transition energy that is consumed during RRC state transitions. As discussed in Section 2.2, there is some inherent latency during state transitions during which the device and RNC negotiate radio resource allocations. During this time the radio interface is active, which consumes energy. [5, 37] 8.

(21) 2.4. Related Work. Energy consumed during the communication of data packets (as opposed to RRC control messages) is known as transfer energy [5]. This is the energy that is used to power the 3G interface during communication of data and hence is essential to the communication of the data. Transmission of a single small packet may thus trigger first a period of state transition energy overhead, continuing with a small amount of transfer energy during transmission, and finally followed by an long energy tail lasting several seconds.. 2.4. Related Work. The impact of traffic patterns on mobile energy consumption has been a highly-researched topic in recent years, with papers presenting techniques for improved energy efficiency and tools for energy consumption modeling. Energy optimization Previous research has shown that both cross-layer solutions and applicationlayer solutions can effectively reduce energy consumption. The TailEnder algorithm [5] alters traffic patterns with aggressive prefetching to achieve reduced energy consumption for certain applications at the expense of increased bandwidth. Similarly, TailTheft [26] reschedules traffic to piggyback onto energy tails of other transmissions. Huang et al. [19] optimize for delay-tolerant background traffic when the device’s screen is turned off without necessarily interfering with foreground traffic when the device is in use. Other approaches [36, 11, 4] try to predict upcoming periods with no communication and dynamically terminate energy tails at such times using the Fast Dormancy 3G extension to return to the device to low-energy state. Such techniques rely on the availability of Fast Dormancy as well as the software taking advantage of it. Vergara et al. [47] implement a traffic shaping kernel module that aggregates traffic background traffic into bursts and utilizes the RRC low-traffic mechanism to transmit small packets in FACH, avoiding state promotions to DCH. Modeling energy consumption Some studies rely on a special hardware setup to physically measure the power drain of mobile devices, a substantial barrier to entry for energy consumption testing. However, recent network energy profilers such as EnergyBox 1 [46] and the AT&T Resource Optimizer 2 [38] are able to accurately model 3G energy consumption using only captured packet traces along with device and network parameters, lowering the difficulty and investment required quantify 3G energy consumption. 1 2. Available at https://github.com/rtslab/EnergyBox Available at http://developer.att.com/application-resource-optimizer. 9.

(22) 2. 3G Background. 2.5. Traffic Shaping. This section introduces methods of shaping traffic patterns for increased energy efficiency. We first introduce the notion of delay-tolerant traffic in Section 2.5.1, followed by a brief walkthrough of some common traffic shaping techniques in Section 2.5.2.. 2.5.1. Delay-Tolerant Traffic. The quality of service (QoS) requirements placed on an application or on classes of traffic have implications on the degree to which traffic shaping may be applied. Delay-tolerant applications are characterized by best-effort QoS requirements and can tolerate some network delays [5]. Examples include email applications and RSS news readers. Another class is delay-sensitive applications, for example web browsing and similar applications, where delays are associated with a degraded user experience [37]. Shaping application’s traffic patterns based on knowledge of the RRC state machine has the potential to reduce 3G energy consumption, but is difficult since the RRC state machine differs between mobile operators and the OS generally does not relay RRC state information to the application layer. Furthermore, traffic shaping has limited applicability for delay-sensitive applications such as web browsing or multimedia streaming [37]. For example, the traffic patterns of web browsing are dependent on the user interactions. When clicking a link the resulting HTTP request must be sent promptly as to not ruin the user experience by introducing additional latency. Aggressive prefetching can greatly reduce the energy consumption of delay-sensitive traffic, but causes large traffic volume overhead instead [5]. Delay-sensitive traffic does not respond well to being shifted temporally. Instead, caching and prefetching data are better traffic shaping approaches. Background traffic, on the other hand, accounts for a majority of 3G energy consumption and is in many instances more delay-tolerant [19].. 2.5.2. Implementations. In the context of 3G networking, traffic shaping has the ability to considerably impact energy consumption. This section will provide an overview of three common traffic shaping techniques: batching, prefetching and piggybacking. Traffic Aggregation and Batching The energy tail characteristic means that the initial cost of transmitting a message and thus causing an RRC state promotion is high, while subsequent transmissions in the high-energy have a lower cost. Generally, the concept of collecting temporally scattered transmissions and and sending them as a single larger transmission is known as traffic aggregation.. 10.

(23) 2.5. Traffic Shaping. The basic concept involves delaying transmissions by putting traffic subject to aggregation in a queue acting as a buffer, which is then emptied based on some criteria. One approach, commonly known as batching, is to periodically transfer the buffer contents when a timer expires, effectively putting an upper limit on maximum delay. Another approach is to limit the buffer by size or by number of items. When the queue reaches the maximum size all messages are transmitted and the buffer is emptied. This effectively limits the amount of memory necessary for the traffic aggregation scheme. Both approaches can also be combined to set both a maximum delay and a limited queue size, a method which has been shown to improve Ethernet energy efficiency [8]. Prefetching Prefetching network resources that is likely to be requested in the near future is a technique that can reduce response times as well as energy consumption at the cost some traffic volume overhead. An example is found in the Chromium browser’s use of DNS prefetching: DNS requests for domains that are entered in the address bar are sent before the user makes the HTTP request for the website [9]. Since the domain name must be resolved to an IP address before the HTTP request can be sent, the DNS prefetching reduces the overall latency. 3G communications can effectively utilize prefetching to reduce energy consumption. The large energy cost of energy tails makes RRC state promotions expensive, but transmitting additional data in a high-consuming state is less costly, since it does not result in additional energy tails. Thus, if the application has knowledge of data which is likely to be fetched in the future, the cost of future transmissions can be amortized by sending them upfront. The difficulty of this approach lies in predicting which resources to prefetch and balancing prefetching aggressiveness. The probability of prefetching resources which will be used should be high, which requires good prediction in order to limit traffic overhead. Piggybacking Delaying transmissions of delay-sensitive traffic until a high-consuming RRC state has been triggered by other traffic is known as piggybacking. As the name implies, the piggybacked traffic essentially gets a free ride on the energy tails caused by other traffic. The dependence on other traffic is a limiting factor of this technique, as delivery of delay-tolerant traffic is dependent on the presence of bursts of delay-sensitive traffic to piggyback onto.. 11.

(24)

(25) Chapter 3 Tools and Test Environment This chapter introduces the Spotify service, its Android application and its test automation environment in Section 3.1. In Section 3.2, profiling is discussed, along with the profiling tools employed in this thesis, both in terms of energy profiling using EnergyBox and CPU profiling.. 3.1. The Spotify Application. Spotify is a music streaming service founded in Sweden 2006. The service currently has over 75 million active users in 58 markets worldwide and is available on a wide range of platforms, including Android, iOS, Windows, Mac OS X, web browsers and embedded devices such as TVs.1 Spotify uses a so-called freemium payment model with two usage tiers: a premium tier where users pay a monthly fee and an ad-supported free tier. Paying premium users can access the music collection without restrictions and may download and store (synchronize or sync in Spotify terms) tracks in their local devices for offline access. Free users on the other hand, are unable to sync tracks, have no offline access and are served audio advertisements in between tracks. Further restrictions are also placed on free users, limiting the ability to choose the playback order of tracks. Another feature that separates the two tiers is the availability of Spotify Connect, which allows users to remote-control playback on a device from another device. Spotify Connect is discussed further in Section 3.1.5.. 3.1.1. Usage Patterns. Usage patterns of the application is a topic that can guide the potential energy savings, since user-initiated traffic is generally unpredictable and delaysensitive, which makes it difficult to alter for energy efficiency purposes [19]. For this reason, the usage patterns of the Spotify application are of interest. The application may either be in focus or backgrounded. When in focus, the application’s user interface (UI) is visible to the user. When the application 1 “Information”, Spotify press, https://press.spotify.com/information/, March 2016. 13.

(26) 3. Tools and Test Environment. is either minimized, another application has focus or the device’s screen is turned off, the application is said to be backgrounded. We use the continuous periods of time when the application is in focus, so-called focus blocks, as a proxy for periods of time with user-initiated traffic. Focus blocks are interleaved with periods of inactivity, during which the application is backgrounded. Searching and browsing the music catalog are the most common activities during focus blocks. Typical for both of these activities is that they are highly delay-sensitive: the occurrence of delays affects the functionality of the application negatively. Activities that depend on unpredictable user-initiated traffic are thus more complex to optimize for energy efficiency [35, 24, 19]. Examining typical user sessions of the Spotify application allows us to assess potential energy savings. A session is defined the span of time from when a user starts interacting with the application to when the application has been idle for three minutes without user interaction or active playback. Clustering analysis of Spotify usage data found six quintessential session types listed in Table 3.1 along with their prevalence (share of total sessions) among Spotify users.2 Session type. Composition of in-focus time. Prevalence. Set & Forget. Few short focus blocks at beginning of the session. 37%. Lean-in Burst. Large parts of session spent in focus, especially during the middle of the session. 24%. Browse & Forget. Medium length focus block in the first half of the session and very few focus blocks in the latter half. 19%. Collection Building. In-focus activity at beginning and end of the session. 15%. Set & Tune. Most of focus time at start, followed by midlength focus periods throughout the session. 4%. Continual Focus. > 80% of session in focus. 1%. Table 3.1: Typical mobile session types for Spotify’s Android application. Figure 3.1 illustrates the relative focus time distribution for each quarter of each session type. For example, the first quarter of a ”Set & Forget” session receives 84% of such a session’s total focus time, whereas the focus time is more evenly distributed in a ”Continual Focus” session, with each quarter receiving roughly 25% of the session’s focus time. The study also found that 10% of total usage of the application on Android phones was spent in focus, while the application was backgrounded the remaining 90%. 2 The source of this data is an internal report that cannot be referenced directly in this thesis. The findings are instead summarized in this section.. 14.

(27) 3.1. The Spotify Application. Figure 3.1: Focus time distribution for the different Spotify session types. In summary, large parts of Spotify sessions are spent with the application backgrounded. This creates room for energy savings through utilization of traffic shaping techniques, provided that QoS restrictions can accommodate it. On the other hand, the 10% of session time spent in focus has less potential for energy savings.. 3.1.2. The Spotify Android Client. Android is the world’s most popular mobile operating system with more than one billion users [33] and a 79% share of the global smartphone market [20]. The Android operating system is based on the Linux kernel and provides application programming interfaces (APIs) for a range of services that can be integrated in applications using the Android Software Development Kit (SDK). Android applications are typically written in Java and are run on a Java Virual Machine (JVM), although Android also has support for native code using the Android Native Development Kit (NDK). The Spotify application has a core written in native C++ code that is shared among most platforms where it is available. Depending on the specific platform, different SDKs and frameworks are present in a layer on top of the core. On the Android platform, the platform-specific parts of the Spotify client are written in Java and use the Android SDK. The Android NDK is utilized to deploy the core to the Android platform with Java Native Interface (JNI) bindings being used to communicate between the two layers. A graphical representation of the application’s architecture can be found on the left side of Figure 3.2. A consequence of this architecture is that parts of the application are run in the JVM while other parts are run natively, which has performance and debugging implications. For example, inspection of JVM stack frames is not sufficient to fully trace the execution of the application or to profile it, as many function calls end up using JNI bindings to access core components. This is especially true for functionality related to network access, which is mostly implemented in the core. 15.

(28) 3. Tools and Test Environment. Android client Backend service. Java Encrypted TCP. JNI Core. Encrypted TCP. AP. CDNs. ⋮ Backend service. Figure 3.2: Architecture of the Spotify system. To interact with an Android device from a desktop computer, the Android SDK contains the Android Debug Bridge (ADB) tool. This tool has a variety of functions, including file transfer, port forwarding, management of application installations and direct shell access. The Android system log is a resource that applications may use to trace and persist runtime information. Collection of information for debugging or performance profiling purposes are common use cases for the system log. The system log is accessible through logcat,3 which can be reached from a connected computer using ADB.. 3.1.3. Spotify Network Architecture. The Spotify client application maintains an encrypted Transmission Control Protocol (TCP) connection with a Spotify access point (AP) at all times. The AP acts as a multiplexer, communicating with different server-side subsystems that provide services such as authentication and content delivery over a single connection. Figure 3.2 illustrates this setup. Previously, Spotify used a proprietary peer-to-peer scheme to deliver multimedia content to their users in addition to serving content from servers [23, 22, 29]. Recently, however, Spotify has phased out this system in favor of a pure client-server architecture. The content is served both from Spotify’s own servers as well as from content delivery networks (CDNs). Clients also communicate with third party advertisement networks, which serve and target ads.. 3.1.4. Test Automation. Spotify uses TA tools to automate system tests of the Android application. TA tests are constructed programmatically and run continually as part of the continuous integration pipeline. TA tests are run on debug builds of the application that listen to traffic on a specific TCP port. The tests, written in the Java unit testing framework JUnit, are run on computers connected via USB 3 ”logcat”, Android official website, http://developer.android.com/tools/help/ logcat.html, March 2016. 16.

(29) 3.1. The Spotify Application. to the test devices running Android. Such a computer is henceforth referred to as a test driver. A TCP connection is established through the USB interface, which allows the test driver to communicate with the device without interfering with the other network interfaces of the device. When a connection between test driver and device is established, arbitrary text strings may be sent to the device. Such strings are interpreted as arbitrary Java commands and executed on the device using BeanShell [6]. The TA tools include a framework that allows the application to be interacted with programmatically, in a similar manner to how a user would interact with the interface. Available actions include clicking on UI elements, navigating to specific views, entering search queries, toggling WiFi connectivity and most other actions available to users. Figure 3.3 illustrates the hardware test setup. 3G Nexus 4. Internet. USB. WiFi. Ethernet. WiFi router. Test driver WiFi. Figure 3.3: Test setup. A technique used in the context of TA is model-based testing (MBT), which models the application as a finite state machine [42]. Each vertex is modeled as a verifiable application state and each edge as an input action. Actions may be chosen deterministically or not depending on the purpose of a test.. 3.1.5. Spotify Connect. Spotify Connect 4 is a feature that allows users to remote-control playback from their other devices. For example, a user may use the Spotify application on their smartphone to start or stop music playback on the desktop client or their Spotify Connect-enabled speakers. The active device that provides music playback can be changed with the push of a button, however, at most one device is allowed to be active at the same time. Devices available for control are automatically updated and listed in the application. Device discovery is not limited to local networks, enabling users to use Spotify Connect even if their devices are on different networks. Inter-network synchronization is facilitated by clients connecting to the AP, registering their availability as a 4 ”Spotify. Connect: the new way to play at home”, https://press.spotify.com/se/ 2013/09/03/spotify-connect-the-new-way-to-play-at-home/, March 2016. 17.

(30) 3. Tools and Test Environment. Spotify Connect device and requesting updated device lists. Both discovery methods can be used simultaneously and are chosen independently based on availability: the client looks for local devices when connected to a local network and looks for remote devices when the AP is reachable. When Spotify Connect is used to play music from another device, the application behaves very similarly to when playing from the local device. The currently playing track as well as its progress is shown on both devices. Actions such as pausing playback, changing volume or changing tracks occur synchronously on both devices. The client always pushes these events to the AP if it is reachable. Considering these features, the Connect system can be said to contain two independent subsystems: 1. A device discovery subsystem, which enables Connect-enabled devices to discover and establish connections to each other. 2. A state synchronization subsystem, which synchronizes playback state and transmits actions among devices. This lets devices be remote controlled, to synchronously display the same playback state, and to seamlessly change the active output device. Chapters 5 and 6 will expand on the energy implications of Spotify Connect.. 3.2. Profiling. In the field of software development the term profiling relates to the attribution of costs to different specific parts of a program. Profiling is an important concept to this thesis and the term can be further clarified by the following definition [25]: “We use the term profiling to mean, in a broad sense, the ability to monitor and trace events that occur during run time, the ability to track the cost of these events, as well as the ability to attribute the cost of the events to specific parts of the program. For example, a profiler may provide information about what portion of the program consumes the most amount of CPU time, or about what portion of the program allocates the most amount of memory.” This thesis is mainly concerned with energy profiling the Spotify application using the tool EnergyBox, a technique discussed further in Section 3.2.1. We also employ CPU profiling of EnergyBox itself to identify performance bottlenecks to improve its performance in Section 3.2.4. The two techniques are similar in the sense that their respective target application’s runtime behavior is analyzed, but the resources measured are different.. 3.2.1. Energy Profiling Using EnergyBox. To model the energy consumption of the Spotify application and identify energy-inefficient application features we use the network energy profiling 18.

(31) 3.2. Profiling. tool EnergyBox [46]. For brevity, the term energy profiling will be used hereafter to mean network energy profiling of 3G communication. EnergyBox separates energy consumption into three factors, which it takes as input to model the resulting energy profile: data traffic, device-specific power levels and network configuration parameters. The data traffic takes the form of a packet trace file, device parameters specify the power usage in different power states (measured at a given device) and the network parameters define operator-controlled RRC parameters such as inactivity timers and buffer sizes. Both 3G and WiFi network operate by letting the wireless interface occupy different states that are associated with varying performance and energy consumption levels. The two network types are significantly different on a protocol level and in terms of media access methods and thus require different energy consumption models. EnergyBox supports 3G and WiFi and models the energy consumption with accuracies of 94–99% and 95–99% respectively compared to physical power measurements. Traffic data from Spotify was in fact used to estimate 3G energy consumption with EnergyBox in the original paper, with a measured accuracy of 94%. EnergyBox was originally developed in C++, but has since then been reimplemented with extended functionality in Java for a bachelor thesis [34] supervised by the original author. The purpose of the rewrite was to increase usability, adding a graphical user interface (GUI), and to refactor the codebase to simplify extending the application. This version uses a model-view-controller (MVC) architecture with the JavaFX framework 5 powering the GUI [28]. The Java implementation is the only version currently being maintained and is the one used in this thesis.. 3.2.2. Simplified RRC State Machine Model. Similar properties and energy consumption levels have allowed researchers [37, 46, 18] to model the RRC protocol as a simpler state machine with only three states, merging the PCH and IDLE states (see Figure 3.4). The benefit of this convention is ease of configuration, as the number of states, transitions and thus the number of required parameters is lowered. EnergyBox uses this simplified model to infer RRC states and thus energy consumption levels, a convention that will henceforth be applied in this thesis as well.. 3.2.3. Low-Traffic State Promotion Avoidance. Many 3G operators implement a mechanism which allows low-bandwidth communications without causing RRC state promotions. This mechanism is modeled in EnergyBox by summing the traffic volume during the last T seconds. If T > D for a state promotion threshold D, a promotion is triggered, 5 JavaFX (official website), http://www.oracle.com/technetwork/java/javase/ overview/javafx-overview-2158620.html, March 2016.. 19.

(32) 3. Tools and Test Environment. Buffer. Buffer B1. IDLE. Buffer B2. FACH Timer T2. DCH Timer T1. Figure 3.4: Simplified RRC state machine. otherwise the UE is allowed to communicate without transitioning to another state. A different D is assigned for downlink and uplink directions and for each different state promotion. The lengths of the timers are not required to be uniform across all state demotions, each demotion can be considered to be under control of its own timer. [46]. 3.2.4. CPU Profiling. The performance of EnergyBox was found to be not adequate for the input packet traces that were collected. CPU profiling is applied in Section 4.6 in order to identify performance bottlenecks in EnergyBox, while this section describes the notion of CPU profiling in general. The method of CPU profiling used in this thesis is CPU sampling. The profiler is linked to the JVM, which is paused intermittently by the profiler to allow sampling of the currently active stack trace [25]. Frequently used methods, or hotspots, are determined statistically by enumerating the number of times a method call is present in the sampled stack traces. Potential bottlenecks can then be revealed by analyzing the application hotspots. The profiler used was VisualVM [48]. Another profiler, hprof [25, 30], was first evaluated, but we found that it could not link to the EnergyBox process properly because of issues related to the JavaFX framework used by EnergyBox.. 20.

(33) Chapter 4 Automated Energy Profiling This chapter presents the automated energy consumption profiling methodology employed in this thesis. The approach has the following three steps: 1. Capturing network traffic from a phone using TA tests. Network traffic generated during executions of TA tests is captured and saved as packet trace files. 2. Extracting application’s internal state from the system log. In order to map application features and events to traffic observed in packet traces with confidence, the application is instrumented so that additional information about its internal state is written to the system log. The system log is then parsed to extract the state information, which facilitates analysis of traffic patterns from different features and the resulting energy consumption. 3. Calculating the application’s energy consumption. The captured packet traces are fed to EnergyBox, which calculates the application’s energy consumption. Section 4.1 briefly motivates the usefulness of energy TA tests as a way to save time and produce better results with high validity. Thereafter, Section 4.2 describes the methodology for packet trace and system log data collection in more detail, while Section 4.3 considers the limited applicability of preexisting test suites. Section 4.4 and Section 4.5 discuss the methodologies for energy quantification and for attributing energy costs to their root cause. Finally, performance enhancements and other modifications made to EnergyBox to enable its use in this thesis are discussed in Section 4.6.. 4.1. The Utility of Automated Energy Testing. Testing an application from an energy consumption perspective can be very time-consuming because of three important aspects that need to be considered in order to produce results with high validity: timing, diversity and reproducibility. This section briefly explains why these factors are important to demonstrate the utility of energy consumption TA testing. 21.

(34) 4. Automated Energy Profiling. 4.1.1. Timing. An essential determinant of energy consumption is timing, because of the nature of energy consumption (power multiplied by time) and the RRC state machine being controlled by timers. Timing characteristics of tests measuring 3G energy consumption have to emulate the natural passage of time and thus, tests cannot be easily “fast-forwarded”. This property means that energy consumption tests are by necessity relatively slow process, making it suitable for automation.. 4.1.2. Diversity. Complex applications such as Spotify generally have several different submodules that generate network traffic [35]. The application’s behavior may differ somewhat between test runs for reasons hard to pin down due to the application’s complexity. Therefore, capturing traffic from multiple test executions, from which mean energy consumption values can be produced, increase confidence in the results. Of course, the more test executions, the more time-consuming testing becomes and the more useful TA becomes.. 4.1.3. Reproducibility. Reproducibility of TA tests is a major advantage of automating the energy consumption testing. Tests executed programmatically allows the timing of the test script to be followed with more precision than a human operator could manage. Energy consumption is not additive function of traffic: the temporal positions of traffic bursts have a considerable effect on the measured energy consumption, making consistent test executions important. Thus, using TA creates confidence that test executions and the resulting energy profiles are consistent.. 4.2. Capturing Data. This section focuses on the data captured from the application and the method of capture. Packet traces were captured from a phone running automated tests using packet capture software installed on the phone. To attribute traffic from the packet traces to application features and specific lines of code, the application was instrumented to output additional state information to the system log. EnergyBox was used to estimate the energy consumption of the application and causes of energy tails were determined by parsing the instrumented system log output. Section 4.2.1 expands on the traffic capture and Section 4.2.2 discusses instrumentation and considerations related to traffic attribution.. 22.

(35) 4.2. Capturing Data. 4.2.1. Isolating and Capturing Spotify Traffic. As previously discussed in Chapter 3, the energy profiler used in this thesis, EnergyBox, utilizes packet traces to infer RRC states and energy consumption. Monitoring 3G traffic to generate such traces required some extensions to the current testing environment. Hence, the TA framework was extended with the functionality to capture packet traces. Although the Android SDK provides a device emulator 1 we were unable to find any studies validating the accuracy of the provided emulation of 3G connectivity. Therefore, we instead set up a rooted 2 Google Nexus 4 smartphone (referred to as the device), connected to the Internet via a 3G from the mobile network operator Telia Sonera. The use of a physical device on a real 3G network has the benefit of making the system under test more similar to the system in the hands of end-users, which boosts confidence in the validity of the results. Packet capture functionality was accomplished by compiling the packet tracing tool tcpdump [41] and installing it on the device. After installation, the tool could be called from the test driver by connecting to the device shell using ADB and executing the tcpdump command. Tests were run in same location in Stockholm to reduce the variability of the 3G connectivity conditions. In addition to the 3G connection the device was also connected to a local WiFi network, which was used in certain tests to prefetch large amounts of data without counting towards the limited 3G data cap. In such cases, to ensure that the WiFi interface did not interfere with the 3G interface, the WiFi interface was always completely disabled using TA tools before packet capture was initialized. To isolate the traffic from the Spotify application, the firewall application DroidWall 3 was installed on the device to block traffic from other applications. DroidWall utilizes the Linux firewall application iptables [21] to filter traffic. All incoming and outgoing user and system applications were blocked and their packets dropped, except for applications necessary for TA testing the Spotify application: the Spotify application itself, the Linux kernel, the Linux shell and Google Play services. Exceptions for the Linux kernel and the shell were necessary to ensure that the TA framework functioned properly. Google Play services [16] provides APIs for several Google services, such as Ads, which is integrated the Spotify Android application. Thus, to avoid interfering with the application’s traffic patterns, Google Play services were allowed in the firewall. Unfortunately, there is no guarantee that the Google Play services traffic is generated by Spotify and not other Google applications such as Gmail or Google Calendar. To reduce this risk all applications and 1 ”Using. the Emulator”, Android (official website), http://developer.android.com/ tools/devices/emulator.html, April 2015 2 Obtaining superuser access to the Android OS, granting the ability to install custom software and modifying system properties is known as rooting the device. 3 DroidWall (Google Play store page), https://play.google.com/store/apps/ details?id=com.googlecode.droidwall.free, April 2015.. 23.

(36) 4. Automated Energy Profiling. background tasks other than Spotify were terminated and all user-controllable automatic background updates were disabled.. 4.2.2. Method Tracing Through System Log Instrumentation. Drawing conclusions about the traffic patterns of different application features and modules requires a method of tracing the origin of traffic bursts. To implement traffic shaping in the application’s source code, we must first learn which specific methods and lines of code are sources of network accesses. With the Spotify traffic being encrypted and the bulk of the traffic being sent to a single endpoint, the traffic itself provides little information. The encryption masks the contents and the multiplexing masks which backend service individual packets are associated with. Two methods were considered for extracting application state information from the traffic stream: man-in-themiddle (MITM) style attacks and system log instrumentation, with the latter approach ultimately being chosen. Using MITM attacks to intercept and decrypt traffic is one method that could be used to extract information from the traffic. Normally this involves installing a custom Certificate Authority (CA) on the device that allows selfsigned certificates to be accepted by the client. However, the Spotify application employs countermeasures against this type of attack that would require further modification of the client application’s source code. In addition, the task of decoding the packet contents in order to attribute them to specific application features remains. Instead of trying to extract information from decrypted packet traces obtained through MITM attacks we opted to utilize the Android system log as a source of information. Given that the testing is done on a special debug build of the application with supplementary logging enabled, the system log provides a wealth of information about the application state, including information about network accesses and their source. Using this approach, traffic bursts are observed in captured packet traces and their root causes can be identified by inspecting the system log output from times when traffic bursts are observed. The information written to the system log always contains the name of the source file and the line number where the print statement is located, which makes it easier to find it in the millions of lines of source code. A more straightforward runtime method tracing technique than system log inspection is provided by the Android SDK [10]. Collection of method traces can be enabled and disabled from within the application code after which they can be analyzed offline using the Traceview tool [17]. However, this approach of method tracing is only applicable for code running in the JVM environment and not the core parts of the application running native code. Besides, method tracing carries a significant performance penalty, since CPU cycles are allocated to the tracing process, which has a large negative effect on application functionality. Tracing methods in native code (outside the JVM environment) is only possible in an emulated Android environment [10] with an emulated 24.

(37) 4.3. The Case for Additional Test Cases. 3G interface, the accuracy of which has not been verified in previous works to the best of our knowledge. Since the application core is written in C++ and compiled to native code, Android’s default method tracing is insufficient for the purposes of this thesis. Instead of automatic method profiling we use instrumentation of system logs to analyze runtime behavior. The application was already wellinstrumented before this thesis, which facilitated identification of modules and source code areas giving rise to energy-inefficient traffic patterns. The code was also further instrumented to provide more details if necessary. Manual instrumentation of the source code is of course more laborious than automatic method tracing. On the other hand, knowledge of the software structure can assist in targeting specific parts of the application. One such example is a module in the Spotify application that collects network usage statistics and sends it to the AP periodically. When a request is sent to the AP, its request type is noted. Meanwhile, the module keeps track of the total number messages of each type since the last time it reported to the AP. This module was instrumented so that when a request is logged, the request is printed to the system log. With request types and times present in the system log, it is possible to analyze which types of requests contribute toward traffic at different points in time, even though the traffic is encrypted.. 4.3. The Case for Additional Test Cases. The application has a preexisting system TA test suite consisting of both conventional imperative JUnit tests and MBTs (described in Section 3.1.4). In general, the finite state machine making up the MBT have been constructed to be non-deterministically walked through while logging failures and measuring response times. The issue of network energy consumption testing has previously largely been a blind spot. Available tests do not take timing of actions into consideration, which is however, a factor of great importance when it comes to 3G energy consumption. Modifications were made to the MBT test suites to collect traffic and system log data for analysis. As a first step to evaluate the possibility of utilizing MBTs for energy profiling purposes, sources of randomness were removed from the tests by statically setting seeds to the path generation modules. With the same static sequence of ”random” numbers generated, deterministic paths were effectively generated. The usefulness of this method is limited as test coverage becomes limited to a single path in each model. However, it allowed us to quickly make the entire MBT suite deterministic, which made evaluating applicability of utilizing MBTs for energy profiling easier. Most user interactions were found to result in network activity, producing an RRC state distribution heavily skewed towards the DCH state in the MBTs. With many actions being performed in short periods of time, it was difficult to determine clear relationships between specific application features and the resulting traffic at a sufficiently granular level. Furthermore, many MBTs were 25.

(38) 4. Automated Energy Profiling. unsuitable for the purposes of this thesis because they did not consistently pass with the expected behavior. This was caused by either software bugs or outdated test cases which tested functionality no longer present in the application. To provide a clear temporal separation between actions, the MBT suite could have been further modified by, for example, inserting periods of inactivity as part of the MBT graph state transitions. Instead of pursuing this approach further, we selected to create a suite of specialized energy consumption tests. These results are more likely to be useful, given that they can be designed from scratch with 3G energy consumption characteristics in mind. Many of these tests proved useful and are discussed in Chapter 5.. 4.4. Energy Quantification. EnergyBox was used to model the energy consumption and the results were regarded as valid based on the evaluation in the original study [46]. We used the same network configuration parameters as the aforementioned study, which we regard to be acceptable since that study along with this was conducted on Telia Sonera 3G networks in Sweden in 2014 and 2015 respectively. The device power levels of the Google Nexus One (DCH/FACH/IDLE = 600/450/0 mW, see Table 2.1) were chosen to stand in for the Google Nexus 4 we used in our tests. The metric we consider during testing is the mean energy consumption for specific test cases over 20 test executions. Both a previous energy consumption study [5] and a recent bachelor thesis performing energy profiling using EnergyBox [28] use results from 20 manual trials to determine average energy consumption. The automated testing applied in this thesis provides consistent, repeatable test runs compared to manually operated tests. With this in mind, even though the Spotify application has more complex traffic patterns than the applications in the aforementioned studies, we use the same sample size of 20.. 4.5. Attributing Traffic to Root Causes. Instrumented system log data along with captured packet traces were used to guide the attribution of traffic bursts to their root cause in the application source code. The packet traces were fed to EnergyBox to quantify the energy impact of traffic bursts. System log files were used as a form of method tracing, allowing us to identify methods that were called near or during RRC state promotions. The use of this information allowed us to inspect methods and further instrument them in an iterative manner to reach a level of granularity that let us identify specific network accesses as well as what triggered them. Knowledge of the root cause of traffic bursts enabled modification of the source code to produce more efficient traffic patterns. 26.

(39) 4.6. EnergyBox Modifications. To aid in this process, the system log timestamps were synchronized with the packet traces. System logs were then filtered programmatically to include messages within a small period of time surrounding RRC state promotions in an effort to reduce superfluous information from the verbose system logs (unfiltered logs were kept as well). This information supported the attribution of RRC state promotions to specific types of system log messages – which in turn could be ascribed to particular source code lines and thus to application features. When log output from a specific feature is consistently present near RRC state promotions, it implies that the feature is a possible source of traffic bursts causing the state transitions.. 4.6. EnergyBox Modifications. The aim of this section is to describe the changes made to EnergyBox to enable its use in this thesis, to motivate this choice and to evaluate the modifications.. 4.6.1. Motivation. During testing it was found that the use of EnergyBox was hampered by its poor performance when processing large input files. A music track downloaded through Spotify is typically a few megabytes in size, so packet trace file sizes in this order of magnitude were not uncommon in this thesis. For example, a 10 MB packet trace took 47 seconds to process in EnergyBox with memory consumption of the EnergyBox process peaking at 1.7 GB, making effective parallelization of multiple EnergyBox processes infeasible. Furthermore, processing times were found to increase drastically with the input file size, with a 30 MB packet trace taking five minutes to process. During this time, use of the development system for other purposes was impeded due to system resources being allocated to EnergyBox. The EnergyBox codebase was also refactored, reducing coupling between the model and view layers of the application. The benefit is twofold: (1) duplicate code that was previously used for command line interface (CLI) support on OS X is removed and a single model for OS X processing is introduced, and (2) the model and view layers are decoupled, making the CLI mode of the application significantly faster since the (hidden) GUI is no longer updated unnecessarily in CLI mode. We also introduced a common interface for packet trace processing, which is implemented by platform-dependent classes. This simplifies the codebase and allows for the other parts of EnergyBox to be completely platform-agnostic. To summarize, the modifications to EnergyBox had the following three goals: 1. Performance improvement 2. OS X support improvement 3. CLI support improvement. 27.

(40) 4. Automated Energy Profiling. 4.6.2. Identifying Performance Bottlenecks. In order to improve performance, we must first identify areas of the program which has room for such improvements. CPU profiling was used to provide an account of where CPU time was being spent during processing of packet traces. Resulting hotspots (frequently used methods) from a profiling run is shown in Figure 4.1. Several profiling runs were executed, yielding similar hotspots, which verifies that the results were representative of normal program execution.. Figure 4.1: Hotspots in EnergyBox. Figure 4.1 shows that the application spends the 50% of CPU time in the subtree representing the method java.util.AbstractList.add, which is called once for each packet in the input packet trace. Listing 1 shows a stack trace obtained at such a time. The previously mentioned method calls ModifiableObservableListBase.add, since EnergyBox uses lists of this subclass. Adding packets from the input packet trace file to a list data structure, a seemingly simple operation, in this case ends up using 15 of the 18 seconds (84%) it takes to model the RRC states.. 4.6.3. Modifications. A considerable amount of the CPU usage is caused by a custom list data type from the JavaFX framework, ModifiableObservableListBase (MO list) 28.

(41) 4.6. EnergyBox Modifications. Listing 1 EnergyBox stack trace. 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17:. java.lang.Object.hashCode java.util.HashMap.has java.util.HashMap.put java.util.HashSet.add javafx.scene.chart.XYChart$Series$1.onChanged com.sun.javafx.collections.ListListenerHelper $SingleChange.fireValueChangedEvent com.sun.javafx.collections.ListListenerHelper .fireValueChangedEvent javafx.collections.ObservableListBase.fireChange javafx.collections.ListChangeBuilder.commit javafx.collections.ListChangeBuilder.endChange javafx.collections.ObservableListBase.endChange javafx.collections.ModifiableObservableListBase.add java.util.AbstractList.add energybox.engines.Engine.packetChartEntry energybox.engines.Engine3G.modelStates energybox.ConsoleBoxOSX.printResults energybox.EnergyBox.start. [27], which we extended to allow more more efficient append-operations. As the name implies, the class is an implementation of a mutable and observable 4 list. The class is used in the context of JavaFX to allow dynamic updates of GUIs. We observe that the use of the lists storing packets from the input packet trace follow certain access patterns: (1) packets are added serially in the same order as they appear in the input packet trace, and (2) the list is not read from until it has been fully populated. Thus, firing notifications before the list has been populated serves no purpose in EnergyBox. Without interfering the functionality we could limit the number of notifications to a single one, sent after the list has been populated down from one per packet. Note that triggering the update notification at least once is necessary for the GUI to properly show the results. Reducing the number of times the observers of the MO list are notified leads to fewer method calls and a shorter call stack every time an item is added to the list (lines 1-11 in listing 1 are called from the MO list add method). To achieve this we implement a new subclass of the MO list, extending it with the desired notification functionality. We name this new class FastModifiableObservableList (FMO list) and use it over the original MO list in EnergyBox to speed up additions to the list. The FMO list has one major difference to the MO list: instead of being triggered automatically by list modification notifications, the observer notifications need to be triggered manually. Since the FMO list implements the interface of the MO list (with some extensions), in can be used in JavaFX and EnergyBox where the MO list is expected. The only functional modifications necessary is the manual firing of the observer 4. In the Observer design pattern, a subject maintains a list of its observers. When the state of the subject changes, it triggers an event that notifies its observers of the new state. The subject is said to be observable. [14]. 29.

No results found