The Flooding Time Synchronization Protocol

1
The Flooding Time Synchronization Protocol

• Authors M. Maroti, B. Kusy, G. Simon, A. Ledeczi
  (Vanderbilt University)
• Speaker Sumit Singh
• (Texas AM University)

2
Outline

• Introduction
• Uncertainties in Radio Message Delivery
• The Protocol
• Evaluation
• Comparison with RBS and TPSN
• Discussion

3
Introduction
4
WHY SYNCHRONISM IS NEEDED?

• Basic communication
• Consistent distributed sensing/control
• Security
• Location
• Mobility
• Power Management
• Logging
• and more

5
WIRED NETWORK SYNCHRONIZATION

• Network Time Protocol (NTP)
• Server with an atomic clock
• Client request time by sending a UDP packet to
  server
• Global Positioning System (GPS)
• Communication with satellites
• GPS receiver in each wireless device
• Time accuracy will vary

Network Time Protocol
Image source http//en.wikipedia.org/wiki/ImageN
etwork_Time_Protocol_servers_and_clients.svg
6
WIRELESS NETWORK SYNCHRONISM

• Type 1
• Relative timing and simplest of all
• Determine if event 1 occurred before event 2
• Clock synchronization is not important
• Type 2
• Node keeps information about its drift and offset
  w.r.t. to its neighbors local timescale
• Nodes can synchronize at any instant with
  neighbor
• Type 3
• Constant global timescale throughout the network
  
• Most complex and the toughest to implement

7
WHAT IS FTSP?

• Flooding Time Synchronization Protocol
• Especially tailored for stringent precision
  applications
• MAC layer time-stamping
• Clock skew estimation
• Robust against node and link failures
• Periodic flooding
• Dynamic topology update
• Low communication bandwidth
• Very low error range (µsec)
• Scalable

8
OTHER PROTOCOLS

• Reference Broadcast Synchronization (RBS)
• Receiver to receiver synchronization
• Not good for large multi hop networks
• Additional message exchange
• Timing Sync Protocol for Sensor Network (TPSN)
• Sender to receiver synchronization
• Designed for multi-hop network

9
Uncertainties in Radio Message Delivery
10
Time Delays in WSN

• Send Time
• Assemble msg request to MAC layer
• Non-deterministic
• 100ms

Send time
Sender
send
Receiver
11
Time Delays in WSN

• Access Time
• Delay to access channel
• Least deterministic
• msec to sec

Send time
Access time
Sender
send
access
Receiver
12
Time Delays in WSN

• Transmission Time
• Time to transmit msg
• Depends on msg size radio speed
• 10ms

Send time
Access time
Transmission time
Sender
send
access
transmission
Receiver
13
Time Delays in WSN

• Reception Time
• Time to receive msg
• Same as transmission time

Send time
Access time
Transmission time
Sender
send
access
transmission
reception
Reception time
Receiver
14
Time Delays in WSN

• Propagation Time
• Time from sender to receiver
• Highly deterministic

Send time
Access time
Transmission time
Sender
send
access
transmission
reception
Propagation time
Reception time
Receiver
15
Time Delays in WSN

• Receive Time
• Time to process incoming msg
• Similar to send time

Send time
Access time
Transmission time
Sender
send
access
transmission
reception
receive
Propagation time
Reception time
Receive time
Receiver
16
Time Delays in WSN

• Remove uncertainties in
• Send Time
• Access Time
• Receive Time

Send time
Access time
Transmission time
Sender
send
access
transmission
reception
receive
Propagation time
RBS
Reception time
Receive time
Receiver
17
Time Delays in WSN

• Remove uncertainties in
• Send Time
• Access Time
• Receive Time
• Propagation Time

Send time
Access time
Transmission time
Sender
send
access
transmission
reception
receive
Propagation time
TPSN
Reception time
Receive time
Receiver
18
Time Delays in WSN

• Remove uncertainties in
• Send Time
• Access Time
• Reception Time
• Receive Time

Send time
Access time
Transmission time
Sender
send
access
transmission
reception
receive
Propagation time
FTSP
Reception time
Receive time
Receiver
19
MESSAGE PROPAGATION IN WSN
20
MESSAGE PROPAGATION IN WSN
Interrupt Handling Time 1µsec
21
MESSAGE PROPAGATION IN WSN
Encoding Time 100µsec
22
MESSAGE PROPAGATION IN WSN
Decoding Time 100µsec Jitters
23
MESSAGE PROPAGATION IN WSN
Byte Alignment Time
24
The Protocol
25
ASSUMPTIONS

• The effect of various coding schemes (Manchester,
  SECDEC, FEC) not considered
• Each node has a local clock exhibiting timing
  errors of crystals
• Node can communicate to its neighbors
• Every node has unique ID

26
THE PROTOCOL

• Sender obtains timestamp when the message was
  actually sent in its own local time
• The message contains the local time of the sender
  at the time of transmission
• Receiver obtains timestamp when the message was
  received in its own local time
• Each node maintains a local and global time
  reference point
• Estimate clock drift and skew by doing regression
  on a set of reference points

27
TIME STAMPING

• Multiple time stamps are made both on the sender
  and receiver sides at byte boundaries
• One final timestamp is embedded in the message

Image source http//www.cs.wustl.edu/jain/cse574
-06/ftp/time_sync/index.htmlSection4.0
28
CLOCK DRIFT MANAGEMENT
Synchronization period can go up to several
minutes depending on the accuracy requirements
29
MULTI HOP TIME SYNCHRONIZATION
30
MULTI HOP TIME SYNCHRONIZATION
31
MULTI HOP TIME SYNCHRONIZATION
32
SYNCHRONIZATION MESSAGE
timeStamp
rootID
seqNum
Message
myrootID
seqNum
At node
33
MANAGING REDUNDANCY

• A node may receive multiple synchronization
  messages
• 8 element regression table available
• Store reference points distributed over longer
  period of time for better estimation
• Use message filtering
• Store (rootID, seqNum) pair once per round

34
ROOT ELECTION

• Global time is synchronized to the local time of
  an elected leader
• No dedicated node to provide time reference info
• Election process uses unique IDs of the nodes
• After ROOT_TIMEOUT, node declares itself as root,
  sets myRootID myID
• Many nodes elect themselves as root
• The lowest myID node in the whole network becomes
  the final root, eventually

35
Evaluation
36
EXPERIMENTAL TOPOLOGY
37
EXPERIMENTAL EVALUATION
1st leader turned off
50 turned off
all turned back on
random nodes turned off/on
all turned on
38
COMPARISON WITH RBS TPSN
39
COMPARISON
40
DISCUSSION
41
DISCUSSION

• Security
• Plant a node as root drive the network yourself
• Securing Flooding Time Synchronization Protocol
  in Sensor Networks UC Berkeley
• Use authentication, redundancy etc but they all
  have overheads
• Power
• During linear regression on the nodes
• Re-electing a root node (power estimation)
• Nodes remain ON during FTSP
• Is this useful?
• Very limited applications such as Counter Sniper
• Stringent

42
THANK YOU