Towards Precise Synchronisation in Wireless Sensor Networks by issuukorea

2010 IEEE/IFIP International Conference on Embedded and Ubiquitous Computing

Towards Precise Synchronisation in Wireless Sensor Networks

Lawrence Cheng, Stephen Hailes

Alan Wilson

Computer Science, University College London, Malet Place, London, UK, WC1E 6BT {l.cheng, s.hailes}@cs.ucl.ac.uk

Structure and Motion Lab, Royal Veterinary College, Hawkshead Lane, Herts., UK, AL9 7TA awilson@rvc.ac.uk

number of solutions to address the delays caused by these assumptions. It should be noted that it is not within the scope of this paper to design a new protocol for WSN synchronisation; the paper’s contribution lies within the explanation of the drawbacks of the common assumptions made in existing WSN synchronisation protocols on enabling precise synchronisation, the suggestions of suitable protocols and technologies – that have not been considered in existing research work - to enable precise synchronisation in WSN, and the analysis on the reasons behind why and how these protocols and technologies are applicable. This paper is organised as follow: firstly, related work and the problem space will be described; secondly, a set of solutions to improve accuracy will be discussed, followed by a set of solutions for addressing reliability, robustness, efficiency issues. Then, the implementation issues are addressed, followed by an evaluation of the key concepts. The paper ends with a conclusion and future work.

Abstract—Many existing Wireless Sensor Network (WSN) synchronisation protocols have demonstrated microsecond-level accuracy is achievable. Furthermore, sub-microsecond-level accuracy has recently been reported; although rather sophisticated, relatively bulky and custom-designed hardware were needed. This paper addresses a fundamental problem in WSN synchronisation: is there a more elegant way to achieve precise synchronisation in WSN? What are the obstacles to pushing the limit in WSN synchronisation? This paper identified the drawbacks caused by the assumptions made in existing WSN synchronisation protocols, and presented and discussed a range of novel solutions to improve the accuracy, reliability and scalability of WSN synchronisation through fusing various types of information and a sensible selection of hardware. Keywords—accuracy; reliability; scalability; synchronisation; wireless sensor networks.

I. INTRODUCTION Accuracy is the most fundamental requirement in Wireless Sensor Network (WSN) synchronisation. One question is: how accurate should clocks 1 run in a WSN? The answer is application dependent: in [3], 21µs was suggested as a suitable benchmark in WSNs, using audio codecs rate at 48kHz as a reference. In the SEnsing for Sports and Managed Exercise (SESAME) project [1], it was described that wireless on-body sensors and track-side sensors (for performance monitoring of elite athletes) sample data from 300Hz to 1MHz [8][11][18]. Thus, microsecond-level accuracy would be sufficient for these systems. However, as identified in [13], microsecond-level accuracy is insufficiently accurate for precise WSN operations, such as single-sided Time-of-Arrival (ToA) radio-based localisation, or more sophisticated control-based applications [13]. Existing WSN synchronisation protocols commonly focus on software issues, and assume tight reception of (sync) messages [3][7] and negligible propagation time of messages [13]. Although in [13], it was suggested that - if combined with an appropriate choice and custom-designed hardware - it is possible to achieve more precise synchronisation (i.e. submicrosecond level accuracy) in WSN; yet, rather sophisticated, relatively bulky, and custom-designed hardware must be used [13]. Clearly, more elegant synchronisation solutions that achieve precise accuracy would benefit the wider WSN community. This paper addresses WSN synchronisation from a different angle: the authors investigate whether it is possible to achieve sub-microsecond-level synchronisation in WSNs in a practical way? In other words – what are the bottlenecks that preventing one from improving accuracy, reliability and robustness of WSN synchronisation? This paper reviews the assumptions in existing WSN synchronisation protocols, and presents a

II. BACKGROUND A. Related Work In [5], a comprehensive survey on existing wireless synchronisation protocols for WSNs was reported. In this section, a summary on the more well-known protocols is provided. A round-trip-based protocol was reported in [6] which requires the sender to estimate a set of upper and lower bound timestamp lifetime values of itself from the moment when a sync message is generated to the arrival of the message at the receiver (a.k.a. the elapsed time). The receiver timestamps the received message using its local clock, and subtracts the timestamp with the locally transformed elapsed time (from the sender) to determine offset. The accuracy of the protocol therefore relies on how accurate the estimation on local clock drifts and delays. The work reported in [7] was designed to adjust local clocks continuously: the sender first sends out a sync message which is timestamped by both itself and the receivers; the sender then sends out a 2nd sync message to the receivers which contains its local timestamp of the 1st sync message. Upon receiving the 2nd message, the receivers adjust their clock respectively by using their local timestamps and the sender’s local timestamp of the 1st sync message. The system is capable of delivering accurate results if message transmission is tight. The Reference Broadcast Synchronisation (RBS) protocol [3] was arguably the most well-known wireless synchronisation protocol in the WSN community. The protocol assumes the receiving nodes will receive the same broadcast sync message from the reference node at approximately the same time. The offset between the receiving times is calculated, so a uniform time domain is achieved among the receiving nodes. Tight communication is assumed. The protocol also assumes linear clock drift, and averages the

There are different types of “clock”, such as crystal clocks, atomic clocks, etc. The term “clock” in this paper refers to electrical oscillators, such as crystal clocks. These clocks are cheap and are commonly found in WSNs.

208

