Beyond the 5-minute Demo

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
Whats 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
Application structure
Command
Logger
7
Energy usage

• Goal 2AA batteries should last for at least 1
  year
• Average power usage 200 uA
• Power usage lt50 uA while powered down, lt20 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 dont do anything
• Doesnt 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