Handling Nodes Mobility and Failure During Bootstrapping in Randomly Deployed Ring-based Wireless Sensor Networks

—Distributed Hash Table (DHT)-based protocols are new approaches proposed to Wireless Sensor Networks (WSN). Their main advantage resides on the easy integration of DHT-based WSN into the Internet Of Things. However, these protocols face multiple challenges in their bootstrapping phase, especially at the case of randomly deployed WSN. We presented in a recent work a bootstrapping protocol for use in DHT-based protocols having the structure of ring in static WSN. However, in most cases, there are some nodes that may fail or move in the network. Bootstrapping should take into account such situations in order to achieve better performance. In this paper, we propose a distributed local recovery method for use in our bootstrapping protocol that allows it to handle efficiently nodes failure and mobility. Simulation results have shown that our proposed approach is able to ensure the local recovery in a timely and energy-efficient manner.


INTRODUCTION I.
The Internet Of Things (IOT) [17] is the future vision of Internet: Internet is no more related to the virtual world but it is extended to our real life. In the future Internet all the objects and area are connected to the internet. Each object is identified with a unique identifier and we can get information about it by sending a query with its identifier. This query will be received by this object even if it has changed its physical position. The communication nature in the Internet of Things is information centric which means that data are identified by keys. When given data need to be retrieved, a query with their corresponding key is sent.
A great part of IOT is made up of Wireless Sensor Networks [1] [2]. Hence, there is a need to conceive protocols that facilitate the integration of these networks into IOT. Distributed Hash Table (DHT)-based protocols [4] and more specifically the protocols having the virtual structure of a ring [5] [6] [10] [11] [12] are suitable solutions to facilitate such integration. Effectively, each node in these protocols is identified with a unique location-independent identifier. All the nodes are organized into a virtual ring with the increasing order of their identifiers. Such structure makes the integration of WSN into IOT, an easy and efficient task.
Also, there are some situation where the WSN cannot be deployed manually such the case of natural disasters and/or hostile supervision. In these cases, sensors are scattered randomly and they should form autonomously their own network without human intervention. It is clear that in such cases, we need the use of autonomous and location independent protocols. DHT-based protocols are autonomous and ensure their functionalities without the need to have any information from any central point in the network. Hence these protocols are well suited to randomly deployed sensors cases.
However, the bootstrapping phase of these DHT-based protocols is so challenging at the case of randomly deployed WSN since all the nodes are scattered simultaneously and start joining the network at the same time. They will then exchange lot of simultaneous messages which leads to interference problems. All these problems lead to multiple inconsistencies. Existing works [8] [9] in this field argue that bootstrapping should contain two phases: In the first phase, all nodes search their places simultaneously and form consequently multiple rings. In the second phase, messages are exchanged between nodes in order to heal all the rings into a global consistent one.
In a recent work [15], we have proposed a bootstrapping approach that avoids concurrent joining and that forms directly one global consistent ring in randomly deployed static WSN. This is ensured by organizing all the nodes into a tree and orchestrating the nodes joining from root to children nodes in a way that at a given time only one node joins the network.
Nodes in WSN are prone to failure. They may fail when scattered or fail due to their energy exhaustion. Also, in most WSN, there are some nodes that can move and change their place during the network bootstrapping. Effectively, even if the total bootstrapping duration is limited, they can be some few nodes that may change their location. For example, at the case of flooding, sensors when scattered in order to collect information about these flooding, are obviously static or move so slowly in the same speed which preserves the same physical neighbors for almost nodes. However, the presence of some physical obstacles, may change the speed of some few nodes leading to a modification in the physical neighbors set. There is hence a need to take into account such situations in order to avoid any inconsistency that could be caused by a node failure or mobility.
In this paper, we propose a distributed local recovery mechanism that can be integrated into our proposed bootstrapping protocol in order to handle efficiently nodes failure and/or mobility in the network.
Our paper is organized as follows. In section 2, we present a general overview of existing ring-based protocols. The related work is given in section 3. We PAPER HANDLING NODES MOBILITY AND FAILURE DURING BOOTSTRAPPING IN RANDOMLY DEPLOYED RING-BASED… specify in section 4 a brief presentation of our bootstrapping protocol. Our proposed improvement to handle nodes failure and mobility is given in section 5. Section 6 specifies the cost of our proposed recovery approach in terms of sent messages number. Section 7 concludes the paper. BACKGROUND

