lecture 5 time synchronization in sensor networks n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Lecture #5: Time Synchronization in Sensor Networks PowerPoint Presentation
Download Presentation
Lecture #5: Time Synchronization in Sensor Networks

Loading in 2 Seconds...

play fullscreen
1 / 135

Lecture #5: Time Synchronization in Sensor Networks - PowerPoint PPT Presentation


  • 130 Views
  • Uploaded on

Lecture #5: Time Synchronization in Sensor Networks. Ack: Slides from Saurabh Ganeriwal, Jeremy Elson. Self Configuration in Sensor Networks. Operate in the presence of obstacles. Ad-Hoc Deployment. Rapid Infrastructure Setup. Self-configuration Challenges. This Lecture.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Lecture #5: Time Synchronization in Sensor Networks' - amal


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
lecture 5 time synchronization in sensor networks

Lecture #5: Time Synchronization in Sensor Networks

Ack: Slides from Saurabh Ganeriwal, Jeremy Elson

self configuration in sensor networks
Self Configuration in Sensor Networks

Operate in the

presence of

obstacles

Ad-Hoc

Deployment

Rapid

Infrastructure

Setup

self configuration challenges
Self-configuration Challenges

This Lecture

  • Timing synchronization
    • When did an event take place?
  • Node Localization
    • Where did an event take place?
  • Calibration
    • What is the value of an event?

Self-configuration crucial to relate to the physical world!

reading list for this lecture required
Reading List for this Lecture: Required
  • RATS - S. Ganeriwal, D. Ganesan, M. Hansen, M. B. Srivastava, D. Estrin, “Predictive time synchronization for long-lived sensor networks,” NESL Technical Report, November 2004.
    • http://nesl.ee.ucla.edu/courses/ee202b/2006s/papers/L05/Ganeriwal05_NESLTechReport.pdf
  • FTSP - M. Maroti, B. Kusy, G. Simon, A. Ledeczi, “The Flooding Time Synchronization Protocol,” In the Proceedings of the Second ACM Conference on Embedded Networked Sensor Systems (SenSys), 2004.
    • http://nesl.ee.ucla.edu/courses/ee202b/2006s/papers/L05/Maroti04_SenSys.pdf
reading list for this lecture optional
Reading List for this Lecture: Optional
  • RBS - J. Elson, L. Girod, D. Estrin, “Fine-Grained Network Time Synchronization using Reference Broadcasts,” In Proceedings of the Fifth Symposium on Operating Systems Design and Implementation (OSDI 2002), Boston, MA. December 2002.
    • http://nesl.ee.ucla.edu/courses/ee202b/2006s/papers/L05/Elson02_OSDI.pdf
  • TPSN - S. Ganeriwal, R. Kumar, M. B. Srivastava, “Timing-sync protocol for sensor networks,” In Proceedings of the First ACM Conference on Embedded Networked Sensor Systems (SenSys), 2003.
    • http://nesl.ee.ucla.edu/courses/ee202b/2006s/papers/L05/Ganeriwal03_SenSys.pdf
  • NTP - D. Mills, “Internet Time Synchronization: The Network Time Protocol,” In Zhonghua Yang and T. Anthony Marsland, editors, Global States and Time in Distributed Systems, IEEE Computer Society Press, 1994.
    • http://www.eecis.udel.edu/~mills/database/papers/trans.pdf
  • Leslie Lamport, “Time, clocks, and the ordering of events in a distributed system”, ACM Journal of communications, 1978.
    • http://portal.acm.org/citation.cfm?id=359563
reading list for this lecture optional1
Reading List for this Lecture: Optional
  • GPS Clocks: http://www.gpsclock.com/gps.html
  • Kay Romer, “Time Synchronization in Ad Hoc Networks,” ACM MobiHoc.
importance of time in sensor networks
Importance of Time in Sensor Networks
  • Time is critical at many layers in sensor nets
    • Beam-forming, localization, tracking, distributed DSP
importance of time in sensor networks1
Importance of Time in Sensor Networks
  • Time is critical at many layers in sensor nets
    • Beam-forming, localization, tracking, distributed DSP
    • Data aggregation & caching

t=1

t=0

t=2

t=3

importance of time in sensor networks2
Importance of Time in Sensor Networks
  • Beam-forming, localization
  • Data aggregation & catching
  • Security protocols
  • MAC layer design
  • Adaptive topology management schemes
  • Absolute time of occurrence
  • Coordinated robotics
  • Debugging
  • User Interface
  • ……
why synchronized time

The Myth of Simultaneity: “Event 1 and event 2 at same time”

Event 1

Event 2

Observer A:

Event 2 is earlier than Event 1

Observer B:

Event 2 is simultaneous to Event 1

Observer C:

Event 1 is earlier than Event 2

Why synchronized time?
why synchronized time1

The Myth of Simultaneity: “Event 1 and event 2 at same time”

Event 1

Event 2

Observer A:

Event 2 is earlier than Event 1

Observer B:

Event 2 is simultaneous to Event 1

Observer C:

Event 1 is earlier than Event 2

Why synchronized time?
  • Ordering of events
  • Coordinated actuation
  • Data logging
  • Absolute time of occurrence
  • Performance measurement
  • …..
what does being synchronized mean
What does being synchronized mean?
  • Clock Skew
    • The difference in time values of two clocks is called clock skew
  • Synchronization
    • Two clocks are said to be synchronized at a particular instance of time if the clock skew of the two clocks is less than some specified constant δ
    • A set of clocks are said to be synchronized if the clock skew of any two clocks in this set is less than δ
  • Clock Synchronization requires:
    • Each node can read the other nodes’ clock values
      • Unpredicted communication delay
    • Time must never run backward
      • Operation repetition
