Time Synchronization

Time Synchronization Murat Demirbas SUNY Buffalo

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

Requirements • Efficiency • Memory constraints • Energy constraints • Scalability • Robustness

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)

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

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

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

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

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

Close up…

Delays in message transmission

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

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

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

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

Handling of sync messages

Sending of Sync messages

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

Experimental data

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

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

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

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

Multi-Hop Time Synchronization

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

Time Synchronization