- By
**amal** - Follow User

- 130 Views
- Uploaded on

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

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

- 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

- 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

- 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: 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

- Time is critical at many layers in sensor nets
- Beam-forming, localization, tracking, distributed DSP

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 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
- ……

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?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?

- 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

Time synchronization in sensor networks.

Why it is so crucial?

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

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

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

- Maximum Error
- Lifetime
- Scope & Availability
- Efficiency (use of power and time)
- Cost and form factor

…

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

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

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 CausalityTime

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

- 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 ab
- If a is the sending of a packet by one node and b is the receipt of the same message by another node, then ab
- If ab and bc, then ac
- Two distinct events a and b are said to be concurrent if ab and ba
- Irreflexive partial ordering
- a a
- Another definition: ab is a causally affected b

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 ab then C(a) <C(b)

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

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

Time Synchronization Approaches

in Distributed Systems

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

- 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: 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?

- 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

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

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 SynchronizationFilter 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 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

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

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

What is so different in sensor networks?

Why can we now use NTP or GPS?

Varying demands

Beam-forming, localization, distributed DSP:

small scope, short lifetime, high precision

Figure source: Courtesy of Jeremy Elson

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

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

RBS: Synchronize Receivers

Based on CesiumSpray system by Verissimo and Rodrigues

Receiver-receiver Synchronization

Figure source: Courtesy of Jeremy Elson

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

- 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

- 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

Mica1 motes with narrowband (19.2K) radios

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

- 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

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)

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)

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 SynchronizationBased on NTP

Enemy is non-determinism!

Asymmetric delays and varying offset

Sender

uncertainty

Propagation

uncertainty

Receiver

uncertainty

Magic behind TPSNALL DELAYS ARE VARIABLE !

sender

receiver

software

software

MAC

TX

propagation

RX

Bottleneck

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

- 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

- 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

- 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

- 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

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 RBSComparison 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

- 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

Example Underwater Sensor Network[Syed et. al., ISI-TR-2005-602]

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

- 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

- 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 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 Synchronization

Sync pulses

Drift Estimate

Test pulses

7usec error after 60 seconds of silence

Ref: based on slides by J. Elson

2

5

6

3

4

7

8

9

10

11

Time RoutingThe 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

2

5

6

3

4

7

8

9

10

11

Synchronizing to External StandardsThe 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)

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)

- Theoretically, error increases with hop distance.
- Randomness of drift and sign of error helps.

Microseconds

TPSN – Synchronization phase

- Node synchronize to a node belonging to one upper level
- Use pair wise synchronization.
- Needs symmetric links!

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?

- 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?

- 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

2nd leader

FTSP experimental evaluationtopology:

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

- 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.

Temporal Aspect

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?

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

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

- 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

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

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

- 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

Repository

Model

Estimation

Error

Prediction

Sampler

Time Synchronization Control LoopHow to predict error?

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

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

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

- 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.

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

Protocol automatically adapts

to the desired user precision

Error bound increases

Energy decreases

Performance Evaluation

Protocol automatically adapts

to the ambient conditions

Avg. sampling period

is more for indoor

Error is more for

outdoors

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

SoftFloatM

1

5

4

2

VClockC

CC1KRadioC

TSCommC

7

CCRadioIntM

TSCommM

VClockM

6

- 1

3

HTimerC

LinearEstM

- FRClockM

HTimerM

8

TinyOS Component GraphMemory 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

- 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….

- 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?

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

- 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

- 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

- 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

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

- 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

- 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

- 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

- 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?

Spatial Aspect

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

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

- 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.

Other Distributed Synchronization

Approaches

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

- 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

- 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.)

- 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

- 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]

- 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 x0D, where D is a compact subset of [0,1]n.

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 /2max(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!

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 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?

- 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

- 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.

Download Presentation

Connecting to Server..