parametric time domain b eamforming
Parametric, Time-domain Beamforming

M2

1

3

d1

2

d2

Y

Search angle

P

d3

f

M3

X

Start of sampling

  • Collect synchronized samples from 3 motes
  • Hypothesize a search angle f
    • Calculate delays d1, d2, d3 for each search angle f
    • Shift and Sum the synchronized waveforms as if the source was at angle f
    • Choose the angle fm that makes the sum maximum

Figure source: Courtesy of Vlassios Tsiatsis

impact of time sync accuracy on acoustic source localization
Impact of Time Sync Accuracy on Acoustic Source Localization

Localization Experiment

TDOA with Constrained Least Squares method

CRB: Cramer-Rao-Bound, the minimal estimation error bound no matter what methods are used.

AML: Approximate Maximum Likelihood estimation

Ack: H. Wang, K. Yao, et. al.

mac layer design
MAC layer design

Radio On

Radio Off

Sender

Radio Off

Receiver

Guard band due to clock skew; receiver can’t

predict exactly when packet will arrive

Time

time synchronization quality metrics
Time Synchronization Quality Metrics
  • Maximum Error
  • Lifetime
  • Scope & Availability
  • Efficiency (use of power and time)
  • Cost and form factor

time clocks
Time & Clocks
  • How to define time?
    • Sun
      • 1s = 1day/(24*60*60)
    • Atomic
      • 1s = Time a cesium atom needs for 9192631770 state transitions
    • Universal Time Coordinated (UTC)
      • Now a standard for time measure.
  • Clocks: Measure of time!
    • Oscillator and counter
    • Synchronized time -> Synchronized clocks
    • Errors
      • Clock skew (offset): Difference between time on two clocks.
        • Different start times
      • Clock drift: Count at different rates.
        • Different frequency of the oscillator.
oscillators
Oscillators

Cost

Drift rate

Rubidium

~10-15 s / day

High

Atomic

Clocks

Cesium

~10-12 s / day

Desktop

~10-6 s / day

~10-6 s / hr

IPAQs

Quartz

~10-6 s / s

Low

Motes

atomic clock
Atomic Clock

CPU power drawn by motes ~ 25 mW

Cost will be the deciding factor!

logical clocks time number assigned to an event satisfying causality

Time

e11

e12

e13

P1

e11

e12

e13

P1

e21

e22

e23

e24

e25

P2

e21

e22

e23

e24

e25

P2

e32

e33

e34

e32

e33

e34

P3

P3

e31

Logical Clocks: “Time” = Number Assignedto an Event Satisfying Causality

Time

e31

“Time, Clocks, and the Ordering of Events in a Distributed System”, Leslie Lamport, Communications of the ACM, July 1978, Volume 21, Number 7.

implementing logical clocks happened before relationship
Implementing Logical Clocks:Happened-before Relationship “”
  • With synchronized physical clocks: An event a happened before an event b if a happened at an earlier time than b
  • Without physical clocks:
    • The events at a node form a sequence, where a occurs before b in this sequence if a happens before b
    • Assume sending and receiving a message is an event in a node
    • The relation “” on the set of events in a distributed system is the smallest relation satisfying the following three conditions:
      • If a and b are events in the same node, and a comes before b, then ab
      • If a is the sending of a packet by one node and b is the receipt of the same message by another node, then ab
      • If ab and bc, then ac
    • Two distinct events a and b are said to be concurrent if ab and ba
    • Irreflexive partial ordering
      • a a
    • Another definition: ab is a causally affected b
implementing logical clocks
Implementing Logical Clocks
  • Just a way of assigning a number to an event, where the number is the time at which the event occurs.
  • Define a clock Ci for each process Ni
    • Assigns a number Ci(a) to any event a in that process
  • The entire system of clocks is represented by the function C which assigns to any event b the number C(b), where C(b) =Cj(b) if b is an event in process Nj
  • The clocks Ci are logical clocks rather than physical clocks
  • The logical clocks is correct if the events of the system that are related to each other by the happened-before relation can be properly ordered using these clocks
    • Clock condition: for any event a, b, if ab then C(a) <C(b)
implementing logical clocks1
Implementing Logical Clocks
  • According to the definition of Happened-before relation, the clock condition is satisfied if the following two conditions hold:
    • C1: if a and b are events in node Ni, and a comes before b, then Ci(a) < Ci(b)
    • C2: if a is the sending of a message by node Ni and b is the receipt of that message by node Nj, then Ci(a)<Cj(b)
  • To meet C1:
    • IR1: each node Ni increments Ci between any two successive events
  • To meet C2:
    • IR2: (a) if event a is the sending of a message m by node Ni, then the message m contains a timestamp Tm = Ci(a).
    • (b) Upon receiving a message m, node Nj sets Cj greater than or equal to its present value and greater than Tm
total ordering of events
Total Ordering of Events
  • One can use the logical clocks satisfying the Clock Condition to place a total ordering on the set of all system events.
    • Simply order the events by the times at which occur
    • To break the ties, use any arbitrary total ordering of the processes, i.e. node id
  • Using this method, one can assign a unique timestamp to each event in a distributed system to provide a total ordering of all events
  • Very useful in distributed system!
slide27

Time Synchronization Approaches

in Distributed Systems

gps overview
GPS overview

T1 = t1 + |X-s1|/c

Gather four satellite signals and solve the non-linear system of equations. Satellite have atomic clocks (four on each), kept within 250 ns of each other.Need only one satellite in “position hold” mode after <x, y, z> is known.

Figure source: http://www.dependability.org/wg10.4/timedepend/03-Schmi.pdf

