Mobile Sensing II Energy-Efficiency Petteri Nurmi Spring 2015

Transkriptio

1 Mobile Sensing II Energy-Efficiency Petteri Nurmi Spring

2 Learning Objectives Understanding the most important resource constraints and how they affect continuous sensing Learn different mechanisms for energy-efficiency and be able to relate them to different parts of the sensing cycle Learn the most common ways to assess the energy impact of sensing applications and understand their advantages and disadvantages

3 Continuous and Sustained Sensing Most mobile sensing applications these days operate in a continuous (and sustained) mode I.e., sensor data continually collected and analyzed Resource-efficiency a critical constraint High CPU or I/O load can hinder other applications Sensors drain battery, forcing users to charge the phone more often Usability concerns Consistency of the application performance Accuracy (etc.) of the classification results, particularly when the user interface is adapted based on them Focus of lecture on resource-efficiency (esp. energy)

4 Resource (and other) Constraints Energy / Battery Sensors consume high amounts of battery è sensing applications rapidly lead to poor user experience Memory & CPU Analysis of massive datasets not possible on mobile devices due to memory constraints CPUs increasingly powerful, but drain battery Programming constraints Limits on how sensors can be operated, limits on what is allowable behaviour Interaction constraints Limited means for conventional interaction techniques (text input, graphics)

5 Mechanisms for Energy- Efficiency General principle: less is more Sensor-level schemes Duty cycling: less sensing Substitution / replacement: less power heavy sensing Personal area network (PAN) schemes: Offloading: less computing/sensing on the device Cooperation: less sensing on one device Hardware and Networking schemes: Frequency/voltage scaling: less heavy CPU Coprocessor: cooperative CPU Intelligent uploading: less sending

6 Energy-Efficiency Revisited: Part I: Reducing Tasks CPU and other hardware components Sensors Networking

7 Duty Cycling Duty cycling reduces sampling by alternating between idle and active states of the sensor Duty cycle = percentage of period where a signal is active D = T / P * 100% where T is active time and P is the period of the signal Sampling sensor for one minute each five minutes thus corresponds to a 20% duty cycle Need to be carefully designed Going from lower sampling state to higher typically has an additional activation cost Moving from a high state to a lower state often has delay è need sufficiently long inactive states to save energy

8 Duty Cycling Example Motion Tracking Duty cycling schemes can be rather sophisticated Example: GPS duty cycling for location reporting Assume location needs to be reported every 100m Given current speed of user v m/s (from last GPS), the next time GPS needs to be sampled (latest) is 100 / v Can also incorporate errors, e.g., if GPS error is E m, the next sample should be within (100 E) / v Similar approach can be adopted for other motionrelated sensors (accelerometer, gyroscope, magnetometer)

9 Sensor Substitution / Replacement Often multiple sensors can be used to measure the same phenomena WiFi/GPS/GSM all provide location information Accelerometer and GPS can be used to estimate speed Energy-accuracy trade-off The more accurate information is required, the more energy heavy sensor (usually) needs to be used Sensor substitution/replacement a generic technique whereby a sensor is replaced with another (less power hungry) one

10 Active / Inactive State Detection Users tend to spend the majority of times within few locations ( 50+% of time at either home or work) During these periods users mainly stationary è can let sensors sleep until something happens Activity spotting: determine if any activity (of interest) is taking place Most common strategy is to consider the variance of accelerometer magnitude Another example is monitoring the stability of WiFi / audio environment Special case of sensor substitution

11 Active / Inactive State Detection: Example Example data from a walking segment Blue line: accelerometer magnitude, i.e., i x i Stationary periods clearly distinguishable as periods of low variance

12 Intelligent Uploading Duty cycling network transmissions Reduce frequency of data transmissions from the mobile client Basic uploading strategies Send all (only realistic for on-demand sensing with low sampling rates) Event-based: e.g., send information when transportation mode changes Persistent even change: ignore fragmentations in classification and send only once the majority of events in a window differ from current one

13 Intelligent Uploading: Examples Intelligent event-based uploading strategies popular in moving objects database literature Position tracking: Send updates only when location changes by more than a given threshold (event = location change) Buddy/proximity tracking: Send updates when a friend arrives/leaves a region that is within x meters from my current location Trajectory tracking: Send updates when the route of the user cannot be reconstructed with given accuracy otherwise Sensor sampling takes place more often, but only some measurements transmitted

