clock synchronization for wireless sensor networks: a surveypeters/...survey-adhocnets-2005.pdf ·...

Ad Hoc Networks 3 (2005) 281–323

www.elsevier.com/locate/adhoc

Clock synchronization for wireless sensor networks: a survey

Bharath Sundararaman, Ugo Buy *, Ajay D. Kshemkalyani

Department of Computer Science, University of Illinois at Chicago, 851 South Morgan Street, Chicago, IL 60607, United States

Received 17 September 2004; received in revised form 1 January 2005; accepted 18 January 2005

Abstract

Recent advances in micro-electromechanical (MEMS) technology have led to the development of small, low-cost,and low-power sensors. Wireless sensor networks (WSNs) are large-scale networks of such sensors, dedicated to observ-ing and monitoring various aspects of the physical world. In such networks, data from each sensor is agglomeratedusing data fusion to form a single meaningful result, which makes time synchronization between sensors highly desir-able. This paper surveys and evaluates existing clock synchronization protocols based on a palette of factors like pre-cision, accuracy, cost, and complexity. The design considerations presented here can help developers either in choosingan existing synchronization protocol or in defining a new protocol that is best suited to the specific needs of a sensor-network application. Finally, the survey provides a valuable framework by which designers can compare new and exist-ing synchronization protocols.� 2005 Elsevier B.V. All rights reserved.

Keywords: Synchronization protocol; Sensor network; Wireless network; Comparative evaluation

1. Introduction

In recent years, tremendous technologicaladvances have occurred in the development oflow-cost sensors, which are capable of wirelesscommunication and data processing [29,32,61,65]. Wireless sensor networks (WSNs) are dis-tributed networks of such sensors, dedicated to

1570-8705/$ - see front matter � 2005 Elsevier B.V. All rights reservdoi:10.1016/j.adhoc.2005.01.002

* Corresponding author. Tel.: +1 312 413 2296; fax: +1 312413 0024.

E-mail address: [email protected] (U. Buy).

closely observing real-world phenomena. Suchsensors may be embedded in the environment orenabled with mobility; they can be deployed ininaccessible, dangerous, or hostile environments.The sensors need to configure themselves in a com-munication network, in order to collect informa-tion that has to be pieced together to assemble abroader picture of the environment than what eachsensor individually senses. A huge surge of interestin this field has been triggered by applications indomains as diverse as military [16], environmental[7,8,63], medical [33], scientific [1,5,39,60,72,73],

ed.

mailto:[email protected]

Table 1Example applications of wireless sensor networks

Domain Applications

Military Detection of nuclear, biological, and chemical attacks and presence of hazardous materialsPrevention of enemy attacks via alerts when enemy aircrafts are spottedMonitoring friendly forces, equipment and ammunition

Environmental Forest fire monitoring, flood detection, and earthquake detectionMonitoring ecological and biological habitats

Civilian Determining spot availability in a parking lot. Active badge tracking at the workplaceSurveillance for security in banks and shopping malls. Highway traffic monitoring

Health Tracking and monitoring doctors inside a hospitalIdentifying pre-defined symptoms by telemonitoring human physiological data

Home and K-12 education The intelligent home and smart kindergarten, where wireless networks areused in developmental, problem-solving environments

Scientific Space and interplanetary exploration. Deep undersea explorationSubatomic particle study. High-energy physics. Study of cosmic radiation

282 B. Sundararaman et al. / Ad Hoc Networks 3 (2005) 281–323

and industrial, civilian, and home networks[9,33,41,69,70], as shown in Table 1. As wirelesssensor networks become an integral part of themodern era [6,13,14,22,23,26], addressing the is-sues in designing such networks becomes manda-tory. Good sources of further information onwireless sensor networks and the challenges thereininclude surveys authored by Akyildiz et al. [2,3],by Culler and Hong [13], by Culler et al. [14], byTilak et al. [64], and by Tubaishat and Madria[66].

In wireless sensor networks, the basic operationis data fusion, whereby data from each sensor isagglomerated to form a single meaningful result[17,44,71,74,76–78]. For instance, in forest firemonitoring, a forest fire can be detected by differ-ent sensors at different points in time when the fireenters the range of each sensor. Sensor readings(e.g., direction or velocity) and timestamps (indi-cating the time at which the fire was sensed) arepassed along so that fusion of such informationfrom various sensors will add up to a global result.In this case, it might be the time elapsed since thefire was first spotted and its direction. The fusionof individual sensor readings is possible only byexchanging messages that are timestamped by eachsensor�s local clock. This mandates the need for acommon notion of time among the sensors. Proto-cols that provide such a common notion of timeare clock synchronization protocols.

Researchers have developed successful clocksynchronization protocols for wired networks overthe past few decades. These are unsuitable for awireless sensor environment because the challengesposed by wireless sensor networks are different andmanifold. The most important differences are sum-marized here. First, wireless sensor networks cancontain several thousands of sensors and theirwide deployment is enabled by the fact that sen-sors are becoming cheaper and smaller in size.For example, a military tracking application mayconsist of hundreds of thousands of sensors, andscalability becomes a major issue. If a particulararea needs sudden surveillance it might be popu-lated with thousands of sensors in an ad-hoc man-ner, and the network must be scalable to thechange. Second, self-configuration and robust-ness become a direct necessity in order to functionunder rapid deployment conditions and operationin inaccessible or dangerous environments. Third,energy conservation is a very important concern.It is impossible to provide a power source to eachsensor in such a vast network, and the small sizesof sensors restrict the amount of energy that canbe stored and procured.

This paper has three objectives. First, it presentsa survey of clock synchronization protocols for therapidly emerging wireless networks, based on apalette of factors such as precision, accuracy, cost,and complexity. The survey will help a reader

B. Sundararaman et al. / Ad Hoc Networks 3 (2005) 281–323 283

choose the most appropriate protocol for hisapplication. Second, our analysis of issues underly-ing synchronization protocols will guide designersin defining new protocols tailored to specific appli-cations of sensor networks. Finally, the surveyestablishes a framework for comparing new andexisting clock synchronization protocols.

Although there are many surveys on wirelesssensor networks, most of the existing surveys donot focus on time synchronization. Culler et al. re-cently published an overview of sensor networks ina special issue of IEEE Computer magazine [14].Tilak et al. [64] present performance metrics forsensor networks along with a classification of sen-sor networks based on the organization of commu-nicating nodes within a network. Their survey isespecially valuable in its ability to relate the syn-chronization requirements to the organization ofa sensor network. Akyildiz et al. wrote an excellentsurvey on sensor networks [3]. These authors dis-cuss various communication protocols based onthe layers of the Open System Interconnection(OSI) model. Several open research issues—includ-ing hardware design, modulation protocols, andstrategies to overcome signal propagation ef-fects—are discussed along with various MAC pro-tocols. Hill et al. [29] discuss various hardwarearchitectures for nodes in sensor networks. Theirsurvey was published in a special issue of the Com-munications of the ACM on wireless sensor net-works. The issue contains various other articlesthat discuss synchronization issues in these net-works [13,63,71]. The work closest to ours is Elsonand Romer�s discussion of the design principlesunderlying synchronization protocols for wirelessnetworks [20].

This paper is organized as follows. Section 2discusses the foundations of clock synchronizationand reviews traditional synchronization protocolsfor wired networks that are not constrained bythe peculiar limitations of wireless sensor net-works. It is necessary to understand these proto-cols to appreciate why new protocols had to bedesigned specifically for wireless sensor networks.Section 3 introduces the reader to clock synchroni-zation in wireless sensor networks by explainingthe peculiar characteristics of such networks thatrender the traditional synchronization protocols

ineffective. The section next explains the designprinciples underlying clock synchronization proto-cols for wireless sensor networks. It then providesa classification of existing protocols based on syn-chronization issues and application-dependent fea-tures. Section 4 analyzes several existing clocksynchronization protocols for wireless sensor net-works. Section 5 presents a quantitative and qual-itative comparison of clock synchronizationprotocols. The conclusions of our survey are givenin Section 6.

2. Traditional clock synchronization

2.1. Motivation

In centralized systems, there is no need for syn-chronized time because there is no time ambigu-ity. A process gets the time by simply issuing asystem call to the kernel. When another processthen tries to get the time, it will get either an equalor a higher time value. Thus, there is a clearordering of events and the times at which theseevents occur.

In distributed systems, there is no global clockor common memory. Each processor has its owninternal clock and its own notion of time. In prac-tice, these clocks can easily drift seconds per day,accumulating significant errors over time. Also,because different clocks tick at different rates, theymay not remain always synchronized althoughthey might be synchronized when they start. Thisclearly poses serious problems to applications thatdepend on a synchronized notion of time. Formost applications and algorithms that run in a dis-tributed system, we need to know time in one ormore of the following aspects.

• The time of the day at which an event happenedon a specific machine in the network.

• The time interval between two events that hap-pened on different machines in the network.

• The relative ordering of events that happenedon different machines in the network.

Unless the clocks in each machine have a com-mon notion of time, time-based queries cannot be


answered. Some practical examples that stress theneed for synchronization are listed below.

• In database systems, the order in which pro-cesses perform updates on a database is impor-tant to ensure a consistent, correct view of thedatabase. To ensure the right ordering ofevents, a common notion of time between co-operating processes becomes imperative.

• Liskov [43] states that clock synchronizationimproves the performance of distributed algo-rithms by replacing communication with localcomputation. When a node N needs to querynode M regarding a property, it can deducethe property with some previous informationit has about node M and its knowledge of thelocal time in node M.

• It is quite common that distributed applicationsand network protocols use timeouts, and theirperformance depends on how well physicallydispersed processors are time-synchronized.Design of such applications is simplified whenclocks are synchronized.

Clock synchronization is the process of ensur-ing that physically distributed processors have acommon notion of time. It has a significant effecton many areas like security systems, fault diagno-sis and recovery, scheduled operations, databasesystems, and real-world clock values.

2.2. Clocks in distributed systems

In distributed systems where each machine hasits own physical clock, we have seen that clocksynchronization is of significant importance. Be-fore delving into the details of synchronizingclocks, we define the notion of a clock. A computer

clock is an electronic device that counts oscilla-tions in an accurately-machined quartz crystal, ata particular frequency. It is also defined as anensemble of hardware and software componentsused to provide an accurate, stable, and reliabletime-of-day function to the operating system andits clients. Computer clocks are essentially timers.The timer counts the oscillations of the crystal,which is associated with a counter register and aholding register. For each oscillation in the crystal,

the counter is decremented by one. When thecounter becomes becomes zero, an interrupt is gen-erated and the counter is reloaded from the hold-ing register. Therefore, it is possible to programa timer to generate an interrupt 60 times a minute,where each interrupt is called a clock tick, by set-ting an appropriate value in the holding register.At each clock tick, the interrupt procedure incre-ments the clock value stored in memory.

The clock value can be scaled to get the time ofthe day; the result can be used to timestamp anevent on that computer. In practice, the quartzcrystals in each of the machines in a distributedsystem will run at slightly different frequencies,causing the clock values to gradually diverge fromeach other. This divergence is formally called theclock skew, which can lead to an inconsistent no-tion of time. Clock synchronization is performedto correct this clock skew in distributed systems.There are two broad ways to achieve this.

• Clocks are synchronized to an accurate real-time standard like universal coordinated time(UTC). Clocks that must not only be synchro-nized with each other but also have to adhereto physical time are termed physical clocks.Such clocks are the subject of this paper.

• For applications in which causality-based logi-cal time can be substituted for real-time (e.g.,mutual exclusion requires only the logical con-dition that no two processes access the criticalsection concurrently), clocks are relatively syn-chronized to each other because the require-ment is only to provide an ordering of events,and not the exact real-world time at which eachevent occurred. For clocks that provide onlyrelative synchrony, only causality-based consis-tency of clocks matters as opposed to syn-chrony with respect to physical time. Suchclocks are denoted by (causality-based) logicalclocks [37,38]. Synchronizing such clocks willnot be considered in this paper.

2.3. Clock inaccuracies

We require the following definitions. For anytwo clocks Ca and Cb, Fig. 1 gives our termino-

Fig. 1. Clock terminology.

Clo

ck ti

me,

C

UTC, t

Fast ClockdC/dt > 1

Perfect ClockdC/dt = 1

Slow ClockdC/dt < 1

Fig. 2. Behavior of fast, slow, and perfect clocks with respect toUTC.


logy, which is consistent with previous definitions[46,47,50].

The term software clock normally refers to thetime in a computer clock to stress that it is just acounter that gets incremented for crystal oscilla-tions. The interrupt handler must increment thesoftware clock by one every time an interrupt(i.e., a clock tick) occurs. Most common clockhardware is not very accurate because the fre-quency that makes time increase is never exactlyright. Even a frequency deviation of just 0.001%would cause a clock error of about one secondper day. This is also a reason why clock perfor-mance is often measured with very fine units likeone part per million (PPM).

Consider the physical clock synchronization ofmachines in a distributed system to UTC. At anypoint of time, if the time at UTC is t, the time inthe clock of machine p is Cp(t). In a perfect world,Cp(t) = t for all p and all t. This means dC/dt = 1.However, due to the clock inaccuracy discussedabove, a timer (clock) is said to be working withinits specification if

1� q 6dCdt

6 1þ q; ð1Þ

Fig. 3. Requirements of clock s

where constant q is the maximum skew rate speci-fied by the manufacturer. Fig. 2 illustrates thebehavior of fast, slow, and perfect clocks with re-spect to UTC.

2.4. Clock synchronization protocols

The requirements of a clock synchronizationprotocol are listed in Fig. 3. Numerous clock syn-chronization protocols have been developed in the

ynchronization protocols.

Time

T0 T1

Request S time

Time server

Client

Fig. 5. Remote clock reading [11].


past few decades. Some of the representative pro-tocols are discussed next.

2.4.1. Remote clock reading method

Clock synchronization between any two nodesis generally accomplished by message exchanges,which allow one of the nodes to estimate the timein the other node�s clock. Once the time differencebetween the clocks of the nodes is computed, theclocks can be corrected or adjusted to run in tan-dem. In the presence of non-deterministic and un-bounded message delays, messages can get delayedarbitrarily, which makes synchronization verydifficult. The effectiveness of a synchronizationprotocol centers around its ability to preventnon-deterministic message delays from affectingthe quality of synchronization.

Cristian defined the Remote Clock Reading

method, which handles unbounded message delaysbetween processes [11]. This protocol is also usedby other clock synchronizing methods [28,51].When a process wants a time estimate of a remoteprocess, it sends a time request and waits for theremote process to respond. When it receives the re-sponse, the process calculates the round-trip as thedifference between the time at which it initiated therequest and the time at which it received the re-sponse. The response contains the estimate of thetime on the remote process. On obtaining such aresponse, it corrects its local clock to the sum ofthe estimate and half the round-trip time. Severaltrials are performed because the message delay isnon-deterministic and the trial which offers theleast round-trip time is chosen; alternately, theaverage of multiple trials is chosen. Cristian�smethod synchronizes several clients to an accuratetime service (universal coordinated time) using the

Fig. 4. Cristian�s synchro

remote clock reading method, as shown in Fig. 4and illustrated in Fig. 5.

Drawbacks. A disadvantage of Cristian�s proto-col is that the time for any message to be sent ishighly variable due to network traffic and messagerouting. These factors are not only hard to mea-sure accurately but also unpredictable. This proto-col also induces a high complexity in terms of thenumber of message exchanges, and there is nodefinitive means of deciding how many trials mustbe performed to reach an accurate round-trip timeestimate.

2.4.2. Time transmission method

Arvind [4] defined the Time Transmission Proto-

col (TTP), which is used by a node to communi-cate the time on its clock to a target node. Thetarget node then estimates the time in the sourcenode by using the message timestamps and mes-sage delay statistics.

Algorithm. Assume that M is the source node andS is the target node. The algorithm for estimatingthe time is given in Fig. 6. Eq. (2) gives the specificformula to estimate the time.

nization protocol.

Fig. 6. The time transmission algorithm [4].


Derivation. The derivation of formula (2) in Fig.6 is as follows.

• The actual time Tact on the source node M�slocal clock is

T act ¼ Rn � dn; ð4Þwhere dn is the offset between clocks S and M.

• Since dn is not determinable, the average valueover n messages is

�dðnÞ ¼ 1

n

Xn

i¼1

di: ð5Þ

• From this formulation, we get,

T approx ¼ Rn � �dðnÞ: ð6Þ• The ith message is received at S only di unitsafter it is transmitted by M.

Ri ¼ T i þ di þ di: ð7Þ

It follows that,

�dðnÞ ¼ RðnÞ � T ðnÞ � �dðnÞ: ð8Þ

Rearranging, we get

T approx ¼ Rn � RðnÞ þ T ðnÞ þ �dðnÞ: ð9Þ

