Meeting Lifetime Goals with Energy Levels

1
Meeting Lifetime Goals with Energy Levels

• A. Lachenmann, P. J. Marron, D. Minder, and K.
  Rothermer.
• In Proc. of the 5th ACM Conference on Embedded
  Networked Sensor Systems (SenSys), 2007.
• Reporter ???

2
1. Motivation

• Traditional sensor network research
• - try to maximize network lifetime
• - single node failure can partition the network
  and thus render large parts of network useless
• Case For some applications that
• - the required lifetime is known in advance
• - no redundant nodes in their topologies
• Solution Levels can achieve that
• - every single node stays alive for a
  user-defined lifetime
• (preserve network connectivity)
• - the application provides the best quality

3
2. Overall introduction of Levels (1/2)

• a programming abstraction (energy level) for
  energy-aware sensor network applications
• meeting user-defined lifetime goals (running time
  is fixed) while maximizing application quality
• Is targeted to applications where there is no
  redundancy and no node should fail early

4
2. Overall introduction of Levels (2/2)

• Specify optional functionality in energy levels
• System decides which level is active
• Only code in active levels is executed
• Similar to model-predictive control schemes
• Profiling energy consumption of optional code
• Battery model that maps voltage to remaining
  energy
• Monitor consumed energy at runtime
• Periodically optimize level assignment for
  remaining energy

5
3.1 Energy Levels

• Energy level contains all statements that can be
  deactivated together
• Optional code for providing basic functionality
• Placed in conditional statement
• Levels form a stack where levels can be
  deactivated from top
• Level l0 always active
• If level li is active, all levels below are
  active
• Each level is associated with utility value ui
• Wiring of levels fits modular development in
  component-oriented language like nesC

6
3.2 Code Example
module Component1 provides energylevel
SenseLevellt1gt provides energylevel
ComputeLevellt2gt ... implementation ...
event TOS_MsgPtr ReceiveMsg.receive(...) if
(ComputeLevel.active) post
computeTask() return msg event
result_t Timer.fired() if
(SenseLevel.active) call
SensorADC.getData() return SUCCESS
command void SenseLevel.activate() call
SensorControl.start() command void
SenseLevel.deactivate() call
SensorControl.stop() ...

• Energy levels provided and wired like interfaces
• Declaration specifies order of levels
• if statement to place code into energy level
• Activate/deactivate commands
• Summary
• Only small changes to nesC
• Low overhead for developer

7
3.3 Energy Profiling (1/2)

• Using simulators like Avrora already include
  energy models
• Tagging an _at_energy attribute to tell build
  system which functions should be measured energy
  consumption

8
3.3 Energy Profiling (2/2)

• Two kinds of energy consumption
• - energy that is consumed once (i.e., when the
  code is executed)
• - energy that is consumed continuously (i.e.,
  by changing the state of a hardware device)

Computing the energy consumption of a code block
9
3.4 Battery Model

• Maps voltage to remaining energy
• Model creation
• Using application to drain batteries and record
  voltage readings
• Computed available capacity from total execution
  time
• Store for each voltage reading average energy
  left and expected accuracy

Energy
10
3.5 Monitoring Energy Consumption in Energy Levels

• In each optional code block
• Add one-time energy consumption for level
• Change in continuous energy consumption for level
• Periodically, every few seconds
• Compute continuously consumed energy in interval
• Periodically, every few hours
• Compute optimal level assignment to reach
  lifetime

Accumulating the energy consumed by a level
11
3.6 Adjustment of Active Energy Levels

• Maximize average utility of energy levels
• Linear programming problem
• Uses fixed-point implementation of Simplex
  algorithm
• Periodically executed every few hours
• React to changes in energy consumption
• Small inaccuracies will be balanced in later
  periods

12
4. Novelty

• Levels, a novel abstraction for energy-aware
  programming of sensor network that allows the
  developer to explicitly single out optional
  functionality

13
5. Strength

• A flexible and easy-to-use programming
  abstraction
• Low overhead for developers
• Preserving the network connectivity and providing
  the best quality

14
6. Weakness

• Levels might not be able to meet the lifetime
  goal in all cases if the nodes load differs
  significantly over time

15
Thank you
16
Appendix-Simplex method