neglected delay caused by air transmission is significantly beyond the 200ns accuracy quoted in [13]. Even if node S and node Rfar were only 10m apart (i.e. an assumption based on the size of a typical office), the neglected delay would be 33.357ns, which is 16.68% of the quoted accuracy in [13]. Although the propagation time is removed from the critical path in [3], but the error introduced by the propagation time is the difference between the reception times at the receiving nodes, which is distance dependent (Figure 1). The same problem applies to [7] as well because it also assumes the master node and all of its salves nodes will be receiving the same sync message (during the first round of the protocol) at the same time. Clearly, for sub-microsecond-level synchronisation, tight communications and negligible propagation times should not be assumed.

offsets over a (short) period of time to address random message processing times2 (PR) and message loss. Perhaps the most related work to the work presented in this paper is [13]; in which a hardware-assisted timestamping mechanism was introduced on sensor nodes and a gateway node for tight communications, and a protocol that maps the IEEE 1588 Precision Time Protocol (PTP) for precise synchronisation in WSN use were presented. The solution – which achieves a accuracy within 200ns - is much more accurate than the protocols presented earlier in the section. However, the system was designed for synchronising WSN nodes with an external IEEE 1588-enabled Ethernet, thus, it requires an accurate master clock to drive the synchronisation process, and a dedicated PTP gateway node to sit between the external IEEE 1588-enabled Ethernet and the WSN for relaying sync messages. Also, linear drift was assumed by using a temperature compensated crystal. The resulting hardware devices are relatively large. These requirements, in general, cannot be assumed in WSN because nodes could be operating in outdoor, or in a remote environment, or in an indoor environment or on-body where spaces for sensor placement and attachment are strictly limited; but none-theless, the work shows that sub-microsecond level of synchronisation is achievable in WSN.

III. CONSIDERATION FACTORS FOR ACCURACY In this section, the solution requirements and assumptions will be identified. Then, a range of suggestions on how to enable precise synchronisation – and their effects and drawbacks - will be discussed. A. Solution Requirements and Assumptions The ideal solution should achieve synchronisation as precise as possible and practical to implement. At this stage of the investigation, 1-hop transmission is assumed and energy consumption is not discussed, but provisioning will be discussed in section IV to minimise the number of wireless transmissions (which consumes significantly more power than local computation). Security issues and WSN topology construction are out-of-scope of this paper: a network topology is assumed to have already existed, that nodes know which node would be the sink; the sink would be the clock reference node and also the node that collects data from all other nodes. Clock drifts are assumed to be random, and nodes are not necessary static but could be mobile. However, clock drift within the reference node is not an issue because for information fusion, the requirement is to establish a unified time domain so that all receivers would be timestamping its data samples using their local clock that could be referenced to the clock of the reference node (i.e. the sink). This argument, however, does not prevent system developers to implement a sink with an accurate clock, either using precise external time reference (such as GPS), or using an Oven-controlled Crystal Oscillator (OCXO). The decision, however, is case specific.

B. Problem Spaces Rfar

S (a.k.a. master)

Rclose

TS0

(a) Timestamp (TSfar) time

(1 ast adc Bro

00m

)

Broadcast (0m ) Timestamp (TSs)

Timestamp (TSclose) error = |TSclose – TSfar|

Figure 1 – The effect of propagation time in RBS and continuous clock synchronisation even with tight communication assumed

As explained in section I, the common assumptions in existing WSN synchronisation protocols are: tight communication and negligible propagation time of the sync message. In reality, communication is not always tight. Such scale of variation in communication times must be addressed for sub-microsecond-level precise synchronisation. Another issue is the (variable) delay between the timestamping of a received time sync message, and the actual moment of timestamping data samples or local clock correction using the received timestamp. But in order to understand the problem space more clearly, assume perfectly tight communication is achieved (i.e. zero difference between interception and timestamping, or 100% predictable processing times). Consider a scenario with three sensor nodes (i.e. node S, Rclose, Rfar): node S acts as the sink3 and broadcasts a sync message to Rclose and Rfar. Node S and Rclose are physically next to each other but node Rfar is 100m away4 (Figure 1). At the speed of light, the propagation time for 100m is 333.57ns. This

B. Fusing Localisation Data with Synchronisation Data Rfar

S (a.k.a. master)

Rclose

TS0

(b)

Pfar

Timestamp (TSfar)

(1 ast adc Bro

time Star time = TS0 = |TSfar-Pfar|

This is defined in this paper either as the moment when the sync signal is generated to the moment it is sent at the sender, or from the moment when the message arrives at the receiving node until it is timestamped. 3 The sink commonly refers to the node that collects data from other nodes, and performs some form of information fusion on the collected data. 4 Sensor nodes could be located in an outdoor environment (such as an outdoor field), or in a large, open indoor environment (such as a warehouse or a sports stadium), equipped with directional antenna for extended range coverage [1][8], etc. Thus, 100m of coverage is a realistic scenario. This does not mean, however, all receivers are 100m away from the sink.

) 00m

Broadcast (0m

Timestamp (TSs)

Start time = TS0

)

Pclose Timestamp (TSclose)

Start time = TS0 = |TSclose – Pclose|

Figure 2 – Utilising propagation times for precise synchronisation