II.
In order to be familiar with the ring-based protocols, we present in this section a short overview of two DHT ringbased protocols: Virtual Ring Routing (VRR) [5] and Scalable Source Routing (SSR) [6].
Virtual Ring Routing A.

Figure 1. Virtual Ring Routing virtual and physical topology
Virtual Ring Routing (VRR) [5] combines DHT and routing functionalities without the need of any underlying routing protocol. VRR is directly integrated on the top of the link layer. VRR nodes identifiers are location independent.
As depicted in figure 1, all the nodes are organized into a virtual ring in an increasing order of their identifiers. Each VRR node maintains in its routing table the next physical hops towards the virtual paths that the current node participated in their setup. It contains also a physical neighbor set containing the identifiers of the physical neighbors in addition to the next physical hops towards the virtual neighbors of the current node. To route a message, the VRR node picks from its routing table the node having the closest identifier to the destination's identifier and forwards the message to its corresponding physical hop.

Scalable Source Routing B.
All the Scalable Source Routing (SSR) [6] nodes should be organized into a global virtual ring. Each node should have a source route to its virtual neighbors. SSR packets contain source address, destination address and source route. The former is not essentially the total route from the source to the destination. It can only be a sub route that ends at an intermediate node. This intermediate node checks its local cache in order to search an appending route to the destination. If this search fails, it appends the source route to the closest node to the destination.

RELATED WORK III.
There are some DHT-based protocols that support bootstrapping in randomly deployed WSN. Iterative Successor Pointer Rewiring Protocol (ISPR) [8] is a simple bootstrap protocol for use in ring-based protocols like SSR [6] or VRR [5]. Each node maintains exactly one and only one successor and predecessor by exchanging Successor Solicitation messages. At the end of this step, multiple consistent local rings are formed. To ensure global consistency, a specified node in each ring floods the network. VRR uses also a similar procedure to ISPR. Flooding the entire network consumes a lot of energy. The linear method [9] shares with ISPR the same steps to reach local ring consistency. However, in order to ensure the global ring consistency, it does not use the flooding step. The linear method assumes that the address space is linear and not a ring. The edges in the virtual graph are undirected. Total ordering of nodes addresses is used in order to distinguish right and left neighbors. To form a global ring, the leftmost node establishes an edge to the rightmost node. The two mentioned approaches require two steps in order to arrive to the steady state: multiple consistent ring formation, then, rings fusion. Our protocol does not need any ring merging since it ensures directly the formation of a global consistent ring. BOOTSTRAPPING IV.