gps evaluation
GPS Evaluation
  • Pros
    • Accuracy ~ 10-100ns (1 PPS signal in GPS)
    • Reliable operation
  • Cons
    • Cannot work indoors, with foliage, obstructions, under water
    • If something goes bad, delay for correcting it can be as large as 30 minutes.
  • Neutral
    • Expensive ~ Cheapest GPS receiver 50 US dollars.
    • Energy hungry!
  • Cautionory note
    • Not all GPS receivers designed for time
      • Some need three satellites in view
      • Some create time glitches when switching to different satellite
      • Some user serial output as opposed to PPS, and worse, consider it a “low priority” task and can delay time code output by random amount of delays if busy computing.
      • NMEA-0183 standard protocol on serial lines doesn’t support preciese timecode
      • Serial port drivers and UART buffering a problem too.
nist radio time service wwvb in fort collins co
NIST Radio Time Service: WWVBin Fort Collins, CO
  • Continuously broadcasts time and frequency signals at 60 KHz using a 50 KW radiated power transmitter
    • Carrier frequency provides stable frequency reference traceable to the national standard
      • Less than 1 part in 10^12 uncertainty
    • BCD time code synchronized to 60 KHz carrier, and broadcast at a rate of 1 bit per second using pulse width modulatiuon
      • Year, day of year, hour, minute, second (31 bits)
      • flags indicating status of day light saving time, leap year, and leap seconds
    • It path delay is removed (e.g. by averaging), WWVB provides uncertainty of less than 100 microseconds relative to UTC
  • Also available via phone
    • < 30 ms delay with landline, < 1 ms stability
    • > 100 ms with cell phones
    • > 250-500 ms with satellite connections
  • Coverage area (signal > 100 microvolt per meter) varies
    • Contracts during day, expands during night
  • Similar services WWV and WWVH for worldwide users

1600 UTC

0400 UTC

why not put a wwvb receiver at every sensor node
Why not put a WWVB receiver at every sensor node?
  • Outages: typically available for ~ 20 hours/day
    • Other 4 hours you are stuck with an uncompensated clock oscillator
  • Most WWVB receivers synchronize to WWVB intermittently, and do so by jumps
    • Since they don’t report when these jumps take place, there is no good way to process their timestamps
  • Inexpensive WWVB receivers are limited to 0.5s accuracy
  • Listening on a radio is not cheap - energy!!!
802 11 synchronization

Send at T1

802.11 Synchronization

Base station

Clients just adopt

the timestamp in the

beacon packet

Very simple, Provides ms accuracy.

Neglects packet delay and delay jitters

  • This approach used by electronic products such as wall clocks, clock radio, wrist watches etc. worldwide to synchronize via WWVB/WWV/WWVH signals
  • Can do better by compensating for propagation delay
ntp internet synchronization

Recv at T2

Send at T1

T2 = T1 + DELAY + OFFSET

Client

Peer

A

B

Recv at T4

Send at T3

T4 = T3 + DELAY- OFFSET

OFFSET = {(T2-T1)-(T4-T3)}/2

DELAY = {(T2-T1)+(T4-T3)}/2

NTP: Internet Synchronization
ntp details

Peer 1

Filter 1

Intersection

and

Clustering

Algorithms

Peer 2

Filiter 2

Combining

Algorithm

Loop Filter

P/F-Lock Loop

Peer 3

Filter 3

LCO

NTP Messages

Timestamps

NTP details
  • Level n synchronizes to level n-1
    • Level 1 synchronizes to UTC via GPS, WWVB etc.
  • Multiple synchronization peers -> redundancy and diversity
  • Path from clients to a canonical clock is short
  • Data filters -> Sliding window
  • Intersection and clustering algorithms -> Discard outliers
  • Combining algorithm -> Weight samples
  • Loop filter and local clock oscillator (LCO) -> implement hybrid phase/frequency-lock feedback loop to minimize jitter

Figure source: RFC on NTP

ntpd ntp dameon capabilities
NTPD: NTP Dameon Capabilities
  • NTPD can compare your local clock against an external reference time source over a long period of time.
    • It can then measure the 'drift' of the clock and apply a correction. This will keep the clock more accurate even if the external synchronization is later removed. It will also reduce the need to 'jump' your clock to keep it in synch.
  • NTPD can allow a computer with a more accurate time source to provide time to other computers. More than 100,000 computers currently form a network of time servers and clients on the Internet.
    • This network can have many levels. For example, a computer with a GPS clock can provide synchronization for several servers which in turn provide synchronization to thousands of client computers.
  • NTPD can compare time accuracy and stability from numerous sources and pick the best one to lock your computer's clock onto.
    • If your GPS clock suddenly goes haywire, NTPD is smart enough to know not to listen to it.
  • NTPD can filter multiple time readings to reduce the effects of jitter.
    • A single time reading may be off due to network congestion or server load. NTPD is smart enough to pick the best readings and use them.
  • NTPD also monitors its own accuracy and the reliability of all the time sources it is using.
    • This statistical information is invaluable in determining of your clocks are actually synchronized. It will also tell you if a change you have made has actually made things better or worse.
  • NTPD, originally from Unix world, now works for almost all modern OS
impact of poor topologies in ntp
Impact of Poor Topologies in NTP

Master

Stratum 2

A

C

Stratum 3

B

?????

Should A or C serve as B’s master?

Either decision leads to poor sync with the other.

ntp evaluation
NTP Evaluation
  • Pros
    • Readily available
    • Industry standard
    • Achieves secure and stable sync to ms accuracy
  • Cons
    • Designed for ms accuracy only!
    • Not flexible
    • Designed for constant operation in the background at low rates
      • E.g. it took NTP an hour to reduce error to 60 microseconds with maximum polling rate of 16 sec.
  • Neutral
    • Not energy friendly!
