On-Demand Traffic-Embedded Clock Synchronization for Wireless Sensor Networks

Sang Hoon Lee

IntroductionWhen does a node require the time information?

Networking operationsWakeup scheduling, TDMA scheduling, Various timer for IFS, slot time, etc.

Data processingEvent ordering, Data fusion, Localization

Especially, in MAC protocols.A wireless sensor node usually employs periodic wakeup and sleep schedul-ing 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 inde-pendently.

MotivationProactive 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 thresh-old 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 syn-chronize their clock to prevent the malfunction of MAC operations.

The proactive clock synchronization scheme is proper for the synchronous MAC.

MotivationIn asynchronous MAC protocols, do we need to carry out a clock synchro-nization process ‘periodically’?

In asynchronous MAC protocols, each node needs no common timeline for MAC opera-tions.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 mal-function of MAC operations.Static synchronization period

The existing algorithms assume that all the nodes share the same synchronization period.

Dynamic synchronization periodThe 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.

OverviewTraffic-embedded clock synchronization

On-demand clock synchronization for asynchronous MAC protocolsEach 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 protocolsEach 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.

On-demand Clock SynchronizationIf 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, WiseMACPreamble – ACK – Data (PAD) scheme: X-MAC, RI-MAC

Offset between A and D: OAD = OAB + OBC + OCD

A B C D

Offset between A and B is OAB

Offset between B and C is OBC

Offset between C and D is OCD

On-demand Clock SynchronizationIn PDA scheme

On-demand Clock SynchronizationIn PAD scheme

On-demand Clock SynchronizationClock 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.

Dynamic Synchronization PeriodIdea

Each node can track its clock skew against its neighbors through periodic clock synchronization.According to the clock skew, each node dynamically adjust its synchroniza-tion period that is the time difference between two consecutive synchroniza-tion processes.

Dynamic synchronization periodEach 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, CID and a synchronization timer, tID.

At first, all the synchronization timers set the initial period, Pinit.

The synchronization period of a node can be calculated as Psynch = Thdrift / max(C0,C1,…,Cn)

where Thdrift represents the maximum tolerable clock drift and n is the number of neighbor nodes.

Dynamic Synchronization PeriodSynchronization process

Traffic-embedded offset and delay estimationWhen 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.