Date post: | 20-Dec-2015 |
Category: |
Documents |
View: | 215 times |
Download: | 2 times |
Time Synchronization
Murat 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
m1m1 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