Scuola Superiore Sant’Anna

Synchronize the WSNs

Paolo Pagano (ReTiS Lab)

Outline

• Problem definition• Resources found on the Web and in the related

Literature• Classes of Clock Synchronization Protocols• RBS• NS-2 implementation • Outlook

Problem definition

• Time synchronization is a critical piece of infrastructure in any distributed system, but WSNs make particularly extensive use of synchronized time;

• Sensor data fusion or coordinated actuation requires synchronized physical time for reasoning about events in the physical world;

• While the clock accuracy and precision requirements are often stricter in sensor networks than in traditional distributed systems, energy and channel constraints limit the resources available to meet these goals.

Communication dominates node’s energy consumption costing from

r2 to r4 depending on transmission distance

The less you transmit, the better is your

approach? it depends....

Solution representation

• Unique best solution doesn’t exist• Possible axes to represent the

domain of the proposed solution:

• precision• lifetime• scope• availability• energy cost

PhD Thesis by Jeremy E. Elson, 2003

Can we borrow the solution...

... from the world of ordinary (wired and wireless) telecommunications?

Let’s quote this:

“Network and node dynamics require continuous, automatic configuration; this precludes a priori selection of a particular node as the master clock [...] the scale of the network and intermittency of its links may preclude the very existence of any single master clock node”.

Which kind of Synchronization?

Three approaches for different scopes:• Mantaining ordering of events:

Possibility to say whether an event E1 occurred before or after event E2;

• Maintaining relative clocks:Nodes run their local clocks independently;Each node keeps information about therelative drift and offset to every other node;

• Maintaining synchronization with a reference clock:Synchronization is always on;Preserve global timescale throughout the network.

Time Synchronization inSensor Networks (slides in PDF by M. Kohvakka & T. Vanhatupa)

In such a case are you really

interested in absolute time?

Notion of the time needed only for simultaneous

action?

What about disconnected topologies or intermittent

communication?

From the Internet to the WSNs

What’s the time?

What’s the time?

Q: What’s the time

here?

Q: What’s the time

here?

Q: What’s the time there

when here it‘s t? Q: What’s the time there

when here it‘s t?

A: tA: t

A: tA: t

A: t’A: t’

Definition of Clocks (1)

• Digital clocks measure time intervals;• A counter h, “the (local) clock” counting time

steps of an ideally fixed length:– denoting the reading of the counter at real time t as

h(t).

• The counter is incremented by an oscillator with a rate (or frequency) f:– the rate f at time t is given as the first derivative of

h(t): f(t) = dh(t)/dt.

Definition of Clocks (2)

• Clock models:– Constant Rate (perfect clock) f(t) = 1;

– Bounded-drift ρmax < ρ(t) = f(t) -1 < ρmin

– Bounded-drift-variation model θmax < θ(t) = dρ(t)/dt < θmin

• Software Clocks:– Piecewise continuous, strictly monotonically increasing function

c(h(t));

– For example: c(h(t)) = t0+h(t)−h(t0) is a software clock that starts with the correct real time t0 and then runs with the same speed as the local clock h.

Classical sources of errors in time services

• Send Time:time spent at the server to construct the

message;• Access Time:

time spent to access the medium in contention contexts;

• Propagation Time:time spent for the signal to reach the

recipients;• Receive Time:

time needed by the network interface to generate an interrupt.

tens of ns

UniCast

BrdCast

Lightweight Time Synchro (LTS)

• Sender/Receiver synchro algorithm:– pair-wise (unicast based and symmetric)

synchronization protocol;– presence of an absolute reference time to

be synchronized with.• Distributed Multihop extension

downgrades the accuracy depending on the distance with the reference node σ2~σ2 n;

• Re-synchronization period depends on the accuracy (δ) desired at each node:

• May permit Post-Facto synchronization.

ihT

3.24

•Centralized Multihop extension downgrades the accuracy depending on the height h of the spanning tree σ2~σ2 n;•Re-synchronization period depends on the accuracy (δ) desired at each node:

•Doesn’t permit Post-Facto synchronization.

h

T3.22

Timing-sync Protocol for SNs (TPSN)

• Sender/Receiver synchro algorithm:– pair-wise (unicast based) asymmetric

synchronization protocol;– presence of an absolute reference time

to be synchronized with.• Need of timing support in the lower

layers of the Network Stack to timestamp packets as soon (late) as possible in order to minimize the uncertainties;

• Multihop extension downgrades the accuracy depending on the depth of the spanning tree: σ2~σ2 h:

– there is a trade-off between synchronization accuracy and energy consumption dealing with the construction of a minimal spanning tree.

Reference Broadcast Synchronization (RBS)

• Receiver/Receiver synchro algorithm:

– group-based synchronization;– PAN coordinators are not required

to synchronize;– no need of an absolute reference

time to be synchronized with.• Need of timing support in the lower

layers of the Network Stack to timestamp packets as soon as the broadcast message arrives;

• Multihop extension based on cluster overlapping

σ ~ 11 μs

The “reference” protocol

Doesn’t matter if it’s judged good or not for a specific application, it seems everybody refers to it for comparing, discussing, proving their proposals in this domain.

PhD Thesis by Jeremy E. Elson, 2003

Explicit timestamp conversion (1)