slide38

What is so different in sensor networks?

Why can we now use NTP or GPS?

varying demands
Varying demands

Beam-forming, localization, distributed DSP:

small scope, short lifetime, high precision

Figure source: Courtesy of Jeremy Elson

slide40

Varying demands

Target tracking:

larger scope, longer lifetime,

but lower required precision

t=2

t=3

t=1

t=0

Figure source: Courtesy of Jeremy Elson

synchronization demands
Synchronization Demands

Multi-modal

  • Event ordering
    • “Did event 1 happened before/after/with event 2?”
  • Internal Synchronization
    • “All cameras should be on after 5 minutes”
  • External Synchronization
    • “Show me targets detected between 2:00 & 8:00 p.m.”
  • Hybrid Synchronization
    • Target tracking: Convert propagation delay of 1.5ms to distance using speed of 345m/s.

Energy, Energy, Energy,….

Scalable

µs – ms accuracy

comparison
Comparison

Specialized costly hardware

Cannot work indoors

rbs synchronize receivers
RBS: Synchronize Receivers

Based on CesiumSpray system by Verissimo and Rodrigues

Receiver-receiver Synchronization

Figure source: Courtesy of Jeremy Elson

slide45

Magic behind RBS

NIC

Sender

Receiver

Critical Path

Time

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

Figure source: Courtesy of Jeremy Elson

observations about rbs
Observations about RBS
  • RBS removes send and accesstime errors
  • Broadcast is used as a relative time reference
  • Each receiver synchronizing to a reference packet
    • Ref. packet was injected into the channel at the same instant for all receivers
  • Message doesn’t contain timestamp
    • Almost any broadcast packet can be used, e.g ARP, RTS/CTS, route discovery packets, etc
phase offset estimation
Phase Offset Estimation
  • Simplest case: single pulse, two receivers
    • Xmitter broadcasts reference packet
    • Each receiver records the time that beacon was received according to its local clock
    • Receivers exchange observations
    • Sufficient information to form a local (relative) timescale
      • However, global timescales are also important
  • Extending simple case to many receivers
    • Assumptions
      • Propagation delay is zero
      • No clock skew
      • Receiver non-determinism (error) is Gaussian
  • Sending more messages increases precision
    • Transmitter broadcasts m packets
    • Each receiver records time the beacon was observed
    • Receivers exchange observations
    • Receiver i computes phase offset to receiver j as the average of the offsets implied by each pulse received by both nodes
  • Result:
receiver determinism
Receiver Determinism

Mica1 motes with narrowband (19.2K) radios

gaussian good
Gaussian == Good!
  • Well behaved distributions are useful
    • Error can be reduced statistically, by sending multiple pulses over time and averaging
    • Also, easier to model/simulate
  • Problem: Clock skew
    • It takes time to send multiple pulses
    • By the time we do, clocks will have drifted
      • Oscillator characteristics
        • Accuracy: difference between expected and actual frequency
        • Difference: Frequency error (usually 10-4 – 10-6)
        • Stability: tendency to stay at same frequency over time
      • Phase difference between two nodes’ clocks will change due to frequency differences
  • Solution: don’t average; fit a line instead!
    • Frequency and phase of local node’s clock recovered from slope and intercept of the line
    • Fitting a line assumes that frequency is stable
      • Assume high short-term frequency stability
      • Ignore data more than a few minutes old
clock skew estimation results
Clock Skew Estimation Results
  • 2 receivers (motes): r1, r2
  • Point (0,0) marks the first pulse
    • Receivers synchronized, no clock skew
  • Clock skew increases as time increases
    • Linear fit gives good results
  • With clock skew estimation, sufficient information exists to convert any time value generated by r1’s clock to a time value that would have been generated by r2’s clock
  • 30 broadcasts improve precision from 11 us to 1.6 us between two receivers
    • Dispersion down to 5.6 us among 20 receivers

Time

slide51

Relative Performance of RBS with NTP on iPaqs with 802.11 Radios

Clock Resolution

With higher network load

RBS degraded slightly (6us to 8us); NTP degraded severely (51us to 1542us)

slide52

Relative Performance of RBS with NTP on iPaqs with 802.11 Radios (contd.)

Clock Resolution

With higher network load RBS degraded slightly (6us to 8us);NTP degraded severely (51us to 1542us)

tpsn conventional sender receiver synchronization

Recv at T2

Send at T3

Send at T1

T2 = T1 + DELAY + OFFSET

A

B

Recv at T4

T4 = T3 + DELAY- OFFSET

OFFSET = {(T2-T1)-(T4-T3)}/2

DELAY = {(T2-T1)+(T4-T3)}/2

TPSN: Conventional Sender-Receiver Synchronization

Based on NTP

Enemy is non-determinism!

Asymmetric delays and varying offset

variability in clock offset

Node B clock

Node A clock

Local node time

Ideal clock

t1

Real Time

t4

Relative offset

Variability in Clock Offset
magic behind tpsn

Use low level time stamping

Sender

uncertainty

Propagation

uncertainty

Receiver

uncertainty

Magic behind TPSN

ALL DELAYS ARE VARIABLE !

sender

receiver

software

software

MAC

TX

propagation

RX

Bottleneck

sources of error tpsn vs rbs
Sources of Error: TPSN vs. RBS
  • Most critical is the MAC delay.
  • Small variations in software delay and propagation delay.
  • Transmission delay and reception delay would have negligible variations
  • Impact of drift between sensor node clocks.

B

C

A

B

A

Drift among the

Clocks in this interval

B

A

TPSN

RBS

C

B

