1. Time Synchronization Murat Demirbas SUNY Buffalo

2. 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. 3 Requirements Efficiency  Memory constraints  Energy constraints Scalability Robustness

4. 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. 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. 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. 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. 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. 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. 10 Close up…

11. 11 Delays in message transmission

12. 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. 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. 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. 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. 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. 17 Handling of sync messages

18. 18 Sending of Sync messages

19. 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. 20 Experimental data

21. 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. 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. 23 Reference broadcast when operating system cannot record instant of message transmission (access delay unknown), but can record instant of reception m1m1 m 1 is received simultaneously by multiple receivers: each records a timestamp value contained in m 1

24. 24 Critical Path Analysis Traditional RBS Send Time Access Time Prop. Delay Rec. Time

25. 25 Reference broadcast… after getting m 1, 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. 26 Multi-Hop Time Synchronization

27. 27 Multi-Hop RBS Performance Average path error is approximately  n for an n hop path