It was identified in section II.B that in order to enable precise synchronisation, tight communication must be enabled and propagation times must be known to the nodes. Tight communications is addressed in the next section (section III.C). But tight communications do not mean one could work out the propagation time of a radio message between two nodes. ToA-type localisation system – which measures the propagation time of a message sent from a transmitter to a receiver (and translates the time into distance, since radio

209

here but readers are referred to [20][21] for more technical details. Essentially, sinc-pulses have the shortest possible duration, which makes them very easy to detect using simple amplitude discriminator. However, they are very sensitive to disturbances and multi-path fading and are therefore not ideal for wireless transmission [20]. The approach adopted in [2][21] converts a sinc-pulse at a transmitter into a more robust chirp pulse using a Dispersive Delay Line (DLL), such as a SAW6 filter. The same conversion is reversed at the receiver. It is the filter that performs a cross-correlation of the received chirp signal and the original (sinc) signal (Figure 3). Thus, robust transmission and sharp signal detection at receiver are achieved.

travels at the speed of light) – would provide a vital piece of information to enable precise synchronisation. Figure 2 shows that if communication is perfectly tight (or 100% determinable) and propagation times are known, the error in synchronisation is minimised. Note that if the nodes were static (or the nodes’ positions are known and fixed), and if tight communication is achieved, one may argue that the propagation time P between two nodes is directly determinable. However, this is not the case when the nodes are mobile, or when the nodes’ locations are unknown, or when the scale of deployment is large that manual distance measurement between the reference nodes to all other nodes is not possible. Furthermore, physical distance does not necessary equate to propagation time because propagation time may be increased by other factors such as multi-path reflection, object obstruction, etc. Thus, real-time measurement of propagation time should be fused with synchronisation data to achieve precise synchronisation.

D. The use of Asynchronous ToA Real-time Localisation Protocol S (sink) M1.1

C. The Effect of Tight Communications It is apparent that tight communications is one of the keys to precise synchronisation in WSNs. It should be noted that, in contrast to most common understanding, there are in fact two requirements to enable tight communications: a) precise timestamping of an incoming or outgoing (sync) message, this commonly refers to the capability to timestamp on the PHY or MAC layer; and b) the capability for the transceiver to detect the leading edge of the cross-correlation function to determine the precise moment of radio signal reception. Requirement a) is commonly known in the research community, for example, in [13], an enhanced Time processor Unit (eTPU) was used to trigger hardware events for enabling precise timestamping at sensor nodes; requirement b) – however - has not been covered in most WSN synchronisation work. Transmitter

(SYNC )

Propagation time (P)

Round-TripTime (RTTS)