error comparison
Error Comparison
  • RBS eliminates impact of sender side jitters
  • TPSN reduces by 2x the impact of propagation and receiver side jitters, and variations in clock drift.
  • With low-level time stamping, sender side jitters will be negligible
    • TPSN will give ~2x better performance than RBS
tpsn vs rbs
TPSN vs. RBS
  • All results have been obtained via 100 independent experimental runs.
  • Only consider the magnitude of synchronization error.

Average Error

(in microseconds)

ftsp estimate clock drift
FTSP: Estimate Clock Drift
  • TPSN and RBS (for motes) estimate only offset
    • FTSP takes multiple readings to estimate both offset and drift.
  • Over short time scales linear model works well!

Slope = drift

Time at Node A

}

Offset

Time at Node B

Based on both TPSN and RBS

magic behind ftsp
Magic behind FTSP
  • Multiple timestamps to accurately estimate the byte boundaries.
  • RBS -> propagation, decoding, interrupt handling.
  • TPSN -> [interrupt handling, encoding, propagation, decoding, interrupt handling] / 2
  • FTSP -> [interrupt handling, encoding, propagation, decoding, byte alignment, interrupt handling] / X , {2 < X < 4}

Extra overhead of 4 bytes per message

Figure source: Courtesy of Miklos Maroti

relative comparison of tpsn and rbs

Mean = -1.8e-16 ≈ 0

Standard deviation = 1.79e-6 ≈ 1.8 microseconds

Mean = -6.5e-15 ≈ 0

Standard deviation = 2.81e-6 ≈ 2.8 microseconds

Relative Comparison of TPSN and RBS

Comparison is not fair: skew v/s [skew, offset estimation]

What does superior time stamping buy?

TPSN

RBS

FTSP ~ 1.4 microseconds

FTSP’s strength lies in doing network-wide time sync!

high latency communication
High-latency Communication
  • FTSP, RBS, TPSN: all implicitly assume that propagation delay is small
    • FTSP, RBS: being receiver-receiver, ignore this
      • They assume that difference between propagation delays to different receivers is negligible
    • TPSN: factors propagation delay, but assumes that it is small enough so that there is negligible clock drift within the message exchange duration
  • This assumption breaks down in acoustic links for underwater sensor networks
    • speed of sound: 1500 m/s
    • RBS and FTSP yield 6 ms error @ 10m, 100s of ms @ 500 m
considering drift during synchronization
Considering Drift During Synchronization
  • Consider Berkeley motes: worst case 40 ppm, or 40 microseconds per second drift
  • For nodes that are 400 meters apart, this means that the clock can drift up to 21 microseconds during a TPSN message exchange
  • USC/ISI’s TSHL: Skew-compensated two-way exchange
    • First model each node’s clock so that nodes are skew synchronized
      • Done without any knowledge of propagation delay, which is assumed to remain constant during the message exchange for this phase
      • Uses linear regression, assuming clock frequencies are short term stable
    • Then, perform TPSN-like two-way exchange for offset correction
peer to peer timing synchronization
Peer to Peer Timing Synchronization
  • Traditional time synchronization: “What time is it”?
    • Forces clocks to be synchronized all the time
    • Forces synchronization to pick one timescale
  • New model: explicit conversions
    • What time is it here?
    • For a given time here, what’s the time there?
  • This model buys enormous freedom!
post facto synchronization
Post-Facto Synchronization
  • Standard question: what time is it?
    • Requires timing available at highest degree of precision all the time and everywhere
    • Expensive in resources
  • New service model: what is the time difference?
    • Need not have global reference
    • Precision depends on purpose (frames, symbols, phase) and can vary throughout the network
    • Allows time-stamping and later resolution of time differences
    • Far lower resource cost
  • Approach
    • 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 synchronization1
Post-facto Synchronization

“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!”

  • Timestamp the events with unsynchronized clocks.
  • Do reconciling at a later stage.

Figure source: Courtesy of Jeremy Elson

post facto synchronization2
Post-facto Synchronization

Sync pulses

Drift Estimate

Test pulses

7usec error after 60 seconds of silence

Ref: based on slides by J. Elson

time routing

1

2

5

6

3

4

7

8

9

10

11

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

Use shortest path search to find a “time route”;

Edges can be weighted by error estimates

Figure source: Courtesy of Jeremy Elson

synchronizing to external standards

1

2

5

6

3

4

7

8

9

10

11

Synchronizing to External Standards

The multihop algorithm can also be

easily used to sync to an external standard such as UTC

1

2

5

A

B

6

3

4

7

C

8

9

GPS

D

GPS

10

11

E.g. in RBS GPS’s PPS generates a series of “fake broadcasts”: “received” by node 11’s local clock and UTC

Ref: based on slides by J. Elson

evaluation of multihop sync on ipaqs rbs based
Evaluation of Multihop Sync on IPAQs(RBS based)

3.68 +/- 2.57

2.73 +/- 2.42

2.73 +/- 1.91

1.85 +/- 1.28

For Gaussian Error: Variance (n hops) = n.Variance (1 hop)

evaluation on otes tpsn based
Evaluation on <otes (TPSN based)
  • Theoretically, error increases with hop distance.
    • Randomness of drift and sign of error helps.

Microseconds

tpsn level discovery phase
TPSN – Level Discovery Phase

2

1

K

B

0

Levels now

all assigned

1

A

H

2

1

F

C

1

2

E

L

3

2

2

3

I

D

G

J

tpsn synchronization phase
TPSN – Synchronization phase
  • Node synchronize to a node belonging to one upper level
    • Use pair wise synchronization.
    • Needs symmetric links!