14 Piggybacking and Tail Energy Piggybacking refers to transporting something on the back of something else Data piggybacking: attaching data transmissions to application-side traffic (opportunistic transmission) Sensing piggybacking: hook to application sensor data requests and pool data across all applications Tail energy minimization Cellular transmission technologies remain in high energy active state after transmission ends Tail energy minimization aims at scheduling transmissions so that low-power time can be maximized

15 Predictive Energy-Efficiency General technique for reducing energy load by predicting what is going to happen Predictive uploading Construct a predictive model and deploy on both client and server / cloud service end Predict the next state/event on the client, and compare results against prediction If agreement, no need to send data (server predicts the same) Predictive sensing Predict next state/sensor values on client Compare prediction against values If prediction matches consistently, sensor can be duty cycled

16 Energy Consumption Statistics: Hardware and Networking CPU has highest correlation with energy usage Screen brightness has major overall impact, but correlated heavily with CPU usage Networking technologies have different power profiles, but generally signal strength quality influences power consumption Sensor level energy-consumption covered later during the lecture

17 Hardware Solutions: Dynamic Voltage and Frequency Scaling (DVFS) CPU one of the most power consuming elements on the mobile device DVFS a hardware level technique for reducing the power drain caused by CPU CPU power consumption: P cpu = P dynamic + P static P static corresponds to transistor current leakages and shortcircuit power consumption P dynamic = CV 2 f where C is capacitance, f is frequency and V is voltage Thus, reducing CPU frequency or voltage reduces overall power drain

18 Hardware Solutions: Coprocessor designs Most high-end smartphones incorporate a coprocessor design Coprocessors additional CPUs which are typically dedicated for a specific task (e.g., motion coprocessor) Low-power so reduces energy footprint Types of coprocessors Graphical (GPU) Audio (especially speech recognition) Motion/Context (specialized activity recognition tasks)

19 Energy-Efficiency Revisited: Part II: Distributing Tasks Cloud Services Nearby devices CPU and other hardware components Sensors Servers Networking

20 Cyber foraging Technique where computationally heavy tasks are offloaded to surrogate computers in the vicinity Proposed in 2001 when CPU resources VERY limited Phases: 1. Surrogate discovery 2. Resource discovery (how much CPU or I/O available) 3. Task partitioning: dividing the original computational task into subcomponents 4. Scheduling: allocating tasks to surrogates and the mobile device 5. Remote execution control: verifying the connection links remain alive and that the tasks are executed

21 Offloading Offloading refers to the general principle of transferring tasks to other devices In principle, ANY part of the sensing chain can be transferred to other devices: Computational offloading: transferring computations to other devices, including remote devices / cloud Cyber foraging a special case where only nearby stationary computers are considered Cooperative/collaborative sensing: transferring sensing tasks to other devices Network offloading: transferring data transmission to other devices or technologies Also, e.g., UI or interaction layers can be offloaded

22 Collaborative Sensing Consider the task of transportation mode detection using accelerometer and GPS GPS energy consuming and has accuracy of around 5m è nearby devices can share measurements Accelerometer has high sampling rate, high cost to share è devices sample locally Need to always ensure utility from collaboration higher than cost of sharing

23 Discovery The first phase of offloading typically consists of discovering potential collaborators Exception when dedicated collaborators used, e.g., a specific server/cloud service Primary technologies: Bluetooth low energy (BLE) WiFi direct Network topology usually restricted by the technology: Star topology: one master and several slaves (unicast) Fully connected: each device communicates with each other (broadcast)

24 Scheduling Process of allocating sensing tasks to devices Factors to consider: Collaboration cost: energy consumption from sharing information (sensor data, classifier results, etc.) Sensing cost: energy consumption from performing sensing on the device Accuracy: quality of sensor information (should not select GPS with poor accuracy in the example) Utility: some sensors might not be needed, does adding them provide significant benefits compared to their cost? Cost of ONE device allowed to be higher, but overall cost for all devices participating should be lower

25 Example: CoMon Middleware solution for collaborative sensing Applications represent sensing needs as declarative queries, middleware executes queries locally on the device or distributes them if collaborators found Bluetooth based collaborator discovery Devices optimize expected benefit Expected Benefit = UTILITY x E(T 2 ) COST DETECT x E(T 1 ) E(T 2 ) is expected duration of cooperation E(T 1 ) is expected waiting time until cooperation opportunity COST DETECT is (constant) cost of discovering collaborators è Collaboration opportunities more actively the higher the cost of sensing and the more likely opportunities exist