Figure 2. Example of randomly deployed network topology
In this section, we give a brief overview of our proposed bootstrapping approach [15]. All the nodes in our approach are organized into a tree. The root node is the first node that joins the network. When active, its child node having the smallest identifier joins the network and so on. When the current joining node has no more children, it sends a message to its parent that in turn chooses another child node to join the network. Recursively, all the nodes join the network.
Bootstrapping in our approach is divided into rounds. In each round i, there is one active node that broadcasts HELLO messages in order to discover its children and starts a hearing phase. In this step, neighboring nodes that received this HELLO message and that did not have received any HELLO messages from any other node PAPER HANDLING NODES MOBILITY AND FAILURE DURING BOOTSTRAPPING IN RANDOMLY DEPLOYED RING-BASED… during the i-1 rounds are considered as children nodes of this active node. This latter, in turn, is considered as their parent forming hence a tree. The children nodes send to their parent node a HELLO response message at a random time in order to avoid interference problems that can be caused by simultaneous message sending. The active node of a given round stores all the identifiers of its waiting set (the set containing the identifiers of the children nodes) by the increasing order of their identifiers. Then, it sends to the node having the smallest identifier in its waiting set a Permission message. This message allows the destination node to start the joining process. For example at the case of VRR, when this message is received by the child node, it sends a setup request message to its corresponding active node. This latter picks from its routing table, the node having the closest identifier to this new node and forwards the message to its corresponding next physical hop and so on until reaching the node having the closest identifier to the current joining node identifier. This node adds the current joining node to its virtual neighbors set called vset. Then, it responds it by a setup message containing the set of its other virtual neighbors in order to help the joining node finding the other neighbors. Once this setup message is arrived to the destination, the source node is added to the vset of this new joining node then it sends setup request messages to the nodes in the vset field of the setup message. When the candidate nodes respond the new joining node, it becomes well stabilized into the virtual ring and becomes active. This recently active node will start the next round and so on. The first branch in the bootstrapping phase starts by an active node chosen at the PAPER HANDLING NODES MOBILITY AND FAILURE DURING BOOTSTRAPPING IN RANDOMLY DEPLOYED RING-BASED… network startup. The first branch ends when the recently active node does not receive any HELLO response messages from any nodes during its entire hearing step (The first branch in figure 3 is made up of nodes 1, 33, 8  and 4). In such a case, this latter node sends to its parent node a Reallocation message. This message informs the parent node that its first child node has no more nodes to treat. When the parent node receives this message, it removes the source node from its waiting set and chooses from its waiting set, the next smallest identifier and sends to its corresponding node a Permission message. All the steps stated before are repeated until the active node receives a Reallocation message from all its waiting set. At this case, the active node sends to its parent node a Reallocation message in order to choose another child node to start the joining process. All the steps are repeated until the first active node (the root) received Reallocation messages from all the nodes in its waiting set.
When this happens, all nodes in the network are well stabilized into one global virtual ring and reach the steady state. Figure 3 illustrates an example of our proposed bootstrapping scheme for the network given in figure 1. The numbers in black color in the figure 3 depict the order of the nodes that join the network.

