Environmental Energy Management in Pervasive Computers - PowerPoint PPT Presentation

environmental energy management in pervasive computers n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Environmental Energy Management in Pervasive Computers PowerPoint Presentation
Download Presentation
Environmental Energy Management in Pervasive Computers

play fullscreen
1 / 28
Environmental Energy Management in Pervasive Computers
68 Views
Download Presentation
feleti
Download Presentation

Environmental Energy Management in Pervasive Computers

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Environmental Energy Management in Pervasive Computers Aman Kansal, John Curnutte, Gautam Kachroo CS 218, Prof Mario Gerla

  2. What are sensor networks? • Networks of numerous deeply embedded devices which sense (and control) the environment • Wireless, low energy, low datarate, autonomous Berkeley’s deployment at Great Duck Island NESL, UCLA’s localization array UCLA’s seismic array (under construction) At Huntington Botanical Gardens

  3. Energy Scarcity • Batteries are too big • Batteries don’t last forever • Methods exist to extract energy from the environment • Solar • Vibrational • Wind • biochemical Smart Dust, Berkeley Prototypes from IASL, UWE, Bristol.

  4. Environmental Energy is Different from Battery Energy • Supply varies with time • Need to adapt performance • Supply varies in space • Different nodes get different energy • Supply is repetitive (does not die out) • Opportunity to last forever

  5. The Problem • Observation: Performance depends on how efficiently the available resources are used • Question: How can the networking performance be adapted to the spatio-temporal characteristics of the energy availability? • Make the network last forever (until the hardware is outdated/damaged) • Scheduling: Who does more work

  6. OUTLINE Hardware Implementation • Theoretical Framework • What performance can be supported eternally? • Algorithm Design • How to achieve it within practical • constraints of sensor networks?

  7. Source Characterization • Leaky bucket like model: Apart from maximum flow, add a constraint for minimum flow too. • Definition: E(t) is a (r-s1-s2) source if for all T:

  8. Harvesting Theory THEOREM 1: If • a system is powered by a (r,s1,s2) source • has energy storage capacity >= (s1+s2) • operates at constant power level r then itutilizes the energy source fully can survive forever. • Larger battery gives no performance gain • At least r rate of energy consumption can be supported

  9. Proof Outline Proof follows by contradiction • Maximum energy we can use = everything provided by environment • Maximum r = average rate of energy • No energy from the environment is wasted: ensured by first condition • Assume Initialization phase during which battery charged to s2 • Consider the first instant when some small energy DE overflows (in time Dt), then E(Dt) = rDt + DE • Consider the preceding time duration t in which the battery had filled up s1 capacity: E(t) = rt + s1 • Then E(t+Dt) = rt + s1 +rDt + DE > r(t + Dt) + s1 which is a contradiction • Similarly using other condition can prove that r can always be supported

  10. Not Operating at Constant Power • Assume a leaky bucket consumer (r’,s) • No constraint on minimum energy usage • Theorem 2: If a (r’,s) consumer powered by (r-s1-s2) source, has battery size s+s1+s2, it can survive eternally s1+s2 Overflow: Energy Wasted s Workload Energy Consumption Sensor Node

  11. Scheduling Issues • Need to determine s1,s2,r, r’, s from measured energy availability and load • Can then provide estimate of feasible performance region • Each node knows only its own energy and a distributed scheduler is desired

  12. Algorithm Design • Estimate the r,s1,s2 parameters of the source • r estimated by a running average until difference between recent maxima and minima is within an acceptable margin • Works for a cyclic source (such as the sun) • Can estimate s1,s2 by locating largest underflow and overflow • Done only at design time to estimate required battery size

  13. Performance Control • Several options: sleep, Dynamic Voltage Scaling, radio range control etc. • Sleep Duty Cycle • Chosen as supported by most hardware • radio range does not affect mote radio power consumption significantly Sensor Event Detected Sensor Node Sleep Timer Timer Expired SNOOZE: Processor and Radio sleeping

  14. Communication in the presence of Sleep • Node can wake up if it has data to send • How does a sleeping node receive data? • No time synchronization required between nodes Wait for ACK Beacon ACK received Transmitter DATA Data generated Beacon Heard Wake to listen for Beacon Receiver Sleep

  15. Optimal Routing for Maximum Lifetime is Impractical Optimal routing can be formulated as a linear programming problem • Needs complete information of traffic flow • Needs global knowledge of routes • Needs global knowledge of energy characteristics at each node

  16. Networking Method: Practical Design • Routing Algorithm for a event monitoring sensor network • Single Sink (base station) Multiple Sources (nodes with events) • Base station sends INIT Receiver sends ACK and forwards INIT • Nodes measure energy and calculate latency

  17. Networking Method: Practical Design • Path latencies important in sleepy network • But sending all latencies to base station reduces scalability • In-network processing to compute path latency • Receive path latencies from children • Forward highest plus own latency

  18. Pseudo-code • Initialize parameters Tsleep = 0, childset = empty, childlatencylist = empty, parent = UNK, is_leaf = FALSE • Spawn thread to estimate L. Generates Lestimated event when finished. • If received INIT message If parent == UNK parent = sender-id from INIT message Send ACK Rebroadcast INIT message with own ID Start ACK timer • If received ACK message childset = childset U sender-id from ACK Delete ACK wait timer • If ACK wait timer expires, set is_leaf = TRUE • If Lestimated event received If is_leaf == TRUE send LATENCY message to parent Adjust Tsleep and duty cycle for this L Else If childlatencylist is complete Calculate L and send LATENCY message Adjust duty cycle and Tsleep Else wait for childlatencylist to complete • If received LATENCY message store latency value in childlatencylist

  19. Simulation Study • Network spread in an outdoor environment with 50 nodes • Solar data • Real data was collected with a single node for 9 days. • Generated random data distributed uniformly around this, nodes assume to receive this energy • Latency performance of our protocol (fully distributed) compared to lowest latency route • Lowest Latency Route: found using Bellman-Ford algorithm (link latency used as cost) • high message overhead

  20. Simulation Study LATENCY of a randomly deployed network Frequency (%) Latency (s) Frequency (%) Latency (s)

  21. Distributed Routing Optimal Routing Worst Case Path Latency (s) Simulation Study Results averaged over 20 random topologies Node Density

  22. Customized node and sensor board Interfaces MK-2 Mica 2 Generic Implementation Battery Chemistry Specific Charging circuitry POWER Mote sized Solar Cells Voltage Level Convertor Environmental and Battery Energy Monitoring ENERGY DATA Heliomote (NESL, UCLA): Harvesting hardware added to Berkeley mote for energy harvesting

  23. Implementation • Our network uses uses available Heliomotes and some standard motes • TinyOS Device Drivers for new harvestor hardware provide simple user interface: • async command result_t getData() • async event result_t dataReady

  24. Measured Data: Single Node E(t) r(t) Intensity Time (10 minute resolution) • Using the solar data collected for 9 days using heliomote and the mote consumption characteristics: • = 23.6mW s1 = 1.463 MJ s2 = 1.856 MJ s = 153 J According to Theorem 2: battery required is only • +s1 + s2 = 3.32 MJ = 922.43mAh at 3V (about 1/2 of AA, could use smaller AAA battery) Note: Larger battery will not help sustainable performance

  25. Network Monitoring for Test-bed • Apart from protocol messages, send each node characteristics to root node for monitoring • Assumptions • Adapt to instantaneous current for demo • Mote range large, two hop created by address blocking 3 1 2

  26. Demo

  27. Future Work • Setting up a network with more helio-motes • Network tests in outdoor environment • Meeting specified latency bounds • Routing for other scenarios • Any node to any node • Energy aware routes

  28. Thank you