time synchronization for wireless sensor networks
Post on 21-Dec-2015
223 views
TRANSCRIPT
Time Synchronizationfor Wireless Sensor Networks
Importance of timesync
• Internet Time Synchronization– Critical in some contexts (e.g. crypto,
distributed packet traces)
– A convenience in many other contexts
• Sensor Network Synchronization– Fundamental to its purpose: data fusion
– Physical time needed to relate events in the physical world
Heterogeneity • Time sync is critical at many layers
– Beam-forming, localization, distributed DSP
– Data aggregation & caching
– TDMA guard bands
– “Traditional” uses (debugging, user interaction…)
• But time sync needs are non-uniform– Maximum Error
– Lifetime
– Scope & Availability
– Efficiency (use of power and time)
– Cost and form factor
Beam-forming, localization, distributed Digital Signal Processing: small scope, short lifetime, high precision
t=3
t=2
t=1
t=0
Target tracking:larger scope, longer lifetime,but lower required precision
Isn’t this solved?
• NTP (Network Time Protocol)– Ubiquitous in the Internet
– Variants appearing in sensor networks
• 802.11 synchronization– Precise clock agreement within a cluster
• GPS, WWVB, other radio time services
• High-stability oscillators (Rubidium, Cesium...)
So what’s wrong?
• This isn’t the Internet– Important assumptions no longer hold
• (fewer resources available for synchronization…)
– Sensor apps have stronger requirements• (…but we have to do better than the Internet anyway)
• Energy, energy energy:– Listening to the network is no longer free; even occasional CPU
use can have a major impact
• Existing work is a critical building blockBUT...
Infrastructure vs. Ad-Hoc
• “NTP provides UTC to the entire Internet”– But wait, you’re cheating! UTC is distributed to
many places in the network out of band via various radio services (WWV, GPS, …)
– Path from clients to a canonical clock is short
• Infrastructure isn’t ubiquitous in sensor nets– GPS doesn’t work indoors, in the forest,
underwater, on Mars…
• What happens without infrastructure?
Poor Topologies
Master
Stratum 2
Stratum 3
?????
A C
B
Should A or C serve as B’s master?Either decision leads to poor sync with the other.
“Mundane” Reasons
• Cost– We can’t put a $500 Rubidium oscillator or a
$50 GPS receiver on a $5 sensor node
• Form factor– Nodes are small, extra components are large
• Not actually a mundane limitation if it changes the economics of the sensor net
So what do we do?
New architectural directions fortime synchronization in sensor networks
Leveraging the Medium
• Wireless networks often use network interfaces with physical-layer broadcasts
• Reference Broadcast Synchronization takes advantage of this to remove most of the non-determinism from the critical path
4 Time Components in Traditional sync
Sender Receiver
At the tone: t=1
NIC
Physical Media
NIC
Send time
Access Time
Propagation Time
Receive Time
Problem: Many sources of unknown, nondeterministiclatency between timestamp and its reception
Reference Broadcasts
Sender Receiver
NIC
Physical Media
NIC
Propagation Time
Receive Time
Sync 2 receivers with each other, NOT sender with receiver
Receiver
NICI saw itat t=4 I saw it
at t=5
NICSender
Receiver 1
Receiver 2
Critical Path
NICSender
Receiver
Critical PathTime
RBS reduces error byremoving much of it from the 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
Receiver Determinism
1st testbed: Berkeley motes with narrowband (19.2K) radios
Time
Comparison to NTP• Second implementation:
– Compaq IPAQs (small Linux machines)
– 11mbit 802.11 PCMCIA cards
• Ran NTP, RBS-Userspace, RBS-Kernel– NTP synced to GPS clock every 16 secs
– NTP with phase correction, too; it did worse (!)
• In each case, asked 2 IPAQs to raise a GPIO line high at the same time; differences measured with logic analyzer
“Here 0 sec after blue pulse!”
“Here 1 sec after blue pulse!”
“Here 3 sec afterred pulse!”
“Here 1 sec afterred pulse!”
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!”
1
3
2
A4
8
C
5
7
6B
10
D11
9
1
3
2
4
8
5
7
6
10 11
9
Time RoutingThe physical topology can be easily
converted to a logical topology; links represent possible clock conversions
Use shortest path search to find a “time route”;Edges can be weighted by error estimates
Multi-Hop RBS
0
1
2
3
4
5
6
7
1 Hop 2 Hop 3 Hop 4 Hop
Error (usec)
Std Dev
Error
1.85 +/- 1.28
2.73 +/- 1.912.73 +/- 2.42
3.68 +/- 2.57
Error (and std dev) over multiple hops, in usec
• Most protocols stay synced all the time
• Post-facto sync:– Clocks start out unsynchronized
– A set of receivers waits for an interesting event
– Locally timestamp an event when it happens
– After the fact, reconcile clocks
• Avoids wasting energy on unneeded sync; it’s easier to predict the past than future
“Post-Facto” Sync
Post-Facto Sync
Test pulses
Sync pulses
Drift Estimate
7usec error after 60 seconds of silence
Applications
A few brief anecdotes
Acoustic Localization
Correlation • Green is reference, Red is measured
– Signals aligned to offset yielding max correlation
Time in Samples (20 uS)
Am
plit
ude
Lessons Learned
What’s the big picture?
We need many methods
Time Sync Parameter Space:(max error, lifetime, scope, etc.)
Application Requirement
Available SyncMethods
Better
Better
Goal: make the set rich enough to minimize waste
We need many methods
Time Sync Parameter Space:(max error, lifetime, scope, etc.)
Application Requirement
Better
Better
Goal: make the set rich enough to minimize waste
Ideally, methodsshould be tunable
A new service model
• Traditional time synchronization: “What time is it”?– Forces clocks to be synchronized all the time
– Forces synchronization to pick one timescale
• Our new model: explicit conversions– What time is it here?
– For a given time here, what’s the time there?
• This model buys us enormous freedom!
No global timescale
A C
B
Your clock is your clock.Just know how your clock relates to others.
Future Work
• RBS is “under-specified” -- Who broadcasts? How is information disseminated?– Are there standard, easily configured solutions?
• Can we exploit global knowledge?– Initial work by Karp, Shenker is promising
• Is post-facto sync really practical?– Does it save enough energy and have a low
enough cost in lost precision?
Summary• Time sync is critical for sensor networks
• Existing solutions are inadequate: insufficient precision, wasteful of energy
• Fruitful new ideas have come about that never would have developed in the Internet:– Leverage the broadcast channel
– Use local timescales
– Sync after the fact
• A new service model is more expressive
• New field = new problems = new solutions!