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.
-
(1)
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.
-
(2)
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.
-
(3)
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
d
and an initial optimal window size W
d
. Once deployed, starting from the beginning of BAN existence, the nodes exchange W
d
time observations, each sample separated by S
d
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
d
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 [4]. 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)):
-
(1)
,
-
(2)
, MIC2
-
(3)
, MIC3,
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 [4]:
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
u
and CN
v
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:
-
(1)
compute
,
-
(2)
calculate (
) using a window of
samples in (2),
-
(3)
compute
using (4),
-
(4)
compute
,
-
(5)
if
, then 
else if
, then
,
-
(6)
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 [8].
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:
-
(1)
compute
,
-
(2)
calculate (
,) using a window of
samples in (2),
-
(3)
compute
using (4),
-
(4)
compute
,
-
(5)
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.