1 / 50

The Flooding Time Synchronization Protocol (SenSys ’04, November 3-5, 2004)

The Flooding Time Synchronization Protocol (SenSys ’04, November 3-5, 2004) Authors: Miklos Maroti, Branislav Kusy, Gyula Simon & Akos Ledeczi Presenter: Ryan Sites 10-13-05. Today’s Agenda. Introduction Uncertainties in Sending/Receiving a Radio Packet

jafari
Download Presentation

The Flooding Time Synchronization Protocol (SenSys ’04, November 3-5, 2004)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Flooding Time Synchronization Protocol(SenSys ’04, November 3-5, 2004) Authors: Miklos Maroti, Branislav Kusy, Gyula Simon & Akos Ledeczi Presenter: Ryan Sites 10-13-05 Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  2. Today’s Agenda • Introduction • Uncertainties in Sending/Receiving a Radio Packet • Alternate Approaches to Time Synchronization • Flooding Time Synchronization Protocol • Calculating the Network Synch Time • Experimental Results • Comparison to Alternate Approaches • Conclusion Overview Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  3. Wireless Sensor Networks • What are wireless sensor networks (WSN)? • Distributed system • Most likely nodes have to communicate by hops • Severe resource constraints • Low-cost • Low-power • Self-organizing • What are the applications of a WSN? • Sonar Arrays • Nanosatellites • Seabird monitoring on Great Duck Island • Home security systems • Anywhere embedded sensing is needed! Introduction Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  4. Time Synchronization • Why Time Synchronization? • Used by a variety of other services • Tracking • Localization • Debugging/logging • Power management • Really any application that needs coordinated action or fused data • Okay, but why do we timestamp? • Messages do not arrive at the base station in order • Some messages are lost/corrupted Introduction Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  5. Reference time is 16:20:00 Network node Introduction Entity of Interest Let’s suppose we have a WSN that is not time synched. Something curious has entered the area and we’d like to track it. Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  6. Reference time is 16:21:00 I see him at 16:20:33 Introduction I see him at 16:22:56 As the object moves through the field our nodes send tracking reports that are timestamped with what the individual node’s local clock says. Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  7. Reference time is 16:24:00 I saw him at 16:20:33 I saw him at 16:23:45 I saw him at 16:25:06 Introduction I saw him at 16:21:36 I saw him at 16:22:56 I saw him at 16:19:56 Eventually every node on the Intruder’s path has reported back to the data collecting station. Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  8. 16:23:45 16:25:06 16:20:33 Introduction 16:22:56 16:19:56 16:21:36 The data collecting station tries to correlate the data to figure out where the Intruder went. Chaos ensues (and this is only a six node network!) Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  9. Synchronize yourself to me! Reference time is 16:24:00 16:23:45 16:21:06 16:20:33 Introduction 16:20:33 16:23:45 16:21:06 But if every node was synched to our reference time, we could easily figure out the path of the Intruder. Unfortunately, it’s not as easy as having a global reference time broadcast its time to all the nodes. Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  10. Today’s Agenda • Introduction • Uncertainties in Sending/Receiving a Radio Packet • Alternate Approaches to Time Synchronization • Flooding Time Synchronization Protocol • Calculating the Network Synch Time • Experimental Results • Comparison to Alternate Approaches • Conclusion Overview Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  11. What Causes Delay in Transmitting a Packet? • Transmitter delays • Send Time – Time needed to create message and issue request to MAC layer • Access Time – Time wasted waiting for access to the channel • Transmission Time – Time needed to transmit the message • Receiver delays • Reception Time – Time needed to receive message • Receive Time – Time needed to interpret the message • Other delays • Interrupt Handling - Time waiting between raising an interrupt and handling it • Encoding/Decoding Time – Time transforming to/from EM waves from/to binary data • Byte Alignment Time – Time needed to synch to different byte alignments between sender and receiver Uncertainties Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  12. Hardware Software Decoding Time Reception Time Propagation Time Transmission Time Receive Time Encoding Time Interrupt Handling Time Uncertainties Access Time Send Time Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  13. Today’s Agenda • Introduction • Uncertainties in Sending/Receiving a Radio Packet • Alternate Approaches to Time Synchronization • Flooding Time Synchronization Protocol • Calculating the Network Synch Time • Experimental Results • Comparison to Alternate Approaches • Conclusion Overview Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  14. Different Ways to Time Synch • Network Time Protocol (Mills, 1991) • Reference Broadcast Synchronization (Elson, Girod, Estrin, 2002) • Timing-Sync Protocol for Sensor Networks (Ganeriwal, Kumar, Srivastava, 2003) • Flooding Time Synchronization Protocol Alternate Approaches Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  15. Network Time Protocol (NTP) External source (ex. GPS Satellite) Message contains server’s local time (not stamped in the MAC layer) Alternate Approaches • Low precision due to nondeterminism in MAC layer • Introduces 100’s of ms delay at each hop • Not really developed for WSN • But it is the synch method for packet switched data networks NTP Time Server Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  16. Reference Broadcast Synchronization Message does not contain server’s time Alternate Approaches • Nodes hear server’s message • No time in server’s message, so no nondeterminism in MAC layer • Eliminates access and send times • Requires add’l messages as nodes retransmit their recorded local time • *Experimented on (nearly) the same platform as FTSP Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  17. Timing-sync Protocol for Sensor Networks • First create a static tree of all nodes • Each node sends two sync messages to its parent (no message broadcasting) • Twice as accurate as RBS due to averaging of multiple messages • Does not estimate clock drift • Does not handle dynamic topology changes • Eliminates access time, propagation time and byte alignment time • *Experimented on (nearly) the same platform as FTSP Alternate Approaches Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  18. Overview • Introduction • Uncertainties in Sending/Receiving a Radio Packet • Alternate Approaches to Time Synchronization • Flooding Time Synchronization Protocol • Calculating the Network Synch Time • Experimental Results • Comparison to Alternate Approaches • Conclusion Overview Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  19. Flooding Time Synch Protocol When node receives message, it timestamps it as well Message contains sender’s time Each node knows its local time FTSP R • (Ideally) One root sender, multiple receivers, one message (without an acknowledgement) • Sender timestamps its message in the MAC layer • Receiver timestamps the received message in the MAC layer as well • Offset is the difference between global and local timestamps • Uses Linear Regression to compensate for clock drift Contains the global time Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  20. Data Packet • Preamble – Used to synch receiver radio to carrier frequency • Sync – Used to calculate bit offset • Timestamps are made at each byte boundary after Sync bytes are transmitted or received…the average reduces the interrupt handling and encoding/decoding times • Data – Meat of the message • CRC – Cyclic Redundancy Check, type of hash function used to produce a checksum, needed for error checking FTSP Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  21. Handling Clock Drift • Synching to a global clock is only part of the problem • Even among identical systems, crystal frequency can be different e.g. different clocks have different definitions of a second • Mica2 clock drifts up to 40 microseconds per second • Therefore we must periodically re-synch • But what about energy consumption? Bandwidth? • Can we estimate? FTSP Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  22. Handling Clock Drift (cont.) • Assume: Short term stability in clocks • Gather offsets over multiple transmissions • Use linear regression to compensate for clock drift FTSP Global-local time pair Table on Node R Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  23. Linear Regression • A method of estimating the expected value of one variable given the values of some other variable • Y – Dependent Variable • X – Independent Variable • Relationship of X & Y is assumed to be linear • Y = ά+βX+έ, where έ is the unexplained variation in Y (hopefully 0)* • So, we do linear regression from localTime to calculate the globalTime • Skew is the ratio of the frequency of the globalTime crystal to the localTime crystal (root skew = 1) FTSP * From wikipedia Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  24. Linear Regression (cont.) • Offset = skew * localTime + offset_0 (1) • OffsetAverage = skew * localAverage + offset_0 (2) • We know the localTime so we subtract (1) and (2) • Offset – offsetAverage = skew * (localTime – localAverage) • GlobalTime = offset – localTime • Therefore, globalTime = offsetAverage + skew * (localTime – localAverage + localTime) FTSP Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  25. Handling Clock Drift (cont.) FTSP Using two nodes Estimating off of eight data points Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  26. Handling Clock Drift (cont.) FTSP So, how often should we resynch? Little difference between 30 secs and 300 secs Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  27. Code • async command result_t GlobalTime.local2Global(uint32_t *time) • { • *time += offsetAverage + (int32_t)(skew * (int32_t)(*time - localAverage)); • return is_synced(); • } • async command result_t GlobalTime.global2Local(uint32_t *time) • { • uint32_t approxLocalTime = *time - offsetAverage; • *time = approxLocalTime - (int32_t)(skew * (int32_t)(approxLocalTime - localAverage)); • return is_synced(); • } • void calculateConversion() • { • float newSkew = skew; • uint32_t newLocalAverage; • int32_t newOffsetAverage; • int64_t localSum; • int64_t offsetSum; • int8_t i; • for(i = 0; i < MAX_ENTRIES && table[i].state != ENTRY_FULL; ++i) • ; • if( i >= MAX_ENTRIES ) // table is empty • return; • /* • We use a rough approximation first to avoid time overflow errors. The idea • is that all times in the table should be relatively close to each other. • */ • newLocalAverage = table[i].localTime; • newOffsetAverage = table[i].timeOffset; FTSP Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  28. Code (cont.) • localSum = 0; • offsetSum = 0; • while( ++i < MAX_ENTRIES ) • if( table[i].state == ENTRY_FULL ) { • localSum += (int32_t)(table[i].localTime - newLocalAverage) / tableEntries; • offsetSum += (int32_t)(table[i].timeOffset - newOffsetAverage) / tableEntries; • } • newLocalAverage += localSum; • newOffsetAverage += offsetSum; • localSum = offsetSum = 0; • for(i = 0; i < MAX_ENTRIES; ++i) • if( table[i].state == ENTRY_FULL ) { • int32_t a = table[i].localTime - newLocalAverage; • int32_t b = table[i].timeOffset - newOffsetAverage; • localSum += (int64_t)a * a; • offsetSum += (int64_t)a * b; • } • if( localSum != 0 ) • newSkew = (float)offsetSum / (float)localSum; • atomic • { • skew = newSkew; • offsetAverage = newOffsetAverage; • localAverage = newLocalAverage; • numEntries = tableEntries; • } • } FTSP Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  29. Multi-hop Time Synchronization • Some considerations… • Need a single root point in the network • What if we have more than one? • What if we lose the one? • What if a new, better one enters the network? • Assume every node in the network has a unique numerical ID FTSP Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  30. timeStamp rootID seqNum Multi-hop (cont.) • Synchronization Message • timeStamp – the global time of the transmitter (not necessarily the root) • rootID – the ID of the perceived root • seqNum – Incremented by the root, used to indicate a new synchronization round • Keep up to eight messages in table • But which ones? There can be so many… FTSP rootID: 23seqNum:17timestamp:1236 Which one(s) do I choose? rootID: 23seqNum:17timestamp:1235 R rootID: 23seqNum:17timestamp: 1234 Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  31. Multi-hop (cont.) • Determining which messages to keep • Keep message if (rootID <= myRootID AND seqNum >= highestSeqNum) • Guarantees that only the first message from each rootID/seqNum pair is used • If we get something way off (100 ms), clear the table FTSP *heartBeats – number of successfully sent messages since adding a new entry with a lower root ID than ours Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  32. Root Election • ROOT_TIMEOUT – if node does not receive new message in this many broadcast periods, it elects itself • This could cause numerous roots to appear in network • To avoid this, whenever a node receives a new message that contains a rootID that is < myRootID, the node acquiesces to the rootID • So by the end of the synchronization, who should be root? • ROOT_TIMEOUT is also used if a new node with a lower ID is introduced to the network • New node does not declare itself as root until ROOT_TIMEOUT has elapsed • During this time, it calcs its offset to the global time of the network • This provides a smooth transition FTSP Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  33. Root Election (cont.) • NUMENTRIES_LIMIT – the number of entries in the regression table needed before linear regression is performed FTSP Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  34. Today’s Agenda • Introduction • Uncertainties in Sending/Receiving a Radio Packet • Alternate Approaches to Time Synchronization • Flooding Time Synchronization Protocol • Calculating the Network Synch Time • Experimental Results • Comparison to Alternate Approaches • Conclusion Overview Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  35. How Long Does This Take? • N = NUMENTRIES_LIMIT • M = ROOT_TIMEOUT • P = Message Broadcast Period • R = Radius of network from root node (which is unknown at this time) • Assume: • No elected root in network • All nodes powered on at same time • Regression table is not cleared • At least one node has at least N entries in its table R Network Synch Time Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  36. How Long Does This Take? (cont.) • P*M – all nodes declare themselves root • Nodes do not broadcast synch messages until N is reached • Minimum time for network to synch to lowest node ID • P*(N-1)*R • Maximum • P*N*R • Total time is between P*(M+(N-1)*R) and P*(M+N*R) • What if we decrease P? Network Synch Time Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  37. Today’s Agenda • Introduction • Uncertainties in Sending/Receiving a Radio Packet • Alternate Approaches to Time Synchronization • Flooding Time Synchronization Protocol • Calculating the Network Synch Time • Experimental Results • Comparison to Alternate Approaches • Conclusion Overview Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  38. Setting Up the Experiment • Killing the root of the network • Removing a portion of the network • Adding a new portion to the network • Used 60 Mica2s (plus a base station and querying node)… Experiment Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  39. The Target Platform • Mica2 • Developed by Crossbow • 7.37 MHz processor • 4K of RAM • 128K of flash • 433 MHz ChipCon radio • Two AA batteries • TinyOS • Open-source, lightweight OS • Event driven • Modular • Uses a variant of C++ called nesC Experiment www.tinyos.net Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  40. Experiment Parameters • P = 30 seconds • NUMENTRIES_LIMIT = 3 • ROOT_TIMEOUT = 6 • R = 6 (initially) • All links are enforced through software (therefore nodes can not talk to anyone but their eight neighbors) Experiment Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  41. Experiment A – Power on (at 4 mins) B – ID1 (the first root) killed C – Random resetting of nodes D – All nodes with odd IDs off E – Odd IDs powered back on F – Experiment end Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  42. Power On and Root Election • For P*M (30*6) seconds, nobody is root • At 7 mins, everybody timed out so everybody is a root • At 17 mins, ID1 is named root • At 18 mins, 100% node synchronization Experiment Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  43. The Death of ID1 • ID1 powered off at 1 hour • Another P*M transpires before nodes timeout (but they keep their offset and drift estimates!) • Unable to tell when ID2 is elected (authors claim at 1:06) • Why did the error stay low during reelection? • Why is error climbing after 1:10? (hint: R now equals 11) Experiment Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  44. Introducing New Nodes • After a half-hour, odd ID nodes are switched back on at 3:01 • Why does the % of synchronized nodes drop? Experiment Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  45. Conclusions of Experiment • Before ID1 powered off • Max average error is 3 microsecs • Over 6 hops, .5 microsecs per hop • Max error was 14 microsecs • After ID1 powered off • Max average error is 17.2 microsecs • Over 11 hops, 1.6 microsecs per hop • Max error was 67 microsecs Experiment Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  46. Today’s Agenda • Introduction • Uncertainties in Sending/Receiving a Radio Packet • Alternate Approaches to Time Synchronization • Flooding Time Synchronization Protocol • Calculating the Network Synch Time • Experimental Results • Comparison to Alternate Approaches • Conclusion Overview Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  47. How Does FTSP Compare? • Accuracy • RBS - On two node network, a 29.1 microsec error • TPSN – On two node network, 16.9 microsec error • FTSP – On our 60 node network, 3 microsec error • *Experiments were ran on Micas, which have a 4Mhz clock • Communication Overhead • FTSP – 1 message per T seconds • RBS – 1.5 messages per T seconds • TPSN – 2 messages per T seconds • Network Topology • FTSP supports dynamic network topology chances • TPSN does not Comparison Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  48. Today’s Agenda • Introduction • Uncertainties in Sending/Receiving a Radio Packet • Alternate Approaches to Time Synchronization • Flooding Time Synchronization Protocol • Calculating the Network Synch Time • Experimental Results • Comparison to Alternate Approaches • Conclusion Overview Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  49. Future Work • Testing FTSP in larger networks • Splitting the broadcast period into two • Short period for initial synch period • Long period for normal operation • Rapid Time Synchronization • http://inrg.cse.ucsc.edu/secon05/demo-abs/RATS_Demo_Abstract.pdf • Applications! Conclusion Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

  50. Wrap-Up • WSNs need time synchronization • FTSP offers a robust and accurate algorithm • Uses one broadcasted message timestamped in low layers to eliminate errors • Uses linear regression to estimate clock drift • Uses root election to converge to lowest ID’s localtime • Tested extensively • Any questions? • Thanks for listening! Conclusion Ryan Sites – CEG 790 Paper PresentationThe Flooding Time Synchronization Protocol

More Related