- Little Rock introduces a new low-power co-processor module integrated into phones to offload continuous sensor tasks, allowing the main processor to sleep more. This improves battery life while providing continuous sensing functionality. - METIS explores opportunistically offloading phone sensing to fixed sensors embedded in the environment. An exploratory deployment found this can reduce energy costs on phones in certain conditions compared to local sensing alone. - KOBE is a tool that aids developing mobile classifiers to optimize the energy-latency-accuracy tradeoff. It profiles and optimizes classifiers via a SQL-like interface and adaptive runtime to identify optimal configurations for different environments and resource constraints.

1. REDUCING ENERGY CONSUMPTION
IN COMPUTING
Nguyen Van Luong!
MSc: SAI Telecom Sudparis
Oct 2013

2. Outline
•
Motivation
•
Little Rock
•
METIS
•
Balancing Energy, Latency
and Accuracy
•
Conclusion

3. Motivation
Feature phone
Smartphone

4. Motivation
http://www.gizmodo.co.uk

5. Motivation
Low battery!!!!
GPS cannot enable!!!!
Low battery!!!!
Cannot make phone call!!!!
Emergency !!!!!

6. Motivation
Low battery!!!!
Cannot make phone call, use camera either enable GPS!!!!

7. Motivation
I want more………..!!!!!!!

8. HOW???
External smartphone battery charger
New lithium-ion battery design
2,000 times more powerful,
recharges 1,000 times faster
Reducing energy consumption of computing

9. Little Rock
Bodhi Priyantha, Dimitrios Lymberopoulos, and Jie Liu
Networked Embedded Computing Group
Microsoft Research
Redmond, WA

10. Little Rock
I have to manage sensors !
I cannot even sleep!!!!!
I need more energy to work!!!!

11. Little Rock
Changing a voltage power supply input
according to the system/user needs
An separate sensing module that employs its own sensors,
processor and a wireless radio for interfacing to the phone

12. Little Rock
Build a small, energy efficient co-processor into the phone and
offloading continuous sensing task to the small processor
[10, 14] uses a bluetooth radio to interface a powerful
sensor board to the phone. This approach is ideal when
the sensor has to be placed on a specific location due to
Challenging: properties. For example, EKG sensors have to
physical
be attached to human
• Low power operation body. On the other hand, continuous bluetooth communication can be energy consum• Minimum impact on other still needs to of the often
ing, and the main processor aspects wake up
phone to exchange bluetooth packets. In addition, the user has
design
to manage, carry and charge multiple devices which can
• The ability to configure and reprogram the
be cumbersome.
sensing In this paper, we explore the direction of building a
architecture
small, energy e cient co-processor into the phone, and
o✏oading continuous sensing tasks to the small processor. All the available sensors on the phone are connected to the small processor enabling the phone to
transition to sleep mode while the co-processor is continuously acquiring and processing sensor data at a low
power overhead. Since the two processors are tightly
integrated, data between them can be exchanged fast
and on demand because the small processor can wake
up the main processor at any time and the main processor can request access to sensor data acquired by the
small processor whenever it needs to.
Designing such an architecture is challenging in sev-
(a)
(b)
Figure 1: (a) The Little Rock sensing platform
(b) The Little Rock board attached to one of our
prototyping smartphones.
approaches while not significantly shortening phone’s

13. Little Rock
•
•
•
•
Transparency!
Power independence!
Interrupt!
Re-purposing

14. Little Rock

15. Little Rock

16. Little Rock

17. Little Rock

18. Little Rock
Phone Interface!
• Directly Accessing sensors
• Phone <-SPI-> MSP430 <-I2C-> sensor
• Phone Software API
• IO control interface for accessing Little
Rock from user application on the phone
• Reprogramming support
• Use a secondary MSP430 processor
• Built in BSL routines of the main
processor

19. Little Rock - Evaluation
Pedometer Application: A Case Study

20. Little Rock - Evaluation
Pedometer Application: A Case Study

