470 likes | 618 Views
Time Synchronization in Sensor Networks. EE206A Athanasios Stathopoulos Huiyu Luo. Time Synchronization in Ad Hoc Networks. Kay Romer. The Sensor Network Here. Nodes are highly dynamic & sparsely distributed Links are short range and short lived
E N D
Time Synchronization in Sensor Networks EE206A Athanasios Stathopoulos Huiyu Luo
Time Synchronization in Ad Hoc Networks Kay Romer
The Sensor Network Here • Nodes are highly dynamic & sparsely distributed • Links are short range and short lived • Messages are transmitted in a store and forward fashion 1 2 3
Synch Sensor Network • Temporal relations play an important role in sensor fusion Which event happened first? • Physical time is itself part of information: e.g. Estimation of target position, direction, speed Providing fire breaking time
Difficulties! • No periodic message exchange is guarante-ed to occur among nodes There may be no links at all • Transmission delay between two nodes is hard to estimate The link distance changes all the time
About Computer Clocks • Clocks in computers • Clock Skew • Due to the clock drift, the local clock need to be periodically synchronized to maintain an accurate global time
Synchronization Scheme • Don’t try to synchronize local clocks all the time • Generate time stamps to record the events’ occurring time • The time stamps are updated along its way by each node using its own local clock • As the result of clock shift and message propagation delay, the final time stamp is expressed as a lower and upper bound
An Example When 1 senses an event, it starts counting time with its clock. 1 sends 2 a message regarding the event, and a time stamp including how long the time has elapsed since the event 1 2 3 N
1 2 3 N A Example (Continued) 2 estimates the transmission delay to the time stamp and continues counting the time Messages are forwarded the same fashion as 12 to node N N is able to recover the time by looking at the time stamp
Assumptions • Maximum clock skew is known • The link can survive long enough so that a synchronization message can be sent after the application message
Time Transformation • Recall • Real time estimation based on clock 1 • Time difference in local clock 2
t4 t5 t6 M1 ACK1 M2 ACK2 t3 t1 t2 Message Delay Estimate delay for M2 Sender: Receiver: Receiver Sender
Note • A transmission of M2 is necessary for receiver to obtain an estimation of delay! Dummy message might need to be sent • It is desirable to make the interval between M1 and M2 short • Notation idle=t2-t1 rtt=t3-t2
1 2 3 N Add Them Together! • Node N puts together the time counted by all the nodes and message delays idle1 idle2 rtt1 rtt2 r1 r2 r3 rN s1 sN s2 s3 3 N 1 2
Evaluation Shows • Inaccuracy is proportional to time stamp length • Time stamp length increases linearly with • the age of time stamp • the number of hops S1 S2
A Simulation • Number of hops <= 5 • Age of time stamp <= 500 s • Length of time stamp <= 3 ms • Able to distinguish two events with time separation >= 6 ms
Possible Improvements • Store and forward the history of time stamp. • Look for common node in history when two time stamps overlap • When events have overlapping time stamps • Use statistical tools to analyze the probability that one event happens before another
Conclusion • The difficulties in synchronizing a type of sensor network are being considered • A new scheme has been proposed • Provides low overhead for a sparse sensor network with low data rate • The time estimation is well bounded • The scheme is evaluated and possible improvements are further proposed
Network-wide Time Synchronization in Sensor Networks Saurabh Ganeriwal Ram Kumar Sachin Adlakha Mani Srivastava
Basic Concept • First create a hierarchical topology in the level discovery phase • As a result, each node is assigned a unique level:0 (root node)12…N • A time synchronization phase is initialized by the root node • Each node synchs to the node which is one level lower than itself
Sender Initiated Synch • Clock drift and propagation delay d between two nodes are estimated by T2 T3 Receiver T1 T4 Sender
Algorithms • Level discovery • Time synchronization • New node: Level request • Root node dies: Local leader election
Level Discovery • Root node initiates the phase by broadcast-ing a level_discovery packet • Upon receiving the packet, each node assi-gns itself a level and broadcast a new level-_discovery packet • Eventually each node in the network is assigned a unique level
Time Synchronization • Root starts the phase by broadcasting a time_synch packet • Nodes in level one wait for some random time and start a two way message exchange to synch their local clocks • This is carried out throughout the whole network
Special Cases • If a node is not assigned a level due to collision or new node, level request is being sent to recover a level from its neighbors • If the root node dies, the level one nodes will undergo a local leader election algorithm
Simulation • Overhead time vs. # of nodes
Simulation • Accuracy synch error vs. level #
Conclusion • A synchronization scheme for absolute time in sensor networks was introduced • The algorithms are scalable since • The accuracy is independent of number of nodes and node clock drift • The overhead is linearly proportional to the network size
Fine-Grained Network Time Synchronization using Reference BroadcastsJeremy Elson, Lewis Girod and Deborah EstrinLECS Lab, UCLA
NTP Overview • Most widely used time synchronization protocol • Hierarchical: server, client, peer • stratum levels • Redundant: each daemon can use several independent time sources • Daemon can pick the most accurate one • Perfectly acceptable for most cases • E.g. Internet (coarse grain synchronization) • Inefficient when fine-grain sync is required • E.g. sensornet applications: localization, beamforming, TDMA scheduling etc
Sources of time synchronization error • Send time • Kernel processing • Context switches • Transfer from host to NIC • Access time • Specific to MAC protocol • E.g. in Ethernet, sender must wait for clear channel • Propagation time • Dominant factor in WANs • Router-induced delays • Very small in LANs • Receive time • Common denominator: non-determinism
Proposed solution: Reference Broadcast Synchronization • RBS synchronizes a set of receivers with each other • In contrast, traditional timesync protocols synchronize a sender with a receiver • Nodes periodically send beacon messages to their neighbors • Requirement: broadcast medium • No-go for point-to-point links • But, can be extended beyond a LAN
RBS: Minimizing the critical path • RBS removes send and accesstime errors • Broadcast is used as a relative time reference • Each receiver synchronizing to a reference packet • Ref. packet was injected into the channel at the same instant for all receivers • Message doesn’t contain timestamp • Almost any broadcast packet can be used, e.g ARP, RTS/CTS, route discovery packets, etc All figures from Elson et. al.
RBS: Phase offset estimation • Simplest case: single pulse, two receivers • Xmitter broadcasts reference packet • Each receiver records the time that beacon was received according to its local clock • Receivers exchange observations • Sufficient information to form a local (relative) timescale • However, global timescales are also important
RBS: Phase offset estimation (cont’d) • Extending simple case to many receivers • Assumptions • Propagation delay is zero • No clock skew • Receiver non-determinism (error) is Gaussian • Sending more messages increases precision • Transmitter broadcasts m packets • Each receiver records time the beacon was observed • Receivers exchange observations • Receiver i computes phase offset to receiver j as the average of the offsets implied by each pulse received by both nodes • Result:
RBS: Phase offset estimation Numerical analysis results • Numerical analysis for m=1..50, n=2..20 • 1000 trials for each m, n • Results: mean dispersion, std.dev • 2-receiver case • 30 broadcasts improve precision from 11 usec to 1.6 usec • 20-receiver case • Dispersion reduced down to 5.6 usec
RBS: Clock skew estimation • Oscillator characteristics • Accuracy: difference between expected and actual frequency • Difference: Frequency error (usually 10-4 – 10-6) • Stability: tendency to stay at same frequency over time • Phase difference between two nodes’ clocks will change due to frequency differences • RBS compensation: instead of averaging phase offsets, perform least-squares linear regression • Frequency and phase of local node’s clock recovered from slope and intercept of the line • Fitting a line assumes that frequency is stable • Assume high short-term frequency stability • Ignore data more than a few minutes old
RBS: Clock skew estimationImplementation results • 2 receivers (motes): r1, r2 • Point (0,0) marks the first pulse • Receivers synchronized, no clock skew • Clock skew increases as time increases • Linear fit gives good results • With clock skew estimation, sufficient information exists to convert any time value generated by r1’s clock to a time value that would have been generated by r2’s clock
RBS: Comparison with NTP • Comparison performed on commodity hardware • IPAQs running Linux • 802.11 wireless Ethernet adapters • RBS, NTP are user-space drivers • 3 different synchronization schemes • RBS • NTP • NTP-Offset • NTP by default limits rate at which it corrects phase error • Although it still keeps an estimate of it • meant to prevent transient frequency errors from being visible in applications • Solved by querying NTP daemon on each trial • Two traffic scenarios • Light load • Heavy load
RBS: Multi-Hop synchronization • Goal: compare times of two events that occurred near receivers 1 and 7 • Nodes A and B periodically send sync pulses • Node 4’s unique position allows it to relate clocks from one cluster to the other • Multihop algorithm • Receivers R1 and R7 observe events at times E1(R1) and E7(R7). • R4 uses A’s pulses to establish best-fit line, in order to convert E1(R1) to E1(R4) • Similarly, R4 converts E1(R4) to E1(R7) • Desired time = E1(R7)-E7(R7)
Physical topology Logical topology. Edges are drawn between nodes that have received a common broadcast RBS: Multi-Hop synchronization(cont’d) • Path through logical topology represents a series of timebase conversions • By performing shortest-path search one can automatically find the conversion series. • Weights can be used to represent quality of conversion and improve shortest-path algorithm results • Problem: shortest-path algorithms don’t scale due to dependence on global information • Solution: Time conversion can be built into the packet forwarding mechanism
GPS Clocks • GPS system’s master clock always kept to within 1 usec accuracy of USNO’s master clock • Each satellite has 4 atomic clocks on board • Always kept within 250 nsec accuracy of each other • LOS to only one satellite needed to extract time information • GPS clock can generate an interrupt every second (thereby sending a PPS) • PPS accuracy of commercial GPS clocks is 1 usec • Cost: ~ $400
RBS: Synchronization with external time scale (GPS) • Absolute time synchronization required for many applications • Reference timescales available via systems like GPS • A GPS receiver can be a node in the RBS-synchronized network • PPS output is the reference broadcast • Host node attached to GPS receiver synchronizes its clock to the GPS time • Phase and skew of node’s clock relative to GPS time can be recovered using presented algorithms • Other nodes can use GPS time by finding multihop conversion route
RBS: Conclusions • Synchronizes a set of receivers with each other • Broadcasts remove largest sources of non-deterministic error • Residual receiver error is often a well-behaved distribution • RBS outperforms NTP • 8 times better for light load • Remarkable performance on heavy load • Multiple broadcasts allow estimation of clock skew • Useful for post-facto synchronization • Extendable across broadcast domains • Can use global timescale • Cannot be applied to the Internet at large • Only works with broadcast medium, not point-to-point links
References • Kay Romer Time Synchronization in Ad Hoc Networks • Saurabh Ganeriwal et al. Network-wide Time Synchronization in Sensor Networks • Jeremy Elson et al. Fine-Grained Network Time Synchronization Using Reference Broadcasts • http://www.gpsclock.com/gps.html