Time SynchronizationMurat Demirbas

SUNY Buffalo

2

Need for TimeSync

• Typical purpose of sensor networks: collect sensor data, log to database and correlate with time, location, etc.

TimeSync may be avoided: The nodes can track the delays incurred to a message at each hop towards the basestation, and the basestation can punch a timestamp for the received message accordingly.

• Power management requires timesync for coordinated sleep and wakeup of nodes

• TDMA based networking strategies requires timesync• Coordinated action in sensor-actuator networks• Certain applications (such as Sniper localization) requires

timesync

3

Requirements

• Efficiency Memory constraints Energy constraints

• Scalability

• Robustness

4

Outline

• Uncertainties in clock hardware in sensors• Uncertainties in radio message delivery• Flooding Time Synchronization Protocol (FTSP)

Single-hop Multi-hop

• Reference Broadcast Synchronization (RBS)

5

Clock hardware in sensors

• Typical sensor CPU has counters that increment by each cycle, generating interrupt upon overflow

we can keep track of time, but managing interrupts is error-prone

• External oscillator (with hardware counter) can increment, generate interrupt

even when CPU is “off” to save power

6

Uncertainties in clock hardware

• cheap, off-the-shelf oscillators can deviate from ideal oscillator rate by one unit per 10-5 (for a

microsecond counter, accuracy could diverge by up to 40 microseconds each second)

oscillator rates vary depending on power supply, temperature

7

Uncertainties in radio

• Send time: Nondeterministic, ~100ms Delay for assembling message & passing it to MAC layer

• Access time: Nondeterministic, ~1ms-~1sec Delay for accessing a clear transmission channel

• Transmission time: ~25ms Time for transmitting (depends on message size, radio clock speed)

• Propagation time: <1microsecond Time bit spends on the air (depends on distance between nodes)

• Reception time: overlaps with transmission time• Receive time: Nondeterministic, ~100ms

Delay for processing incoming message and notifying application

8

MAC layer timestamping

• Message can be timestamped during transmission and reception

Mica2 and TinyOS enable direct access to MAC layer

• This eliminates 3 main sources of uncertainties Send time, access time, and receive time are eliminated

• However, uncertainties remain due to overlapping transmission and reception times

9

Close up

• Interrupt handling time ~1microsec-~??microsec Delay between radio chip raising and CPU responding Abuses of interrupt disabling may cause problems

• Encoding time ~100microsec Delay for putting the wave on air

• Decoding time ~100microsec Delay for decoding wave to binary data

• Byte alignment time Delay due to different byte alignment of sender and receiver

10

Close up…

11

Delays in message transmission

12

Outline

• Uncertainties in clock hardware in sensors• Uncertainties in radio message delivery• Flooding Time Synchronization Protocol (FTSP)

Single-hop Multi-hop

• Reference Broadcast Synchronization (RBS)

13

Flooding Time Synchronization

• FTSP syncronizes time of a sender to multiple receivers RBS performs receiver-to-receiver synchronization

• Two important ideas MAC layer timestamping Compensation for clock drift

• Protocol for extending single-hop sync to network-wide sync

14

MAC layer timestamping

• FTSP reduces the jitter of the interrupt handling and encoding/decoding times by recording multiple timestamps at the sender and receiver

Timestamps made at each byte boundary These timestamps are normalized to detect the jitter due to disabled

interrupts The minimum of the normalized timestamps is sent only

15

Clock drift management

• Need to estimate the drift of the receiver clock wrt sender clock to avoid sending frequent sync messages

• The offset between two clocks changes in a linear fashion Linear regression is used to find the line L best approximating over the

past 8 data points

16

Multi-hop timesync

• All the nodes sync their clocks to that of the root Root is a single, dynamically re-elected node

• Nodes form an ad hoc structure, as opposed to a fixed spanning tree, to transfer the global time from the root to all nodes

When a node collects enough data points, it can estimate its skew and offset, and is considered synchronize

Only synchronized nodes broadcast sync messages to the rest of the network

17

Handling of sync messages

18

Sending of Sync messages

19

Convergence time

• Depends on N: NUMENTRIES_LIMIT M: ROOT_TIMEOUT R: Network radius measured from the current root

• Start-up convergence time P*(M+N*R)

• Root-failure convergence time P*(R+M+R’)

20

Experimental data

21

Outline

• Uncertainties in clock hardware in sensors• Uncertainties in radio message delivery• Flooding Time Synchronization Protocol (FTSP)

Single-hop Multi-hop

• Reference Broadcast Synchronization (RBS)

22

RBS idea

• Use broadcast as a relative time reference Broadcast packet does NOT include timestamp Any broadcast, e.g., RTS/CTS, can be used

• A set of nodes synchronize with each other (not with the sender)

Significantly reduces non-determinism

23

Reference broadcast• when operating system cannot record instant of

message transmission (access delay unknown), but can record instant of reception

m1 m1 is received simultaneously by multiple receivers: each records a timestamp value contained in m1

24

Critical Path Analysis

Traditional RBS

Send Time

AccessTime Prop.

DelayRec.Time

25

Reference broadcast…• after getting m1, all receivers share their local

timestamps at instant of reception

now, receivers come to consensus on a value for synchronized time: for example, each adjusts local clock/counter to agree with average of local timestamps

26

Multi-Hop Time Synchronization

27

Multi-Hop RBS Performance

Average path error is approximately n for an n hop path