Model-Based Design Exploration of Wireless Sensor Node Lifetimes - PowerPoint PPT Presentation

liam
model based design exploration of wireless sensor node lifetimes l.
Skip this Video
Loading SlideShow in 5 Seconds..
Model-Based Design Exploration of Wireless Sensor Node Lifetimes PowerPoint Presentation
Download Presentation
Model-Based Design Exploration of Wireless Sensor Node Lifetimes

play fullscreen
1 / 30
Download Presentation
Model-Based Design Exploration of Wireless Sensor Node Lifetimes
756 Views
Download Presentation

Model-Based Design Exploration of Wireless Sensor Node Lifetimes

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

  1. Model-Based Design Exploration of WirelessSensor Node Lifetimes Deokwoo Jung deokwoo.jung@yale.edu Embedded Networks and Applications Lab (ENALAB) Yale University http://www.eng.yale.edu/enalab Deokwoo Jung, Thiago Teixeira , Andrew-Barton Sweeney and Andreas Savvides

  2. How to explore the design space of wireless sensor platform? Energy Constraint Sensor Platform Design • Battery operated wireless sensor node • Energy-opt. design vs Performance-opt. design • Choice of hardware components Model-Based Design Exploration • Two Major Design Paradigm • Trigger-Driven / Schedule-Driven • Reveal Trade-off between two Design Choice • Detection probability / Node lifetime • Matlab Pre-sensor platform design toolbox • Parallel lifetime comparison of new platform • Power budget/ breakdown analysis

  3. Motivation & Related Work • Motivation • Mica2(2002) , XYZ(2003), Telos(2004), iMote2(2005), Hitachi(2006), ??… (20xx) • Standard way of analyzing node level lifetime over the platforms? • Talking about how a chosen combination of hardware components and operation patterns can influence node lifetime • Node level lifetime analysis • Nath et al : Markov chain-based simulation to analyze energy dissipation behavior per node. • Snyder et al : Power consumption simulation tool, PowerTOSSIM • Coleri et al: Hybrid automata models for analyzing power consumption of a node at the operating system level (TinyOS) • Our Work • Focus on the Node level & Hardware Impact in Lifetime • Consider many realistic factors in model such as ‘transition energy cost’ • Derived models that show the effect of each parameter on the lifetime

  4. Trigger-Driven Strategy Schedule-Driven Strategy Simple Sensor Intelligent Sensor Processor Processor Polling Interrupt Event Monitoring Duty Cycle Trigger vs Schedule Driven Operation

  5. Mathematical Model • In order to capture energy consumption pattern, must consider “Time” and “Power” simultaneously • Need “Continuous Markov Chain” • {Z(t):t ≥ 0} describing the state the chain is in at time t: Generalized Markov chain, or Semi-Markov process • It does not have the Markov property: future depends on • The present state, and • The length of time the process has spent in this state • Not too much complex and also practical • Modeling most typical pattern of node behavior • Reduce the number of states (Consider only practically meaningful power level) • Only consider 1’st order statistics of RV, mean value.

  6. Power State Description • Preprocessor (On), Sensor (Off / On), CPU (Off /On /Idle), Radios (Off / Tx / Rx) • CPU On=Busy or Normal / Radio Rx= Listen or Idle • Off = The lowest power mode at each component • CP=CPU Wakeup Energy Cost, CR=Radio Wakeup Energy Cost

  7. Power State Cost for Different Nodes (iMote2, XYZ, Mica2, Telos) • Trigger Driven Platform Schedule Driven Platform

  8. Inter-arrival Time,X Interrupt to CPU Proc. Time,Y Process Complete Tx Time,Z Tx Radio On Radio Off Trigger Driven Model Power Profile/ Markov Chain Model (Simplified)

  9. Job completed Job enters Tx completed Channel Idle Trigger Driven Model Power Profile Model (Detailed) Processing Stage Communication Stage

  10. Preprocessing Stage Processing Stage Triggered by Event Job completed Monitoring Event Job enters Tx completed Channel Idle Communication Stage Trigger Driven Model Markov Chain Model (Detailed)

  11. Minimize if Minimize if Trigger-Driven Model Formula Event Arrival Rate Preprocessing Power • Simplified • Detailed Average time spent in non-preprocessing stages per event Average energy spent in non-preprocessing stages per event

  12. Communication Stage Processing Stage Missed Event Detected Event Schedule Driven Model Power Profile Model

  13. Idle Stage Processing Stage Event Detected Job completed Monitoring Event Job enters Tx completed Channel Idle Schedule Driven Model Markov Chain Model (Awake Period) Communication Stage

  14. Average Power at Awake Period Power at Asleep Period Detection Probability = duty cycle • If and , Minimize Idle Power • If , Minimize Sleep Power CPU Wake-up Energy Cost Duty Period=Asleep + Awake Period Idle State Power Average power spent in non-preprocessing stages per event Average energy spent in non-preprocessing stages per event Schedule-Driven Model Formula • Average Power at Awake Period

  15. Numerical Validation of the Models • Comparison between prediction and simulation results using discrete event simulator

  16. Trigger-Driven and Schedule-Driven Comparison Average Steady State Power Consumption Comparison • Trigger-Driven Model • Schedule-Driven Model

  17. Average Power Consumption Trigger driven node Schedule driven node Average Detection Probability Trade-off Diagram

  18. Does it make sense to develop a trigger driven camera node ?

  19. Preprocessor Event Sensing Motion PIR Motion Detector Motion Data PIC microcontroller To BaseStation Wake-Up Signal Sensing Image Processing and Communication Unit Imote2 Image Data OV7649 Camera Centroid Data CC2420 Radios PXA 27x DMA Turn On Does it make sense to develop a trigger driven camera node ?

  20. Does it make sense to develop a trigger driven camera node ? • Single target localization application

  21. Measured Power profile of iMote2

  22. What is the expected lifetime for the existing platform versus detection probability (duty cycle)?

  23. The best lifetime of the proposed Camera iMote2 given a certain arrival rate? Even with the lowest power level less then 25 days of Lifetime Less then 10 days of Lifetime with default configuration

  24. What is the bottleneck for extending lifetime of trigger-driven camera iMote2 ? • Power breakdown of Markov Chain State Exponential decrease of arrival rate brings only linear decrease of Preprocessing Power Due to Leakage Power of Camera Board During Preprocessing Stage

  25. iMote2 Deep Sleep 94.15 2 10 Camera board Off PXA Standby Mode Camera board Off PXA Standby Mode Camera Standby 12.33 Lifetime (days) 1 10 8.45 0 10 -3 -2 -1 0 1 2 10 10 10 10 10 10 Event Inter-Arrival Rate (1/min) Using the models to characterize andmake decisions about a camera sensor node • Preprocessor (PIR+PIC) is always ON & • Non -Preprocessing Unit (Camear+iMote2) are selectively ON 10X Improvement

  26. 25 l =0 iMote2 in Deep-Sleep Mode 20 l =0 PXA in Standby Mode 15 l =1/10min Lifetime (days) PXA in Standby Mode 10 l ¥ = PXA in Standby Mode 5 0 0 10 20 30 40 50 60 70 80 90 100 Preprocessor (mW) Maximum Power Budget of Preprocessor given lifetime requirement and event arrival rate

  27. Lifetime trend versus detection probability (duty cycle) for the sentry node described in VigilNet Reported Lifetime: 90 days Our Prediction: 92.5 days He, T et al. ‘Achieving long-termsurveillance in vigilnet’ ,Infocom 2006.

  28. 94.15 What if the Vigilnet sentry node was trigger-driven?

  29. Conclusion • Parametric lifetime model for trigger-driven node and schedule-driven node • Key parameter for trigger-driven and schedule driven • Trade-Off Diagram between Trigger and Schedule • Numerical Correctness validated though simulation • The application of the models in making decisions about a iMote2+camera node platform • No significant lifetime improvement without reducing leakage power in trigger-driven architecture • Quick & Standard Way of Comparing Platform Lifetime • MATLAB toolbox for Pre-design and Platform comparison tool • Future work • Extending our models to cover more complex cases involving multiple processors and radios.

  30. For more details visit http:// www.eng.yale.edu/enalab/aspire.htm Thanks