From TimeSync to EmStar: Whats really hard about Wireless Sensor Networks

1
From TimeSync to EmStarWhats really hard
aboutWireless Sensor Networks?

• Jeremy Elson
• Department of Computer Science
• University of California, Los Angeles
• jelson_at_cs.ucla.edu
• http//google.com/search?qjeremyelson

April 2004
2
Whats a sensor network?

• Large-scale, distributed, wireless network
• Integral with the environment in which its
  situated senses phenomena up close
• Scale dictates that we cant wire them
• Can reveal previously unobservable phenomena
• Mental picture drop lots of nodes out of an
  airplane expect them to self-organize and return
  useful data

3
Whats hard about networking?

• In the Internet
• Scale
• Heterogeneity
• Failures
• In sensor networks...
• Its all much, much worse
• Harsher environment, flakier links, lower
  bandwidth, tiny hardware, finite energy, lower
  ratio of humans, and no pervasive infrastructure

A tale of two network partitions
4
The Internet
Misconfigured router caused a network partition
Users noticed, complained to me, I looked into it
and contacted the router maintainers
5
Sensor Network Partition
6
Using traditional synchronization
Master
Time t30, I command thee!
yes, master
yes, master
Nodes simply assume they have a correct
clock Service model What time is it?
7
partitions are bad news.
Master 1
Time t30, I command thee!
Time t28, I command thee!
Master 2
In the Internet, we assume there are multiple
masters that are, themselves, synchronized
out-of-band (GPS)
8
The Egalitarian ViewNo Global Clock
Instead, learn the relationship between your
clock and your neighbors
5
-7
3
11
-10
2
1
2
2
-6
1
0
4
-1
-8
2
6
7
New service model 1) What time is it here? 2)
For a given time here, what time is it there?
3
9
Traditional synchronizationDetermining a
Neighbor Relationship
ProblemSources of unknown, nondeterministic laten
cy between timestamp and its reception
Sender
Receiver
Send time
Receive Time
At the tone t1
NIC
NIC
Access Time
Propagation Time
Physical Media
10
Reference Broadcast Synchronization (RBS)
Sync receivers with each other that observed a
common event this does NOT sync the sender with
the receiver
Sender
Receiver
Receiver
Receive Time
NIC
NIC
NIC
I saw it at t4
I saw it at t5
Propagation Time
Physical Media
11
RBS reduces error by removing much of it from the
critical path
NIC
Sender

Receiver 1

Receiver 2
Critical Path
Traditional critical path From the time the
sender reads its clock, to when the receiver
reads its clock
RBS Only sensitive to the differences in receive
time and propagation delay
12
Receiver Determinism
1st testbed Berkeley motes with narrowband
(19.2K) radios
13
Time
14
Clock Resolution
6us avg
51us avg
1.5us avg
RBS does much better than NTP under identical
conditions
15
Clock Resolution
Under load RBS degraded slightly (6 to 8us) NTP
severely (51 to 1,542us)
16
Multi-Hop RBS

• Some nodes broadcast RF synchronization pulses
• Receivers in a neighborhood are synced by using
  the pulse as a time reference. (The pulse
  senders are not synced.)
• Nodes that hear both can relate the time bases to
  each other

Red pulse 2 secafter blue pulse!
Here 3 sec after red pulse!
Here 1 sec after blue pulse!
Here 1 sec afterred pulse!
Here 0 sec after blue pulse!
17
Time Routing
The physical topology can be easily converted to
a logical topology links represent possible
clock conversions
1
2
5
A
B
6
3
4
7
C
8
9
D
10
11
Edges can be weighted by error estimates Gaussian
s independent, so, sqrt(n) error growth!
18
Applications

• A few brief anecdotes

19
Acoustic Ranging
20
Real Version

• Sensoria Corp under contract from DARPA
• Goal Nodes localize themselves within 1m, MOVE
  to fill in gaps
• Network completely self-organizing, autonomous
• Uses RBS timesync for acoustic ranging

21
Errors are expensive
10 MOBILE nodes, 1 is deactivated, and then...
22
It might seem simple...

• Just use timesync for acoustic ranging, build a
  map, react to it
• Would you believe the system had about 20
  application-specific daemons?

• Time synchronization
• Cluster multilateration
• Cluster map transmission/federation
• Healing with holdoff
• Rocket thruster device driver
• Network arm/disarm/safety
• Visualization proxy
• Command proxy (debugging)

• Process management/logging
• Radio device drivers (x2)
• Fragmentation and reassembly (x2)
• Neighbor discovery (x2)
• Cluster formation/leader election
• Flood routing
• Acoustic ranging
• Acoustic range scheduling

• Each system generation had 2x the nodes (up to
  100), and required almost a complete redesign

Now add dynamics into the mix! The Science was
maybe 10 of the work
23
The EmStar Approach

• Allow software to be finely decomposed,
  modularized
• Toolchest of mechanism, not policy modules
• Provide rich forms of inter-module communication
• Isolate as much domain knowledge as possible
• Run-time environments for deep debugging
• Debug in a transparent context before the
  necessarily opaque deployment
• Same code runs in simulation, reality, and
  hybrids
• High visibility into the system is key -- status
  is exposed in both human- and machine-readable
  form

24
EmStars Gradual Descent into Reality

• EmStar allows the same Linux code to be used
• In a pure (low-fidelity) simulation
• Mostly simulated, but using a real wireless
  channel
• In a real testbed, small-scale but
  high-visibility
• Deployed, in-situ, at scale -- but low
  visibility
• Advantage over traditional simulators the
  debugged code itself, not just the high-level
  concepts, flow from simulation into the real
  world
• To maintain high visibility, we trade scale for
  reality

25
EmStar Run-Time Environments
The spectrum allows high-visibility
debugging before jumping into low-visibility
deployment
26
The Ceiling Array A Real Wireless Channel
Motes used to transmit and receive packets -- A
real-world augmentation to a virtual simulation
27
Portable Array In-Situ, so Smaller Scale
Cables (green, invisible) attach to in-situ motes
28
Future (current) work

• A Wireless Seismic Testbed
• Seismology is a data-driven science, but data
  collection is often biased by GPS availability
• Real-time data only near cities (infrastructure)
• The Center for Embedded Networked Sensing is a
  collaboration of science and systems research
• Use EmStar and RBS to distribute time, collect
  data
• Result (ideally) A system that both pushes the
  boundaries of distributed systems and provides
  real data

29
Thank you!