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

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

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

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

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

Application structure BroadcastRouteSenseNet Prog Logger AMClockWakeup Command

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

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

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

Improved communication primitives

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

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

Higher level functionality

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

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

Future

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?

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?

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

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