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

Ryan Sites – CEG 790 Paper Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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. Network node Reference time is 16:20:00 Introduction

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

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

Ryan Sites – CEG 790 Paper Presentation The Flooding Time Synchronization Protocol 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!) 16:19:56 16:23:45 16:20:33 16:22:56 16:21:36 16:25:06 Introduction

Ryan Sites – CEG 790 Paper Presentation The Flooding Time Synchronization Protocol 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. 16:23:45 16:20:33 16:21:06 Reference time is 16:24:00 Synchronize yourself to me! Introduction

Ryan Sites – CEG 790 Paper Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol Software Hardware Send Time Access Time Transmission Time Propagation Time Reception Time Receive Time Interrupt Handling Time Encoding Time Decoding Time Uncertainties

Ryan Sites – CEG 790 Paper Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol Network Time Protocol (NTP) NTP Time Server -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 Message contains server’s local time (not stamped in the MAC layer) External source (ex. GPS Satellite) Alternate Approaches

Ryan Sites – CEG 790 Paper Presentation The Flooding Time Synchronization Protocol Reference Broadcast Synchronization Message does not contain server’s time -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 Alternate Approaches

Ryan Sites – CEG 790 Paper Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol Flooding Time Synch Protocol R Contains the global time Message contains sender’s time Each node knows its local time When node receives message, it timestamps it as well -(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 FTSP

Ryan Sites – CEG 790 Paper Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol Handling Clock Drift (cont.)  Assume: Short term stability in clocks  Gather offsets over multiple transmissions  Use linear regression to compensate for clock drift Root timestamp Local timestampOffset StateLocal timestamp Offset Full Full Empty Global-local time pairTable on Node R FTSP

Ryan Sites – CEG 790 Paper Presentation The Flooding Time Synchronization Protocol 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) * From wikipedia FTSP

Ryan Sites – CEG 790 Paper Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol Handling Clock Drift (cont.) Using two nodes Estimating off of eight data points FTSP

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

Ryan Sites – CEG 790 Paper Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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… timeStamprootIDseqNum R rootID: 23 seqNum:17 timestamp: 1234 rootID: 23 seqNum:17 timestamp:1235 rootID: 23 seqNum:17 timestamp:1236 Which one(s) do I choose? FTSP

Ryan Sites – CEG 790 Paper Presentation The Flooding Time Synchronization Protocol Multi-hop (cont.)  Determining which messages to keep  Keep message if (rootID = 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 *heartBeats – number of successfully sent messages since adding a new entry with a lower root ID than ours FTSP

Ryan Sites – CEG 790 Paper Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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

Ryan Sites – CEG 790 Paper Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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 Experiment

Ryan Sites – CEG 790 Paper Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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 Presentation The Flooding Time Synchronization Protocol 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  abs/RATS_Demo_Abstract.pdf abs/RATS_Demo_Abstract.pdf  Applications! Conclusion

Ryan Sites – CEG 790 Paper Presentation The Flooding Time Synchronization Protocol 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