26 Example: Remora Middleware for collaborative sensing Neighbour management Potential collaborators detected using proximity sensing Duration prediction: the length of collaboration opportunity predicted by considering type of contact, current activity, and calendar information Sharing-aware classifier design Weak classifiers at each device and shares the classifier results (instead of sharing sensor data) Each weak classifier considers single sensor Classifiers combined to obtain final result

27 Evaluating Energy Efficiency Estimating the overall battery drain of an application crucial for continuous sensing applications Two main ways to accomplish this: Install application on devices and see how it influences battery recharging cycles of users Difficult to conduct, but gives the absolute effect Model-based validation: estimate power consumption using models of sensor/hardware energy consumption Allows relative comparison of applications, but does not give absolute effect

28 Evaluating Energy Efficiency: Metrics and Units 1. Temporal Absolute/relative influence on charging time (hours or percentage decreases) 2. Power unit measures Milliwatts (mw), unit of power drain per second Millijoules (mj), specific power drain, e.g., the cost of turning GPS on (watts over time) 3. Discharge Rate State of charge (SOC): the percentage of battery remaining Discharge rate = ΔSOC / Δt (typically at one percent increments)

29 Energy Profiling Energy profile refers to a mathematical characterization of power consumption, i.e., a model-based approach Basic idea: 1. Construct a reference model that estimates power consumption of sensor/hardware unit within unit time Typically separate different states, e.g., CPU level as percentage or idle/active/turning on/turning off for sensors 2. Calculate the time the hardware/sensor is in different states during the execution of application Readily supported by mobile platforms 3. Estimate power consumption by multiplying the time spent in a state with estimated power consumption 4. Sum over all sensors/hardware components

30 Energy Profiling: Reference Models Different ways to construct the reference model 1. Manufacturer provided values: Typically minimum and maximum, values for other states interpolated 2. Empirical models 1. Sensor-level models Using sensor X for t seconds consumes P amount of power (on average) 2. Aggregate models Using application Y for t seconds consumes R amount of power (on average)

31 Energy Profiling: Sensor-Level Empirical Models Three steps in constructing a sensor-level model: 1. Isolate the sensor and utilize it in different states 2. Estimate energy consumed in each state 3. Divide energy by time to obtain reference model Typically a separate background model that contains no sensors is first estimated and subtracted States not necessarily easy to define Mobile data has tail whereby the radio remains for a while in active state even without any transmission GPS has different start-up costs depending on how long the sensor has been inactive

32 Example Consider constructing a power model for gyroscope 1. Ensure phone is not collected to any power source 2. Implement a program that samples the gyroscope (potentially at different rates) 3. Isolate the sensor Turn screen off Turn of radio sensors or even switch to airplane mode Use wake lock to prevent system from suspending If possible, control CPU speed 4. Run program several times, measure power drain, and estimate power consumption

33 Power Monitor Modelling Power monitor is a tool that measures power drain Phone battery linked with cables to monitor, logs drain directly Most accurate way to construct reference models But also most cumbersome, and limited in terms of situations where measurements can be taken

34 Power Monitor Modelling: Practical Issues Controlling signal strength levels difficult, especially low signal levels difficult to emulate Requires a Faraday box, bomb shelter, or other means of isolation Most sensors (and hardware components) have strong relationship with CPU Power consumptions seldom independent, e.g., gyroscope and accelerometer often on same chip The more variation in the states of the sensor, the more difficult to estimate power consumption E.g., CPU consumption highly volatile

35 Application Level Profiling Smartphones have a smart battery interface which provides information about battery level Responsible for analysing voltage, temperature etc. and determining currently remaining battery level State of charge (SOC): Percentage of battery currently remaining Discharge rate: change of SOC as a function of time, i.e., rate = ΔSOC / Δt Application level profiling operates on SOC measurements Observe which sensors / applications running and monitor changes in the SOC values

36 Example: PowerTutor Source: u/projects/powertutor/ (Semi-)automatic tool for power model construction directly on the phone Discharge rate used as energy unit Battery-specific lookup table for converting discharge values into voltages Constructed by discharging the phone once with constant rate and logging the results Energy modelled using regression Linear relationship between different states of the system and energy (P = i ß i U i + c)

37 Example: Carat Source: Crowdsourced-based energy modelling approach Original focus on applications, but similar methodology can be used to construct sensor-level models Discharge rates used as energy unit Each device represented by a discharge profile Looks at applications running on the device and how they affect discharge Device-specific profile compared against community average Profiles with higher discharge rates have problems, and potential applications causing the problem can be identified from the discharge profiles

