Download presentation
Presentation is loading. Please wait.
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
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.