NODES MOBILITY AND FAILURE V.
A. Case of homogeneous WSN In this section, we describe the behavior of our bootstrapping protocol at the case of nodes mobility and failure. The key idea is to detect the node departure by neighboring nodes and to try to heal the tree locally and to associate the orphan nodes of a leaving parent to other parents without the need to reconstruct the tree and without causing any inconsistency. In order to detect that a node is no longer a physical neighbor, each node in the network that is already associated to a parent, broadcasts LIFE messages. In order to avoid interference problems, each node starts broadcasting these LIFE messages at a random time. Each node that is already associated and receives this LIFE message, sends an acknowledgement. If the source node does not receive any acknowledgement, it perceives that there is an interference problem.
When an interference is detected, the node rebroadcasts LIFE messages after another random time. This procedure is repeated until no interference is detected. From that moment, LIFE messages are broadcasted each T period from the successful broadcast and so on. The LIFE message contains the source node identifier and the identifier of the source node's parent. Each node that receives this message, adds the identifier of the source node in its physical neighbors set. Nodes that have received a LIFE message from a node whose parent is the same as their parent are considered in the same level. They add the identifier of the source node in their Level set. When the physical neighbors of a given node do not receive any LIFE message from it during two periods of T, they realize that this neighbor becomes unreachable. This can be due to two different reasons: the physical neighbor failed or moved and changed its place. The unreachable node can be not yet active and it can be also active and having children nodes. In the first case, the corresponding parent of the unreachable node deletes it from its waiting set. In the second case, the children nodes of the moving parent can have multiple status: 1. Children nodes have already sent to their parent a Reallocation message: In such a case, the children nodes and their corresponding children have already joined the network, hence they do not need to be associated to another parent. 2. Children nodes have not sent a Reallocation message to their parent. Then, they need a parent to orchestrate their joining process if they have not yet joined the network and to orchestrate the joining process of their children otherwise. In the second case, the orphan node broadcasts a ParentRequest message. This message contains the identifier of the old parent. We assume here that the network is sufficiently dense so that each node A is at least a physical neighbor of a node B having the same level as the parent of A. If there are nodes having received this message and belonging to the same level of the old node that do not have yet sent to their parent a Reallocation message, they will respond this orphan node with a ParentOffer message. When the orphan node receives the first ParentOffer message from a given node, it chooses the source node of this message as its new parent and sends it an Association message in order to become its child. After that, it ignores any other parent offer since it has been already associated to a parent. When the orphan nodes do not receive any ParentOffer message from any nodes, they notice that the other nodes having the same level as their old parent, have already joined the network with their children. They will then broadcast a ParentRequestException message. When the nodes having the same level as the old node, receive these messages, they are aware that the orphan nodes did not find a new parent. They will then send ParentOfferException to these nodes. These latter choose the source of the first received ParentOfferException message as new parent and respond it with an Association message. The parent node PAPER HANDLING NODES MOBILITY AND FAILURE DURING BOOTSTRAPPING IN RANDOMLY DEPLOYED RING-BASED… that receives this message, adds the identifier of the source node in its waiting set and sends to the first active node in the network a PermissionException message. This message is routed using the used routing protocol (for example in our case, this message is routed to the destination using VRR). At the reception of this message, the first active node adds the identifier of the source node in its Additional Waiting set. When this active node receives Reallocation messages from all its waiting set, it sends a Permission message to the first node in its Additional Waiting Set using the appropriate routing protocol. At the reception of this message, the parent node sends a Permission message to the first node in its waiting set and the procedure of bootstrapping already explained is repeated until the waiting set of the parent node becomes empty. When this happens, the parent node sends a Reallocation message to the first active node which allows it to send a Permission message to the next node in its Additional Waiting Set. When the waiting set as well as the Additional waiting set of the first active node become empty, the network reaches the steady state. The node that do not receive any LIFE messages from any node from its physical neighbors set from 2T period of time, realizes that it has been moved from its place. If a moving node is already active, it does not need to be reinserted in the bootstrapping tree. Since it does no longer belong to the tree, it does not respond to any Parent request or Parent Exception request message. The moving node only needs to update the path between it and its virtual neighbors. In most cases, this update can be achieved locally by replacing only the next hops towards its virtual neighbors. If this local repair fails, the path between the moved node and its virtual neighbors is reconstructed. If the moving node has not yet joined the network, it hears LIFE messages from its new physical neighbors nodes. There are different cases that can be presented: 1. There is a neighboring node that is active and that have not yet sent a Reallocation message to its parent. In this case, the mobile node sends a parentRequest message to this node and becomes associated to it. 2. All neighboring nodes are not yet active. The moved node does not receive in such case any LIFE messages. It should then wait for the activation of one of these neighboring nodes in order to be associated to it. 3. All neighboring nodes are active and have already sent Reallocation messages to their parents. Hence, the moved node sends a ParentRequestException message to the closest node to it. The latter node adds the moved node in its waiting set and sends to the first active node a PermissionRequestException. Figure 4 gives an example of a node mobility. When the node 8 moves, its neighboring nodes do not receive from it any LIFE messages during a period T. Algorithm 1 presents the tree recovery process pseudocode and figure 3 summarizes the main tree recovery cases that can occur.
Its children nodes 4, 18 and 56 become orphans. They are not yet active (the joining process is still in step 2 as depicted in the figure). Hence, they will search a new parent. They start broadcasting ParentRequest messages containing the identifier of their old parent, the node 8. Nodes 11 and 91 find the node 8 in their level set. The node 11 sends to the node 4 a ParentOffer message. Similarly, the node 91 sends to the nodes 18 and 56 ParentOffer messages. Evidently, node 11 does not receive the ParentRequest messages that are sent by the nodes 18 and 56 because they are not its physical neighbors as shown in figure 1. When the node 4 receives the ParentOffer from the node 11, it sends it an Association message and becomes its new child. Nodes 18 and 56 become also the children of the node 91. The moving node 8 is in this case already active, hence it is aware that the nodes 1 and 33 are its virtual neighbors. In this case, the node 8 does not need to rejoin the tree. It only needs to update its virtual paths to its virtual neighbors depending on its new position. Taking into account such heterogeneity and especially energy variation, when conceiving a network protocol improves significantly network performance. We have proposed in [18], an energy-aware bootstrapping protocol for use in heterogeneous WSN. The main goal of this approach is to use at most energy powerful nodes in the bootstrapping phase in order to avoid the use of energy critical nodes and preserve their amount of energy. In this protocol, the priority of the joining process is given to energy-powerful nodes as depicted in figure 4. If a node that has not yet joined and is associated to a weak node receives HELLO message from an energy powerful node; it removes its association to the weak node and reassociates itself to the new strong node. This builds an powerful network backbone for use in the routing process. In order to handle nodes failure and mobility in this bootstrapping protocol, we should also take into account nodes heterogeneity. Hence, the orphan node should not be associated directly to the first parent form which it has received a ParentOffer. Instead of that, it starts a timer of 1 second when it broadcast the ParentRequest message. During this time, if the orphan node has received a ParentOffer from an energy powerful node, it is associated to it. Otherwise, at the timer expiration, the orphan node is associated to a weak node since it has not found an energy-powerful parent.