Reply time (RR) K) /W AC M1.2 (H

Propagation time (P)

) (SYNC M2.1

Propagation time (P)

Round-Trip- Time (RTTR)

Reply time (RS) M2.2 (H /W AC K)

Propagation time (P)

M3.1 (R

TTSR, R

R calculates P

Receiver

DDL

R (receiver)

RTCS

M3.2 (R

DDL

TCS )

Propagation time (P) RTCR = RTCS + P

time Drift S (DS)

Drift R (DR)

Figure 4 – The system protocol Original signal (sinc)

Signal in transit (chirp)

Reconstructed signal (sinc)

To fuse localisation data with synchronisation data to enable precise synchronisation, one may argue that ToA-type localisation would require precisely synchronised nodes, which creates a chicken-and-egg problem. An alternative approach would be the asynchronous ToA-type localisation technique. A round-trip-based protocol (i.e. top part of Figure 4) is probably the simplest protocol for calculating propagation times [19]. A drawback is that the protocol is very sensitive to clock drift. Equation (3.1) shows how the propagation time (P) would be calculated if there were no drift; whereas equation (3.2) shows how PD would be calculated when there were drifts (i.e. DS and DR). It should also be noted that propagation time changes when the sensors are in motion; but at the speed of light, the variation in propagation times during a typical round trip is negligible: assuming a sensor is on a high speed moving train that runs at 300km/hr, over 10ms (which is a very long time for processing times [14]), the distance traveled would be ~0.833m; at the speed of light, the propagation time difference between the sensor and a (say) track-side sensor is negligible (i.e. 2.78ns). Thus, propagation times are assumed to be identical during a round trip. Note that reply time includes the times it takes to timestamp messages and creating a reply message. To understand the effect of drift, let the actual propagation time P = 30ns, and

Figure 3 – Conversion between sinc-pulse and chirp pulse

To understand requirement b), it is important to understand the characteristics of radio. Recent radio technology advancements have enabled one to improve the time resolution of detecting the moment of a signal reception by narrowing correlation peak using wider signal bandwidth. This is in fact why UltraWideBand (UWB) technology - commonly with 500MHz of bandwidth radio - has gained significant popularity in precise ToA-based localisation systems [24][25]. At the time of writing, however, UWB devices are expensive; furthermore, the UWB frequency band is yet to be licensed worldwide. An alternative to UWB-based solution is the Chirp Spread Spectrum (CSS) technology, which uses only 80MHz of bandwidth and operates in the 2.45GHz licensed radio band [2]. It was reported that a tight communication within 250ns with averaging over correlation measurements while receiving a packet could be achieved [17]. Such tight communication is critical to ToA-based radio localisation systems – as well as to precise synchronisation system. Although it is not within the scope of this paper to discuss radio technologies in details; but in order to allow the readers to understand why CSS is favourable, a summary is provided

210

assume linear drift (e.g. DS = +40ppm, DR = -40ppm5), and RR = 1ms; P would be ~70ns. The effect of drift on propagation time estimation is significant6. (3.1) P ( RTTS R R ) y 2 P D

( RTT (1 D ) R (1 D )) y 2 S S R R

determinable and the reply times at S and R are identical. In this case, clock drift becomes an important issue. In many existing protocols, randomness in clock drifts is not completely addressed: they assume the variations are either linear [3][13], or determinable [7], or estimatable [6]. In reality, clock drifts are affected by many environmental factors such as temperature and are likely to be variable. It is also difficult to achieve identical reply times. There are existing approaches to address randomness in processing times and drifts, for example additional hardware could be added: adding a temperature sensor to monitor the current temperature of the clock for calibration [12]; or to use an OCXO to maintain a constant temperature of the crystal [13], or add an additional clock in close proximity for software calibration [4]. Adding temperature control or monitoring hardware is power consuming and cost ineffective7 [16]. It is therefore important to understand the effect of variable clock drift and reply times on propagation time estimation of the presented protocol. The authors argue that under the presented solution, the effect of both would be minimised to an acceptable level. To understand how, equation (3.7) is rearranged to give equation (3.8):

(3.2)

To combat drift, consider a double-sided sync protocol (Figure 4) [10][14], which essentially involves two round trips initiated from both sides sequentially: equation (3.3) to (3.4) show how the propagation time P is determined. Note that the values of RTTS, RR, RTTS and RR are directly measured at S and R respectively. Equation (3.5) shows the relationship between RTT, P, and R. (3.3) RTT 2P R S R P

P S

RTTS RTTR P

(3.4)

P R 4P RS RR

( RTT R RTT R ) y 4 S S R R

(3.5) (3.6)

Taking into account the drifts, equation (3.6) would give equation (3.7): PD (( RTTS R S )(1 D S ) ( RTTR R R )(1 D R )) y 4 (3.7)

( RTT R RTT R ) S S R R

(( RTT R ) D ( RTT R ) D ) S S S R R R

(3.8)

Comparing to equation (3.6), the second half on the right hand side of equation (3.8) represents the error between P and PD (i.e. the propagation time including the effects of clock drift). If R increases, RTT will increase, the difference between the two will also increase. Thus, the error will increase. However, as long as the reply times are identical, drift has negligible effect on the accuracy of the protocol for calculating PD. To further understand why, focus on the error element in equation (3.8):

Using the same assumptions from the example discussed earlier on in the section, and also assumes RS = 1ms, the calculated propagation time PD would be 30ns, which is the same as the actual value. Clearly, the double-sided protocol would provide accurate propagation time calculation, hence achieving more accurate synchronisation than a single roundtrip-based protocol. It is possible because the double-sided arrangement allows one to minimise the effect of drift by multiplying it with the difference of two relatively large numbers (i.e. RTTS minus RS) which are measured by the same clock (hence the drift of the two parameters are the same). After the initial exchange, S sends its round trip time information to R in M3.1, and R computes the propagation time value P using equation (3.7). The last action is to update Râ&#x20AC;&#x2122;s Real Time Clock (RTC) using Sâ&#x20AC;&#x2122;s RTC value (i.e. RTCS) by adding P to RTCS (i.e. the sinkâ&#x20AC;&#x2122;s RTC value included in message M3.2). This should be a separate operation from M3.1 to ensure P is already available (as a result of receiving message M3.1) for shift clock update. Alternatively, the sync message received by the sensor node could be used to drive the sensor to sample data through a hardware interrupt. As discussed in section II.B, it is a case specific decision as to whether to update RTC or interrupt-driven sampling upon packet reception.

Error

( RTTS R S ) D S ( RTTR R R ) D R

(3.9)

Since RS = RR = R, therefore RTTS = RTTR = RTT; rearrange equation (3.9) to give equation (3.10): Error

( RTT R )( D S D R )

(3.10)

The reason behind a small error caused by drift is that when reply times are identical (as illustrated in equation (3.10)): RTT minus R equals to 2P, which is small; DS and DR are small as well, so the product is small; further divided by four would give negligible error. The effect of variations in reply times should be understood. The authors argue that, as long as the reply times are kept small, the effect of variation of reply times on error would be limited. This is because, although an increase in error caused by an increase in reply time is expected - since equation (3.3) shows that RTT is related to R, and equation (3.9) shows that the error is proportional to the difference between RTT and R - a large(r) error is expected when two proportional large(r) values subtract each other than when two proportional small(er) values subtract each other. Thus, if WSN designers anticipated that variation in reply time is unavoidable, reply time should be kept small. This would allow the system to support a larger range of variation in reply times, yet it would still give accurate results. It should be noted that, such variation

E. Variable Clock Drifts and Reply Times It is important to understand what other practical factors may affect the accuracy of the protocol presented in section III.D. According to equation (3.7), the fundamental requirement to use the presented protocol is that the drifts are 5 40ppm was chosen as the drift used in this paper as a reference because it is considered as the standard tolerance of crystal clocks [9]. Crystal clocksâ&#x20AC;&#x2122; datasheet typically indicates drift in parts-permillion (ppm) per Â°C. The Dallas DS1307 RTC, commonly found in embedded sensors, has a drift of 0.042ppm/Â°C with an operating range of -40 to +85Â°C. 6 Although one may argue 70ns is not significant in synchronisation, given many existing work reports microsecond-level accuracy; our aim is to achieve synchronisation as precise as possible.

A crystal clock consumes 20ÂľW, whereas am OCXO consumes 1 to 3W [16]. The latter is considered to be too power hungry for most WSN applications.

211

the sensor (e.g. displacement of the sensor of more than a few meters caused by body motion), or when the deployment environment of the sensors is expected to be changing significantly on a regular basis, hence the propagation time of packets is changing significantly (e.g. sensors in a construction site). This is because the propagation time between two static sensors in an unchanged environment is always the same. Another advantage of enforcing tight communication is that, comparing to existing protocols such as RBS, the synchronisation phase requires significantly less number of messages: one verse at least three (note that RBS requires the receiving nodes to exchange their timestamps, thus the number of timestamp exchange message is proportional to the number of receiving nodes). Also, in RBS, the source node is not synchronised with the receiving nodes after the process; whereas the protocol presented in [6] requires a four-message exchange. Note that even for a highly dynamic environment, in which each synchronisation phase must be accompanied by a localisation phase, the total number of message exchanged in the presented protocol is only five, but would enable both S and all it’s receivers in the same broadcast domain to be synchronised to a much more precise level of accuracy. The authors therefore argue that, given the much more precise level of accuracy, the introduction of an extra message is justified at the expense of a slightly longer convergence time over a network of nodes when comparing with existing protocols.

may not be toleratable in precise localisation system – a nanosecond difference at the speed of light would result in a positional error of (at least) ~30cm – but as will be shown in the evaluation section (section VI), even with such degree of variation, the availability of localisation data would still enable significant improvement to the accuracy of precise synchronisation system in today’s standard. IV. CONSIDERATION FACTORS FOR APPLICABILITY In section III, it was demonstrated that various approaches could achieve accurate synchronisation, by addressing the assumptions made in existing protocols. At this section, the provisioning made in the protocol to address other issues besides accuracy will be explained. A. Efficeincy and Scalability S (sink)

R (receiver) MI.1 (SYNC request) (optional)

ML.1

(SYNC )

RTTS P

P RR

ML.2 (H

K) /W AC

P RTTR

RS P

ML.3 (H

Localisation phase (one per change in node position)

B. Utilising Inertial Sensors for Improved Efficiency A change in location (in both direction and magnitude) caused by the sensor’s motion is determinable from inertial sensors. The use of cheap, tiny inertial sensors - integrated with sensor nodes - for real-world 3D displacement estimation has been reported in many literature [22][23], and also found in many user devices (such as the iPhone). Note that an accurate measurement of sensor’s displacement by the inertial sensor is not needed, but the measurement will be used as an indication of the sensor’s displacement having exceeded a user-defined threshold8 . Note that the minor 3D displacement estimations (that did not result in a trigger for the localisation phase) are aggregated and would be reset only once the system has relocalised (i.e. when the threshold is reached). Another option, is to use the wireless chip on the sensor node for localisation analysis, and determine the change in the relative location between two nodes of interest. In other cases, the localisation phase should be carried out on a much less frequent interval when compared to the frequency of the synchronisation phase. Such arrangement would reduce the number of wireless transmissions, hence reducing the power needed efficiency and scalability. Note that the protocol could be instantiated by either the sink or the receiver (i.e. R sends MI.1 - a sync request message - to S, should R wants to be synchronised with S). Note further that, if both S and R have on-board inertial sensors, either one of them would be able to determine a change in its own location and would be able to decide whether a re-localisation is needed. If the respective displacements of both nodes have exceeded the threshold, the request from R to S to synchronise will be ignored by S because S would have triggered the synchronisation process.

/W AC K)

ML.4 (RTT SR ,

RS)

R calculates P RTCS1

MS.1

(RTC

S1 )

P RTCR1 = RTCS1 + P

RTCS2

MS.2

(RTC

S2 )

P RTCR2 = RTCS2 + P

RTCSn

time

MS.2

Synchronisation phase (recursive, update rate is applicationdependent)

(RTC

Sn )

RTCRn = RTCSn + P

Figure 5 – The complete protocol

As identified in existing literature, it is important to limit the number of message exchange in wireless synchronisation for power efficiency. The first four messages in the presented protocol (Figure 4) is therefore re-shuffled to become a 3-way protocol by merging M1.2 and M2.1 together. Note that M3.1 should not be merged with M2.2; this is because M2.2 is a h/w ACK for critically important timestamping purpose, which should not contain any data; whereas M3.1 contains time information from the sink for the receiver to calculate propagation time. The complete protocol is shown in Figure 5. Note the separation between the localisation phase (which requires four messages for each round) and the synchronisation phase (which requires only one message for each round), and that all functions are done on the PHY and MAC layer [3]. It should be noted that the frequency of synchronisation (i.e. how often should the sink synchronise with its leaf nodes) depends on the accuracy of synchronisation needed, which is a case specific issue. Once both phases have been run through once, the localisation phase, however, should be instantiated again only when there is a significant change in the physical location of

Once the threshold is exceeded the localisation phase would be (re)instantiated. The threshold is an application-specific parameter which is defined by the level of synchronisation accuracy needed.

212

largely dependent on the sampling rate of the interrupt system on the transceiver for receiving or transmitting a packet; in the NNL case, the interrupt system is driven from the 32MHz clock and runs at 4MHz. Thus, to improve tight communication, a higher frequency internal oscillator circuitry for the wireless transceiver is preferred.

C. Improving Robustness and Reliability using a Real-time Node Election Protocol It is important to understand the effect of sink failure on the robustness of synchronisation, since it is the sink that actually initiates the sync process with others. One may argue that should the sink fails, the protocol would fail. This argument, however, is not entirely valid. It was assumed that the sink would be collecting information from others for information fusion; so if the sink fails, there would be no real need for synchronisation among the others with respect to the (failed) sink, since it would no longer be able to collect data anyway. If another node is elected to be the new sink – which is an application-layer decision – the new sink could instantiate the sync process. A scalable and efficient solution using a Distributed Hash Table (DHT)-based protocol for automatically electing wireless nodes to become a sink in realtime was reported by the authors in [15]. The protocol enables a network of nodes to be instantiated through a DHT map, of which there is a Super Peer (e.g. the sink) and normal peers. Should the Super Peer node fails, the Super Peer node’s key is automatically transferred to another node yet the transfer is announced automatically to all other peers in the network without explicit notification. Hence, efficiency and scalability are enhanced. If a node that fails is the only intermediary node between two (network of) nodes (i.e. a bridge), and it is supposed to relay synchronisation messages; and if that node fails, data on the other side of the network would not be uploaded to the sink. In other words, a new (temporary) sink must be elected for the part of the network that is no longer receiving sync messages. The authors suggested that the sink election process could start when nodes have failed to receive synchronisation messages after a timeout using the same protocol presented in [15]. To address reliability issues related to the unreliable wireless links (which may lead to message loss or corruption): a) nodes re-transmit or re-instantiate the sync process after a pre-defined timeout, or b) nodes instantiate the sync process at fixed time intervals; these are commonly considered as acceptable approaches in existing work [4][5][6][7].

