Reaching Trusted Byzantine Agreement in a Cluster-Based Wireless Sensor Network

Abstract

A wireless sensor network (WSN) consists of spatially distributed autonomous devices which use sensor nodes to monitor physical or environmental conditions cooperatively. Currently, WSNs are expected to be integrated into the internet of things (IoT), where sensor nodes join the internet dynamically and collaborate to accomplish their tasks. In the application of the IoT, WSNs can play an important role by collecting surrounding contextual and environmental information. However, ensuring a stable and reliable topology is an important issue with regard to WSNs. To cope with the influence of faulty components, it is essential to reach a common agreement in the presence of faults, before performing certain tasks. However, the Byzantine agreement (BA) problem is a fundamental issue in fault-tolerant distributed systems. To enhance the fault tolerance and reliability of the WSN, the BA problem in the cluster-based WSN (CWSN) is revisited in this study. The proposed protocol can achieve agreement on a common value among all functional nodes in a minimal number of message exchange rounds, and can tolerate a maximal number of allowable faulty components in the CWSN.

Appendices

Appendix 1: Manchester Encoding

Manchester encoding is a synchronous clock encoding technique used by the OSI physical layer to encode the clock and data of a synchronous bit stream [11]. In this technique, the actual binary data to be transmitted over the cable are not sent as a sequence of logical 1’s and 0’s. Instead, the bits are translated into a slightly different format that has a number of advantages over using straight binary encoding. The rules of Manchester encoding are shown in Table 1.

Table 1 The rules of Manchester encoding

Figure 5 shows a typical Manchester encoded signal with the corresponding binary representation of the data (1,0,1,0,0,0) being sent.

Fig. 5

The waveform for a Manchester encoded bit stream carrying the sequence of bits 101000

In the Manchester encoding shown, logic 0 is indicated by a 0 to 1 (upward transition at bit centre) transition at the centre of the bit and logic 1 is indicated by a 1 to 0 (downward transition at bit centre) transition at the centre of the bit [11].

Due to the fact that a crash fault happens when a component is broken, in such a case, the component would not send any signal to the receiving processor. An omission fault occurs when a component fails to transmit or receive the signal on time or at all. A stuck-at fault occurs when the signal from a certain communication medium is constant. Therefore, a healthy processor can detect crash faults, omission faults, and stuck-at faults caused by the faulty components if the protocol encodes a transmitted message via the Manchester code before transmission.

Appendix 2: The Message-Gathering Tree (mg-tree)

Figure 4d shows an mg-tree for the CWSN model shown in Fig. 4a. Each healthy node maintains such an mg-tree during the execution of TAP. In the first round, the source (node $n_{s}$) multicasts its initial value to each cluster’s nodes by TTCB through TTCB control channel. When healthy node receives the value sent from the source, it stores the received value, denoted as $\hbox {val}(s)$, at the root of its mg-tree as shown in Fig. 4b. In the second round, each node multicasts the value stored in the root of the mg-tree to each cluster’s nodes (except the source node) by TTCB through TTCB control channel. If the node $n_{1}$ sends message $\hbox {val}(s)$ to the nodes in cluster $C_{4}$, then the nodes in cluster $C_{4}$ stores the received value from node $n_{1}$, denoted as $\hbox {val}(s4)$, in vertex $s4$ of its mg-tree, which is shown in Fig. 4c. Similarly, if the nodes in cluster $C_{2}$ sends messages $\hbox {val}(s1)$ to the nodes in cluster $C_{1}$, then the value is denoted as $\hbox {val}(s12)$ and stored in vertex $s12$ of node $n_{1}$’s mg-tree in the third round, which is illustrated in Fig. 4d. The $\hbox {val}({\upalpha }i)$ tells that the message is sent to a series of receivers, denoted as $\upalpha$, and the nodes in cluster $C_{i}$ are the latest receivers. For instance, the message $\hbox {val}(s1{\ldots }4)$, stored in the vertex $s1{\ldots }4$ of an mg-tree, which implies that the message just received was sent through the source, the nodes in cluster $C_{1}$, the nodes in cluster $C_{4}$ (the nodes in cluster $C_{4}$ is the latest nodes to pass the message). And it is denoted as $\hbox {val}(\upalpha 4)$. When the message is transmitted through the nodes in cluster more than once, the name of the cluster will be repeated correspondingly. For example, $\hbox {val}(s11)$, stored in vertex $s11$ of Fig. 4d, indicates that the message is sent from $s$ to the nodes in cluster $C_{1}$, then to the nodes in cluster $C_{1}$ again.

In summary, the root of an mg-tree is always named $s$ to denote that the stored message is sent from the source node in the first round, and the vertex of an mg-tree is labeled by a list of cluster names. The cluster name list contains the names of the clusters through which the stored message was transferred.

Appendix 3: The Information-Collecting tree (ic-tree)

An ic-tree is reorganized from a corresponding mg-tree by removing the vertices with repeated cluster names in order to reduce the influence from a faulty node repeatedly in an ic-tree. Figure 4e is an example of reorganizing an mg-tree to an ic-tree by deleting the repeated cluster names of mg-tree.