As individual message delays are not known,�dðnÞ is replaced with �d, an expected value ofmessage delay. Tapprox now becomes

T est ¼ Rn � RðnÞ þ T ðnÞ þ �d: ð10Þ

Drawbacks. The protocol involves a large num-ber of synchronization messages, resulting in ahigh computational overhead. The number of mes-sages required for synchronization reduces theapplicability of the protocol.

2.4.3. Offset delay estimation method

The offset delay estimation method is employedby the Network Time Protocol (NTP) [48] which iswidely used for clock synchronization on the Inter-net. The design of NTP involves a hierarchical treeof time servers. The primary server at the root syn-chronizes with the UTC. The next level containssecondary servers, which act as a backup to theprimary server. At the lowest level is the synchro-nization subnet which has the clients.

Clock offset and delay estimation. In practice, asource node cannot accurately estimate the localtime on the target node due to varying messageor network delays between the nodes. This proto-col employs a very common practice of performingseveral trials and chooses the trial with the mini-mum delay. Recall that Cristian�s remote clockreading method [11] also relied on the same strat-egy to estimate message delay.

Fig. 7 shows how NTP timestamps are num-bered and exchanged between peers A and B. LetT1, T2, T3, T4 be the values of the four most recenttimestamps as shown. Assume that clocks A and B

are stable and running at the same speed. Leta = T1 � T3 and b = T2 � T4. If the network delaydifference from A to B and from B to A, called

Ti-3

Ti-2Server A

Server B

Ti-1

Ti

Fig. 8. Timing diagram for the two servers [48].

T3

T1

A

BT2

T4

Fig. 7. Offset and delay estimation [48].


differential delay, is small, the clock offset h andround-trip delay d of B relative to A at time T4

are approximately given by the following.

h ¼ aþ b2

; d ¼ a� b: ð11Þ

Each NTP message includes the latest threetimestamps T1, T2 and T3, while T4 is determinedupon arrival. Thus, both peers A and B can inde-pendently calculate delay and offset using a singlebidirectional message stream as shown in Fig. 8.The NTP protocol is shown in Fig. 9.

Fig. 9. The network time protocol

Drawbacks. The offset delay estimation proto-col is similar to Cristian�s method [11] due to itsaveraging approach. The disadvantage of bothmethods is that they lead to a high synchronizationoverhead in terms of message complexity and re-duced accuracy. However, accuracy of the net-work time protocol is better than for Cristian�sprotocol because delays are partly compensated.

2.4.4. Set-valued estimation method

The set-valued estimation method [40] is partic-ularly useful in systems where modeling uncer-

synchronization protocol [48].

Fig. 10. The set-valued estimation protocol, shown for a pair of processes Pi and Pj [40].

P

P

i2t iNtt iNt

i

jj1 j2

i2

jNt tt

tti1i1

Fig. 11. Message passing between Pi and Pj [40].

t

t

t

t

t

t

t t

a

b

true timing relationship

timing uncertainty

tj2

i1

i1

i2

i2

jN

i3

i3

j1

ij

ij

Fig. 12. Data triples plotted with the local time of Pj on the X-axis and the local time of Pi on the Y-axis [40].


tainty is not directly captured by a priori models.Assume that a distributed system consists of pro-cessors Pi, for i = 1, . . .,N. Let ti denote the localtime on the clock for processor Pi. We assume thatthe local times ti and tj on processors Pi and Pj,respectively, can be related by the linear equation:

ti ¼ aijtj þ bij; ð17Þwhere aij and bij represent the relative skew and off-set between the two hardware clocks.

For any two processors Pi and Pj which passmessages between each other, the protocol worksas shown in Fig. 10.

Clock correction. Clock correction is performedusing an algorithm by Dolev et al. [18], whichworks as follows. Synchronization proceeds inrounds and the interval between synchronizationrounds is predefined. The node that first reachesthe end of the synchronization round is obviouslythe fastest and all other nodes have to adjust theirrate to match the rate of this node.

There are two tasks associated with each node,time monitor and message handler. If a nodereaches the end of the synchronization period be-fore receiving any message from other nodes, itperforms the time monitor task by sending a mes-sage to every other node indicating that it hasreached the end of its synchronization period first.Every other node will execute the message handlerto process the incoming message and adjust itsclock to the fastest clock.

Drawbacks. The advantage of this protocol isthat every node tries to act as a synchronizer atthe same time and at least one succeeds. There isno single point of failure associated with the sys-

tem. However, message corruption and messagelosses might greatly degrade the accuracy. In addi-tion, there is a possibility of instability during clockcorrection because nodes always seek to adjusttheir clock rates to match the fastest clock in the


network. If a processor Pi overcorrects its clock(e.g., because of variations in message transmissiondelays), this will trigger a new round of correctionsas all other nodes will try to match the new clockrate of Pi. Worse yet, this phenomenon may repeatitself and continue indefinitely, leading to fasterand faster clock rates throughout the network.

3. Clock synchronization in wireless sensor networks

The traditional clock synchronization protocolssurveyed in the previous section are widely used inwired networks. However, they are not suitablefor wireless sensor networks for a variety of reasonsthat we discuss in this section. Clock synchroniza-tion in wireless sensor networks requires newerand more robust approaches. A thorough under-standing of the challenges posed by wireless sensornetworks is crucial for the successful design ofsynchronization protocols for such networks. Thissection examines the design principles for clock syn-chronization in wireless sensor networks, and thenclassifies various such synchronization protocols.

Transceiver

EmbeddedProcessor

Battery

Memory

Sensors66% of Total Cost

Requires Supervision

1 Kbps–1Mbps,3–100 meters

Lossy Transmissions

8–bit, 10 MHz,Slow Computations

Limited Lifetime

Limited Storage128KB–1MB

Fig. 13. Sensor node hardware for Mica mote [29].

3.1. Challenges of sensor networking

Wireless sensor networks have tremendous po-tential because they will expand our ability to mon-itor and interact remotely with the physical world.Smart sensors have the ability to collect vastamounts of hitherto unknown data, which will pavethe way for a new breed of computing applicationsas we showed in Table 1. Sensors can be accessed re-motely and placed where it is impractical to deploydata and power lines. Nodes can be spaced closely,yielding fine-grained pictures of real-world phe-nomena that are currently modeled only on a largescale. However, to exploit the full potential ofsensor networks, we must first address the peculiarlimitations of these networks and the resulting tech-nical issues. Evidently, sensor networks can be bestexploited by applications that perform data fusionto synthesize global knowledge from raw data onthe fly. Although data fusion requires that nodesbe synchronized, the synchronization protocolsfor sensor networks must address the following fea-tures of these networks.

3.1.1. Limited energy

While the efficiency of computing devices isincreasing rapidly, the energy consumption of awireless sensor network is becoming a bottleneck.Due to the small size and cheap availability of thesensors, sensor networks can employ thousandsof sensors. This makes it impossible to wire eachof these sensors to a power source. Also, the needfor unmanned operation dictates that the sensorsbe battery-powered. Since the amount of energyavailable to such sensors is quite modest, synchro-nization must be achieved while preserving energyto utilize these sensors in an efficient fashion.

3.1.2. Limited bandwidth

In wireless sensor nets, much less power isconsumed in processing data than transmitting it.Presently, wireless communication is restricted toa data rate in the order of 10–100 Kbits/s [21].Pottie and Kaiser [55] have shown that the energyrequired to transmit 1 bit over 100 m, which is3 joules, can be used to execute 3 million instruc-tions. Bandwidth limitation directly affects messageexchanges among sensors, and synchronization isimpossible without message exchanges.

3.1.3. Limited hardware

The hardware of a sensor node is usually very re-stricted due to its small size. A typical sensor nodelike the Berkeley Mica2 mote [35] has a small solarbattery, an 8-bit CPU that runs at a speed of10 MHz, 128 KB to 1 MB memory, and a commu-nication range of less than 50 m. Hill et al. [29] sur-veyed some sensor-network platforms as well as themost popular sensor architectures, such as Spec,Smartdust, Intel�s Imote [32], and Stargate. Fig.13 illustrates the configuration of a typical sensor


node. The restrictions on computational power andstorage space pose a huge challenge. The size of asensor cannot be increased because it would makeit more expensive and consume more power. Thiswould prevent the deployment of thousands of sen-sor nodes, which is usually required for efficientoperation of several critical applications.

3.1.4. Unstable network connections

An implicit advantage usually available to awireless network is mobility. Mobile ad-hoc net-works are becoming increasingly popular and thefollowing issues must be addressed.

• The communication range of the mobile sensorsis very limited (roughly 20–100 m), whichmakes message exchanges between sensor nodesdifficult.

• A wireless medium is unshielded to externalinterference and this may lead to a high percent-age of message loss.

• A wireless connection suffers from a restrictedbandwidth and intermittent connectivity.

• The network topology frequently changes dueto the mobility of the nodes. Dynamic reconfig-uration becomes necessary.

3.1.5. Tight coupling between sensors and physicalworld

WSNs seek to monitor real-world phenomenaand the network design is tailored to the specificenvironment being sensed. Therefore, as WSNsare used for critical and diverse applications likemilitary tracking, forest fire monitoring, and geo-graphical surveillance, the network has to betailored to suit the application. For instance, sen-sors can be used to measure temperature, light,sound, or humidity, and the application (e.g., for-est fire monitoring) decides the type of sensors tobe used (e.g., temperature sensors).

3.2. Design principles of clock synchronization in

sensor networks

Researchers have developed a wide variety ofclock synchronization protocols for traditionalwired networks over the past few decades, as sur-

veyed in Section 2. However, due to the peculiarcharacteristics, limitations, and the dynamic natureof wireless sensor networks, as seen in Section 3.1,these protocols cannot be applied directly. Severalimportant design considerations are listed next.

3.2.1. Energy efficiency

• External time standard (GPS) usageIn sensor nets, energy conservation is veryimportant. Traditional protocols like NTP [48]and TEMPO [28] use an external standard likeGlobal Positioning System (GPS) or UniversalTime (UTC) to synchronize the network to anaccurate time source. However, the use of GPSposes a high demand for energy which is usuallynot available in sensor networks. This makes itdifficult to maintain a common notion of time.

• Mode of transmissionReduction of energy is achieved by choosing totransmit over multiple short distances instead ofa single long path. This translates into either alower transmit power or a higher data transmis-sion speed over a given distance. Either one willdecrease the total end-to-end energy needed totransmit a packet of data. This implies that inlarge sensor networks, data is transmitted insequences or hops, instead of a single long pathfrom the sender to the receiver.

• Proactive versus reactive routingA proactive protocol keeps track of all the nodesin a node�s neighborhood, having total knowl-edge of all possible routes at all times. Reactiveprotocols do not maintain routing informationproactively and find routes only when they needthem. A reactive protocol leads to energy sav-ings because nodes do not waste energy byattempting to maintain synchronization at alltimes. Nodes are awakened only when they areneeded. Elson et al.�s Reference Broadcast Syn-chronization (RBS) [19] uses a similar technique,called post-facto synchronization.

3.2.2. InfrastructureIn many critical sensor applications, the net-

work is deployed in an ad-hoc fashion. Ad-hocnetworks are networks of mobile wireless sensors


in which the mobile nodes constantly change theirneighborhood and the configuration. This deniesthe convenience of having an infrastructure likeNTP [48], which has several layers of servers thatprovide an accurate source of time. In ad-hoc sen-sor networks, the nodes must cooperate to orga-nize themselves into a network and resolvecontention for the available bandwidth. Thesetasks become more complex if the number ofnodes grows or if the relationship among nodeschanges rapidly, for instance, because of mobility.

3.2.3. End-to-end latencyTraditional wired networks are fully connected

networks inwhich the variability in the propagationand (intermediate) queuing delay is relatively small.In addition, any node can send amessage directly toanother node at any point in time. This implies aconstant end-to-end delay throughout the networkand provides a close approximation for the actuallatency. Sensor nets may be large in size and haveto deal bothwithmobility andwireless transmissionover a shared medium. These features make itimpractical to assume a single latency bound be-tween the ends of the network. Sensor nets thereforeneed localization algorithms to reduce this latencyerror aswell as the jitter, the unpredictable variationin transmission times. Also, protocols that assume afully connected network cannot be applied tomulti-hop sensor networks.

3.2.4. Message loss and message delivery

Fault-tolerant algorithms for traditional wirednetworks handle message loss by sending extramessages. This ensures that every node partici-pates in the synchronization, leading to betteroperation. Several protocols for wired networksemploy the averaging method to compute thedelay between two nodes, which is a critical aspectin maintaining synchronized time. Message losshandling and estimating message delay by averag-ing are not desirable in sensor nets because of thefollowing reasons.

• Transmission of every bit requires energy andmultiple message transmissions to estimate aver-age delays lead to higher energy requirements.

• Message delivery is very unreliable due to thedynamic nature of the network, the intermittentconnectivity, and the limited communicationrange of each node.

3.2.5. Network dynamics

A stationary sensor network, without anymobility, usually requires an initial set-up beforebeginning operation. However, if the applicationdemands a higher population of nodes in a partic-ular part of the network, the addition of extranodes changes the neighborhood of each nodeand the configuration of the network. Dynamicsensor networks add further challenges becausethe nodes are mobile. Mobility directly leads to afrequent change in topology of the network.Hence, the protocols used for such networks,whether stationary or dynamic, must ensure self-configuration (by use of suitable neighborhooddefinition or leader election protocols) to achievesynchronization.

3.3. Classification of synchronization protocols

Wireless sensor networking can be applied to awide range of applications, from simple parkinglot monitoring to safety-critical applications likeearthquake detection. As most networks are veryclosely coupled to the application, the protocolsused for synchronization differ from each otherin some aspects and resemble each other in otheraspects. We classify synchronization protocolsbased on two kinds of features.

1. Synchronization issues2. Application-dependent features

3.3.1. Synchronization issues

Wireless sensor networks provide answers touser queries by fusing data from each sensor toform a single answer or result. To accomplish thisdata fusion, it becomes necessary for these sensorsto agree on a common notion of time. All the par-ticipating sensors can be enveloped in a commontimescale by either synchronizing the local clocksin each sensor or by just translating timestamps


that arrive at a sensor into the local clock times.Various options are now described.

• Master–slave versus peer-to-peer synchroniza-

tionMaster–slave. A master–slave protocol assignsone node as the master and the other nodesas slaves. The slave nodes consider the localclock reading of the master as the referencetime and attempt to synchronize with the mas-ter. In general, the master node requires CPUresources proportional to the number of slaves,and nodes with powerful processors or lighterloads are assigned to be the master node.Mock et al. [49] have adopted the IEEE802.11 clock synchronization protocol due toits simple, non-redundant, master/slave struc-ture. Ping�s protocol [54] also adheres to themaster–slave mode.Peer-to-peer. Most protocols in the literature,such as RBS [19], Romer�s protocol [56], theprotocol by PalChaudhuri et al. [53], the timediffusion protocol by Su and Akyildiz [62],and the asynchronous diffusion protocol of Liand Rus [42] are based on a peer-to-peer struc-ture. Any node can communicate directly withevery other node in the network. This elimi-nates the risk of master node failure, whichwould prevent further synchronization. Peer-to-peer configurations offer more flexibilitybut they are also more difficult to control.

• Clock correction versus untethered clocks

Clock correction. Most methods in practice per-form synchronization by correcting the localclock in each node to run on par with a globaltimescale or an atomic clock, which is used toprovide a convenient reference time. The proto-col of Mock et al. [49] and Ping�s protocol [54]are based on this method. The local clocks ofnodes that participate in the network are cor-rected either instantaneously or continually tokeep the entire network synchronized.Untethered clocks. Achieving a common notionof time without synchronization is becomingpopular, because a considerable amount ofenergy can be saved by this approach. RBS [19]builds a table of parameters that relate the local

clock of each node to the local clock of everyother node in the network. Local timestampsare then compared using the table. In this way,a global timescale is maintained while lettingthe clocks run untethered. Romer [56] uses thesame principle. When timestamps are exchangedbetween nodes, they are transformed to the localclock values of the receiving node. The round-trip delay between two nodes and the idle timeof a message are taken into consideration.

• Internal synchronization versus external synchro-

nization

Internal synchronization. In this approach, aglobal time base, called real-time, is not avail-able from within the system and the goal is tominimize the maximum difference between thereadings of local clocks of the sensors. The pro-tocol of Mock et al. [49] uses internal synchro-nization.External synchronization. In external synchroni-zation, a standard source of time such as Uni-versal Time (UTC) is provided. Here, we donot need a global time base since we have anatomic clock that provides actual real-worldtime, usually called reference time. The localclocks of sensors seek to adjust to this referencetime in order to be synchronized. Protocols likeNTP [48] synchronize in this fashion becauseexternal synchronization is better suited toloosely coupled networks like the Internet.Most protocols in sensor networks do not per-form external synchronization unless the appli-cation demands it, because energy efficiency is aprimary concern and employing an externaltime source typically induces high-energyrequirements.