B. The Bracelet Computer

Power board

USB-serial interface (for programming only) Wireless board

Processor board

Bracelet strip (mounted on fibre glass for development purpose)

Figure 6 – The Bracelet computer

Note that the nanoLoc transceiver has a number of ultimate advantages over the hardware choices reported in [13]: it is tiny and the SPI interface means it can be easily integrated with almost any micro-processor or micro-controllers. To demonstrate the advantage of portability: consider the Bracelet computer (Figure 6) [26]. It is a light-weight, low-cost, tiny, wearable modular computer that enhances functional flexibility by allowing for different combination of modules to be used for a wide range of WSN applications. It is out-ofscope of this paper to discuss the details of the Bracelet computer, but essentially, the main unit of the system is the processor board (a MSP430 microcontroller for data processing) and the power board (for supplying power to the system). It is designed to be flexible: it supports a range of daughter boards that are mounted on a flexible strip; the daughter boards include a motion sensor board which includes a 3-axis accelerometer and gyroscope, an atmospheric pressure sensor board, etc. Note that the system is flexible: other daughter boards are also available (e.g. for CO sensing, blood pressure sensing, etc.). Contiki is ported onto the Bracelet computer to ease programming. It should be noted that the presented suggestions on enabling precise synchronisation are not limited to the Bracelet computer: the SPI interface on the main processor board – which is an interface also commonly available on many micro-processor and micro-controller - is connected to a (optional) wireless board, which is - in this case - the nanoLoc TRX transceiver. This approach results in a more generic approach than the one presented in [13].

