200 likes | 269 Views
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
E N D
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 Environment monitoring DB Traditional network SerialForwarder Remote control console for motes SerialForwarder SerialForwarder Inventory tracking
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
Broadcast Route Sense Net Prog AM Wakeup Clock Application structure Command Logger
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
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
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
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