Securely Restoring Lost Global Synchronization

If a node hears a packet with equal Sync ID, but the PRNG seed does not match it’s own, this may be an indication that the network has somehow become partitioned into two or more virtual clusters which have the same Sync ID and hence will not merge according to the previous algorithm. This should be a rare occurrence. It might occur if a node that forms an exclusive path fails and is not replaced for a while (allowing clock drift to accumulate to the point that the two virtual clusters no longer have matching PRNG seeds despite having the same Sync ID).

We propose a method of restoring synchronization under these conditions that is robust against tampering by deceptive jammers. The algorithm for restoring lost global synchronization causes a node that detects lost synchronization to undergo a verification

process with the sender of the packet that was out of sync. If successful, the node adopts the new schedule and propogates it to any neighbors it had. Those neighbors recursively propagate the new schedule to the rest of the cluster that was also following the old schedule.

FIGURE 4.11. Global Sync Restore Example: A border node of one cluster will initiate the restoration process. If all goes well, one of the two clusters will join the other cluster.

1. A node that hears an out of sync neighbor with identical Sync ID temporarily adopts the secondary scheduleB from this SYNC packet along with its own scheduleA. It

broadcasts a verification request in a SYNC slot of scheduleB. This would be heard by

any node in range that is part of the scheduleB virtual cluster. If there is no apparent

response, it tries once more in the next frame. The purpose of this packet is to simply increase the SYNC rate of the scheduleBnode in order to increase the speed of recovery.

We call the verification packet SYNC-V. It is a standard scheduleB SYNC packet with

a special value in the type field indicating that it is a SYNC-V rather than an ordinary SYNC packet. We will introduce a few similar packets below that are also distinguished only by the type field.

2. A node hearing a SYNC-V simply increases its SYNC rate temporarily and will not heed a SYNC-R (reset request) for a period of time. This keeps it from accidentally going through the reset process that the sender of the SYNC-V request initiated. This is necessary in case the SYNC-V sender is not an exclusive connection to the virtual cluster following scheduleAwhich might allow a reset to propagate into the scheduleB

cluster at the same time that scheduleB is propagating into the scheduleAcluster. The

verifying responders transmit scheduleB SYNC-H packets for a few frames and sets its

cool-down timer. A node with an active cool-down timer treats special SYNC packets as ordinary, and does not send a SYNC-V when discovering an incorrect PRNG seed. 3. A scheduleB node hearing a SYNC-H propagates it and holds its schedule by setting

its cool-down timer. It also propagates the SYNC-H for a few frames. These nodes are simply waiting for the network to settle.

4. When the node on scheduleA receives 2 SYNC packets with the correct seed and at

the expected time according to scheduleB, it has confidence that it has detected a

legitimate node in a different virtual cluster. It sets its primary schedule to scheduleB

and takes it upon itself to propagate a scheduleB SYNC-R (reset request) through the

scheduleA cluster.

5. A node newly following scheduleB converts its cluster members from scheduleA by

sending scheduleB SYNC-R packets at a high rate for many frames (determined by

to listen for additional SYNC on that schedule for verification. This similar to the SYNC-V exchange, except the nodes hearing a SYNC-R skip the step of sending a SYNC-V to trigger an increased SYNC rate (a node sending SYNC-R is already using a higher rate). As with SYNC-V verification, if the scheduleA node hears 2 SYNC

packets after the SYNC-R at the expected time, they adopt scheduleB and engage in

converting their neighbors for a short period as well (spreading the SYNC-R through the scheduleA cluster).

6. Nodes that have undergone a schedule reset or heard the SYNC-H packet ignore new schedule resets for a specified cool-down period so that the separated clusters have time to merge and settle before considering additional orphaned clusters. This aids in the functioning of the algorithm in also prevents malicious nodes from triggering a sync restore attempt repeatedly (wasting energy). All nodes continue normal commu- nications on their primary schedule while resynchronization occurs in the background (though their communications is limited to the virtual cluster they are a member of until the reset propagates).

The length of the cool-down period depends on the expected network size. We will test this in our simulator under different conditions.

4.4

Remarks

Although RSMAC was inspired by the need to resist intelligent jammers, while adding the random sleep feature we discovered a method for globally synchronizing the network and eliminating explicit neighbor discovery. This should improve energy fairness and reduce en- ergy consumption, perhaps by enough to make up for the additional energy consumed by larger SYNC packets and algorithmic complexity. Global synchronization has additional ben-

synchronized regardless of location. We will determine the basic energy and performance tradeoffs by performing preliminary testing in our novel simulator.

We are currently preparing a separate publication describing RSMAC. It will contain a summary of the background material in chapters 1 and 2, the details in this chapter, and the experimental results from chapter 5 that illuminate the functionality of the protocol.

Chapter

5

Experimentation