V. CONSIDERATION FACTORS FOR IMPLEMENTATION In previous sections, a range of suggestions have been made to enable precise localisation in WSNs in an efficient and reliable way. In this section, the authors will describe a range of factors that should be considered when it comes to actual implementation. A. Wireless Transceiver One candidate to enable tight communications is the nanoLoc (NNL) TRX transceiver [2]. These type of specifically-designed transceiver – such as the NNL transceiver - has several advantages over conventional WiFi chips: a) it operates in the 2.4GHz band and it uses CSS to support both wireless data transmission (with data rates from 125kbps to 2Mbps, which is sufficient for most WSN applications) and ToA-type localisation; b) unlike the custommade device from [13], the nanoLoc TRX transceiver is a cost-effective (~£60 unit price), commercially available transceiver which does not require additional hardware or gateway, and does not require power consuming temperature compensated crystal oscillator; its SPI interface means it can be easily connected to sensor nodes; c) its (relatively) low power feature is ideal for WSN (i.e. ~76mW for transmission); and d) it’s readily available drivers and libraries mean programming is relatively straightforward. Note that, as explained in section III.C, the synchronisation accuracy is

C. Bottlenecks: Software or Hardware? The bottlenecks to enable precise synchronisation may initially appear to be – arguably - the lack of new novel ideas for more accurate synchronisation protocol (one may argue that many protocols – that are very similar in nature - have already been reported on the topic); however, as demonstrated in this paper, the innovation on protocol design can be reignited by revisiting the problem from a different angle and a sensible choice of hardware. The authors suggest that, to

213

nodes may be involved in other critically important missions and may not be able to reply within the defined time limit. Again, it is assumed that P = 30ns, clocks drift randomly from -40ppm to +40ppm, RS = 0.5ms, but RR is longer than RS by 10%, 20%, and 50% respectively. The results (Table 2) clearly show that, a) a small reply time is favourable; and b) as the deviation between the reply times increases, so as the error. In fact, if RS = 0.5ms, RR could be ~5,000% of RS (i.e. 25.5ms) yet the error (i.e. 169.186±119.447ns) would just exceed the benchmark (i.e. 200ns).

enable precise synchronisation, it is critically important to address the problem from both hardware and software side. Although one may argue that new hardware – in this case the nanoLoc transceiver - would be incorporated in the solution; but the authors argue that: a) at the time of writing, there is neither a de-facto wireless transceiver nor a de-facto sensor node for WSNs, thus, any practical solution should be considered; b) many software-based synchronisation solutions have already been proposed but none could quite reach submicrosecond level accuracy, and there aren’t sufficient evidence to suggest a pure software-based approach would enable sub-microsecond level accuracy; and c) such approach is more beneficial and elegant than the one presented in [13] because only a commercially available wireless transceiver would be required. It is therefore important to understand what the bottlenecks are and to identify appropriate solutions so that WSN system developers could build their systems based on a sensitive choice of software and hardware as well as their application’s requirements.

Table 2 – Error analysis of 2,000 calculated propagation time (PD) errors when RS does not equal to RS with random clock drift from 40ppm to +40ppm

VI. EVALUATIONS

A. Propagation Time Accuracy Evaluation with Variable Drift

Mean (ns)

SD (ns)

Error (ns)

0.5

0.000391

0.000281

0.000531

0.000396

0.000277

0.000534

0.000402

0.000288

0.000547

Mean (ns)

0.5

0.55

0.3441

0.24

0.464

0.5

0.6

0.668

0.468

0.902

0.5

0.75

1.695

1.197

2.293

SD (ns)

Error (ns)

Table 3 – Error analysis of 2,000 calculated propagation time (PD) errors when RS does not equal to RR with random clock drift from 40ppm to +40ppm

