Sustainable Sensor Networks for Long-Term Monitoring

1. Beyond the 5-minute Demo Building blocks for sensor networks that need to last for months Robert Szewczyk, Anind Dey, David Gay NEST Retreat, January 2002

2. What’s been missing so far • TinyOS apps make very good demos, but… • Many carefully tuned parameters, lots of hard coding • Limited self monitoring • Coded as a demo, not a as a service • Different requirements for long running networks • Use many devices (possibly different) to contribute to the network – building general purpose net, on application-specific sensors • Control parameters change over time – either need to provide common control mechanism, or automatically adjust local parameters

3. Application model Environment monitoring DB Traditional network SerialForwarder Remote control console for motes SerialForwarder SerialForwarder Inventory tracking

4. Example: Network in Cory Hall • 50+ Rene motes • MySQL backend, a number of front end visualization tools • Deployed in May/June 2001, ~ 3 weeks, 500 thousand samples

5. Experiences from Cory Hall network • Relatively brittle application • Too high power usage • 2-3 weeks on a set of batteries • Variable range • No self monitoring of nodes • Random failures, noticed only when the application has been accessed • Lack of advanced monitoring/scheduled maintance • Unacceptably high maintenance costs • Battery checks, code upgrades, database maintenance, connectivity checking • Relatively difficult to deploy

6. Broadcast Route Sense Net Prog AM Wakeup Clock Application structure Command Logger

7. Energy usage • Goal: 2AA batteries should last for at least 1 year • Average power usage: 200 uA • Power usage: <50 uA while powered down, <20 mA while running full bore • Can control both the duty cycle and (to some extent) the active power usage • Reducing active power usage • Most power used for communication • Cannot avoid transmission costs • Lower power listening • Early message rejection

8. Duty cycle control • WAKEUP component • Mechanism for putting node to sleep for a specified period of time • Gets us into the uA range • Requires time synchronization to work • Need to coordinate the awake periods to maintain multihop connectivity • Scheduling policies • Synchronize the entire network • Schedule rendezvous between parents and children, a flavor of distributed TDMA

9. Low power communication • Builds on the new networking stack • Adds a preamble which allows for a 10% duty cycle • Radio layers too slow, need to break TinyOS model • Poll while radio is being turned on

10. Improved communication primitives

11. Global Broadcast • Very simple flooding, from any source, based on a sequence number • If message not seen previously rebroadcast, otherwise don’t do anything • Doesn’t depend on any particular broadcast tree, as long the network has good connectivity • Useful as a transport for many control messages

12. Base station routing • “Mostly” beaconless routing • Gather local neighborhood information across several components • Least-recently heard replacement policy • Select a parent from the neighborhood • Beacons take a form of infrequent broadcasts, carry time sync information, level, duty cycle information, etc. • Parent selection reinforced by regular traffic • Route testing for bi-directionality • Observe retransmissions from the parent • Dedicated local ping service

13. Higher level functionality

14. Controlling application • A dispatch component for controlling the functions of the nodes • Time synchronization • Setting mote parameters – duty cycle control, transmission power, sampling speeds, etc. • Interactive control of the sensor networks

15. Field upgrades – network programming • Reprogramming model: • Download program to local non-volatile storage • Save local state • Reload local program, reset the system • Basic mechanism – 4 message handlers • Program announce, write fragment, read fragment, start reprogramming • Idempotent messages • Communication protocols optimized for local, single hop broadcasts in dense neighborhoods • Also exists in a multihop version, viral reprogramming under construction

16. Future

17. Richer “core” TinyOS • More standardized functionality • Broadcast, routing, network programming, ping, other “standard” message handlers • Non-volatile storage • Need a richer model for sharing state between components • Sharing some state between unrelated message handlers • Optimize for cheap and flexible state access/modification • Contexts per network stack? Registry of attributes? What state should be nonvolatile?

18. Network deployment • Why it would be a pain to deploy a bucket of SmartDust motes • ID assignment • Selection of program to run, and what happens when that program crashes • Some approaches to try • Primordial program – equivalent of bootp • Periodic resets • Viral propagation of code – local broadcast, infect the new nodes with the current program • Functional partitioning of motes?

19. The Demo • 3 distinct parts • Snapshots of environmental data • People tracking • Social network formation • Audience participation encouraged • Will present results later during retreat

20. Active badges • Autonomous motes, detecting each other • Periodic beaconing • Local history buildup – who did you spend time with during the retreat • Opportunistic offloading of data to the infrastructure – detecting presence of a cheap link (e.g. a nearby base station) • Relatively low power • But nowhere near the IDF demo power consumption • Cached data on the PC side