Our proposal consists of two periodic phases. In case the WSN needs to also synchronize to UTC time, we propose to add a third phase.
Secure CN Pairwise (Re-)synchronization. Each pair of neighbor CNs use the SPS-SE protocol to synchronize, initialize and maintain RATS, and schedule each subsequent time synchronization iteration. In this manner, a common time reference is set up for the WSN.
Secure BAN (Re-)synchronization. The CN uses the SPS-SE protocol to synchronize each BAN member. In this manner, a common time reference is set up for the BAN. RATS is accommodated to use it with multiple nodes.
UTC Synchronization. WSN time is translated to UTC time.
In the remainder of this paper, let us consider that at each period a new controller node is elected in each BAN. Note that if the controller node is fixed, then R is the WSN lifetime.
We divide pairwise and BAN time in a number of variable time periods and , where complying and complying , respectively. A period or can encompass one or more consecutive sleep plus wake intervals. In any case, we define the beginning of each period or right to coincide with the beginning of a wake interval.
The duration of a period does not necessarily coincide with any , for . The duration of a period does not necessarily coincide with any , for . The duration of a period does not necessarily coincide with any , for .
In the predeployment phase, that is, during manufacture, the sensor nodes are preconfigured with an initial default sampling period S
and an initial optimal window size W
. Once deployed, starting from the beginning of BAN existence, the nodes exchange W
time observations, each sample separated by S
seconds. The messages used to exchange these observations are protected by secure means.
After seconds, the sensors derive the first estimate of their clocks using (1). If this estimation error is between the thresholds , then the sensor nodes use the clock estimations for synchronizing. Otherwise, the sensors keep exchanging time observations each S
seconds till the estimation error is between the two thresholds. From this moment on, the sensors use the clock estimations for synchronizing.
During the rest of the BAN existence, the quality of the estimation is optimized to the particular conditions of each epoch. The nodes employ RATS to periodically calculate the optimal duration of and , , to maintain the precision of the clock estimations between the thresholds . Moreover, a corresponding new optimal window size and , , is obtained. Additionally, after each interval or , , the nodes securely exchange a new time sample and recalculate the clock estimations.
These steps are repeated after each controller node re-election.
In the rest of the section, we thoroughly describe the SPS-SE protocol and each of the phases of the synchronization system.
4.1. Secure Pairwise Synchronization with Sample Exchange
We propose a protocol for secure pairwise synchronization and sample exchange that leverages SPS . SPS is based on sender-receiver synchronization. It performs a handshake protocol between two nodes u and v.
The integrity and authenticity of SPS-SE messages are guaranteed using message integrity codes (MICs) and a shared key . Moreover, the MIC provides resistance to pulse-delay attacks and external attackers.
The SPS-SE protocol consists of the following message exchanges (time samples between brackets denote message time of send (tos) or time of arrival (toa)):
where , , and is the key shared by u and v.
At the end of the protocol, both nodes calculate the SPS message end-to-end delay as specified in :
The end-to-end delay is used to detect pulse-delay attacks against SPS-SE.
The clock offset is also calculated as follows:
Subsequently, u and v add the new time sample to their respective sample repository.
For sensor nodes using crystal oscillators with stability up to 100 ppm, the duration of the protocol is to be bounded to a few hundred milliseconds. In such case, we can assume the clock drift to be negligible and accept the time observations accurate enough for the prediction.
4.2. Synchronization Method
The synchronization method allows two nodes to adapt their respective time measures. We distinguish two methods: short-lasting synchronization and long-lasting synchronization.
4.2.1. Short-Lasting Synchronization
Short-lasting synchronization is used during the initialization phase of RATS for the nodes to establish short-lasting accurate clock synchronization and for exchanging samples for a clock estimation with the required target precision.
Note that because of the low quality of clock crystals, this method cannot be used to maintain a high precision during a relative long time without an expensive energy cost. For instance, the CC2420 can drift up to 80 μ s per second, and in 60 seconds the clocks may drift up to 4810 μ s. To guarantee a precision below the 100 μ s, the nodes would need to synchronize each second.
The method works as follows. Firstly, by using the SPS-SE protocol, two nodes u and v calculate their relative clock offset. Subsequently, to synchronize a node's time measure, with another's clock measure the clock offset is added (or subtracted, as needed). For instance, if sensor u collects and timestamps a data sample at , translates data collection time to to get the time measure relative to its own notion of time.
For subsequent message exchanges between u and v, the message delay d needs also to be taken into account to calculate the synchronized time. For messages timestamped below the MAC layer immediately prior to their transmission, the delay (d) adds the contribution of the transmission time, the propagation time, and the reception time. The transmission time is the time needed for the sender to transmit the message bit by bit at the physical layer. This time can be easily calculated by the receiver by knowing the length in bits of the message and the radio speed. The propagation time is the actual time taken by the message to traverse the wireless link from the sender to the receiver. In WSN, the distance among neighbor sensor nodes is of a few meters. Therefore, because radio waves move at the speed of light and the radio speed is up to a few Mbit/s, the propagation time is neglected compared to the rest of times. The reception time accounts for the time taken by the receiver in receiving the bits and passing them to the MAC layer. This time can also be easily calculated by the receiving node. Thus,
For instance, for a timestamped message that u sends at time and reaches v at time , v will interpret sent time as . For instance, v can check the time integrity of the message by verifying that the difference between and is below a certain threshold.
4.2.2. Long-Lasting Synchronization
Long-lasting synchronization is used to maintain precise clock synchronization with fine-tuned RATS.
Each new time sample (e.g., (, )) exchanged with SPS-SE includes the offset but not the delay contribution, which is a particular measure of each exchanged message. Therefore, with estimated clocks, for a timestamped message that u sends at time and reaches v at time , v will interpret sent time as . Furthermore, if sensor u collects and timestamps a data sample at , v translates data collection time to to get the time measure relative to its own notion of time. Here is an estimation of the current offset between and .
4.3. Secure CN Pairwise (Re-)Synchronization
Secure CN pairwise (re-)synchronization is used to periodically synchronize two neighbor CNs. Each and every pair of neighboring CNs of the WSN is to synchronize following this method. In this manner, WSN time is established.
The interval of time starts right after two newly elected CNs and discover each other by physical and MAC layer means (the description of these means is out of the scope of this paper).
During time periods , , BAN controller nodes use the short-lasting synchronization method. Additionally, this time is also employed to exchange the first time samples. Right at the beginning of each time period , , by using the SPS-SE protocol nodes and synchronize and exchange a time sample , . To detect wormhole and pulse-delay attacks, each CN also measures the maximum SPS-SE expected message delay .
At the beginning of period both CNs calculate the first clock estimations and initialize RATS for the first time. At the end of both CNs estimate their relative clock offset as follows:
If is below the required accuracy threshold , then RATS is considered to be fine-tuned. Consequently, BAN controller nodes switch to the long-lasting synchronization method for the following BAN periods.
Otherwise, yet the synchronization method to be used is short-lasting synchronization for subsequent BAN periods , , till the condition is satisfied. Let us refer to the period when this condition is satisfied as . Typically, .
During BAN periods , , BAN controller nodes use the long-lasting synchronization methods. Right at the beginning of each of these periods, and exchange a new time sample (, ) by using the SPS-SE protocol and add it to their respective sample repository. RATS is employed to periodically recalculate (see Section 4.3.1). Additionally, the clock estimations are recalculated using (1). Finally, a real measure of the clock offset is calculated using the SPS-SE protocol to validate the estimation of the clock offset and, thus, to continuously monitor the quality of the clock estimations.
Since the clocks of CN
drift throughout , , the measure of at the end of the period will likely be different at and . To counter this relativistic effect, we define pairwise period-dependent time of guard. Despite the fact that clocks can get desynchronized, the time of guard guarantees that both CNs are ready to concurrently use the radio channel after long sleeping periods. In order to preserve energy of nodes the time of guard needs to be accurately minimized.
The pairwise period-dependent time of guard to be used at the beginning of , , is calculated as follows:
During its each CN is only allowed to receive messages. The first CN exhausting its triggers the re-synchronization.
At the very end of each period , , the offset is accurately predicted by using (8).
The uncertainty included by the data rate is just 4 ppm at 250 kbps. Because nodes of a WSN are separated at most a few tens of meters, the contribution by the propagation delay can be neglected.
4.3.1. Calculation of Optimal Sample Period and Window Size
By using RATS, the two CNs calculate the optimal window size for the current period . Additionally, the optimal duration for the the current period is recalculated. The pseudocode for the RATS algorithm is as follows:
calculate () using a window of samples in (2),
compute using (4),
if , then
else if , then ,
if , then
else if , then .
4.3.2. Estimation of Relative Clock Skew
By using the time observations (, ), where in (1) and (2), nodes and estimate and , respectively.
4.4. Secure BAN (Re-)Synchronization
Secure BAN (re-)synchronization is used to periodically synchronize BAN members with the CN. This, in turn, guarantees that each BAN member is synchronized to the same reference time. This process establishes BAN time without the need for each BAN member to pairwisely synchronize.
BAN wise synchronization can be scheduled in two different manners. First, we let each node to independently schedule its re-synchronization interval. That is, each node has an own measure of the BAN period . At the beginning of each node-dependent BAN period, the node synchronizes with the CN. This manner requires the CN to be asleep each time a BAN member is to synchronize. Because of the independency of the length of each , , the requirement of low-duty cycling is hard to comply for the CN.
A second manner consists of letting the CN to schedule a unique re-synchronization interval for all the BAN members. At the beginning of each BAN period, a slot of time is reserved for each node to synchronize with the CN. This scheduling can be designed to accommodate for CN duty cycling requirements.
Observe that to comply that clock estimations are below the required accuracy level during the period , then the must select as the minimum duration for a BAN period required by all the nodes of the BAN.
To solve this issue, we have again two possible approaches. The first approach consists of letting each node of the BAN, , calculate its own measure of , that is, . Then, each node independently sends to the CN. Finally, the CN heads select for all .
The second approach consists of the calculating for all , . Then, the CN heads select for all .
We favor the second approach because it does not require the nodes to send to the CN. The need to send messages has implications of added energy consumption and delay both for the BAN members and the CN. The second approach requires much more computational effort in the CN than the first approach. However, the implied energy consumption and delay are neglected compared to the overhead of the first approach.
The rest of the section describes the details of this second approach.
The interval of time starts right after the BAN is formed. Right at its beginning the CN generates a BAN broadcast key chain of length by repeatedly hashing a random value . The successive keys , , are to be used with μ TESLA to protect broadcast synchronization messages. We assume that the reader is familiar with μ TESLA .
The duration of the first time periods , , is fixed by default. The intervals , , are used to exchange the first time samples that allow for RATS initialization and for the first clock estimations. At the beginning of each of these periods the and each node of the BAN, , synchronize and exchange a new time sample , , by using the SPS-SE protocol. In one of these SPE-SE exchanges, the CN sends the last value of the key chain for each BAN member.
Because the clocks are not yet estimated, during time periods , , the CN and each node u of the BAN, , use the short-lasting synchronization method. Note that because of clock drifts, and each node u may need to re-synchronize multiple times during the duration of any period , .
At the beginning of period the CN calculates the first clock estimations , , and initializes RATS for the first time. At the end of the CN and each node u estimate their relative clock offset as follows:
If is below the required accuracy threshold , then RATS is considered to be fine-tuned for the CN and the corresponding node u. Consequently, the CN and the node u complying switch to the long-lasting synchronization method for the following BAN periods.
The nodes not yet complying are to use the short-lasting synchronization method for subsequent BAN periods , , till the condition is satisfied.
In this moment the BAN can have from 0 to n nodes synchronized with the long-lasting method. The remaining nodes, up to the n nodes still use the short-lasting method. This status exists till all the BAN members switch to long-lasting synchronization. For both groups of nodes the subsequent measure of is different. The first adapts the measure of by using RATS. The second keep using the default value of .
Let us refer to the period when one or more BAN members first switch to long-lasting synchronization as . Typically, . Let us use n′ to refer to the BAN members using long-lasting synchronization. In the rest of the section we describe the details of long-lasting synchronization.
Secure BAN long-lasting re-synchronization is performed at the beginning of each period , . By using the SPS-SE protocol, nodes CN and u, , re-synchronize and exchange a new time sample and add it to their respective repository. Additionally, each node u calculates . RATS is employed to periodically recalculate (see Section 4.4.1).
When each and every pair (CN, u), for , of the BAN is synchronized, then BAN time is established.
Since the clocks of CN and u, , drift throughout , the measure of at the end of the period will likely be different at and . To counter this relativistic effect, we define BAN period and node-dependent times of guard (see Figure 1) to be used at the beginning of :
where , is the local identifier of each BAN member and B is the time required to run the SPS-SE protocol in three steps. This method allocates a different time slot for SPS-SE-based synchronization between the CN and a node u.
At the very end of each period the CN calculates , for . Each node calculates .
The CN does not need to contend to access the wireless media. After and each subperiod are exhausted, the CN is the only node in the BAN allowed to start communication. After receiving an initial message from the CN, just the corresponding node u, , is allowed to answer.
4.4.1. Calculation of Optimal Sample Period
By leveraging RATS, the CN calculates the optimal duration for the current period . The pseudocode for the RATS algorithm is as follows:
calculate (,) using a window of samples in (2),
compute using (4),
if , then
else if , then ,
( 6) if , then
else if , then .
Finally, for all u, .
Right after , the CN broadcasts the current period in an integrity-protected message under key . After seconds, for all u, the CN reveals (see Figure 2).
In receiving each node u first validates the authenticity of the key by hashing it and comparing it with the previous stored authentic value . If the validation is positive, then the node stores to be used in the next BAN time period. Subsequently, the integrity of the message containing is verified. Finally, the value is stored for scheduling the next re-synchronization.
4.4.2. Estimation of CN Time
By leveraging RATS, each node u, for , independently calculates with the same pseudocode the CN used (see Section 4.4.1). The node stores the obtained but ignores the obtained . Instead, it will use as next sampling period.
By using the time observations , where in (1) and (2), each node u estimates .
4.5. UTC Synchronization
We propose to securely pairwise synchronize the base station(s) with the CNs to which it is wireless connected using secure pairwise CN synchronization. Additionally, the base station is to be securely synchronized to UTC time by other means (the details of this synchronization means is out of the scope of this paper). Then, a correspondence WSN to UTC is then simple at the base station.