Table 1 – Error analysis of 2,000 calculated propagation time (PD) errors when RS = RR with random clock drift from -40ppm to +40ppm RR (ms)

RR (ms)

To further investigate these features, the same evaluation is repeated but with RS = 1ms and 10ms respectively. The results are shown in Table 3 and Table 4 respectively. Note that when RS is 10ms and RR is 50% longer, the error is only ~25% of the benchmark (i.e. which was 200ns).

In this section, some of the key concepts are evaluated. It should be noted that this is not a full evaluation of all the presented solutions, but to justify some of the arguments.

RS (ms)

RR (ms)

Mean (ns)

SD (ns)

Error (ns)

1.1

0.662

0.477

0.9

1.2

1.345

0.931

1.811

1.5

3.364

2.345

4.536

Table 4 – Error analysis of 2,000 calculated propagation time (PD) errors when RS does not equal to RR with random clock drift from 40ppm to +40ppm

The highest accuracy (i.e. 200ns) reported in existing literature [13] on WSN synchronisation would be used as the benchmark for this paper. Let the actual propagation (P) be 30ns, and assume RS = RR = 0.5ms, 1ms, and 10ms respectively. Note that in ranging protocols, reply times typically have a normal distribution with a mean at 400µs and standard deviation of reply time of 100µs [14]. Thus, the assumption on reply times – which ranges from 0.5ms to 10ms – would cover a wide range of possible values, hence providing a more complete picture. Also assume that the clocks of S and R drift randomly from -40ppm to +40ppm9, which is the standard tolerance [9]. The propagation time with drift (PD) is calculated using equation (3.7). The errors, which are the differences between the calculated PD and the actual P over 2,000 trials, are presented in Table 1. Note that the errors are in nanoseconds (ns). The results from Table 1 show that the (negligible) error increases when the reply time’s duration increases when clock drifts randomly.

RS (ms)

RR (ms)

Mean (ns)

SD (ns)

Error (ns)

6.6223

4.745

8.996

13.197

9.424

17.909

33.089

23.335

44.757

Note that RTTS, RS, RTTR, RR are measurable by S and R respectively, but DS and DR are random and are changing all the time; so they are not measurable. One may ask: so how does one calculate P, since equation (3.7) requires DS and DR? The results presented in this section suggest that DS and DR could be any random value within the range of drift of the clock’s specification (e.g. -40ppm to +40ppm), yet the error in PD calculation would still be within acceptable limit (i.e. <200ns), provided that the reply times within reasonable limits. The results suggest that, unlike existing solutions, there is no need to assume drift since the effect of drift is minimised in the protocol.

B. Propagation Time Accuracy Evaluation with Variable Drift and Variable Reply Time The effects of variability in both drift and reply times on the protocol are evaluated in this section in order to understand how much variation on the reply times the protocol could tolerate; especially to investigate whether there would be any “side-effects” if there were both random clock drifts and variable reply times. This is because, in real WSNs, sensor

VII. CONCLUSION & FUTURE WORK In this paper, the common assumption factors that create synchronisation delays in existing WSN synchronisation protocols, such as tight communications and negligible propagation times, etc. are identified. The authors suggested that, to enable precise, sub-microsecond-level synchronisation accuracy, these assumptions must be addressed. A number of solutions were presented to improve the accuracy, reliability,

All random values used for evaluation in this paper are pseudorandom numbers generated in Microsoft Excel.

214

efficiency of WSN synchronisation. As a summary, the contributions of this paper are: x This paper is the first to identify that tight communications and negligible propagation times – which are assumed in many existing protocols - have important roles in improving the precision of WSN synchronisation; x This paper is the first to identify a solution to enable precise synchronisation in WSN by fusing real-time localisation information with synchronisation information; x This paper is the first to identify that a suitable selection of radio technology has a significant effect of WSN synchronisation accuracy; x Comparing to [13] which requires a number of different hardware, only a low-cost, light-weight, small-size, low power wireless module, which uses a standard communication interface (i.e. a SPI interface), is needed in the presented solution. Thus, such arrangement improves practicability (i.e. only one wireless module is needed); x The effect of variability of clock drifts and reply times on the protocol’s accuracy was investigated; x Efficiency, scalability, reliability, and robustness issues of the presented protocol are discussed; implementation issues were also addressed. This paper is the first to identify the integration of inertial sensor data with localisation data to improve efficiency and scalability in precise WSN synchronisation. Also, a real-time, dynamic sink (re)election protocol was identified to address reliability and robustness issues; and the relationship between the frequency of the internal oscillator circuitry for the wireless transceiver and tightness of communication was explored. The authors’ future work includes implementing the protocol on the Bracelet computer. The computer would provide an ideal platform for the presented suggestions. The commercially available driver needs further modifications in order to access low level device information, such as packet interception times. acknowledgement

[8]

[9]

[10] [11]

[12]

[13]

[14]

[15]

[16]

[17] [18]

ACKNOWLEDGEMENT [19]

The authors would like to thank Venus Shum, Graeme McPhillips, and John Lowe for their contributions and support. This work was funded by EPSRC grant number EP/D076943.

[20]

REFERENCES [1] [2]

[3]

[4]

[5]

[6]

[7]

