1 In-Situ Habitat and Environmental Monitoring Alan Mainwaring, Joe Polastre and Rob Szewczyk Intel Research - Berkeley Lablet

2 Talk Outline Introduction to habitat monitoring Field sites and application requirements Establishing the design context Summer milestones and wrap-up Demo: live data from two networks

3 Introduction Habitat monitoring represents a class of sensor network applications enormous potential impact for scientific communities and society as a whole. Instrumentation of natural spaces enables long-term data collection at scales and resolutions that are difficult, if not impossible, to obtain otherwise. Intimate connection with physical environment allows sensor networks to provide local information that complements macroscopic remote sensing.

4 Application-Driven Sensor Network Research Benefits to others –Computer scientists help life scientists –Small steps for us can be revolutionary for others Provides design context –Eliminates some issues, constrains others –Can add new ones, e.g., packaging Prioritizes issues –Low-power communication stacks –Run-time systems and VM’s for re-tasking –Health and status monitoring systems –Tools deployment and on-site interaction

5 Habitat Monitoring Goal: Remote, in-situ system consisting of –Sensor networks in scientifically interesting areas –WLANs link sensor networks to base station (DB) –Internet link remote users to local resources Access models –Remote DB, admin, health and status monitoring –Continuous data logger to DB for long-term analysis –Interactive inspection of sensor nodes (near real-time) Sensors of interest: too many to list –E,g., light, temperature, relative humidity, barometric pressure, infrared, O2, CO2, soil moisture, fluid flow, chemical detection, weight, sound pressure levels, vibration –Need both relative and absolute measurements with units

6 Field Sites and Application Requirements

7 Great Duck Island (ME) James Reserve (CA) Habitat Monitoring Field Sites

8 Application Requirements I Internet access –24x7 3 to 4 sensor networks (habitats) –network of sensor networks 128 stationary motes per network –50% may miss interesting phenomena 1 year lifetime -- minimum –standalone data-loggers run 1 to 10 years Change and adaptation may take days –Static node locations, infrequent occlusions Off-the-grid power: it’s off, it’s big, or it’s solar –Disconnected operation possible at all levels

9 Application Requirements II Field re-tasking (local or remote) –Adjust sampling rates, operational parameters, Remote management (one site visit per year) –1 person can locate/touch/service all motes in 1 week Inconspicuous packaging and operation –No bright colors, no sounds (buzzing) or blinking lights Pack it out: cannot “deploy and forget” –Must find motes in field after year(s) of operation –Can’t leave 1000’s of leaking Li/Cd batteries Users want predictable system operation –Cannot burden users with more complexity

10 Sensing Requirements: Weather Board SensorAccuracyInter- changability Sample Rate (Hz) Current (mA) Photoresistor N/A10% I2C temperature 1 K0.20 K Barometric pressure 1.5 mbar0.5% Barometric temperature 0.8 K0.24 K Relative humidity 2%3% IR thermopile 3 K5% Thermistor 5 K10%

11 Some Non-Requirements Localization –Oftentimes nodes are precisely placed Data aggregation –Of readings on node (yes), across nodes (no) Precise time synchronization (yet) –Depends on what precise means… Instantaneous adaptation to change –Prompt detection but not reaction Object tracking –Unless it’s passive and over large distances

12 Establishing the Design Context

13 Design Context: Power Budget Basics Batteries –2xAA2850 mAhr (est. 75% usable) –daily 5.86 mAhr (365 day target lifetime) What can the mica do with 5.86 mAhr? –Compute for 46 minutes –Or send messages –Or take temp readings

14 Design Context: Sensing Demands Sensorfrequencybytes/day compressed –Photo1 min (95%) –I2C temp15 min –Baro/pressure15 min –Baro/temp15 min –%RH15 min –IR thermopilesecond (95%) –Thermistorsecond (95%) Totals –0.04 mAhr for sensing –349KB/day or ~11600 msgs –18KB/day or ~600 msgs (compressed)

15 Design Context: Two Communications Budgets (1) Low-power listening(2) Global scheduling 98% idle1.17 mAhr99% idle1.188 mAhr 1% listen3.60 mAhrlisten timen/a 1% runtime1.08 mAhr1% runtime4.668 mAhr sensing0.044 mAhrsensing0.044 mAhr for comm:1.036 mAhrfor comm:4.624 mAhr What’s 1 mAhr worth?And 4.6 mAhr? –12431 msg opportunities55487 msg opportunities –1 msg every 7 seconds1 msg every 1.5 seconds –In 128 node network,In 128 node network, 32 msgs/leaf-node/day 144 msgs/leaf-node/day

16 Communications Design Challenge  Want network to last 1 year  Want uniform amount of data from motes  Route 18KB from each sensor to DB  1 mAhr communication budget (low-power listening)  4 mAhr communication budget (global scheduling) The key design challenge for habitat monitoring with sensor networks is resolving the trade-off between globally-scheduled approaches to communications and alternative approaches based on local information.

17 Summer Milestones

18 Summer Milestones June –Weather sensor board debug and SW –Low-power multi-hop routing for 1% duty cycle –Setup lab network with new sensors and SW (6/27) July –Upgrade Great Duck Island network (7/8 – 7/12) –Upgrade James Reserve network (7/24 – 7/25) –Monitor data collection, begin evaluation August –Invited talk: COA board of trustees (8/1) –TR: experiences and initial evaluation (8/25) –NPR segment / National Geographic article (tbd)

19 Conclusions Habitat monitoring is broadly representative of a seemingly simple class of sensor network applications. –Reference for benchmarking and comparison The habitat monitoring application domain makes some systems issues concrete yet leaves others open. –no mobility, 1 year longevity, resource budgets We can pursue sensor network systems research while delivering significant value to life scientists, today. –what’s trivial to one can be revolutionary to another We need robust multi-hop routing on spanning trees –You’ve got 1 to 4 mAhr per day to accomplish it

20 Demo?