38 Energy Profiles: Accelerometer Energy profile of accelerometer indicates more or less constant power drain Spikes on the background most likely due to CPU and I/O Low overall consumption Around 21mW on Galaxy SIII Note: measurements contain also background consumption General rule of thumb: can be used, and device tends to sample regularly anyway

39 Energy Profiles: GPS Only contains cost from sampling the GPS (10 times) Heavy cost from turning on the GPS and/or from searching for a position fix when no satellites visible HUGE variations in energy consumption across devices General rule of thumb: avoid as much as can (for energy)

40 Energy Profiles: WiFi Contains samples from scanning the WiFi 100 times Cost of scanning high, but more or less constant Sending data over WiFi difficult to model, depends on signal quality (bad signal è more retransmissions), amount of data sent etc. Sensitivity of WiFi chips varies across devices è unpredictable energy costs General rule of thumb: use cautiously

41 Energy Profiles: Audio Contains samples from continuous audio recording Cost of collecting one sample average, but costs accumulate quickly due to high sampling rate Processing data requires heavy CPU and I/O è high variation General rule of thumb: do not use continuously and use otherwise cautiously

42 Summary Energy significant problem for continuous sensing applications and need to be optimized Main categories of mechanisms: Reduction: sensor substitution, duty cycling, power optimization, intelligent uploading Task distribution: cyber foraging, cooperative sensing Energy-efficiency evaluated using energy profiling Power monitor based empirical models Empirical models constructed from SOC / discharge rate measurements

43 References Bhattacharya, S.; Blunck, H.; Kjergaard, M. & Nurmi, P., Robust and Energy-Efficient Trajectory Tracking for Mobile Devices, IEEE Transactions on Mobile Computing, 2015 Kim, D. H.; Kim, Y.; Estrin, D. & Srivastava, M. B., SensLoc: sensing everyday places and paths using less energy, Proceedings of the 8th ACM Conference on Embedded Networked Sensor Systems (SenSys), ACM, 2010, Lee, Y.; Ju, Y.; Min, C.; Kang, S.; Hwang, I. & Song, J., CoMon: Cooperative Ambience Monitoring Platform with Continuity and Benefit Awareness, Proceedings of the 10th International Conference on Mobile Systems, Applications, and Services (MobiSys), ACM, 2012, Keally, M.; Zhou, G.; Xing, G. & Wu, J., Remora: Sensing Resource Sharing Among Smartphone-based Body Sensor Networks, Proc. of 21st International IEEE/ACM Symposium on Quality of Service, 2013, 1-10 Musolesi, M.; Piraccini, M.; Fodor, K.; Corradi, A. & Campbell, A. T., Supporting Energy-Efficient Uploading Strategies for Continuous Sensing Applications on Mobile Phones, Proceedings of the International Conference on Pervasive Computing (Pervasive), 2010, Balan, R. K.; Flinn, J.; Satyanarayanan, M.; Sinnamohideen, S. & Yang, H., The case for cyber foraging, Proceedings of the 10th ACM SIGOPS European Workshop,

44 References Ferreira, D.; Dey, A. K. & Kostakos, V., Understanding Human-Smartphone Concerns: A Study of Battery Life, Proceedings of the 9th International Conference on Pervasive Computing, 2011 Banerjee, A.; Chong, L. K.; Chattopadhyay, S. & Roychoudhury, A., Detecting Energy Bugs and Hotspots in Mobile Apps, Proceedings of the 22Nd ACM SIGSOFT International Symposium on Foundations of Software Engineering, ACM, 2014, Zhang, L.; Tiwana, B.; Qian, Z.; Wang, Z.; Dick, R. P.; Mao, Z. M. & Yang, L., Accurate Online Power Estimation and Automatic Battery Behavior Based Power Model Generation for Smartphones, Proceedings of the Eighth IEEE/ACM/IFIP International Conference on Hardware/Software Codesign and System Synthesis, ACM, 2010, Oliner, A. J.; Iyer, A. P.; Stoica, I.; Lagerspetz, E. & Tarkoma, S., Carat: Collaborative Energy Diagnosis for Mobile Devices, Proceedings of the 11th ACM Conference on Embedded Networked Sensor Systems (SenSys), ACM, 2013, 10:1-10:14 Kjærgaard, M. B. & Blunck, H., Unsupervised Power Profiling for Mobile Devices, Proceedings of the 8th Annual International Conference on Mobile and Ubiquitous Systems: Computing, Networking and Services (Mobiquitous),