Ryan%20Sites%20

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
2
Todays 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
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
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
5
Reference time is 162000
Network node
Introduction
Entity of Interest
Lets suppose we have a WSN that is not time
synched. Something curious has entered the area
and wed like to track it.
6
Reference time is 162100
I see him at 162033
Introduction
I see him at 162256
As the object moves through the field our nodes
send tracking reports that are timestamped with
what the individual nodes local clock says.
7
Reference time is 162400
I saw him at 162033
I saw him at 162345
I saw him at 162506
I saw him at 162136
Introduction
I saw him at 162256
I saw him at 161956
Eventually every node on the Intruders path has
reported back to the data collecting station.
8
162345
162506
162033
Introduction
162256
161956
162136
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!)
9
Synchronize yourself to me!
Reference time is 162400
162345
162106
162033
Introduction
162033
162345
162106
But if every node was synched to our reference
time, we could easily figure out the path of the
Intruder. Unfortunately, its not as easy as
having a global reference time broadcast its time
to all the nodes.
10
Todays 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
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
12
Decoding Time
Reception Time
Propagation Time
Transmission Time
Receive Time
Encoding Time
Interrupt Handling Time
Uncertainties
Access Time
Send Time
13
Todays 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
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
15
Network Time Protocol (NTP)
External source (ex. GPS Satellite)
Message contains servers local time (not stamped
in the MAC layer)
Alternate Approaches

• Low precision due to nondeterminism in MAC layer
• Introduces 100s 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
16
Reference Broadcast Synchronization
Message does not contain servers time
Alternate Approaches

• Nodes hear servers message
• No time in servers message, so no nondeterminism
  in MAC layer
• Eliminates access and send times
• Requires addl messages as nodes retransmit their
  recorded local time
• Experimented on (nearly) the same platform as
  FTSP

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
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
19
Flooding Time Synch Protocol
When node receives message, it timestamps it as
well
Message contains senders time
Each node knows its local time
R
FTSP

• (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
20
Data Packet
FTSP

• 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 receivedthe
  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

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
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
Root timestamp Local timestamp Offset
1129031942 1129031996 0000000054
1129032763 1129032864 0000000101
1129040002 1129040102 0000000100
State Local timestamp Offset
Full 1129031996 0000000054
Full 1129032864 0000000101
Empty
Global-local time pair
Table on Node
R
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
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
25
Handling Clock Drift (cont.)
FTSP
Using two nodes Estimating off of eight data
points
26
Handling Clock Drift (cont.)
FTSP
So, how often should we resynch? Little
difference between 30 secs and 300 secs
27
Code

• async command result_t GlobalTime.local2Global(uin
  t32_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

FTSP
28
Code (cont.)

• localSum 0
• offsetSum 0
• while( i lt MAX_ENTRIES )
• if( tablei.state ENTRY_FULL )
• localSum (int32_t)(tablei.loc
  alTime - newLocalAverage) / tableEntries
• offsetSum (int32_t)(tablei.ti
  meOffset - newOffsetAverage) / tableEntries
• newLocalAverage localSum
• newOffsetAverage offsetSum
• localSum offsetSum 0
• for(i 0 i lt MAX_ENTRIES i)
• if( tablei.state ENTRY_FULL )
• int32_t a tablei.localTime -
  newLocalAverage
• int32_t b tablei.timeOffset -
  newOffsetAverage
• localSum (int64_t)a a

FTSP
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
30
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 23seqNum17timestamp1236
Which one(s) do I choose?
rootID 23seqNum17timestamp1235
R
rootID 23seqNum17timestamp 1234
31
Multi-hop (cont.)

• Determining which messages to keep
• Keep message if (rootID lt myRootID AND seqNum gt
  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
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 lt
  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
33
Root Election (cont.)

• NUMENTRIES_LIMIT the number of entries in the
  regression table needed before linear regression
  is performed

FTSP
34
Todays 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
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
36
How Long Does This Take? (cont.)

• PM 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
• PNR
• Total time is between P(M(N-1)R) and P(MNR)
• What if we decrease P?

Network Synch Time
37
Todays 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
38
Setting Up the Experiment
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)

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
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
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
42
Power On and Root Election

• For PM (306) 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
43
The Death of ID1

• ID1 powered off at 1 hour
• Another PM transpires before nodes timeout (but
  they keep their offset and drift estimates!)
• Unable to tell when ID2 is elected (authors claim
  at 106)
• Why did the error stay low during reelection?
• Why is error climbing after 110? (hint R now
  equals 11)

Experiment
44
Introducing New Nodes

• After a half-hour, odd ID nodes are switched back
  on at 301
• Why does the of synchronized nodes drop?

Experiment
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
46
Todays 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
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
48
Todays 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
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_Dem
  o_Abstract.pdf
• Applications!

Conclusion
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 IDs
  localtime
• Tested extensively
• Any questions?
• Thanks for listening!

Conclusion