1. On-Demand Traffic-Embedded Clock Synchronization for Wireless Sensor Networks Sang Hoon Lee

2. Introduction When does a node require the time information? Networking operations Wakeup scheduling, TDMA scheduling, Various timer for IFS, slot time, etc. Data processing Event ordering, Data fusion, Localization Especially, in MAC protocols. A wireless sensor node usually employs periodic wakeup and sleep scheduling to reduce the energy consumption due to idle listening. The interval and the duration of this wakeup must be scheduled and coordinated with other nodes for an effective communication. Synchronous wakeup scheduling vs. Asynchronous wakeup scheduling. In synchronous wakeup scheduling the wakeup of each node is synchronized with its neighbors. In contrast, asynchronous wakeup scheduling allows each node to wake up independently.

3. Motivation Proactive approach Since existing synchronization schemes assume that any node can use time information at any time, all the nodes synchronize their clock whether they use time information or not. The proactive approach can maintain nodes’ clocks within a certain threshold by periodically carrying out a clock synchronization process. It suits the specific networks where nodes frequently use time information for operations. Especially, in synchronous wakeup scheduling MAC nodes always need to synchronize their clock to prevent the malfunction of MAC operations. The proactive clock synchronization scheme is proper for the synchronous MAC.

4. Motivation In asynchronous MAC protocols, do we need to carry out a clock synchronization process ‘periodically’? In asynchronous MAC protocols, each node needs no common timeline for MAC operations. Time information is used by a processor of data. A data generator needs to synchronize its clock with a processor that is usually a sink. An arbitrary node also can be a data processor since time information can be used in data fusion or localization. Therefore, a node needs time information when it generates or processes data. In synchronous MAC protocols, do all the nodes need to carry out a clock synchronization process according to ‘the same frequency’? Although there is no traffic, nodes need to synchronize their clock to prevent the malfunction of MAC operations. Static synchronization period The existing algorithms assume that all the nodes share the same synchronization period. Dynamic synchronization period The clock skew of each node would be different from other nodes. Each node dynamically adjusts its synchronization period according to its clock skew against its neighbors.

5. Overview Traffic-embedded clock synchronization On-demand clock synchronization for asynchronous MAC protocols Each node synchronizes its clock when there is traffic. Time information can be embedded in the existing packet: data and ACK. We can reduce the communication overhead for the periodical clock synchronization. Dynamic synchronization period for synchronous MAC protocols Each node synchronizes its clock right before its clock drift becomes bigger than the predefined threshold. If a node has a packet to be transmitted in its buffer, it embeds time information in the packet. If a node has no packet, like the existing algorithms it generates dedicated control packets to exchange time information.

6. On-demand Clock Synchronization If we can know the offset between source’s clock and destination’s clock, we can adjust the time information of a source node in a data packet. To implement the above clock synchronization algorithm based on the accumulated offset value, we need three-way handshaking: request, reply, and offset delivery. Since each operation requires only timestamps and node address, we can embed the information into the header field of an existing packet if possible. There are two types of asynchronous MAC. Preamble – Data – ACK (PDA) scheme: B-MAC, WiseMAC Preamble – ACK – Data (PAD) scheme: X-MAC, RI-MAC Offset between A and D: O AD = O AB + O BC + O CD ABCD Offset between A and B is O AB Offset between B and C is O BC Offset between C and D is O CD

7. On-demand Clock Synchronization In PDA scheme

8. On-demand Clock Synchronization In PAD scheme

9. On-demand Clock Synchronization Clock Synchronization during Broadcasting a Data The broadcast-based clock synchronization Doesn’t try to measure the exact offset and delay. Instead, each node simply broadcasts its clock information and it assumes that it can estimate the message delay by using a certain probability function or there is no message delay.

10. Dynamic Synchronization Period Idea Each node can track its clock skew against its neighbors through periodic clock synchronization. According to the clock skew, each node dynamically adjust its synchronization period that is the time difference between two consecutive synchronization processes. Dynamic synchronization period Each node maintains a clock skew table that contains clock skew values for all the neighbor nodes. Clock skew can be estimated through multiple synchronization processes. Each entry of a clock skew table contains a neighbor node ID, ID, clock skew, C ID and a synchronization timer, t ID. At first, all the synchronization timers set the initial period, P init. The synchronization period of a node can be calculated as P synch = Th drift / max(C 0,C 1,…,C n ) where Th drift represents the maximum tolerable clock drift and n is the number of neighbor nodes.

11. Dynamic Synchronization Period Synchronization process Traffic-embedded offset and delay estimation When a synchronization timer expires, a node carries out a synchronization process with its neighbor with respect to the timer. If a node has a packet to be transmitted to the neighbor node, it utilizes the packet transaction. RTS and CTS packets are used to estimate both offset and delay. Estimated values can be inserted into a data packet. Otherwise, the node generates a dummy data packet and utilizes the dummy packet transaction.