The SEnsing for Sports And Managed Exercise (SESAME) project, http://www.sesame.ucl.ac.uk nanotron TRX, http://www.nanotron.com/EN/pdf/Factsheet_nanoLOCNA5TR1.pdf J. Elson, L. Girod, and D. Estrin, “Fine-grained Network Time Synchronisation using Reference Broadcasts”, in Proceedings of ACM SIGOPS Operating Systems Review, Vol. 36, Issue SI (Winter 2002), pp. 147-163. T. Schmid, Z. Charbiwala, J. Friedman, Y. Cho, and M. Srivastava, “Exploiting Manufacturing Variations for Compensating Environment-induced Clock Drif in Time Synchronisation”, in Proceedings of ACM Sigmetrics 2008, Vol. 36, Issue 1, June 2008, pp. 97-108. B. Sundararaman, U. Buy, and A. Kshemkalyani, “Clock Synchronisation for Wireless Sensor Networks: a Survey”, in Proceedings of Ad Hoc Networks, Vol. 3, Issue 3, May 2005, pp. 281-323. K. Romer, “Time Synchronisation in Ad Hoc Networks”, in Proceeding os ACM Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc 2001), Oct 2001 pp. 173-182. M. Mock, R. Frings, E. Nett, and S. Trikaliotis, “Continuous Clock Synchronisation in Wireless Real-time Applications”, in Proceedings of the 19th IEEE Symposium on Reliable Distributed Systems (SRDS), Oct. 2000, pp. 125-133.

[21] [22]

[23]

[24] [25] [26]

215

L. Cheng, H. Tan, G. Kuntze, K. Roskilly, J. Lowe, I. N. Bezodis, S. Hailes, A. Wilson, and D. G. Kerwin, “Sensing for Stride Information of Sprinters", in Proceedings of the 7th European Conference on Wireless Sensor Networks (EWSN), Coimbra, Portugal, Feb 2010. R. Hach, “Symmetric Double Sided Two-Way Ranging,” IEEE P802.15 Working Group for Wireless Personal Area Networks (WPAN), Doc. IEEE P.802.15-05-0334-00-004a, 2005. IEEE Computer Society, IEEE Std 802.15.4a – 2007, Aug. 2007. L. Cheng, H. Tan, G. Kuntze, I. N. Bezodis, S. Hailes, D. G. Kerwin, and A. Wilson, “A Low-cost Accurate Speed Tracking System for Supporting Sprint Coaching”, in Proceedings of the Institution of Mechanical Engineers, Part P, Journal of Sports Engineering and Technology. D. Newell and R. Bangert, “Temperature Compensation of Quartz Crystal oscillators”, in Proceedings of the 17th Annual Symposium on Frequency Control, 1963, pp. 461-507. H. Cho, J. Jung, B. Cho, Y. Jin, S. Less, and Y. Baek, “Precision Time Synchronisation using IEEE 1588 for Wireless Sensor Networks”, in Proceedings of the International Conference on Computational Science and Engineering, 2009. H. Kim, “Performance Analysis of the SDS-TWR-MA Algorithm”, in Proceedings of the International Conference on Communications And Mobile Computing, Leipzig, Germany, 2009, pp. 399-403. L. Cheng, K. Jean, R. Ocampo, A. Galis, P. Kersch, and R. Szabo, “Securely Bootstrapping Distributed Hash Tables in Dynamic Wireless Networks”, in Proceedings of IEEE International Conference on Communications (ICC), Glasgow, Scotland, Jun 2007. O. Mancini, “Precision Frequency Generation Utilising OCXO and Rubidium Atomic Standards with Applications for Commercial, Space, Military, and Challenging Environments”, IEEE Long Island Chapter, March 18, 2004. Nanotron technologies, “Real Time Location Systems (RTLS)”, white paper from nanotron technologies GmbH, 2007. L. Cheng, G. Kuntze, H. Tan, K. Roskilly, J. Lowe, I. N. Bezodis, S. Hailes, A. Wilson, and D. G. Kerwin, “Practical Sensing for Sprint Parameter Monitoring”, in Proceedings of the 7th IEEE Communications Society Conference on Sensor, Mesh, and Ad Hoc Communications and Networks (SECON), Boston, USA, June 2010. S. Ganeriwal, R. Kumar, S. Adlakha, and M. Srivastava, “Network-wide Time Synchronisation in Sensor Networks“, Technical Report, Networked and Embedded Systems Lab, Elec. Eng. Dept., UCLA, 2003. A. Nieuwenhuyse, J. Wyffels, J. Goemaere, L, Strycker, and B. Nauwelaers, “Time of Arrival Based on Chrip Pulses as a means to Perform Localisation in IEEE 802.15.4a Wireless Sensor Networks“, in Proceedings of Advances in Electrical and Computer Engineering, Vol. 10, No. 2, 2010. nanotron, “nanoNeChrip Based Wireless Networks,” white paper, v1.04, NA-04-000-0298-1.04. S. Shin, C. Park, J. Kim, H. Hong, and J. Lee, “Adaptive Step Length Estimation Algorithm using Low-cost MEMS Inertial Sensors“, in Proceedings of IEEE Sensors Applications Symposium (SAS), San Diego, California, USA, Feb 2007. H. Schepers, D. Roetenberg, and P. Veltink, “Ambulatory Human Motion Tracking by Fusion of Inertial and Magnetic Sensing with Adaptive Actuation”, in Proceedings of Med. Biol. Eng. Computing, 2010, Jan; 48(1): 27-37, Dec 2009. decaWave, http://www.decawave.com/rtls.html Ubisense, http://www.ubisense.net/en/products L. Cheng, G. Kuntze, H. Tan, K. Roskilly, J. Lowe, S. Hailes, D. G. Kerwin, and A. Wilson, “Stride Information Monitoring and Sensing in Sports“, to be published in the Proceedings of the 7th IEEE International Conference on Mobile Ad-hoc and Sensor Systems (MASS), San Francisco, CA, USA, Nov 2010.