ftsp synchronization phase
FTSP – Synchronization phase
  • Use simple flooding
  • Receiver gets the tuple (TA,TB)
    • Uses this to update the estimate on the clock drift.
what will happen in fixed area networks

Evaluation using TPSN

What will happen in fixed-area networks?
  • Overhead
    • Energy expenditure per node remains a constant
  • Error
    • Just increases by 10% even after doubling the total number of nodes.

Time taken

Number of nodes

Scalable!

what will happen in expanding networks

Evaluation using TPSN

What will happen in expanding networks?
  • Error increases as distance from root node increases
  • Optimal results will be obtained if we instead establish a minimum spanning tree structure
    • Energy v/s Accuracy tradeoff

Y coordinate

X coordinate

Not Scalable!

Position of root node

ftsp experimental evaluation

1st leader

2nd leader

FTSP experimental evaluation

topology:

avg. error: 1.6 μs

max. error: 6.1 μs

per hop

50% turned off

1st leader turned off

random nodes turned off/on

all turned back on

all turned on

slide83

Other Approaches

  • Probabilistic clock synchronization by Chaudri et. al in IPSN 2004.
  • Interval based Synchronization by Philipp et. al in IPSN 2004.
  • Tiny/mini Sync by Sichuti et. al in WCNC 2003
  • Light-weight Time Synchronization by Greunen et. al in WSNA

2003.

  • A pulse-coupled oscillator approach to synchronization by Lucarelli et. al in SenSys 2004.
current state of the art
Current State of the Art...
  • Accuracy of a few microseconds for instantaneous synchronization between pair of nodes.
  • But nodes go out of sync….
    • Long term synchronization needed:
      • Better design of network layers such as MAC, power management.
      • Synchronized sampling, data logging, coordinated actuation….
  • How error increases with time?
    • No systematic study!
      • Do periodic sync at an arbitrary period.
      • Is periodic the right way to do it?
slide86

Sample

Repository

Model

Estimation

Prediction Error

Estimation

Sampler

Decide new

beaconing time of A

(TA , TB)

Window (W)

Error

Bound (Emax)

Sampling period (S)

Time Synchronization Control Loop

Synchronize a pair of nodes A and B.

optimization problem
Optimization Problem

Given: Past repository of samples

Find: W, K and S

Optimize: Maximize S

Constraint: Ep < Emax

Approach: Do an empirical study to understand the interplay between W, K and S and their impact on Ep.

Real time data sets gathered with a sampling period of 5 minutes

impact of window size
Impact of Window Size
  • Observe evolution of prediction error with window size.
    • Fix the sampling period
    • Fix the model estimation to be linear
  • U-type behavior
    • For smaller W, we have less samples for accurately estimating the model.
    • For higher W, its an over-constrained problem.

Their exists an optimal window size

interplay between sampling period and window size
Interplay between Sampling Period and Window Size

Beyond a particular sampling period, optimal window

size is equal to the minimum possible i.e.2.

Optimal window size changes with the sampling period

existence of optimal time history
Existence of Optimal Time History

T = 8 minutes

  • But……
    • W * S = Constant (T)
  • Any time history beyond T minutes is worthless.

S = 1 minute, W=8

S = 2 minute, W=4

S >= 8minute, W=?

Optimal point of operation is easily deducible

impact of estimation scheme
Impact of Estimation Scheme
  • Minimum error for linear is lower
  • (T)quadratic > (T)linear
    • For the same W, higher energy overhead

(S)quadratic > (S)linear

    • For the same S, higher storage overhead

(W)quadratic > (W)linear

Linear is the best estimation strategy

time synchronization control loop

Sample

Repository

Model

Estimation

Error

Prediction

Sampler

Time Synchronization Control Loop

How to predict error?

error prediction
Error Prediction
  • Use Standard Regression theory to predict error for (1-α) confidence interval.

Upper quantile of t-distribution

With n-2 degrees of freedom

Standard error

  • But reality is not polynomial model….

Ambient conditions

Bias term

  • Bias term cannot be accounted using regression theory!
introduction of scaling factor
Introduction of Scaling Factor
  • Simple approach of widening the confidence bands.

Estimation from

regression theory

Scaling factor

  • How to choose the scaling factor?
    • Use data sets to learn about it -> Reverse engineering!
slide95

Synchronize a pair of nodes A and B.

Sample

Repository

Model

Estimation

Error

Prediction

Sampler

Decide new

beaconing time of A

(TA , TB)

Sampling period (S)

Window (W)

Error

Bound (Emax)

Rate-Adaptive Protocol: RATS

  • Estimate δ.
  • Scale δ by Δ
  • to find EP

Choose

W=max(2,T/S)

Use W samples

to estimate β0and β1

Follow a MIMD

policy to update S

metrics of evaluation
Metrics of Evaluation
  • Faulty ratio
    • Depicts the percentage by which error goes beyond the desired user-level precision
  • Average sampling period
    • Reflects the energy consumption of the protocol.
slide97

Better Energy

Performance

Better Error

Performance

Comparison with best possible periodic strategy

Best possible periodic strategy is not possible in practice.

It gives an upper bound.

Not a single scenario where MIMD performs worse either on error or energy

Energy gains ~ 1.1x – 12.5x

Error gains ~ 1.25x – 13.5x

performance evaluation
Performance Evaluation

Protocol automatically adapts

to the desired user precision

Error bound increases

Energy decreases

performance evaluation1
Performance Evaluation

Protocol automatically adapts

to the ambient conditions

Avg. sampling period

is more for indoor

Error is more for

outdoors

slide100

Comparison with Existing Systems

For an error bound of 90µs

For a scenario of 1 event / day

Energy gain of 2800x due to time sync

tinyos component graph

SoftFloatC