“Time synchronization schemes (regardless of the underlying method) don't set the clock, but rather build a set of parameters relating the phase and frequency of the local clock to other timescales in the system”;

“The clock is freed from the requirement that it must be synchronized continuously. Instead, a node can query the clock for a timestamp when an event occurs, and perform synchronization after the fact (post-facto synchronization, no clairvoyance)”;

Explicit timestamp conversion (2)

“The local clock runs undisciplined, and thus is monotonic and relatively stable (a critical feature to many signal processing algorithms)”;

“An undisciplined clock requires no continuous corrections to the clock by the CPU or kernel, as are required by algorithms such as NTP (harmful for energy conservation issues)”.

Reformulations and add-up’s

• Other formulations and add-up’s not included in this dissertation:– “Cluster-based Hierarchical Time

Synchronization for Multi-hop Wireless Sensor Networks” by H. Kim, D. Kim and S. Yoo;

– Accurate Multihop Clock Synchronization in Mobile Ad Hoc Networks by G. Cao and J. L. Welch.

• We may stop here and try to implement RBS in the simulator.

• Remainder (from November 17th)

Selected package

• We selected NS-2 (USC-ISI):http://www.isi.edu/nsnam/ns/

for 4 reasons:– diffusion in the scientific

community;– open source nature;– C++ coded;– 802.15.4 MAC support.

OTcl C++OTcl script describing simulation

Tcl

CL

Simulators NS-2 OPNET QualNet/GloMoSim

Tranport 75% 18% 7%

Network 70% 18% 12%

MAC & PHY 42% 26% 22%

The RBS protocol

The Algorithm:• A server broadcast “m” “Hello” messages sent at

random time;• The clients share the timestamps done at the reception

of the server messages;• Each client computes the relative skew with the

neighbor one and is in charge of interpolating the data.

Constructing a simple demo

• Using Java RMI distributed system framework.

• Why ?– Because has the native idea of registering for a

service through the so called “call-back” mechanism;– Because I want everything under control in a high

end software before translating it to ns2.

DEMO using Network Simulator 2

• Required software:– ns2 code, tcl interpreter

(e.g. using ns-allinone-2.29.3.tar.gz) (*)

http://nsnam.isi.edu/nsnam/index.php/Main_Page

– preferably include RTSim as suggested in the instructions you find on the WEB;

– whatever Data Analysis Platform, using

ROOT (http://root.cern.ch)

(*) v2.29.2 doesn’t install under X/Cygwin

Switching to NS-2

• First exercise is to provide a local clock to each node:– the possibility to tune clock

frequency (to match hardware manufacturing details), offset and skew;

• Implementing an NTP-like service at the Agent layer.

Moving to wireless

Wired

802.15.4

802.11

RTS/CTS

Naïve RBS implementation in ns2

set recInfty 1.0e-08Phy/WirelessPhy set CSThresh_ $recInftyPhy/WirelessPhy set RXThresh_ $recInfty

set topo [new Topography] ;# Create topographycreate-god [expr $val(n) + 1] ;# create the General Operations

Director$topo load_flatgrid $val(lambda) $val(lambda) ;# load a flat gridset chan_1 [new Channel/WirelessChannel] ;# create the

wireless channel$ns node-config \ -adhocRouting AODV \ -llType LL \ -macType Mac/802_15_4\ -ifqType Queue/DropTail/PriQueue \ -ifqLen 50 \ -antType Antenna/OmniAntenna \ -propType Propagation/TwoRayGround \ -phyType Phy/WirelessPhy/802_15_4\ -topoInstance $topo \ -agentTrace ON \ -routerTrace ON \ -macTrace ON \ -movementTrace OFF \ -wiredRouting OFF\ -channel $chan_1

Dummy unicast to establish the route (AODV)

• A dummy unicast must be sent before the synchroAlgo otherwise the nodes don’t know how to reach each other and packets get loss.

Somewhat useless, preferably to use DumbAgent but I wasn’t aware when I wrote the code

Broadcasts

Sharing local timing infos

• Now the nodes can exchange their timing information

• A timeout is triggered after the last message received in broadcast

Synchronization done

• In this way, if node A wants to take action together with node B, they have the means to do it.

NS2 linked with ROOT

Possibility to book histos, and perform statistical analysis anywhere in the code

ρ is constant in time:• you need to synchronize only once;• need only two points and no statistical interpolation.

Conclusions

• Problems related to clock synchronization in Wireless Sensor Networks are here discussed;

• The main concept here reported proves there is not a unique solution for the existing vaste variety of domains;

• Some contours must be drawn for proposing a synchronization protocol:– External/Internal;– Global/Local;– Continuous/PostFacto; – Etc.

• The most popular Time Synchronization protocols have been presented devoting particular attention to RBS.

Outlook

• RBS will now be implemented in NS2;• The code :

– is a bit out of date;• (e.g. it has an embedded OS simulation instead

of the RTSim-based one, it relies on AODV, etc.)

– is not finalized;– is implemented only for a single broadcast domain.

• Thus we may re-code the protocol in C and enable the new Network Stack in ERIKA to make use of it;

• We can finally test RBS in final hardware making use of the recently delivered MicaZ motes equipped with 802.15.4 compliant radio;

• The resources mentioned in this seminar have been uploaded to the ReTiS WEB site:

http://feanor.sssup.it:8080/retis/ReservedArea/sens_nets/time-synchronization