Internal synchronization usually leads to amore correct operation of the system, whileexternal synchronization is primarily used togive users convenient reference time informa-tion. Note that internal synchronization canbe performed in a master–slave or peer-to-peerfashion. External synchronization cannot beperformed in a peer-to-peer fashion; it requiresa master node which communicates with a timeservice like GPS to synchronize the slaves anditself to the reference time.


• Probabilistic versus deterministic synchroniza-

tion

Probabilistic synchronization. This techniqueprovides a probabilistic guarantee on the maxi-mum clock offset with a failure probability thatcan be bounded or determined. The reasoningbehind a probabilistic approach is that a deter-ministic approach usually forces the synchroni-zation protocol to perform more messagetransfers and induces extra processing. In awireless environment where energy is scarce,this can be very expensive. The protocol of Pal-Chaudhuri et al. [53] is a probabilistic variationof RBS [19]. Arvind [4] defined a probabilisticprotocol for wired networks.Deterministic synchronization. Arvind [4] definesdeterministic algorithms as those that guaranteean upper bound on the clock offset with cer-tainty. Most algorithms in the literature aredeterministic. Sichitiu and Veerarittiphan�s pro-tocol [58] is centered on a deterministic algo-rithm. RBS [19] and the time-diffusionprotocol [62] are also deterministic.

• Sender-to-receiver versus receiver-to-receiver

synchronization

Most existing methods synchronize a senderwith a receiver by transmitting the current clockvalues as timestamps. As a consequence, thesemethods are vulnerable to variance in messagedelay. Newer methods such as RBS [19] per-form synchronization among receivers usingthe time at which each receiver receives thesame message. Such an approach reduces thetime-critical path, which is the path of a messagethat contributes to non-deterministic errors inthe protocol.Sender-to-receiver synchronization. This tradi-tional approach usually happens in threesteps.

1. The sender node periodically sends a mes-sage with its local time as a timestamp tothe receiver.

2. The receiver then synchronizes with thesender using the timestamp it receives fromthe sender.

3. The message delay between the sender andreceiver is calculated by measuring the totalround-trip time, from the time a receiver

requests a timestamp until the time itactually receives a response.The drawbacks of this approach are obvi-ous. There is a variance in message delaybetween the sender and the receiver. Thevariance is due to network delays (promi-nent in multi-hop networks) and the work-load in the nodes that are involved. Mostmethods compute the average message delayafter performing many trials, during whichthey lose accuracy and add further over-head. Also, optimization of the time takenby the sender to prepare and transmit themessage, and the time taken by the receiverto process the message must be considered.

Receiver-to-receiver synchronization. This ap-proach exploits the property of the physicalbroadcast medium that if any two receiversreceive the same message in single-hop trans-mission (see below), they receive it at approxi-mately the same time. Instead of interactingwith a sender, receivers exchange the time atwhich they received the same message and com-pute their offset based on the difference in recep-tion times. The obvious advantage is thereduction of the message-delay variance. Thisprotocol is vulnerable only to the propagationdelay to the various receivers and the differencesin receive time.

Table 2 classifies the various protocols for clocksynchronization, based on the analysis in thissection.

3.3.2. Application-dependent features

• Single-hop versus multi-hop networksSingle-hop communication. In a single-hop net-work, a sensor node can directly communicateand exchange messages with any other sensorin the network. However, many wireless sen-sor-network applications span several domainsor neighborhoods. (Nodes within a neighbor-hood can communicate via single-hop messagetransmission.) The network is often too large,making it impossible for each sensor node todirectly exchange messages with every othernode. Elson and Romer [20] show that a single

Table 2Classification based on synchronization issues

Protocol Synchronization issues

Master–slave vs.peer-to-peer

Internal vs. external Probabilisticvs. deterministic

Sender-to-receivervs. receiver-to-receiver

Clockcorrection

RBS [19] Peer-to-peer Both Deterministic Receiver-to-receiver NoRomer [56] Peer-to-peer Internal Deterministic Sender-to-receiver NoMock et al. [49] Master/slave Internal Deterministic Receiver-to-receiver YesGaneriwal et al. [25] Master/slave Both Deterministic Sender-to-receiver YesPing [54] Master/slave Both Deterministic Sender-to-receiver YesPalChaudhuri et al. [53] Peer-to-peer Both Probabilistic Receiver-to-receiver NoSichitiu and Veerarittiphan [58] Peer-to-peer Internal Deterministic Sender-to-receiver YesTime-diffusion protocol [62] Peer-to-peer Internal Deterministic Receiver-to-receiver YesAsynchronous diffusion [42] Peer-to-peer Internal Deterministic Sender-to-receiver Yes


latency bound cannot be assumed. Protocolssuch as those by Mock et al. [49], Ganeriwalet al. [24,25], Ping [54], and PalChaudhuriet al. [53] are based on single-hop communica-tion; however, they can be extended to multi-hop communication.Multi-hop communication. The need for multi-hop communication arises due to the increasein the size of wireless sensor networks. In suchsettings, sensors in one domain communicatewith sensors in another domain via an interme-diate sensor that can relate to both domains[19]. Communication can also occur as asequence of hops through a chain of pairwise-adjacent sensors. RBS [19], Ping�s protocol[54], the protocol by PalChaudhuri et al. [53],and Su and Akyildiz�s time-diffusion protocol[62] can be suitably extended to handle multi-hop communication.

• Stationary networks versus mobile networks

Most sensor networks are tightly coupled to theapplication and synchronization protocols varydepending on the application at hand. Mobilityis an inherent advantage of a wireless environ-ment but it induces more difficulties in achiev-ing synchronization. It leads to frequentchanges in network topology and demands thatthe protocol be more robust.Stationary networks. In stationary sensor net-works, the sensors do not move. An exampleis a network of sensors for monitoring themotion of a vehicle in a certain area. Forthese sensor networks, the topology remainsunchanged once the sensors are deployed in

the environment. The protocols used by RBS[19], Mock et al. [49], Ganeriwal et al. [24,25],and PalChaudhuri et al. [53] are geared to sta-tionary networks.Mobile networks. In a mobile network, the sen-sors have the ability to move, and they connectwith other sensors only when entering the geo-graphical scope of those sensors. The scope ofa mobile sensor is the communication range upto which it can communicate and successfullyexchange messages with other sensors. Romer[56] shows the need for a robust protocol,which can handle the frequent changes in net-work topology due to the mobility of the nodes.The change in topology is often a problembecause it requires resynchronization of nodesand recomputation of the neighborhoods orclusters.

• MAC-layer-based approach versus standard

approach

The Media Access Control (MAC) layer is apart of the Data Link Layer of the Open SystemInterconnection (OSI) model. This layer isresponsible for the following functions.– Providing reliability to the layers above it

with respect to the connections establishedby the physical layer.

– Preventing transmission collisions so that themessage transmission between one senderand the intended receiver node(s) does notinterfere with transmission by other nodes.

MAC protocols effectively utilize theMAC layerto achieve better energy efficiency, which is cru-cial in sensor networks. The IEEE 802.11 MAC


protocol [31] is widely used. Several variationsof this protocol have been defined for the pur-pose of controlling power consumption, includ-ing the protocols listed below. A survey by Chenet al. [10] compares some of these protocols.– Sensor-MAC (S-MAC) [75],– Power-Aware Multi-Access Protocol

(PAMAS) [59],– Energy-Conserving MAC (EC-MAC) [34],– Packet-Reservation Multiple Access MAC

(PRMA) [27],– Distributed-Queuing Request Update Multi-

ple Access (DQRUMA) [36],– Multiservice Dynamic Reservation TDMA

(MDR-TDMA) [52].
Reference Broadcast Synchronization [19] doesnot rely on MAC protocols in order to avoid atight integration of the application with theMAC layer. The protocols used by Mock et al.[49], Ganeriwal et al. [24,25], and Sichitiu andVeerarittiphan [58] rely on theCSMA/CAproto-col for the MAC layer. A survey of MAC proto-cols for sensor networks is given by Jones et al.[34].
Table 3 classifies the various protocols for clocksynchronization, based on the analysis in thissection.

4. Discussion of synchronization protocols

In the previous section, we analyzed the issuesunderlying synchronization in sensor networks.

Table 3Classification based on application-dependent features

Protocol Application-dependent featu

Single-hop vs. multi-hop

RBS [19] BothRomer [56] BothMock et al. [49] Single-hopGaneriwal et al. [25] BothPing [54] BothPalChaudhuri et al. [53] BothSichitiu and Veerarittiphan [58] BothTime-diffusion protocol [62] BothAsynchronous diffusion [42] Both

Now we summarize various existing synchroniza-tion protocols and their relationships to the aboveissues. We also discuss the relative advantages anddisadvantages of these protocols. Given that sensornetworks are generally closely tied to the real-worldenvironment that they monitor, different networkswill have different characteristics affecting theirsynchronization requirements. For this reason,some of the protocols that we discuss below willbe more suitable than others in some cases and viceversa.

We will specifically consider the followingprotocols.

1. Reference Broadcast Synchronization (RBS)seeks to reduce non-deterministic latency usingreceiver-to-receiver synchronization and to con-serve energy via post-facto synchronization [19].

2. Romer�s protocol, which has been successfullyapplied to mobile ad-hoc networks, uses aninnovative time transformation algorithm forachieving clock synchronization [56]. This pro-tocol appears to be especially effective in envi-ronments with strict resource constraints.

3. Mock�s protocol extends the IEEE 802.11master–slave protocol by exploiting thetightness property of the communication med-ium [49]. Minimal message complexity and faulttolerance are the main benefits of this protocol.

4. Network-wide Time Synchronization is gearedtoward networks with a large node density [24].

5. Delay Measurement Time Synchronization Pro-

tocol for wireless sensor networks [54] is anenergy-efficient protocol due to its low message

res

MAC layer vs. standard Geared to mobility

Standard NoStandard YesMAC layer NoMAC Layer YesStandard NoStandard NoMAC Layer NoStandard YesStandard Yes


complexity. It is also lighter in computationalcost, albeit less accurate, than the RBS protocol[19].

6. The Probabilistic Clock Synchronization Service

for sensor networks extends RBS by providingprobabilistic bounds on the accuracy of clocksynchronization [53].

7. Sichitiu and Veerarittiphan�s protocol providesgood synchronization accuracy in wireless sen-sor networks while using a deterministic proto-col with minimal computational and storagecomplexity [58].

8. The Time-Diffusion Protocol (TDP) by Su andAkyildiz achieves a network-wide ‘‘equilib-rium’’ time using an iterative, weighted averag-ing technique based on a diffusion of messagesinvolving all the nodes in the synchronizationprocess [62].

9. The Asynchronous Diffusion protocol by Li andRus uses a strategy similar to TDP; however,network nodes execute the protocol and correcttheir clocks asynchronously with respect to eachother [42].

4.1. Reference broadcast synchronization [19]

The Reference Broadcast Synchronization (RBS)protocol is so named because it exploits the broad-cast property of the wireless communication med-ium [19]. According to this property, two receiverslocated within listening distance of the same senderwill receive the same message at approximately thesame time. In other words, a message that is

NIC

Receiv

Receiv

Receiver

Sender Sender

Critical Path

Time

Fig. 14. Time-critical path for traditional proto

broadcast at the physical layer will arrive at a setof receivers with very little variability in its delay.If each receiver records the local time as soon asthe message arrives, all receivers can synchronizewith a high degree of precision by comparing theirlocal clock values when the message was received.This protocol uses a sequence of synchronizationmessages from a given sender in order to estimateboth offset and skew of the local clocks relative toeach other. The protocol exploits the concept oftime-critical path, that is, the path of a messagethat contributes to non-deterministic errors in aprotocol. Fig. 14 compares the time-critical pathof traditional protocols, which are based on sen-der-to-receiver synchronization, with receiver-to-receiver synchronization in RBS.

Non-deterministic transmission delays are detri-mental to the accuracy of a synchronization proto-col because they make it difficult for a receiver toestimate the time at which a message was sentand vice versa. In general, the time involved insending a message from a sender to a receiver isthe result of the following four factors, all of whichcan vary non-deterministically.

1. Send time: The time spent by the sender formessage construction and the time spent totransmit the message from the sender�s host tothe network interface.

2. Access time: The time spent waiting to accessthe transmit channel.

3. Propagation time: The time taken for the mes-sage to reach the receiver, once it has left thesender.

NIC

er

er

Critical Path

cols (left) and RBS protocol (right) [19].


4. Receive time: The time spent by the receiver toprocess the message.

By considering only the times at which a mes-sage reaches different receivers, the RBS protocoldirectly removes two of the largest sources ofnon-determinism involved in message transmis-sion, namely the send time and the access time.Thus, this protocol can provide a high degree ofsynchronization accuracy in sensor networks.The RBS protocol uses the algorithm shown inFig. 15 to estimate the phase offset between theclocks of two receivers.

This protocol can produce highly accurate re-sults if message reception by each receiver is tightand if each receiver can record its local clock read-ing as soon as the message is received. This is oftenthe case for single-hop communication in a wire-less network. In practice, however, messages sentover a wireless sensor network can be corrupted.In addition, a receiving node may not be able torecord the time of message arrival promptly, forinstance, if the node was busy with other computa-tions when the message arrived. To alleviate thesenon-deterministic factors, the RBS protocol uses asequence of reference messages from the same sen-der, rather than a single message. Receiver j willcompute its offset relative to any other receiver i

as the average of clock differences for each packetreceived by nodes i and j:

Offset½i; j� ¼ 1

m

Xm

k¼1

ðT i;k � T j;kÞ: ð19Þ

In this equation, parameters i and j denote tworeceivers, m is the number of reference broadcasts,and Ti,k is node i�s clock when it receives broad-cast k.

Elson et al. [19] conducted an experiment withan actual network of n sensor nodes that were

Fig. 15. Estimation of phase off

given random clock offsets; the times of m messagetransmissions were selected randomly. Each syn-chronization message was delivered to every recei-ver and timestamped using the receiver�s clock.Since every receiver computes its offset with everyother receiver, O(n2) offsets were obtained andcompared with the actual offsets. The maximumdifference between computed and actual offsetswas considered to be the group dispersion.

In order to show that the precision of offset esti-mation increased with the number of broadcasts,an experiment was conducted for values of m be-tween 1 and 50 broadcasts and values of n between1 and 20 receivers for a total of 1000 trials. In thecase of two receivers, the results show that when 30reference broadcasts were sent instead of onebroadcast, the precision improved from an errorof 11 ls to 1.6 ls. A precision of the order ofmicroseconds is clearly an excellent accuracy resultfor a sensor network.

The RBS protocol also estimates the skew be-tween clocks in neighboring nodes of a sensor net-work. The skew computation must use multiplereference broadcasts in order to observe variationsin the offset of two node clocks over time. Elsonet al. [19] use the least squares method to find abest-fit line that will provide an estimate of an-other node�s clock skew.

An experiment was conducted with a networkof Berkeley motes [35]. A reference packet with asequence number was periodically broadcast in anetwork of five motes. Each mote used a 2 ls res-olution clock to timestamp the reception times ofincoming broadcasts.

Fig. 16 shows a diagram by Elson et al. in whichthey plot the performance of their protocol [19].Each point in the diagram represents the differencebetween the times at which the two nodes reportedreceiving a reference broadcast, plotted on a time-

set in RBS protocol [19].

10

5

05

10

15

20

2001501000 50

400

500

200

100

15

Time (sec)

+

+

++

+

++

+

++

++

++20

300

(mic

roF

itse

c)E

rror

Pha

se

sec)