B. Case of heterogeneous WSN
MOBILITY AND FAILURE DETECTION COST VI.
The total bootstrapping phase lasts approximately 20 seconds in a 100-nodes network. Each node should broadcast a LIFE message each 1 second. Hence, each node needs to broadcast 20 messages during the bootstrapping phase. The nodes that detect the node departure need to broadcast ParentRequest messages. Since the bootstrapping period is very short, there is only so few nodes that can change their places during this phase. We assume that the maximal number of moving nodes in the bootstrapping phase is 4. There is on average 2 physical neighbors that are associated to a given parent. Hence, the maximal number of ParentRequest messages is 8 messages. There is also at most 8 ParentRequestException messages. Each orphan node has to be associated to a new parent by sending an Association message. Hence, there are on average 8 Association messages that are sent during the bootstrapping phase. Nodes having the same level as the old parent send ParentOffer and Par! entOfferException messages to the orphan nodes. There are on average 8 orphan nodes. There are hence on average 8 ParentOffer messages or 8 ParentOfferException messages (the nodes that send ParentOffer message to a node do not send it ParentOfferException and vice versa). When the ParentOfferException is accepted, the new parent sends PermissionException message. The maximal number of PermissionException messages is 8. The active node responds by at most 8 Permission messages. The total number of messages needed to detect a failure or a mobility and recover the bootstrapping tree is at most 2048 messages.

SIMULATION VII.
In order to investigate the feasibility of our proposed mobility support scheme in the bootstrapping phase, we have used simulations on NS2 [13]. We analyzed the behavior of the physical neighbors in order to recover the bootstrapping tree at the case of nodes mobility and/or failure. The basic configuration simulates 50 nodes distributed randomly over 100 m*200 m plane. We vary the number of simultaneous mobile nodes in the network and measure the time and the energy needed by the neighboring nodes to recover locally the tree without the need of whole reconstruction. It is clear that when a node has no children or has an empty waiting list, its neighboring nodes do not need to exchange any messages and need only to delete the moved node's identifier from the physical neighbors list. That's why we have chosen the time of the nodes mobility in a way that the mobile node has already some children in its waiting set in order to study the reassociation process of these children nodes to new parents.   Figure 6 measures the total amount of consumed energy at the recovery phase. Evidently, this amount increases slightly when the number of mobile nodes increases PAPER HANDLING NODES MOBILITY AND FAILURE DURING BOOTSTRAPPING IN RANDOMLY DEPLOYED RING-BASED… because the number of exchanged messages to recover the tree increases as well. However, it is clear that the total consumed energy is so limited. CONCLUSION VIII.
In this paper, we have improved our bootstrapping protocol in order to take into account nodes mobility and failure cases. Nodes detecting the failure or the movement of a node, try to heal the tree locally and in a totally distributed manner without the need to reconstruct all the tree. This ensures ring global consistency and avoids time and energy wastage of global tree reconstruction.