SoftFloatM

1

5

4

2

VClockC

CC1KRadioC

TSCommC

7

CCRadioIntM

TSCommM

VClockM

6

  • 1

3

HTimerC

LinearEstM

  • FRClockM

HTimerM

8

TinyOS Component Graph
memory consumption
Memory Consumption

26990

  • Possible optimizations
    • Reduce size of sample repository and perhaps store it in ROM
    • Move static lookup tables to ROM
    • Reduce TOS_Msg requirements
  • In principle, possible to reduce to 100 bytes of RAM
rats summary
RATS Summary
  • Achieve a desired user-level precision with optimizing on energy.
  • Adapts itself to the environment conditions, noisy measurements, outliers.
  • Does not requires any application-specific customization.
  • Outperforms existing approaches by two-three orders of magnitude.
  • Outperforms best possible hypothetical periodic re-synchronization approach by an order of magnitude.
  • RATS is equivalent to a 300 nW stable clock source
    • By contrast, NIST’s chip-scale atomic clock is 75 mW
open issues in rats
Open issues in RATS….
  • Multihop Synchronization
    • Error is non-gaussian over long-time scales.
    • How to define optimal sampling period
    • What if there is a conflict?
  • Complex Estimators
    • World is not based on polynomial based estimation.
    • How to incorporate factors such as temperature, humidity explicitly?
multihop synchronization

RX

TX

Multihop Synchronization

Simple translation of virtual clock parameters across multiple hops

recall radio duty cycling
Recall: Radio Duty Cycling
  • Goal: minimize idle listening cost

Something important happened.

Need to receive a packet

Keep the radio on for long duration

Listening

Radio off

time uncertainty problem
Time Uncertainty Problem
  • Scenario: A and B need to communicate
  • Clocks at A and B can drift arbitrarily
  • If sleep-listen schedule of these nodes do not intersect, there will be a packet loss

Packet ready

@ Tx

B

A

asynchronous approach bmac
Asynchronous Approach: BMAC
  • Choose a preamble such that receiver is guaranteed to wake up during the preamble transmission time.
  • 11.5% duty cycle  250 bytes or preamble, 2.2% duty cycle  1212 bytes of preamble.
  • This is a large overhead, as in TinyOS one transmits just a 29 byte payload!

Packet ready

@ Tx

Rx ready

B

Preamble

Payload

A

conventional synchronous approaches smac tmac
Conventional Synchronous Approaches: SMAC, TMAC
  • Time-synchronized duty-cycling of nodes.
    • Achieved by periodic re-synchronization.
  • Limited by the current time synchronization approaches.
    • FTSP proposes to synchronize every 45 seconds for achieving 90μs error.

Packet ready

@ Tx

Rx ready

B

Preamble

Payload

A

Drift

Periodic time synchronization

leveraging rats long term synchronization
Leveraging RATS’ Long-term Synchronization

RATS + BMAC  UBMAC

  • Background
    • Minimum preamble length  4
    • Extra bytes added for taking care of time uncertainty.
  • Fixed Preamble mode
    • BMAC chooses to use a preamble of x bytes irrespective of duty-cycle.
    • Maximum time uncertainty allowed -> (x-4)*byte time.
    • RATS objective is to achieve this error bound
  • Variable Preamble mode
    • When transmitting packet BMAC ask RATS to estimate the time uncertainty between the nodes.
    • Based on this, the preamble size is chosen on the fly!
uncertainty driven b mac for motes
Uncertainty-driven B-MAC for Motes
  • 35.5% duty cycle, application level packet every 30s
  • Asynchronous BMAC uses 94B preamble
  • UBMAC (BMAC+RATS) set to use 6B and RATS tries to keep error bound within 2B = 832us
  • 24 hour experiment
    • BMAC: 2800 packets with 94B preamble
    • UBMAC: 2800 packets with 6B preamble + 28 RATS packets
    • Total energy improvement at Tx: 3X
    • Similar gains at Rx, as it too is on for shorted duration
  • RATS is equivalent to having a stable clock source of < 300 nW
packet loss performance
Packet Loss Performance
  • Loss rates are comparable.
    • Packets are lost because of channel ambiguities.
  • No bulk packet losses
    • No packet lost because of the time uncertainty problem.
  • Extra energy gains
    • At Rx: Receiving a shorter preamble.
    • Piggyback timestamp information: Cut-down extra packets.

Packet loss rates

Indoor

Outdoor

gauging the energy gains
Gauging the Energy Gains
  • Cut off point of relative event and time sync frequency, beyond which energy gains of UBMAC over BMAC constant
  • With lower duty-cycle energy gains increases.
    • UBMAC -> Functionality remains unchanged,
    • BMAC -> Need to use a longer preamble to tackle the worst-case.
  • For applications with mild latency constraints (1.5s per hop == 1% duty cycle), energy gains of UBMAC can be up to 60x than BMAC.
handling bad scenarios
Handling Bad Scenarios
  • What if there is a steep transient?
    • Won’t we have multiple packet losses?
    • RATS will take time (the next sample) to adjust.
  • BMAC has MAC level acks integrated into the state machine.
    • Exploit it!
    • On bulk packet losses, trigger a panic time sync beacon exchange.
    • Even if it is a false positive, loss is just one packet transmitted!
  • Or, how about detecting sudden changes in ambient and switching to BMAC-like long preamble?
global consistency

1

4

2

3

Sender

Receiver

R-R

I

S-R

R-R

  • In large networks, several conversion paths exist
  • Combining the different sources of information can give us better end-to-end synchronization.

II

S-R

III

S-R

S-R

S-R