(mic

roO

ffse

t

Fig. 16. Clock skew estimation in RBS: each point representsthe phase offset between two nodes [19].


scale defined by one node�s clock. If Ti,k is the timeat which receiver i�s clock received message k, thecoordinates of each point in the figure are definedas follows for each message k received by receiversr1 and r2:

x ¼ T r1;k; y ¼ T r2;k � T r1;k: ð20ÞThe diagonal line drawn through the points rep-

resents the best linear fit of the plotted points. Thevertical impulses, read with respect to the right-hand Y-axis, show the distance from each pointto the best-fit line. Outliers (i.e., the points withthe highest residual error) are discarded. A nodecan compute a least squares error fit (diagonalline) and convert time values between its localclock and that of its peers. Here are some addi-tional features of the RBS protocol [19].

No clock correction. Once clock offset and skeware estimated, the local clocks of nodes are notcorrected to run synchronously with a global time-scale. Instead, each node keeps a table of parame-ters that relate the offset and skew of the node withrespect to every other clock in the network. When-ever a clock reading is received from another node,a node checks its table to translate the clock valuereceived to the local timescale. The advantage ofthis method is that considerable energy is savedby avoiding the process of correcting or resettingeach node�s local clock to a global time.

Post-facto synchronization. The RBS protocolachieves a high level of energy conservation byperforming synchronization only when it is

needed. Clocks run untethered at their own natu-ral rates and the timestamps from different clocksare compared only when an event of interest oc-curs. This technique is similar to reactive routing,which we discussed earlier. By synchronizing thenodes only when necessary, energy is conservedbecause the nodes can be switched to power-savingmode at all other times.

Multi-hop communication. Multi-hop synchro-nization is required in sensor networks that spanseveral node neighborhoods. Evidently, the possi-bility of multiple hops would introduce a high de-gree of variability in message transmission timebetween multiple receivers of the same message.In this case, the RBS protocol would lose its accu-racy. To avoid loss of precision, two nodes locatedin different neighborhoods are typically synchro-nized using a third node lying in the intersec-tion of the two neighborhoods. The supportfor multi-hop communication is more than aconvenience; large sensor networks make it anecessity.

Advantages:
1. The largest sources of error (send time and
access time) are removed from the critical pathby decoupling the sender from the receivers.

2. Clock offset and skew are estimated indepen-dently of each other; in addition, clock correc-tion does not interfere with either estimationbecause local clocks are never modified.

3. Post-facto synchronization prevents energyfrom being wasted on expensive clock updates.

4. Multi-hop support is provided by using nodesbelonging to multiple neighborhoods (i.e.,broadcasting domains) as gateways.

5. This protocol is applicable to both wired andwireless networks.

6. Both absolute and relative timescales can bemaintained.

Disadvantages:

1. The protocol is not applicable to point-to-pointnetworks; a broadcasting medium is required.

2. For a single-hop network of n nodes, this proto-col requires O(n2) message exchanges, whichcan be computationally expensive in the caseof large neighborhoods.

32

321

2

1

t

t

1

Fig. 17. Store and forward communication [56].


3. Convergence time, which is the time required tosynchronize the network, can be high due to thelarge number of message exchanges.

4. The reference sender is left unsynchronized inthis method. In some sensor networks, if the ref-erence sender needs to be synchronized, it willlead to a significant waste of energy.

4.2. Time synchronization in ad-hoc networks [56]

Romer�s synchronization protocol was designedspecifically for ad-hoc communication networks[56]. These networks consist of mobile, wirelesscomputing devices that can spontaneously com-municate when they are brought within eachother�s relatively limited transmission range. Whenthis happens, a symmetric bidirectional link isformed between pairs of neighboring nodes andnode synchronization takes place, if necessary.Ad-hoc networks are further characterized by thefollowing features. First, nodes are highly dynamic(mobile) and sparsely distributed. Second, thelinks or connections among the nodes have a rela-tively short range (e.g., measuring in the order ofhundred feet or less) and a short life span, due tonode mobility. Third, message passing is possiblein the following two ways.

1. Two nodes can exchange messages if one nodeenters the communication range of the other.This is a direct way of message exchange.

2. Two nodes that reside in different partitions cancommunicate by using store and forward tech-niques. An intermediate node can receive themessage from the sender, store it temporarily,and eventually forward it to the receiver afterentering the receiver�s communication range.

Fig. 17 shows a time chart for communicationbetween a sender and a receiver through an inter-mediate node. At time t1, node 1 (the sender) sendsa message to node 3 (the receiver) through node 2,an intermediate node that stores the message. Ifnode 2 comes into the receiver�s transmission rangeat time t2, the message is forwarded to node 3.

Romer notes that two fundamental assump-tions underlying synchronization in traditionalnetworks no longer hold in ad-hoc networks [56].

First, in traditional networks, the message trans-mission delay between any two nodes can be esti-mated with a high degree of accuracy. Second, inthose networks it is possible for nodes to periodi-cally exchange messages in order to synchronizewith each other. In ad-hoc networks, the firstassumption does not hold because an intermediatenode may introduce an arbitrarily long delay incommunication between a sender and a receiver.The second assumption does not hold becauseenergy constraints make it impossible to establisha-priori synchronization between arbitrary pairsof nodes in ad-hoc networks.

Romer�s protocol is based on two assumptions.The first assumption puts an upper bound, usuallydenoted by q, on the maximum skew of computerclocks. Second, whenever a message is exchangedbetween two nodes, the connection remains longenough for the two nodes to exchange one addi-tional message.

Similar to RBS, the key idea underlying Ro-mer�s protocol is to avoid synchronizing the localclocks of network nodes but instead to generatetimestamps using untethered local clocks. Whentimestamps are passed between nodes, they aretransformed to the local time of the receivingnode. Since this transformation will generallyintroduce errors, Romer�s protocol seeks to definean upper bound on the absolute value of the clockerror received by a node.

When a message containing a timestamp istransferred between nodes, the timestamp is firsttransformed from the local time to a common timetransfer format (UTC) and then to the local timeof the receiver. In more detail, the synchronizationprotocol performs the following steps: (1) deter-mine lower and upper bounds for the real-timeelapsed from the generation of the timestamp inthe source node to the arrival of the message inthe destination node; (2) transform these bounds


to the time of the destination node; and (3) sub-tract the resulting values from the time of arrivalin the destination node. The resulting intervalspecifies lower and upper bounds for the real-timeelapsed from the generation of the timestamp inthe source node to the arrival of the message inthe destination node. If real-time differences(UTC) are denoted by Dt and computer clock dif-ferences by DC, the transformation is based on thefollowing equation.

ð1� qÞ 6 DCDt

6 ð1þ qÞ: ð21Þ

The equation above can be transformed into:

ð1� qÞDt 6 DC 6 ð1þ qÞDt; ð22Þ

DC1þ q

6 Dt 6DC1� q

: ð23Þ

It can be inferred that the local clock differenceDC that corresponds to the real-time difference Dtcan be bounded by the following interval:

½ð1� qÞDt; ð1þ qÞDt�: ð24ÞThe basic principles underlying Romer�s syn-

chronization protocol are summarized in Fig. 18.In order to transform a time difference DC from

Fig. 18. Principles underlying Romer�

t 1

Sender

Receiver

t 2

t 4

M1 M2ACK 1

Fig. 19. Message delay

the local time of node 1 (with an upper bound q1on its skew) to the local time of node 2 (with upperbound q2), Dt is first estimated by the real-timeinterval ½ DC

1þq1; DC1�q1

�, which in turn is estimated bythe time interval ½DC 1�q2

1þq1, DC 1þq2

1�q1� relative to the

local time of node 2. Since an estimate of the life-time of a timestamp is calculated as the timestampis passed along different nodes, it is not practical toassume a constant message delay. In general, thetransmission delay between any pair of nodes in-volved in the transmission will be variable. Thus,the message delay between every pair of nodesalong the path must be estimated in order to arriveat an accurate solution. The message delay be-tween two nodes is estimated by bounding it with-in interval [0, rtt] where rtt is the round-trip timebetween the two nodes.

According to Fig. 19, the delay d for messageM2 can be estimated by the following equation,relative to the sender�s clock:

0 6 d 6 ðt3 � t2Þ � ðt6 � t5Þ1� qs

1þ qr

: ð25Þ

The difference t3 � t2 is the round-trip time (rtt),and t6 �t5 represents the storage time of the mes-sage at the receiver. Also, qs and qr are the q valuesfor sender and receiver, respectively.

s synchronization protocol [56].

t 3

t 5 t 6

ACK2

Time in Sender

Time in Receiver

estimation [56].

1 N32

2

21

1 rtt

idle

rtt

idle

Fig. 20. Timestamp estimation process [56].


As a message is transmitted over a sequence ofnodes, the round-trip time rtt between each pair ofnodes and the idle time (or storage time) are accu-mulated to estimate the value of the timestamp. Anode n involved in the transmission must add thetimes computed by all nodes including the messagedelay between each pair of nodes in order to esti-mate the timestamp�s value. Fig. 20 further illus-trates this mechanism.

Meier et al. recently defined an improved ver-sion of Romer�s protocol [45]. We briefly discussthis improvement in Section 4.10 below.

Advantages:

1. Local node clocks are allowed to run at theirown natural rates, which saves energy by avoid-ing computer clock correction.

2. The protocol requires low resource and messageoverhead, making it appropriate for resource-restricted environments.

3. The protocol is suitable for applications thatneed to communicate over long distances, thatis, distances much greater than the nodes� trans-mission ranges.

4. The time estimation is bounded within aninterval.

Disadvantages:

Deadline miss

before sync

after sync20

18

Fig. 21. Instantaneous versus continuous correction [57].

1. The synchronization error increases with thenumber of hops along the path of the messagecontaining the timestamp. In sparse networks,the number of hops is usually high and thisposes an obvious problem unless q is quitesmall.

2. Elson and Romer [20] have claimed that thesynchronization achieved by this approach islocalized and short-lived. This is appropriatefor networks with highly mobile nodes, but itclearly limits the applicability of Romer�sprotocol.

3. The protocol requires round-trip estimation,which can increase the synchronization error.

4.3. Continuous clock synchronization in wireless

real-time applications [49]

Mock et al. [49] defined a protocol for continu-ous clock synchronization in wireless sensor net-works by extending the IEEE 802.11 standard[31] for wireless local area networks. Their proto-col improves precision by exploiting the tightnessof the communication medium, similar to RBS[19], and also tolerates message loss. The corner-stone of the protocol by Mock et al. is the use ofcontinuous clock synchronization. This is in con-trast with the IEEE 802.11 standard, which usesinstantaneous clock synchronization.

In the case of instantaneous synchronization, anode computes a local clock error and adjusts itsclock using this computation. This results inabrupt changes in local clock time, which cancause time discontinuity. Time discontinuity canlead to serious faults in distributed systems, suchas a node missing important events (e.g., dead-lines) or recording the same event multiple times.Ryu and Hong [57] show one such possibility, asseen in Fig. 21. In the figure, assume that a taskhas a deadline at time 19. Assume further that at

Fig. 22. The IEEE 802.11 protocol.

master

t1time

t tt s3 4 t5 t6

slave

t2

Fig. 24. Reduced time-critical path (from t3 to ts) [49].


time 18 resynchronization occurs, resulting in localclock being corrected by 2 time units in the for-ward direction because it lags behind the referenceclock by 2 time units. After synchronization, thelocal clock advances to time 20 and the deadlineat time 19 is missed.

Continuous clock synchronization avoids suchdiscrepancies by spreading the correction over a fi-nite interval. The local clock time is corrected bygradually speeding up or slowing down the clockrate. However, this approach suffers from a highrun-time overhead since clocks need to be adjustedevery clock tick.

The IEEE 802.11 standard [31] includes a mas-ter–slave protocol for clock synchronization whichachieves limited precision due to instantaneoussynchronization. Mock et al. improved the IEEE802.11 protocol, which we show in Fig. 22, byemploying continuous correction and by using anadvanced rate adjustment algorithm.

The time-critical path in the IEEE 802.11 proto-col is the interval between the master taking itstimestamp and the slaves adjusting their clocks

–

Fig. 25. Synchronization protocol by Mock et al. [49

time432 ttt1t

master

slave

Fig. 23. Time-critical path of IEEE synchronization protocol[49].

(i.e., from t1 to t4). Fig. 23 illustrates this time-crit-ical path.

Given that the time-critical path above could bequite lengthy, Mock et al. exploit the broadcastproperty of the medium by assuming that messagereception is tight, similar to the RBS protocol [19].If two receivers receive the same message, it can beassumed that they receive it at approximately thesame time. Based on this property, the time criticalpath is shortened as shown in Fig. 24.

Fig. 25 shows the main steps in the synchroniza-tion protocol of Mock et al. The protocol uses twomessages for synchronization between a masterand a group of slaves, a so-called indication mes-

sage followed by a confirmation message. However,subsequent synchronizations are achieved with asingle message as the master timestamp for the lastconfirmation message now serves as the indicationmessage for the next synchronization round. Thistechnique achieves synchronization with just onebroadcast message per synchronization round,resulting in a significant reduction in the messageoverhead.

After the slave nodes complete the estimation ofthe master�s time, they must correct their local

]. Time instants t1, . . ., t6 are relative to Fig. 24.


clocks to reflect the master�s clock value. As wediscussed earlier, the protocol uses a rate-basedalgorithm to adjust the virtual clocks of slavenodes to run in tandem with the master. The differ-ence between a virtual and a physical clock can besummarized as follows. The physical clock of anode consists of an oscillator, which periodicallygenerates events, and a counter, which recordsthe number of elapsed events. This physical clockis not adjustable in any way. The counter�s valuecannot be incremented or decremented by the sys-tem�s software, and its frequency is also fixed. Avirtual clock is defined as a function from physicalclock values to virtual clock values. A virtual clockis intended to correct the skew rate of the physicalclock of the slave such that it resembles the phys-ical clock of the master. The function chosen isusually a linear transformation for the sake ofsimplicity.

Clock correction is performed by correcting theparameters of the linear transformation fromphysical to virtual clock values with every new syn-chronization. Thus, changing a virtual clock reallymeans changing the parameters of the transforma-tion from physical to virtual clock values. The goalis to make the virtual clock match the master clockas closely as possible.

Fig. 26 plots the transformation from physicalto virtual clock values at a slave node. FunctionMC relates actual master clock values with a slave�sclock values. The goal of the protocol is to estimatethis function as accurately as possible. Assuming a

t j Physicalclock

Virtualclock

t j+k t i-1 t i t i*

tm j

tm j+k

Ti-1

Ti*

P

P'

MC

QQ'

SCi-1

SCi'

Fig. 26. Time adjustment showing the slave�s physical clock onthe X-axis and the virtual clock on the Y-axis [49].

constant clock skew between the master�s and theslave�s clocks, function MC is linear. Thus, thisfunction is shown in Fig. 26 as a straight line. LetSC be the virtual clock of a slave that is correctedat every synchronization point. The values tmj,tmj+k contained in a message indicate the mastertimestamps for synchronization messages smj andsmj+k, respectively. Values tj and tj+k indicate thecorresponding timestamps on the slave�s physicalclock. Suppose that ti is the next synchronizationpoint and that t�i is some physical time betweenti�1 and ti. Ti�1 and T �

i are the corresponding vir-tual times of the slave clock for physical timesti�1 and t�i , respectively. Clock correction is per-formed by adjusting SC at every synchronizationpoint. The adjustment is performed by changingthe parameters of the linear transformation func-tion and this adjustment is performed graduallyover a period of time (continuous) to avoid timediscontinuity. After the point Q in Fig. 26, it canbe observed that the master node and the slaveare in synchrony, assuming tight reception.

The protocol of Mock et al. also provides a highdegree of tolerance with respect to message loss.This is an important feature because the rate ofmessage loss is higher in wireless than in wired net-works as the wireless medium is rather prone toexternal interference. The protocol defines an omis-

sion degree OD to be an upper bound on the num-ber of consecutive messages that can be lost dueto errors in the medium. In order to tolerate upto OD consecutive message losses, the timestampvalues for the last n (n = OD + 1) messages are in-cluded in each synchronization message. Thus, aslave can synchronize with the master on the recep-tion of a message, if it has received at least one ofthe previous n synchronization messages.

Advantages:
1. The protocol provides reasonably good accu-
racy results when message transmission betweenmaster and slaves is tight.

2. The protocol improves over the IEEE 802.11protocol by using continuous, rather thaninstantaneous, clock updates [31].

3. The message complexity of the protocol is quitelow because the protocol requires only one mes-sage per synchronization round.


4. The protocol accounts for potential messagelosses, a common situation in wireless net-works.

Disadvantages:

Node A

2 3

4

Node B

T1

TT

T

Fig. 27. Message exchange between two nodes A and B [24].

1. The protocol assumes tight communicationbetween the master and the slaves. Conse-quently, the protocol cannot accommodatemulti-hop communication because of its longerand unpredictable delays.

2. A considerable amount of energy is spent onperforming clock correction. This problem isexacerbated by the fact that clock correction iscontinuous.

3. The computational load on each node is highdue to the rate-based correction method.

4.4. Network-wide time synchronization in sensornetworks [24]

Scalability is a primary concern in wireless sen-sor networks because of the large number of nodeswith very limited energy resources at each node.The network-wide time synchronization protocolis aimed at ensuring that synchronization accuracydoes not degrade significantly as the number ofnodes being deployed increases [24]. The objectiveof the protocol is to establish a unique global time-scale by creating a self-configuring hierarchicalstructure in a wireless network. A node in thisstructure can simultaneously act as a synchroniza-tion server to a number of client nodes and as a syn-chronization client to another (server) node. Thesignificance of this method lies in achieving syn-chronization at a network-wide level as opposedto methods which work effectively only within asmall cluster of nodes lying in a neighborhood,such as RBS and continuous clock correction[19,49]. The network-wide time synchronizationprotocol works in two phases: The level discovery

phase, followed by the synchronization phase.Level discovery phase. The level discovery phase

is based on constrained flooding. The root node isassigned level 0; this node initiates this phase bybroadcasting a level-discovery packet that con-tains the identity and the level of the sender. Theimmediate neighbors that receive this packet as-

sign themselves a level that is one greater thanthe level in the packet received (i.e., level 1 in thiscase). After this step, these neighbors broadcast anew level-discovery packet with their own level.This process is continued until each node has alevel. Upon being assigned a level, a node neglectsfurther packets to implement a constrainedflooding.

Collision handling is important at this point be-cause a node may not receive any level-discovery

packets due to MAC layer collisions. When a nodeis deployed, it waits for some time to be assigned alevel. If it is not assigned a level within that period,it times out and broadcasts a level-request packet.The neighbors reply to this request by sendingtheir own level and the new node defines its levelto be one greater than the level it received.

Synchronization phase. Consider a message ex-change between two nodes A and B, as shown inFig. 27. T1 and T4 represent the time measuredby A�s local clock. Similarly, T2 and T3 representthe time measured by B�s local clock. We assumethat A�s level is greater than B�s by one. The syn-chronization phase of the protocol is described inFig. 28.

Unfortunately, the hierarchical structure thatthe protocol imposes on the net makes the proto-col vulnerable to node failures. This issue mustbe addressed because nodes can fail unpredictablyin a sensor network. When this happens, it is pos-sible for a node at level i not to have a neighbor(i.e., a synchronization server) at level i � 1. Insuch cases, the node at level i would not receivean acknowledgement to its synchronization mes-sage. To handle this case, the node retransmits a

Fig. 28. Synchronization protocol for network


message for a fixed number of times before assum-ing that it has lost all its neighbors. If the nodedoes not receive any responses to its synchroniza-tion messages, it broadcasts a level-request packetwith a new level. Next, the node synchronizes withits new neighbors as described in Fig. 28. Thenumber of retransmissions of a synchronizationmessage is subject to two constraints. If this num-ber is too large, it will increase the time taken forsynchronization (i.e., the convergence time). Ifthe number is too small, a node may erroneouslyconclude that its server has died. In this case, theprotocol will cause unnecessary message floodingin the network. The authors suggest that an opti-mal number of retransmissions is four [24].

Advantages:
1. The protocol is scalable and the synchroniza-
tion accuracy does not degrade significantly asthe size of the network is increased.

2. Network-wide synchronization is effectivelyachieved in contrast with the protocol by Mocket al. [49], which works effectively only within asmall cluster of nodes.

3. Network-wide synchronization is computation-ally less expensive when compared to such pro-tocols as NTP [48].

Fig. 29. Algorithm underlying flexible ligh

Disadvantages:
1. Energy conservation is not very effective
because it requires a physical clock correctionto be performed on local clocks of sensors whileachieving synchronization.

2. The protocol requires a hierarchical infrastruc-ture which makes it unsuitable for applicationswith highly mobile nodes.

3. Support for multi-hop communication is notprovided.

4.5. Delay measurement time synchronization

protocol [54]

Time-keeping is the process of maintaining auniform notion of time among the sensors thatparticipate in the network [54]. A global time-stamp provides a basis for merging individual sen-sor readings into a database. Also, synchronizedtime is essential for energy-efficient schedulingand power management. This protocol, which ap-pears in Fig. 29, includes the following features.

1. Maintenance of a local clock.2. Synchronization of local clocks over the whole

network to create a network time.

-wide time synchronization protocol [24].

tweight time-keeping protocol [54].

B. Sundararaman et al. / Ad Hoc

3. Synchronizing to a global time source by con-necting the global source to the synchronizationleader in the network.

4. Application programming interface for provid-ing services to client applications.

This protocol has been implemented on sensornodes consisting of Berkeley motes running theTinyOS kernel [61]. Node synchronization is basedon the concepts of event timestamps and network

event scheduling. The synchronization protocolspecifically combines delay measurement with theproperty of the sender�s timestamp being a com-mon-view timestamp from the receivers� point ofview. The receivers can synchronize with eachother better than they can synchronize with thesender.

The synchronization accuracy of this protocol isbounded mainly by the precision of delay measure-ments along the path. Since only one message is re-quired to synchronize all nodes within the leader�stransmission range, this method is quite energyefficient. It is also computationally lightweight be-cause there are no complex mathematical opera-tions involved.

Multi-hop synchronization is also supported byextending the single-hop synchronization protocolas follows. If a node knows that it has children, itsends a broadcast time signal after adjusting itsown time. The node can now synchronize withits children by using single-hop time communica-tion with a known leader. To tackle the problemthat in most networks nodes have no knowledgeabout their children, the concept of a time-sourcelevel is used to identify the network distance of anode from the master. A time master initiates thesynchronization protocol; the master�s time sourcelevel is zero. A node synchronizing directly withthe master is at time source level one. This algo-rithm guarantees that the root time will be propa-gated to all network nodes with a limited numberof broadcasts.

Advantages:
1. A user application interface is provided to mon-
itor a wireless sensor network at run-time.2. Computational complexity is low and energy

efficiency is quite high.

Disadvantages:
1. The protocol can be applied only to low resolu-
tion, low frequency external clocks.2. Synchronization accuracy is traded for low com-

putational complexity and energy efficiency.

4.6. Probabilistic clock synchronization service in

sensor networks [53]

Most synchronization protocols in practice relyexclusively on deterministic algorithms. An advan-tage of deterministic methods is that they usuallyguarantee an upper bound on the error in clockoffset estimation. However, when the system re-sources are severely constrained, a guarantee onsynchronization accuracy may result in a largenumber of messages being exchanged during syn-chronization. In these cases, probabilistic algo-rithms can provide reasonable synchronizationaccuracy with lower computational and networkoverhead than deterministic protocols. Pal-Chaudhuri et al. [53] defined an extension toRBS [19], by providing a probabilistic bound onthe accuracy of clock synchronization. An attrac-tive feature of their protocol extension is that itallows to tradeoff dynamically synchronizationaccuracy for computational and energy resources.

As we show in Fig. 16, in RBS [19] multiplemessages are sent from the sender to the set ofreceivers, and the differences in actual receptiontimes at the receivers are plotted. As these mes-sages are independently distributed, the differencein reception times gives a Gaussian (or normal)distribution with zero mean. Assuming a Gaussianprobability distribution for the synchronizationerror, the relationship between a given maximumerror in synchronization and the probability ofactually synchronizing with an error less than themaximum error can be easily computed.

If the maximum error allowed between two syn-chronizing nodes is �max, then the probability ofsynchronizing with an error � 6 �max is derivedfrom the Gaussian distribution property,

Pðj � j6 �maxÞ ¼R �max

��max��x2=2 dxffiffiffiffiffiffi2p

p : ð27Þ

Networks 3 (2005) 281–323 307

308 B. Sundararaman et al. / Ad Hoc

As the �max limit is increased, the probabilityof failure (1 � P(j�j 6 �max)) decreases exponen-tially.

Based on this relation between the maximumsynchronization error and the probability of actu-ally synchronizing with a smaller error than thepredefined maximum, PalChaudhuri et al. [53] de-rive expressions that convert service specifications(maximum clock synchronization error) to actualprotocol parameters (number of messages and syn-chronization overhead). The probability of theachieved error being less than the maximum spec-ified error is given as follows:

P ðj � j6 �maxÞ ¼ 2erf

ffiffiffin

p�max

r: ð28Þ

In the above equation, n is the minimum num-ber of synchronization messages to guarantee theerror and r is the variation of the distribution.

The relationship between the number ofmessages, n, and error probability P is shown inTable 4. The table reports data for �max/r ratiosof 0.5, 1.0, and 2.0.

Advantages:
1. A probabilistic guarantee reduces both the
number of messages exchanged among nodesand the computational load on each node.

2. A tradeoff between synchronization accuracyand resource cost is allowed.

3. Support for multi-hop networks, which spanseveral domains, is provided.

Table 4Variation in probability and number of messages for differentvalues of �max=r [53]

�max/r Probability Number of messages

0.5 0.95 160.5 0.99 280.5 0.999 44

1.0 0.95 41.0 0.99 71.0 0.999 11

2.0 0.95 12.0 0.99 22.0 0.999 3

Disadvantages:
1. In safety-critical applications (e.g., nuclear
plant monitoring), a probabilistic guaranteeon accuracy may not suffice.

2. The protocol is sensitive to message loss; how-ever, provisions for message loss are notconsidered.

Networks 3 (2005) 281–323

4.7. Sichitiu and Veerarittiphan’s protocol [58]

Sichitiu and Veerarittiphan�s protocol [58] pro-vides deterministic clock synchronization for wire-less sensor networks with minimal computationaland storage complexity. The protocol is especiallysuitable for applications with severe constraints oncomputational power and bandwidth. It uses twoalgorithms called mini-sync and tiny-sync. Thetiny-sync algorithm acquires its name from the factthat it needs very limited resources, fewer re-sources than mini-sync.

The two algorithms have various commonfeatures.

1. A tight deterministic bound is provided forclock offset and skew, as opposed to probabilis-tic guarantees [53].

2. The protocols are highly tolerant to messagelosses.

3. Both protocols have low computational andstorage complexity.

4. Both protocols can be extended to any commu-nication network that allows bidirectional datatransmission.

5. The estimation of clock skew and offset is per-formed using the set-valued estimation method[40] discussed in Section 2.4.4.

Recalling Eq. (17) of the set-valued estima-tion method, for nodes 1 and 2, the skew andoffset between their clocks are captured by the fol-lowing equation, where a12 and b12 represent theskew and offset between the clocks in node 1 andnode 2.

t1ðtÞ ¼ a12t2ðtÞ þ b12: ð29ÞSichitiu and Veerarittiphan�s protocol [58] ex-

tends the set-valued estimation method [40] intwo significant ways.


1. Relaxing the immediate reply assumption. InFig. 11, it is assumed that node Pj immediatelyresponds to node Pi. The correctness of theapproach is not affected if Pj sends a delayedreply. However, if the delay between tik and tikincreases, the precision of the estimates willdecrease. Since Pj can delay its reply in practice,the loss of precision is handled by letting Pj

timestamp the message both upon receipt (tjkr)and when it resends it (tjkt). This gives us twodata points (tik, tjkr, tik and tik, tjkt, tik) which willbe treated independently. The obvious solutionis to choose the data point that gives a betterprecision.

2. Increasing accuracy by considering the minimum

delay. If the minimum delay that a messageencounters between two nodes is known, thedata points can be adjusted for a boost in preci-sion. In Fig. 11, if the delay between the time Pi

timestamps the message (ti1) and the time atwhich Pj timestamps the message (tj1), as wellas the delay between Pj timestamping the mes-sage and Pi receiving that timestamp areknown, we can use this information in the datatriplet to make more estimates.

Tiny-sync: The tiny-sync algorithm is based onthe observation that not all data points obtainedfrom the set-valued estimation method are useful.Each data point consists of two constraints, whichare bounds on the clock offset and clock skew. Atany point of time, only four constraints are kept in-stead of six constraints. Upon the arrival of a newdata point, the two new constraints are comparedwith the existing data points and only the four con-straints that result in the best estimates are kept.

The computational complexity of the tiny-syncalgorithm is relatively low because the compari-sons to determine the four best constraints involveonly a few arithmetic operations. In addition, thestorage space required is also quite low becauseat any time, only four constraints and eight time-stamps (two per constraint) need to be stored.

Mini-sync: The mini-sync algorithm improvesthe accuracy of Tiny-sync at a small computationalcost. In Fig. 12, when the data point that corre-sponds to [ti3; ti3] arrives, we can ignore thedata point that corresponds to ti2 and consider only

the first and third data points. However, when thefourth data point arrives, since we discarded thesecond data point, we are forced to use the firstand the fourth data points as bounding constraints.Although the second data point—when bound tothe fourth data point—could have yielded betterprecision, this precision cannot be accomplishedbecause the second data point was discarded.Mini-

sync corrects this flaw and improves precision bydiscarding a constraint only if a newer constrainteliminates an existing constraint. This means thatthe constraints corresponding to the second datapoint will not be discarded when the third datapoint arrives. It will instead be saved until thefourth data point uses it to obtain a better estimate.In practice, experiments reveal that around 40 datapoints (80 constraints) have to be stored at a time,which is quite reasonable.

Advantages:
1. The protocols provide a tight, deterministic syn-
chronization scheme with low storage and com-putational complexity.

2. The protocols are suitable for sensor networksthat are highly constrained in bandwidth andcomputational power.

3. The protocols are tolerant of message losses.

Disadvantages:
1. The scalability and robustness of the protocols
have not been discussed.2. The convergence time, which is the time needed

to achieve synchronization of the entire net-work, is high.

3. The sensor network is logically organized as ahierarchy, making it inapplicable to mobile sen-sor networks.

4.8. Time-diffusion synchronization protocol [62]

The Time-Diffusion synchronization Protocol(TDP) enables all the sensors in the network tohave a local time that is within a small boundedtime deviation from the network-wide ‘‘equilib-rium’’ time. Due to clock skews, the algorithmswithin the protocol have to be applied periodically.

Fig. 30. Illustration of timing relationships between the TProunds (each of duration d) and the PEP duration within eachcycle, and the various cycles, each of duration s, within anactive phase.

J

C

D E

F

A

B

by E

by K

by A

diffusion initiated

diffusion initiated

diffusion initiated

diffused leader nodemaster node

GH

I

K

Fig. 31. Illustration of time diffusion with three master nodesand n = 3 hops. The level of a node is defined with respect toeach master. Outlier nodes, which do not diffuse timingmessages, are not shown for simplicity. In each round, nodestake the hop-weighted (or cumulative deviation weighted)average of the different times received from the masters�diffused broadcasts.


Hence, the protocol operates in alternating active

and inactive phases. The protocol is comprised ofseveral algorithms, which will be described nextin the context of one such active phase.

Within each active phase there are multiple cy-cles, each cycle lasting a duration s. In each cycle,a subset of the nodes are elected as the masters byan Election/Relection Procedure (ERP). Eachmaster concurrently initiates a diffusion of timingmessages; these messages effectively create a tree-like propagation structure dynamically in the net-work, for each diffusion. The non-leaf nodes in thistree are the nodes which propagate the timing mes-sages, and are termed as ‘‘diffused leaders’’. Thesediffused-leader nodes are also elected by the ERP.Thus, it may happen that a node does not qualifyto be a diffused leader node, and hence will notpropagate the diffusion. The goals of the ERPare twofold.

• To eliminate outlier nodes whose clock varianceis above some threshold function based on aspecific type of variance calculation, termedthe Allen variance. This variance is determinedby exchanging messages and calculating devia-tions between pairs of adjacent nodes using aPeer Evaluation Procedure (PEP).

• To achieve load distribution among the nodesbecause the roles of masters and diffused leadersput a greater demand on the energy resource.The load distribution is achieved by takingturns at being the master, based on factors suchas the available energy level being above a tun-able threshold.

In each cycle, the diffusion of timing messageshelps to converge the local times, and reach a com-mon notion of the system-wide time.

Each cycle has two logical functions, executedserially—(1) determining master nodes and dif-fused leader nodes, using the PEP, and then (2)the main Time Diffusion Procedure (TP). Eachcycle has duration s; the TP consists of multiplerounds, initiated d time units apart. The timingrelations are illustrated in Fig. 30. There is a singlebroadcast within each round, with respect to a sin-gle master. Note that each master initiates a con-current broadcast that gets diffused in that round

in a tree-like structure, as illustrated in Fig. 31.Also note that the masters� time can be coordi-nated to an external precise time server that doesperiodic broadcasts of a reference time. If no timeservers are available, the protocol works equallywell by using a time that is independent of the timeused by the Internet, e.g., Universal CoordinatedTime (UTC). We now look at the details of a sin-gle cycle with respect to a single master.

1. The first function (PEP) in each cycle is todetermine the master node eligibility for thenext cycle, and the diffused leader responsibilityfor the remainder of this cycle.(a) The first step occurs between any master,

which is at level one, and its neighbors.(i) The master sends a large number of

timestamped scan messages to itsneighbors.


(ii) The neighbors send back acknowledge-ments containing the 2-sample Allenvariance of the local clock from themaster�s clock.

(iii) Based on the received samples, the mas-ter calculates (a) an outlier ratio cyz foritself (y) and each neighbor z, (b) theaverage of the Allen variances, and(c) the average of the Allen deviations.Now, (a), (b), and (c) are sent to eachneighbor z in a RESULT message.

(b) In each subsequent step j = 2,3, . . .,n, theabove is repeated between each level j dif-fused leader node and its neighbors.

As this broadcast diffusion progresses, all sen-sors will get the outlier ratios and the averageAllen deviation (with respect to their neigh-bors). These are used to evaluate the qualityof their clocks with respect to their neighbors.If a node�s average outlier ratio is >1, its localclock deviates from the clocks of its neighborsby more than twice the Allen variance. In thiscase, that node does not become a diffused lea-der during the (Time Diffusion Procedure ofthe) current cycle, or a master in the nextcycle.Further, among the nodes that are eligible forbeing masters in the next cycle, whether a nodewill actually qualify for being a master in thenext cycle now depends on its energy availabil-ity being above a certain (dynamically adjust-able) threshold. Load balancing is done byrotating the role of master nodes; hence thealgorithm can be viewed as being distributed.Analogously but somewhat differently, whetherthe nodes eligible to become diffused leaders inthe current cycle actually assume that role isdetermined dynamically for each round in thiscycle, based on energy level considerations.

2. The TP performs the main function of diffusingthe time from each master in a tree-like mannerfor n hops, where n is some predeterminedparameter smaller than the diameter of the net-work. It uses the message M(tM,i,n,bM,k), where• tM,i is the diffused time of the master M, to

which the nodes synchronize in round i.• n is the number of levels (i.e., depth) to which

the timing information is to be diffused.

• bM,k is the deviation of the correspondingtM,i at a node k hops from the master M.

The TP within any cycle has a succession ofrounds initiated by the master, d time unitsapart from tM,0. The broadcast within a roundcompletes before the next round is initiated.The following broadcast is executed for eachround i.(a) The first step, executed between any master,

which is at level one, and its neighbors:(i) Send a timing message M(tM,i,n,bM,k)

to neighboring nodes at time tM,i.(ii) Elected diffused leaders at the next level

respond with a timestamped ACKmessage.

(iii) Master computes D = average(Dj),where Dj is the round-trip time betweenthe master and the diffused leader j.The diffused time from the master nodeis

tM ;i ¼ tM ;i þ D=2þ d: ð30ÞHere, d is the amount of time that thenodes wait (relative to tM,i) beforeadjusting their clocks at the end ofthe round. The standard deviation aof the rtt Dj, which gives an estimateof the quality of diffused time tM,i, isaccumulated in bM,k at each hop fromthe master. This accumulated deviationis

bM ;k ¼ bM ;k�1 þ a; ð31Þ

where k 6 n is the number of hopsfrom the master.

(b) On receiving a timing messageM(tM,i,n,bM,k), for each subsequent stepj = 2,3, . . .,n, the above is repeated betweenthe elected diffused leaders at level j, andtheir neighbors.

For each round, each node builds a table Tablewith rows of the following format, and popu-lates it with the information received within thatround.

hmaster id M ; bM ;k; tM ;ii: ð32Þ

After each round i within a cycle, each node re-sets its time to ti, the weighted sum of the times


tM,i in its table, based on the values of all thediffused messages received in this round fromdifferent master initiators, and as recorded inthe local Table. The table is also cleared at theend of each round i.

ti ¼X

hbM ;k ;tM ;ii in Table

½P

bM 0 ;k0 in TablebM 0;k0 � � bM ;kPhbM 00 ;k00 ;tM 00 ;ii in Table½½

PbM 0 ;k0 in TablebM 0;k0 � � bM 00;k00 �

� tM ;i: ð33Þ

For any tM,i, (i) the numerator of the weight isthe sum of all the deviations of all the diffusionmessages, less the deviation for this particularmessage, and (ii) the denominator of theweight is the sum of all such numerators forall the timing entries in the table. Thus, the va-lue of each clock is set to the weighted averageof the clock values of the different masternodes of that round, after averaging the datacollected from multiple messages received with-in that round. Due to the weighted averaging,all the nodes tend towards a common equilib-rium time.

Advantages:

1. The protocol is tolerant of message losses.2. The protocol achieves a system-wide ‘‘equilib-

rium’’ time across all nodes, computed usingan iterative weighted averaging technique, andinvolves all the nodes in the synchronizationprocess.

3. The diffusion does not rely on a static level-by-level transmission. This non-dependence on astatic structure provides flexibility and fault-tolerance.

4. The protocol is geared towards mobility.5. Although there is a hierarchical structure, that

is neutralized by having multiple master nodesdistributed across the network.

6. Most synchronization protocols require precisetime servers and cannot function properly with-out these servers. On the other hand, the TDPprotocol can provide synchronization evenwithout external time servers.

Disadvantages:
1. Each active period has multiple cycles, and each
cycle has multiple rounds, in each of which adiffusion broadcast is initiated by multiple mas-ters. This leads to high complexity.

2. The convergence time tends to be high when noexternal precise time servers are used. However,if the servers are used, the convergence time iscomparable to a server-based technique.

3. It appears that it is possible for clocks torun backward. This can happen whenever aclock value is suddenly adjusted to a lowervalue.

4.9. Asynchronous diffusion protocol [42]

Li and Rus have defined a so-called rate-based

diffusion protocol in which nodes achieve synchro-nization by flooding their neighbors with informa-tion about each node�s local clock value [42]. Aftereach node has learned the clock values of all itsneighbors, the node can use a mutually agreedupon consensus value to adjust its clock. Examplesof consensus values suggested by the authors in-clude the highest clock reading in the net, the low-est clock reading, or some statistical value basedon the clock readings (e.g., the average or the med-ian of the readings). According to the authors,using the highest or the lowest reading yields thesimplest synchronization algorithm; however, thisstrategy lacks robustness. A malicious or erraticnode may impose an abnormally high (or low)clock value on the whole network.

Li and Rus define a synchronous and anasynchronous version of their rate-based diffusionprotocol [42]. Fig. 32 illustrates the synchronousversion. The algorithm appearing in the figure isassumed to be executed with a certain frequencyby all nodes contained in the network. Duringeach synchronization round, each network nodeni exchanges its clock reading with every neighbornj. Node ni adjusts its clock value by a factor pro-portional to ti � tj, the difference in the clock val-ues of ni and nj. Coefficient rij is the so-calleddiffusion value of node nj relative to ni; this valueindicates the weight of nj when adjusting ni’s clockvalue.

Fig. 32. Algorithm underlying the synchronous version of Liand Rus�s diffusion protocol [42].


Li and Rus define the r coefficients in such a waythat "i"j, rij P 0 and also

P8j2Nrij ¼ 1. Also, the

coefficients are symmetric, meaning that "i"j, rij =rji. When nodes ni and nj are not in the same neigh-borhood, they cannot exchange clock readings. Inthis case, the coefficients are assigned values rij =rji = 0. Li and Rus showed that this protocol con-verges to the average value of the clock readingsin the network, within a certain error, in a boundednumber of synchronization rounds [42]. Thenumber of synchronization rounds depends onthe actual values of the coefficients in the network.

In the asynchronous version of Li and Rus�s dif-fusion-based protocol, nodes compute averageclock readings asynchronously with respect toother network nodes. (In the synchronous version,nodes exchange clock values and adjust theirclocks simultaneously.) Fig. 33 illustrates the algo-rithm underlying the asynchronous version of thediffusion protocol.

Any network node can now update its clock va-lue asynchronously with respect to other nodes inthe network. As we show in Fig. 33, a node ni startsa round of synchronization by first asking all itsneighbors for their clock values. Next, the nodecomputes the average of its clock value and the val-ues obtained from the neighbors. Finally, the nodeupdates its clock to the computed average and noti-fies its neighbors of the computed value. Li andRus show that the asynchronous version of theprotocol converges to the average value of clockreadings in the network, under relatively broad

Fig. 33. Algorithm underlying the asynchronous ve

assumptions on network connectivity, providedthat all net nodes perform synchronization with acertain probability. Nodes are not required to befully connected with all other nodes in the networkin order for this protocol to converge, although thenetwork must be connected at all times [42]. Evi-dently, if a node or node subset becomes perma-nently disconnected from the rest of the network,network-wide clock synchronization is impossible.

Li and Rus ran many simulations of the asyn-chronous synchronization algorithm while varyingseveral synchronization parameters. Some simula-tions show that the synchronization error amongnetwork nodes decreases exponentially with thenumber of synchronization rounds for a networkof 200 nodes [42]. In addition, Li and Rus analyzedthe convergence speed of the protocol as a functionof node density (i.e., the number of nodes in aneighborhood). These simulations show thatsparse networks (i.e., networks with few nodes ina given area) exhibit both a slower convergencespeed and a high variation in convergence time.Networks with a high node density converge faster,and with lower variation, than sparse networks.Similarly, the convergence speed improves as thecommunication range of the nodes is increased.

Advantages:
1. The protocol achieves a system-wide ‘‘equilib-
rium’’ time across all nodes involved in asynchronization.

2. The protocol does not rely on an external timeserver or a synchronization leader to reach con-vergence, which is beneficial for the robustnessof the protocol.

Disadvantages:

1. The protocol seems to violate a fundamentalrequirement of clock synchronization, namely,that time never run backward. (See Fig. 3above.) As nodes adjust their clock values

rsion of Li and Rus�s diffusion protocol [42].


down, they will repeat clock values obtainedearlier, defeating one purpose of synchroniza-tion. This problem is exacerbated in the asyn-chronous version of the protocol because inthis case, nodes can adjust their clock valuesindependent of other nodes in the network.

2. The protocol assumes that any two nodes canaccurately swap their clock readings when run-ning their synchronization protocol. In practice,achieving this goal can be quite difficult. Li andRus advocate the use of the RBS protocol [19]for this purpose, because RBS can in factachieve a high level of accuracy.

3. The complexity of the protocol is quite high,comparable to that of RBS. Many synchroniza-tion rounds are needed to reach reasonable con-vergence, and each node must communicatewith every other node in its neighborhoodto achieve convergence. Worse yet, in Li andRus�s simulations, hundreds of synchronizationrounds are needed to achieve reasonable accu-racy [42]. It is unclear whether the asynchro-nous diffusion protocol can improve RBS�ssynchronization accuracy.

4. The protocol makes no provisions for exploit-ing clock skews in achieving synchronization.Given that all node pairs exchange clock infor-mation during each synchronization round, itwould be relatively easy for nodes to estimatethe skew of their neighbors� clocks in an effortto improve accuracy.

4.10. Other protocols

Clock synchronization in sensor networks iscurrently the subject of numerous active investiga-tions. For reasons of space, we are unable to dis-cuss in detail all the new protocols that havebeen defined recently. In this subsection, we brieflysummarize some of those protocols.

4.10.1. Tulone’s Clock Reading protocols

Tulone sketched a deterministic protocol and aprobabilistic protocol for clock synchronization insensor networks [67]. The first protocol, calledDeterministic Clock Reading (DCR), seeks to mini-

mize the offset of a node�s clock relative to othernodes in a sensor network when the node is outof the communication range of any other networknode. Assume that synchronization rounds, duringwhich nodes correct their clock values, occur peri-odically in a sensor network. If a node becomestemporarily isolated from the network, it will missone or more synchronization rounds with neigh-boring nodes. In this case, the offset of the node�sclock relative to the clock of its neighbors maygrow beyond an acceptable threshold.

The DCR protocol observes the standard devi-ation of a node�s clock with respect to one of thenode�s neighbors over two consecutive synchroni-zation rounds. The observed deviations can beused to correct the speed of a node�s clock, similarto Cristian and Fetzer�s calibrated-clocks method[12]. In the world of sensor networks, the rationaleof the DCR method is similar to that of the set-valued estimation protocol, which we discussedin Section 2.4.4, in that DCR adjusts a node�sclock rate based on multiple readings of a neigh-bor�s clock. As with set-valued estimation, it is un-clear whether DCR will work in practice, becauseit is possible for a node to overcorrect its clockrate. This may happen when a node overestimatesthe speed of a neighbor�s clock, for instance, be-cause of unpredictable variations in message trans-mission delays. When this happens, a chain ofcorrections involving all nodes in an entire neigh-borhood may ensue, causing all nodes to increaseindefinitely their clock rates.

The second protocol, Probabilistic Clock Read-

ing (PCR) is a probabilistic variation of DCR.PCR overcomes the problem of intermittent com-munication by using the theory of time-seriesforecasting. A network node uses a time-seriesapproximation of a sequence of clock readingsfrom one of the node�s neighbors in order to esti-mate the offset and skew of the neighbor�s clockrelative to the node�s clock [67].

4.10.2. Meier et al.’s protocol

Meier et al. recently defined an improved ver-sion of Romer�s protocol [45] which we discussedin Section 4.2. Similar to Romer�s protocol, Meieret al. seek to provide tight lower and upper boundson the clock reading of local node ni when an event


is detected by a different node nj. Meier et al. definea tighter lower bound for ni�s clock reading using adifferent formula from Romer�s protocol. In addi-tion, Meier et al. define a method for defining opti-mal bounds under the assumption that messagedelay uncertainties are negligible [45]. Under thisassumption, multiple consecutive message ex-changes between two nodes can be regarded as asingle communication event. Although theseassumption are not true in practice, the methodof Meier et al. can be modified to accommodatesmall communication delays, such as thoseachieved with RBS [19].

4.10.3. Lightweight Tree-based Synchronization

Van Greunen and Rabaey�s Lightweight Tree-

based Synchronization (LTS) protocol [68] is aslight variation of the network-wide synchroniza-tion protocol of Ganeriwal et al. [25] which we dis-cussed in Section 4.4. Similar to network-widesynchronization, the main goal of the LTS proto-col is to achieve reasonable accuracy while usingmodest computational resources (both in termsof memory space and CPU time). Van Greunenand Rabaey give two versions of the LTS protocol[68]. In the centralized version, each round of syn-chronization is initiated by a designated node atsome frequency. In the decentralized version, anynode can start a synchronization round. As withNetwork-Wide Synchronization [25], the LTSprotocol seeks to build a tree structure within thenetwork. Adjacent tree nodes exchange synchroni-zation information with each other. A disadvan-tage is that the accuracy of synchronizationdecreases linearly in the depth of the synchroniza-tion tree (i.e., the longest path from the node thatinitiates synchronization to a leaf node). Van Gre-unen and Rabaey discuss various ideas for limitingthe depth of the tree; the performance of both pro-tocol versions is analyzed with simulations [68].

4.10.4. TSync protocol

Similar to Van Greunen and Rabaey�s LTS pro-tocol, Dai and Han�s TSync protocol [15] is basedon the network-wide synchronization protocol ofGaneriwal et al. [25]. As with LTS, TSync has a

centralized version, called the Hierarchical Refer-

encing Time Synchronization (HRTS) protocol,and a decentralized version, called the Individual

Time Request (ITR) protocol. The HRTS protocolcleverly combines the notion of hierarchical syn-chronization, typical of network-wide synchroniza-tion, with receiver-to-receiver synchronization,similar to RBS [19]. Dai and Han further enhancethe performance of both the HTRS and ITR proto-cols by using dedicated MAC-layer channels forsynchronization. The ITR protocol differs fromthe HRTS protocol in that synchronization is initi-ated by any node as opposed to a designated basestation. Dai and Han compared empirically theperformance of the HRTS and ITR protocols witha multi-hop extension of RBS [19]. In Dai andHan�s experiments, HRTS can achieve a synchroni-zation accuracy close to that of the RBS extension,while reducing the total number of exchanged mes-sages with respect to RBS. However, the accuracyobtained with both RBS and HRTS, in the orderof 20 ls for single-hop synchronization, is lowerthan other reported results for RBS. (See, e.g.,[19].) The performance of the ITR protocol isworse than both HRTS and RBS, especially inthe case of multi-hop synchronization.

4.10.5. Hu and Servetto’s protocol

Finally, Hu and Servetto [30] defined a protocolfor synchronization in networks with a high con-centration of nodes per unit of surface. Synchroni-zation proceeds in concentric waves, starting froma master node located in the center of the network.Under strong assumptions on the behavior of thenet, Hu and Servetto show that their protocol isoptimal in the sense that all nodes will eventuallysynchronize with the master�s clock. This is a valu-able theoretical result; however, it is currently un-clear how this protocol will perform in practice.Hu and Servetto assume that there is no communi-cation delay between nodes (i.e., message transmis-sion delay is always zero) and no conflicts onnetwork use (i.e., a node will have immediate ac-cess to the network whenever it needs to transmita message). In addition, the complexity of the pro-tocol seems to be high, meaning that achievingoptimality involves a large number of message ex-changes among network nodes.


5. Comparison of protocols

We compare and evaluate the various synchro-nization protocols. Before we evaluate the variousprotocols, we must first define in detail the criteriathat we will use in our comparisons. For the sakeof clarity, we divide our evaluation criteria be-tween quantitative and qualitative criteria. Theformer include synchronization accuracy, compu-tational complexity, and convergence time. Thelatter include scalability, energy efficiency, andfault-tolerance. When taken together, these mea-sures provide a good characterization of the appli-cability and performance of each protocol.

5.1. Quantitative evaluation

We note at the outset that the protocols dif-fer broadly in their computational requirements,energy consumption, precision of synchroniza-tion results, and communication requirements. Inaddition, no protocol clearly outperforms theothers in all possible applications of wirelessnetworks. Rather, it is quite likely that the choiceof a protocol will be driven by the characteristicsand requirements of each application. For in-stance, a low-cost, low-precision protocol couldbe appropriate for many environmental monitor-ing applications. However, many safety-criticalapplications, such as aircraft navigation or intru-sion detection in military systems, will demandhigh-precision protocols in order for nodes tocorrectly identify events occurring in the net andfor an application to respond to those events.

Synchronization precision. Each network nodehas a physical clock consisting of hardware oscilla-tor circuits. Unfortunately, the frequency of hard-ware clocks varies from one node to anotherwithin a specified range. Thus, clocks on differentnodes in wireless networks operate at differentrates. Consequently, the clock values used for syn-chronization in wireless networks are not physicalclock readings. Instead, network nodes generallyuse a logical notion of clocks and time. Logicalclocks can be modified both by software (e.g., dur-ing synchronization) and hardware (e.g., by thephysical clocks). Consequently, synchronizationprecision can be defined in two ways.

1. Absolute precision. The maximum error (i.e.,skew and offset) of a node�s logical clock withrespect to an external standard such as UTC.

2. Relative precision. The maximum deviation(i.e., skew and offset) among logical clock read-ings of the nodes belonging to a wirelessnetwork.

In our discussions, we generally use the notionof relative precision (2) above, unless otherwisenoted. In general, high synchronization precisionis clearly a desirable feature of a synchronizationprotocol. However, in the protocols that we stud-ied, higher synchronization precision comes atthe expense of increased computational cost mea-sured in terms of algorithmic complexity, the num-ber of messages exchanged among nodes, and thestorage requirements of the protocol. The quanti-tative precision of the various protocols appearsin Table 5.

Piggybacking. Piggybacking is the process ofcombining the acknowledgement messages duringsynchronization with messages that carry synchro-nization data among nodes. Instead of sendingindependent acknowledgement messages, thesemessages are piggybacked on the data messagesthat have to be sent to the node, in order to reducemessage traffic in the network. Piggybacking isclearly advantageous because wireless networksare often subject to severe bandwidth constraintsand piggybacking alleviates communication de-mands on the network. In addition, piggybackingcan also reduce the storage requirements on net-work nodes because storage space is also savedby clubbing acknowledgements with data mes-sages. Romer�s protocol [56] and network-widetime synchronization [24,25] use piggybacking.

Computational complexity. As wireless net-works often have limited hardware capabilitiesand severe energy constraints, the complexity ofa synchronization protocol can make a protocolimpractical for many applications. Here we distin-guish between the computational complexity of aprotocol (i.e., its run-time and memory require-ments) from the message complexity (i.e., thenumber of messages exchanged during synchroni-zation). (See also discussion on convergence timebelow.)

Table 5Quantitative performance comparison of synchronization protocols

Protocols Factors for performance comparison

Precision Piggybacking Complexity Convergencetime

GUIservices

Networksize

Sleepmode

RBS [19] 1.85 ± 1.28 ls N/A High N/A No 2–20 Nodes YesRomer [56] 3 ms Yes Low N/A No Unknown YesMock et al. [49] 150 ls No High Low No Unknown NoGaneriwal et al. [25] 16.9 ls No Low Unknown No 150–300 Nodes YesPing [54] 32 ls Yes Low High (multi-hop) Yes Unknown NoPalChaudhuri et al. [53] Unknown Unknown High N/A No Unknown YesSichitiu et al. [58] 945 ls No Low High (multi-hop) No N/A YesTime Diffusion Protocol [62] 100 ls No High High (multi-hop) No 200 Nodes YesAsynchronous diffusion [42] Unknown No High High (multi-hop) No 200–400 Nodes Yes


In our evaluations, we consider both the asymp-totic behavior of a protocol�s computation timeand its memory requirements, relative to the num-ber of nodes being synchronized. Even though aprotocol�s computational requirements might belinear in the number of nodes synchronizing witheach other, the protocol may still be impracticalif these requirements exceed physical node re-sources. RBS [19], the protocol by Mock et al.[49], asynchronous diffusion [42], and TDP [62]have higher computational and storage complexitycompared to Romer�s protocol [56], network-widetime synchronization [25], and the protocol by Sic-hitiu and Veerarittiphan [58].

Convergence time. Convergence time is the totaltime required to synchronize a network. A proto-col that requires a large number of message ex-changes per synchronization will result in alonger convergence time. As discussed earlier,reducing message complexity is vital to the cost-efficiency of a synchronization protocol for sensornetworks. Since convergence time is directly pro-portional to message complexity and bandwidthuse, reducing the convergence time is also animportant factor in wireless networks.

RBS [19], Romer�s protocol [56], and the proto-col by PalChaudhuri et al. [53] do not emphasizelow convergence time because they are based onreactive routing. In these protocols, synchroniza-tion is performed relatively infrequently, when anevent of interest occurs in the net. Thus, conver-gence time and message complexity are of less crit-ical importance in protocols that use reactiverouting. The protocol by Mock et al. [49] requires

a low convergence time because only one messageis required per synchronization round. Other pro-tocols [54,58] can tolerate high convergence timesfor multi-hop networks.

GUI services. Graphic User Interface (GUI) ser-vices can present, in a clear and comprehensiblemanner, meaningful results achieved by the net-work to an end user. Since some wireless networksrequire on-line monitoring by human users, we in-cluded the existence of GUI services in our perfor-mance comparisons. Only Ping�s protocol [54]provides such services to the application andhigher-level kernel modules. Two services are spe-cifically defined: (1) time reading and (2) synchro-nized network event scheduling. These servicesallow a user to schedule a synchronized event overa network by providing an interface to the user�stimeframe.

Network size. Some authors have conductedempirical evaluations of synchronization protocolson actual sensor networks. Although this informa-tion is not available for most of the protocols thatwe studied, the network-wide time synchronizationprotocol of Ganeriwal et al. [25] is noteworthy inthis regard. This protocol was found to handleneighborhoods with up to 300 nodes.

Compatibility with sleep mode. The ability of anode to be in low-power (sleep) mode can be criti-cal to meeting the node�s energy requirements. Thekey idea underlying sleep mode is that nodes mustbe synchronized and active only when the applica-tion demands it. RBS [19] highlights this feature byway of post-facto synchronization. Other protocols[24,25,56] support this feature as well.


Table 5 shows the performance of the protocolsrelative to the quantitative criteria. The RBS pro-tocol [19] yields excellent accuracy results even inthe case of networks with modestly-equipped sen-sor nodes. The accuracy reached by the protocol istruly outstanding, in the order of few microsec-onds, for a network of nodes (i.e., the Berkeleymotes) with severely limited computational andenergy resources. The convergence time and mes-sage complexity of the protocol are relatively high,of the order of O(m Æ n2) messages for m synchroni-zation rounds involving n nodes within single-hopreach of each other. However, the CPU load andstorage requirements of the protocol are modest,making RBS appropriate for even the simplest oftoday�s sensor nodes. Moreover, the lack of clockadjustments sharply reduces the energy needs ofthe protocol relative to other protocols. Romer�sprotocol [56] achieves reasonably good accuracy(in the order of few milliseconds) with low compu-tational complexity. The advantages of continuoustime synchronization [49] are high accuracy resultsand low convergence time; however, these resultsare obtained at the expense of computationalcomplexity.

Network-wide Time Synchronization [24,25] isan excellent compromise among synchronizationaccuracy, computational complexity, and conver-gence time. While the accuracy results are in theorder of tens of microseconds, low computationalcomplexity and fast convergence time make thisprotocol quite attractive when higher accuracy isnot required. An additional strength of this proto-col is that the protocol has been tested on an ac-tual sensor network containing 300 nodes. TheDelay-Measurement Time Synchronization proto-col has comparable accuracy results as Network-Wide Time Synchronization [54]. However, thisresult is obtained at the expense of a longerconvergence time. Improvements to Network-Wide Time Synchronization were defined by Daiand Han [15]. Their method has yielded excellentaccuracy results with lower message complexitythan RBS.

The protocol by PalChaudhuri et al. [53] isinteresting because it uses a probabilistic algo-rithm. While probabilistic algorithms hold consid-erable promise for clock synchronization in sensor

networks, at this time it is unclear how these pro-tocols will perform in practice. Finally, a protocolby Sichitiu and Veerarittiphan [58] achieves goodaccuracy results (less than one millisecond). Thisis quite impressive considering that the protocolalso has low computational complexity. How-ever, the convergence time of this protocol is quitehigh.

The asynchronous diffusion protocol of Li andRus [42] and the time diffusion protocol of Suand Akyildiz [62] use an averaging method to ad-just node clocks. These protocols are reasonablyrobust; however, the issue of clocks running back-ward must be suitably addressed before these pro-tocols are implemented in practice.

5.2. Qualitative evaluation

We evaluate the protocols based on overallquality criteria. In contrast to Section 5.1 above,here we discuss the goals of each protocol andthe extent to which we deem that the protocol suc-ceeds in achieving those goals. While a quantita-tive study deals with parameters that help thereader fine-tune a synchronization protocol byproviding a telescopic view, a qualitative studyprovides a broader and more general perspective.Table 6 compares the various protocols in termsof the following qualitative criteria.

Energy efficiency. Energy efficiency is an impli-cit requirement in most wireless networks. The ex-tent to which this requirement must be enforcedwill vary depending on an application. For in-stance, in the case of sensor networks the require-ment is quite strict, forcing nodes to sleep asfrequently as possible and severely limiting the en-ergy available for synchronization and other net-work tasks. The main reason behind this energyconstraint is the small size of batteries in sensornodes, which greatly limits the amount of energythat can be stored and produced (e.g., with solarcells).

An important tradeoff for wireless networks isbetween using the available energy for computingor for communicating. Pottie and Kaiser [55] haveshown that, in the case of sensor networks usingradio frequency transmitters and receivers, theenergy required to transmit 1 bit over 100 m,


which is 3 joules, can be used to execute 3 millioninstructions. This finding makes it clear that com-munication is far more energy-intensive than com-putation. Elson and Romer [20] have stressed thatin low-power radio networks, listening and send-ing and receiving messages requires much more en-ergy than in a wired network. The CPU is alsosparingly available because it is shut down oftento conserve energy.

Accuracy. Accuracy is a measure of how well thetime maintained within the network is true to thestandard time. In other words, it is a measure ofthe precision of synchronization. A protocol withhigh accuracy thereby guarantees high precision.In the case of absolute precision, this means thatthe synchronized time in the network does not devi-ate much from an external standard (e.g., UTC orGPS). In the case of relative precision, this meansthat, when a set of synchronized nodes is consid-ered, the maximum deviation of the clock of anynode within the set is reasonably small.

Several protocols considered in this survey arehighly accurate. (See, e.g., [19,58].) Probabilisticsynchronization [53] allows a user to choose a de-sired level of accuracy. The option of trading offaccuracy for a lower complexity could be quiteuseful, depending on the network�s load.

Scalability. Elson and Romer [20] state that thescope of a network is the geographic span of nodesthat are synchronized and the completeness of cov-erage within that region. In general, the scope of anetwork can be expanded by increasing the numberof nodes in the network. As the sensors are becom-

Table 6Qualitative performance tabulation of synchronization protocols

Protocols Qualitative performance compar

Accuracy Energy efficiency

RBS [19] High HighRomer [56] Average HighMock et al. [49] High LowGaneriwal et al. [25] High AveragePing [54] High HighPalChaudhuri et al. [53] Unknown HighSichitiu and Veerarittiphan [58] High HighTime Diffusion Protocol [62] High AverageAsynchronous diffusion [42] Unknown Low

ing cheaper, wireless sensor networks are becomingincreasingly large, up to tens of thousands ofnodes. Thus, synchronization protocols must besufficiently scalable with respect to network size.Most protocols that handle sensor networks placescalability on top of their list of priorities.

Although most authors have not measured sca-lability in their experiments, Ganeriwal et al.[24,25] have used a network of 150–300 nodes totest scalability. In addition, Su and Akyildiz useda net with 200 nodes to test the scalability ofTDP [62]. RBS [19] typically synchronizes 3–20nodes in a neighborhood; however, this protocolworks well even in much larger networks usinggateways between neighborhoods. Protocols inwhich the synchronization error increases withthe size of the network, such as Romer�s protocol[56], achieve scalability at the expense of accuracy.

Overall complexity. The quantitative evaluationin the previous subsection distinguishes variouscomplexity measures, including CPU load, storagerequirements, and message complexity (i.e., con-vergence time). In this section, overall complexityis viewed as a combination of algorithmic complex-ity, overhead caused due to fault tolerance provi-sions, and communication overhead. Romer�sprotocol [56] is probably the best choice for a re-source-restricted environment because of its lowcomplexity. However, this method is not highlyaccurate. This is not surprising as highly accurateprotocols usually incur high overall complexity.

Fault tolerance. Fault tolerance plays an impor-tant role because a wireless medium is rather

ison

Overall complexity Scalability Fault tolerance

High Good NoLow Poor NoLow N/A YesLow Good YesLow Good NoLow Good NoLow N/A YesHigh Good YesHigh N/A Yes


error-prone. The poor reliability of message deliv-ery in a wireless medium can have devastating ef-fects on synchronization protocols becausesynchronization requires message exchanges.

Some fault-tolerant protocols [24,49,58] addressmessage loss to some extent, but others have not ad-dressed this issue. Consequently, it is unclear howsensitive their protocols are to message loss. Thisis somewhat troublesome because handling mes-sage loss can result in significant overheads and per-formance degradation during synchronization.

6. Conclusions

With increasing frequency, attention has beenfocused on wireless sensor networks because oftheir wide applicability to a diverse range of appli-cation areas. Among the many difficulties indesigning and building such networks, a centralchallenge is providing clock synchronizationamong the sensor nodes. Providing a commontime axis is necessary for a large number of sensorapplications because the data they report has to bemeaningfully fused to draw coherent inferencesabout the environment being sensed.

Traditional clock synchronization protocols forwired networks cannot be used because wirelesssensor-network protocols require the ability toadapt dynamically, the ability to handle sensormobility, and scalability. The sensors themselvesare heavily resource-constrained because of limitedbattery power. Furthermore, they need to operatein highly lossy and unreliable environments. As aresult, several clock synchronization protocolsfor wireless sensor networks have been designedin the recent past.

This paper presented a survey and analysis ofexisting clock synchronization protocols for wire-less sensor networks, based on a variety of factorsincluding precision, accuracy, cost, and complex-ity. The design considerations presented here willhelp the designer in building a successful clocksynchronization scheme, best tailored to his appli-cation. Specifically, the detailed analysis of thevarious options and possible solutions for eachof the factors involved will guide the designer in

integrating various solution features to create asuccessful clock synchronization scheme for theapplication. Finally, the survey will be a helpfulbenchmark for designers to compare and contrasttheir results with the protocols that are widely inuse.

References

[1] I.F. Akyildiz, O. Akan, C. Chen, J. Fang, W. Su,InterPlaNetary Internet: state-of-the-art and research chal-lenges, Computer Networks 43 (2) (2003) 75–112.

[2] I.F. Akyildiz, W. Su, Y. Sankarasubramanian, E. Cayirci,A survey on sensor networks, IEEE CommunicationsMagazine 40 (8) (2002) 102–114.

[3] I. Akyildiz, W. Su, Y. Sankarasubramanian, E. Cayirci,Wireless sensor networks: a survey, Computer Networks38 (4) (2002) 393–422.

[4] K. Arvind, Probabilistic clock synchronization in distrib-uted systems, IEEE Transactions on Parallel and Distrib-uted Systems 5 (5) (1994) 474–487.

[5] S. Burleigh, V. Cerf, R. Durst, K. Fall, A. Hooke, K. Scott,H. Weiss, The InterPlaNetary Internet: a communicationsinfrastructure for Mars exploration, in: 53rd InternationalAstronautical Congress, The World Space Congress,October 2002.

[6] CENS: Center for Embedded Networked Sensing. Avail-able at <http://www.cens.ucla.edu/index.html>.

[7] CENS: Monitoring of marine microorganisms. Avail-able at <http://www.cens.ucla.edu/Research/Applications/momm.htm>.

[8] CENS: Seismic monitoring and structural response. Avail-able at <http://www.cens.ucla.edu/Research/Applications/seismicmonitor.htm>.

[9] Chart on the Web. Maryland Department of Transporta-tion. Available at <http://www.chart.state.md.us/>.

[10] J.-C. Chen, K.M. Sivalingam, P. Agrawal, S. Kishore, Acomparison of MAC protocols for wireless local networksbased on battery power consumption, in: IEEE Info-com�98, San Francisco, USA, March 1998, pp. 150–157.

[11] F. Cristian, Probabilistic clock synchronization, Distrib-uted Computing 3 (1989) 148–153.

[12] F. Cristian, C. Fetzer, The timed asynchronous distributedsystem model, IEEE Transactions on Parallel and Distrib-uted Systems 10 (6) (1999) 642–657.

[13] D. Culler, W. Hong (Eds.), Introduction, Communicationsof the ACM 47 (6) (2004) 30–34.

[14] D. Culler, M. Srivastava, D. Estrin (Eds.), Guest Editors�Introduction: Overview of Sensor Networks, IEEE Com-puter 37 (8) (2004) 41–49.

[15] H. Dai, R. Han, TSync: a lightweight bidirectional timesynchronization service for wireless sensor networks, ACMSIGMOBILE Mobile Computing and CommunicationsReview 8 (1) (2004) 125–139.

http://www.cens.ucla.edu/index.html

http://www.cens.ucla.edu/Research/Applications/momm.htm

http://www.cens.ucla.edu/Research/Applications/momm.htm

http://www.cens.ucla.edu/Research/Applications/seismicmonitor.htm

http://www.cens.ucla.edu/Research/Applications/seismicmonitor.htm

http://www.chart.state.md.us/


[16] Distributed Surveillance Sensor Network. ONR SPAWARSystems Center, San Diego. Available from <http://www.spawar.navy.mil/robots/undersea/dssn/dssn.html>.

[17] A. Dobra, M. Garofalakis, J. Gehrke, R. Rastogi,Processing complex aggregate queries over data streams,in: Proceedings of SIGMOD International Conference onData Management, 2002, pp. 61–72.

[18] D. Dolev, J.Y. Halpern, B. Simons, R. Strong, Dynamicfault-tolerant clock synchronization, Journal of the ACM42 (1) (1985) 143–185.

[19] J. Elson, L. Girod, D. Estrin, Fine-grained network timesynchronization using reference broadcasts, in: Proceed-ings of Fifth Symposium on Operating Systems Design andImplementation (OSDI 2002), vol. 36, 2002, pp. 147–163.

[20] J. Elson, K. Romer, Wireless sensor networks: a newregime for time synchronization, in: Proceedings of FirstWorkshop on Hot Topics In Networks (HotNets-I),Princeton, New Jersey, October 2002.

[21] R.C. Shah, J. Rabaey, Energy aware routing for lowenergy ad-hoc sensor networks, IEEE Wireless Communi-cation and Networking Conference (WCNC), March 2002,pp. 350–355.

[22] D. Estrin, D. Culler, K. Pister, G. Sukhatme, Connectingthe physical world with pervasive networks, IEEE Perva-sive Computing 1 (1) (2002) 59–69.

[23] D. Estrin, R. Govindan, J. Heidemann, S. Kumar, Nextcentury challenges: scalable coordination in sensor net-works, in: Proceedings of Fifth Annual InternationalConference on Mobile Computing and Networks (Mobi-COM �99), August 1999, pp. 263–270.

[24] S. Ganeriwal, R. Kumar, S. Adlakha, M. Srivastava,Network-wide time synchronization in sensor networks,Technical Report, Networked and Embedded SystemsLab, Electronic Engineering Department, UCLA,2003.

[25] S. Ganeriwal, R. Kumar, M. Srivastava, Timing-Syncprotocol for sensor networks, in: Proceedings of FirstInternational Conference on Embedded Networked SensorSystems, Los Angeles, California, November 2003.

[26] L. Girod, V. Bychkovskiy, J. Elson, D. Estrin, Locatingtiny sensors in time and space: a case study, in: Proceedingsof International Conference on Computer Design (ICCD2002), September 2002.

[27] D.J. Goodman, R.A. Valenzuela, K.T. Gayliard, B.Ramamurthi, Packet reservation multiple access for localwireless communications, IEEE Transactions on Commu-nications 37 (1989) 885–890.

[28] R. Gusella, S. Zatti, TEMPO—A network time controllerfor a distributed Berkeley UNIX system, IEEE DistributedProcessing Technical Committee Newsletter 6 (S12-2)(1984) 7–14.

[29] J. Hill, M. Horton, R. Kling, L. Krishnamurthy, Theplatforms enabling wireless, sensor networks, Communi-cations of the ACM 47 (6) (2004) 41–46.

[30] A.-S. Hu, S.D. Servetto, Asymptotically optimal timesynchronization in dense sensor networks, in: Proceedingsof 2nd ACM International Workshop on Wireless Sensor

Networks and Applications (WSNA �03), San Diego,California, September 2003, pp. 1–10.

[31] IEEE, Wireless LAN Medium Access Control (MAC) andPhysical Layer (PHY) Specifications. IEEE Std. 802.11,November 1997.

[32] The Intel Mote. Intel Corporation. Available at <http://www.intel.com/research/exploratory/motes.htm>.

[33] P. Johnson, et al., Remote continuous physiological mon-itoring in the home, Journal of Telemedicine Telecare 2 (2)(1996) 107–113.

[34] C.E. Jones, K.M. Sivalingam, P. Agrawal, J. Cheng, Asurvey of energy efficient protocols for wireless networks,Wireless Networks 7 (4) (2001) 343–358.

[35] J.M. Kahn, R.H. Katz, K.S.J. Pister, Next centurychallenges: mobile networking for Smart Dust, in: Pro-ceedings of Fifth Annual ACM/IEEE International Con-ference on Mobile Computing and Networking, 1999, pp.271–278.

[36] M.J. Karol, Z. Liu, K.Y. Eng, An efficient demand-assignment multiple access protocol for wireless packet(ATM) networks, ACM/Baltzer Wireless Networks 1 (3)(1995) 267–279.

[37] A.D. Kshemkalyani, The power of logical clock abstrac-tions, Distributed Computing 17 (2) (2004) 131–150.

[38] L. Lamport, Time, clocks, and the ordering of events in adistributed system, Communications of the ACM 21 (7)(1978) 558–565.

[39] L. Lemmerman, et al. Earth science vision: platformtechnology challenges. in: Proceedings of InternationalGeoscience and Remote Sensing Symposium (IGARSS2001), Sydney, Australia, 2001.

[40] M.D. Lemmon, J. Ganguly, L. Xia, Model-based clocksynchronization in networks with drifting clocks, in:Proceedings of 2000 Pacific Rim International Symposiumon Dependable Computing, December 2000.

[41] Q. Li, M. DeRosa, D. Rus, Distributed algorithms forguiding navigation across a sensor network. in: Proceed-ings of Ninth Annual International Conference on MobileComputing and Networking, September 2003, pp. 313–326.

[42] Q. Li, D. Rus, Global clock synchronization in sensornetworks, in: Proceedings of IEEE Conference on Com-puter Communications (INFOCOM 2004), vol. 1, HongKong, China, March 2004, pp. 564–574.

[43] B. Liskov, Practical uses of synchronized clocks in distrib-uted systems, in: Proceedings of Tenth Annual ACMSymposium on Principles of Distributed Computing,August 1991, pp. 1–9.

[44] S. Madden, R. Szewczyk, M. Franklin, D. Culler, Sup-porting aggregate queries over ad-hoc wireless sensornetworks, in: Proceedings of Workshop on Mobile Com-puting Systems and Applications, 2002.

[45] L. Meier, P. Blum, L. Thiele, Internal synchronization ofdrift-constrained clocks in ad-hoc sensor networks, in:Proceedings of 5th ACM International Symposium onMobile Ad Hoc Networking and Computing (MobiHoc�04), Roppongi Hills, Japan, May 2004, pp. 90–97.

http://www.spawar.navy.mil/robots/undersea/dssn/dssn.html

http://www.spawar.navy.mil/robots/undersea/dssn/dssn.html

http://www.intel.com/research/exploratory/motes.htm

http://www.intel.com/research/exploratory/motes.htm


[46] D.L. Mills, Network time protocol (version 3): specifica-tion, implementation, and analysis, Technical Report,Network Information Center, SRI International, MenloPark, CA, March 1992.

[47] D.L. Mills, Modelling and analysis of computer networkclocks, Technical Report, 92-5-2, Electrical EngineeringDepartment, University of Delaware, May 1992.

[48] D.L. Mills, Internet time synchronization: the networktime protocol, IEEE Transactions of Communications 39(10) (1991) 1482–1493.

[49] M. Mock, R. Frings, E. Nett, S. Trikaliotis, Continuousclock synchronization in wireless real-time applications, in:Proceedings of 19th IEEE Symposium on Reliable Dis-tributed Systems (SRDS-00), October 2000, pp. 125–133.

[50] S.B. Moon, P. Skelly, D. Towsley, Estimation and removalof clock skew from network delay measurements, Proceed-ings of IEEE INFOCOM, vol. 1, 1999, pp. 227–234.

[51] A. Olson, K. Shin, Fault-tolerant clock synchronization inlarge multicomputer systems, IEEE Transactions on Par-allel and Distributed Computing 5 (9) (1994) 912–923.

[52] D. Raychaudhuri, N.D. Wilson, ATM-based transportarchitecture for multi-services wireless personal communi-cation networks, IEEE Journal on Selected Areas inCommunications 12 (1994) 1401–1414.

[53] S. PalChaudhuri, A. Saha, D.B. Johnson, Probabilisticclock synchronization service in sensor networks, Techni-cal Report TR 03-418, Department of Computer Science,Rice University, 2003.

[54] S. Ping, Delay measurement time synchronization forwireless sensor networks, Intel Research, IRB-TR-03-013,June 2003.

[55] G. Pottie, W. Kaiser, Wireless integrated network sensors,Communications of the ACM 43 (5) (2000) 51–58.

[56] K. Romer, Time synchronization in ad hoc networks, in:Proceedings of ACM Symposium on Mobile Ad HocNetworking and Computing (MobiHoc �01), October 2001,pp. 173–182.

[57] M. Ryu, S. Hong, Revisiting clock synchronization prob-lems: static and dynamic constraint transformations forcorrect timing enforcement, Technical Report No. SNU-EE-TR-1998-3, Seoul National University, South Korea,September 1998.

[58] M.L. Sichitiu, C. Veerarittiphan, Simple, accurate timesynchronization for wireless sensor networks, in: Proceed-ings of IEEE Wireless Communications and NetworkingConference (WCNC 2003), 2003, pp. 1266–1273.

[59] S. Singh, C.S. Raghavendra, PAMAS: power aware multi-access protocol with signaling for ad hoc networks,Distributed Computing 6 (1993) 211–219.

[60] The sensor web project, NASA Jet Propulsion Laboratory,Available from <http://sensorwebs.jpl.nasa.gov>.

[61] SmartDust, Autonomous sensing and communication in acubic millimeter, Available at <http://robotics.eecs.berke-ley.edu/~pister/SmartDust/>.

[62] W. Su, I. Akyildiz, Time-diffusion synchronization proto-cols for sensor networks, IEEE/ACM Transactions onNetworking, in press.

[63] R. Szewczyk, E. Osterweil, J. Polastre, M. Hamilton, A.Mainwaring, D. Estrin, Habitat monitoring with sensornetworks, Communications of the ACM 47 (6) (2004) 34–40.

[64] S. Tilak, N.B. Abu-Ghazaleh, W. Heinzelman, Taxonomyof wireless micro-sensor network models, ACM MobileComputing and Communications Review 6 (2) (2002) 28–36.

[65] TinyOS. An operating system for networked sensors,Available at <http://www.tinyos.net>.

[66] M. Tubaishat, S. Madria, Sensor networks: an overview,IEEE Potentials 22 (2) (2003) 20–23.

[67] D. Tulone, Resource-efficient time estimation for wirelesssensor networks, in: S. Basagni, C.A. Phillips (Eds.),Proceedings of DIALM-POMC Workshop on Founda-tions of Mobile Computing, October 2004, pp. 52–59,Philadelphia, Pennsylvania. Available at <http://www.informatik.uni-trier.de//~ley/db/conf/dialm/dialm2004.html>.

[68] J. van Greunen, J. Rabaey, Lightweight time synchroniza-tion for sensor networks, in: Proc. 2nd ACM Int. Work-shop on Wireless Sensor Networks and Applications(WSNA �03), San Diego, California, September 2003, pp.11–19.

[69] R. Want, A. Hopper, V. Falcao, J. Gibbons, The activebadge location system, ACM Transactions on InformationSystems 10 (1) (1992) 91–102.

[70] J. Werb, C. Lanzl, Designing a positioning system forfinding things and people indoors, IEEE Spectrum 35 (9)(1998) 71–78.

[71] A. Woo, S. Madden, R. Govindan, Networking supportfor query processing in sensor networks, Communicationsof the ACM 47 (6) (2004) 47–52.

[72] Available at <http://deepspace.jpl.nasa.gov/dsn>.[73] Available at <http://marsnet.jpl.nasa.gov>.[74] Y. Yao, J. Gehrke, Query processing in sensor networks,

in: Proceedings of the First Biennial Conference onInnovative Data Systems Research, Asilomar, California,January 2003.

[75] W. Ye, J. Heidemann, D. Estrin, An energy-efficient MACprotocol for wireless sensor networks, in: Proceedings ofthe 21st International Annual Joint Conference of theIEEE Computer and Communications Societies (INFO-COM 2002), June, 2002, pp. 1567–1576.

[76] X.Yu, K. Niyogi, S. Mehrotra, N. Venkatasubramanian,Adaptive middleware for distributed sensor environments.IEEE Distributed Systems Online, May 2003.

[77] W. Yuan, S. Krishnamurthy, S. Tripathi, Synchronizationof multiple levels of data fusion in wireless sensornetworks, in: Proceedings of IEEE GlobalTelecommunications Conference (Globecom), pp. 221–225, 2003.

[78] J. Zhao, R. Govindan, D. Estrin, Computing aggregatesfor monitoring wireless sensor networks, in:Proceedings of IEEE Workshop on Sensor NetworkProtocols and Applications (SANPA), May 2003, pp.139–148.

http://sensorwebs.jpl.nasa.gov

http://robotics.eecs.berkeley.edu/~pister/SmartDust/

http://robotics.eecs.berkeley.edu/~pister/SmartDust/

http://www.tinyos.net

http://www.informatik.uni-trier.de//~ley/db/conf/dialm/dialm2004.html



http://deepspace.jpl.nasa.gov/dsn

http://marsnet.jpl.nasa.gov

Hoc Networks 3 (2005) 281–323 323

Bharath Sundararaman was born andraised in Chennai, India and currentlylives in Palatine, Illinois. Bharathreceived a Bachelor of Engineeringdegree in Computer Science fromMadras University, India in 2000 and aMaster of Sciences degree in ComputerScience from the University of Illinoisat Chicago in 2003. He currently worksas a Senior Software Engineer forStarthis Inc., a provider of automationmiddleware solutions in ArlingtonHeights, Illinois.

B. Sundararaman et al. / Ad

Ugo Buy is an Associate Professor inthe Department of Computer Scienceof the University of Illinois at Chicago.He obtained his MS and PhD degreesin Computer Science from the Univer-sity of Massachusetts at Amherst in1983 and 1990, respectively. From 1983to 1986 he was a Senior SoftwareEngineer with the Digital EquipmentCorporation in Hudson, Massachu-setts. He has been on the UIC facultysince 1990.His research interests are in the area

of software engineering. In the past, he has been involved in
several NSF-sponsored projects whose common goal was the
definition of techniques and tools for the static analysis ofconcurrent and real-time software. Using a variety of programrepresentations (e.g., finite-state automata and Petri nets), heinvestigated several techniques for promoting the reliability ofconcurrent and real-time software.He is currently investigating techniques for the automatic

synthesis of supervisory controllers for discrete manufacturingsystems. The controllers must enforce traditional safety andtiming properties of manufacturing plants. An additionalresearch interest is the exploration of new computing applica-tions based on wireless sensor networks.

Ajay Kshemkalyani is an AssociateProfessor of Computer Science at theUniversity of Illinois at Chicago since2000. He previously spent several yearsat IBM Research Triangle Park work-ing on various aspects of computernetworks. Ajay Kshemkalyani receiveda Ph.D. and an M.S. in Computer andInformation Science from The OhioState University in 1991 and 1988,respectively, and a B.Tech. in Com-puter Science and Engineering fromthe Indian Institute of Technology,Bombay, in 1987. His current research

interests include computer networks, distributed computing,algorithms, and concurrent systems. He is a recipient of theNational Science Foundation�s CAREER Award. He is amember of the ACM and a senior member of the IEEE.

clock synchronization for wireless sensor networks: a surveypeters/...survey-adhocnets-2005.pdf ·...

Documents