21. Little Rock - Evaluation
Pedometer Application: A Case Study

22. METIS
Kiran K. Rachuri†, Christos Efstratiou†, Ilias Leontiadis†, Cecilia Mascolo†, Peter J. Rentfrow‡
†Computer Laboratory, ‡Department of Psychology, University of Cambridge, UK

23. METIS
Opportunistically offloading sensing to fixed
sensors embedded in the environment
•
•
Local sensing
Light sensor

24. METIS
Sensing offloading
built on the vision of mobile phone users living in an environment
instrumented with a range of sensors that can be accessed over the
internet. Within such environment certain pieces of information can
potentially be sensed through either the user’s mobile device or a
sensor that is embedded in the environment

25. METIS
Exploratory deployment
• The primary objective : identify the conditions under
• which offloading could reduce the energy cost on the mobile device
• those where offloading would lead to higher energy consumption
than local sensing
• Two key sensing modalities:
• location/co-location sensing
• conversation detection
• 10 participants
• 10 offices instrumented with sensors
• lasted one week
• Benchmarks
• Never Offload
• Always Offload

26. METIS
Benchmarks result

27. METIS
Benchmarks result

28. METIS

29. METIS
Sensing Offloading
• Gain threshold based offloading
• Gain Time Threshold
• Probability of Gain Estimation

30. METIS
Benchmark

31. METIS
Benchmark

32. Balancing energy, latency and accuracy
Microsoft Research and National Taiwan University

33. KOBE
•
Data application classification
• Classify the sensor data according to application
• Statistical Machine Learning (SML)
• Not for mobile
• Not built for the challenges of mobile systems:
energy, latency, and the dynamics of mobile.
Kobe is a tool that aids mobile classifier
development. With the help of a SQL-like
programming interface, Kobe performs profiling and
optimization of classifiers to achieve an optimal
energy-latency-accuracy tradeoff

34. KOBE
• a SML classifier programming interface, classifier optimizer,
and adaptive runtime for mobile
• Addresses three challenges:
• Kobe identifies configurations that offer the best accuracy to
cost trade off
• Classifier-specific parameter
• Classifier partitioning
• Leverages the optimisation techniques described above and
identifies configuration under a range of different
environments as characterised by network band-width and
latency, processor load, device and user
• provides a SQL-like interface to ease development and
decouple application logic from SML algorithms.

35. KOBE - Some mobile classifiers
•Sound classification (SC)
•Image Recognition (IR)
•Motion Classification

36. KOBE - Limitation of Existing
Solutions
•Energy and Latency
•Adaptivity
•Tight Coupling

37. KOBE - A brief system overview

38. KOBE - The Kope programming
interface
• App Developer Interface. App developers construct classifiers with
the CLASSIFIER keyword.
• MyC = CLASSIFIER ( TRAINING DATA , CONSTRAINTS ,PROTOTYPE
PIPELINE)
• The SQL-like interface naturally supports standard SQL operations
and composition of multiple pipelines

39. KOBE - System architecture
•Cost modelling
•Searching
•Runtime Adaptation and
Cloud Offloading
•Query optimizer
•Personalizer

40. KOBE - Evaluation
•Methodology
•Balancing Accuracy, Energy and Latency
•Adapting to changes
•Programming Interface benefits
•Scalability and overhead

41. Conclusion

42. Conclusion!
•
Little Rock:!
•
•
METIS:!
•
•
Introduce a new module in to the phone architecture which can offload the
interactions with sensors and give the phone’s main processor and associated
circuitry more time to go to the sleep mode!
a sensing platform that implements a novel adaptive sensing distribution scheme
that automatically distributes the sensing tasks between the local phone and sensing
infrastructure sensors in order to support accurate continuous sensing of social
activities!
KOPE!
• ability to tune classifiers to different latency and energy budgets proved quite useful!
• currently only supports three stage linear classifiers!
• supports only one sensor input at the sensor sample stage