Global Consistency
  • Event occurs at node A at local time t1
  • Convert this time t1 to node B clock
    • directly via skew/offset relative to B
    • indirectly via skew/offset relative to C and then C’s skew/offset relative to B
  • These times might be different!

A

B

C

optimal synchronization
Optimal Synchronization

Recent work by Karp et. al

  • Assumptions
    • no clock drift
    • Error is Gaussian and independent
    • variance of error is known
  • Theorem:

Minimum-variance estimator is globally consistent

  • Theorem:

The minimum-variance and maximum-likelihood estimates of the offsets coincide

  • Solution to maximum-likelihood estimates is a set of least square equations
    • Feasible by Iterative distributed algorithm
from theory to practice
From Theory to Practice
  • Need to model clock drifts
  • Periodic broadcast by nodes!
    • Energy consumption.
  • How much information needs to be collected?
    • Broadcast rate.
  • Which information needs to be collected?
    • Sender-receiver v/s Receiver-receiver.
    • Hop count.
  • Iterative distributed algorithm
    • Feasibility on motes.
distributed time synchronization as a consensus problem
Distributed Time Synchronization as a Consensus Problem
  • Global averaging
    • Each node broadcasts its local clock time periodically
    • The node waits for time T
      • The node collects the messages broadcast by other nodes.
      • For each message received, the node keeps the local time.
      • At the end of T, the node estimates the skew of its clock with respect to each of the other nodes on the basis of the times at which it received.
      • The node computes a fault-tolerant average of the estimated skews and uses it to adjust its local clock
  • Localized averaging
    • Each node exchanges its clock time with its neighbors
    • Then sets its clock time to the average of its own clock and the clock times of its neighbors
biologically inspired approaches
Biologically-inspired Approaches
  • Synchrony observed in swarms of coupled biological systems
    • Synchronous flashing fireflies in southeast Asia
    • Spiking of neurons
  • Basically, pulse-coupled integrate-and-fire model
    • Nodes integrate the coupling caused by the signal pulses received from other nodes
    • Nodes fire a pulse after reaching a designated threshold
    • Early analytic study by Mirollo & Strogatz in 1990
      • Proved synchronization of a network of pulse-coupled oscillators under assumptions of uniform coupling and zero delay between firing and receiving
    • Later studies with different assumptions on delays and coupling
  • Ideal for ad hoc networks!
    • decentralized and simple mechanism
  • Observation: instead of locking to a central clock or a specific node, all nodes agree on a common phase so that their pulses are maximally aligned
pulse coupling
Pulse Coupling
  • Each node maintains an internal state variable x(t)
  • A pulse is emitted whenever x(t)=1, and the state variable is reset to 0
  • x(t) evolves according to
  • Without coupling, each state equation is periodic with the same frequency but different phase
  • If a neighbor  Ni fires, then the state variable is updated according towhere g() is chosen positive over [0,1]
pulse coupling contd
Pulse Coupling (contd.)
  • Coupled equations:where tj* is the firing time of the j-th oscillator
  • Coupling procedure drives the phase differences to zero
    • Since g() is positive over [0,1], the effect of a single coupling is to decrease the time to fire for the receiving node
convergence property
Convergence Property
  • Key theorem by Mirollo & Strogatz,1990: if the function governing the evolution of state variables is smooth, monotonically increasing, and concave down, then the set of initial states xi(0) i, that never result in synchrony has measure 0.
  • Example, leaky integrate-and-fire model used in pacemakers
    • Pulse-coupled equation for constant coupling functionnote that the summation is over all nodes in the network, which implies all-to-all communication
convergence with nearest neighbor coupling lucarelli04
Convergence with Nearest Neighbor Coupling [Lucarelli04]
  • Set on n oscillators coupled according to n interconnection graph G and with identical uncoupled dynamics and identical coupling functions
  • Theorem Lucarelli et. al., SenSys 2004: Let GC be a connected graph describing the coupling topology of a system of oscillators of the above form. If g/f is an uneven function such that (0)=0 and · ()>0, 0, then in the limit as 0, the system asymptotically synchronized for any initial condition x0D, where D is a compact subset of [0,1]n.
linear protocol
Linear Protocol
  • Coupled state equations
  • Firing updates are given by
  • Result: convergence to synchronization is robust with respect to the communication link delay, provided the delay is less than /2max(G) where max(G) is the maximum eigen value of the graph Laplacian L(G) = D(G)-A(G) = Degree Matrix - Adjacency Matrix
big picture we need many methods
Big Picture: We need many methods!

Goal: make the set rich enough to minimize waste

Time Sync Parameter Space:

(max error, lifetime, scope, etc.)

Available Sync

Methods

Better

Application Requirement

Better

big picture we need many methods1
Big Picture: We need many methods!

Goal: make the set rich enough to minimize waste

Time Sync Parameter Space:

(max error, lifetime, scope, etc.)

Ideally, methods

should be tunable

Better

Application Requirement

Better

need for new service models for sensor networks
Need for new service models for sensor networks?
  • Traditional time synchronization: “What time is it”?
    • Forces clocks to be synchronized all the time
    • Forces synchronization to pick one timescale
  • Sensor networks also need explicit conversions to relate a node’s clock to another node’s
    • What time is it here?
    • For a given time here, what’s the time there
summary
Summary
  • Time Synchronization
    • Crucial to any distributed systems but for sensor network it forms the backbone.
  • What has been done?
    • Several protocols with available prototype implementations.
      • Can synchronize nodes within 5 microseconds.
      • Can synchronize nodes on-demand lying on a path.
      • Can provide network-wide time sync.
  • What is currently being done?
    • Long-term time sync: Temporal aspect
  • Challenges….
    • Long-term time sync: Spatial aspect.
    • Secure time sync.