BackBone Selecting Procedure

In the first phase of SmartBone as we previous presented, neighborhood information is collected and recorded into the neighbor list. In the second phase of SmartBone, critical nodes are selected as backbone seeds. The backbone seeds in the

network topology include the sensor gateways and the critical nodes selected via FlowBP. Subsequently, backbone selection algorithm starts from these seeds in the third phase of SmartBone. According to the priority of nodes, some high priority nodes are picked out as backbone nodes, and some nodes are eliminated as redundant nodes via DDC. The following is the selecting and cutback procedure described in detail.

In the backbone selecting procedure, backbone seed checks its 1-hop neighbor list, and the neighbor node with maximum priority is picked out. However, disregarding the priority, the nodes with degree = 1 would not be the candidates for the coordinators. The reason is obvious that these kinds of nodes are on the edge of network and can not provide relaying service to other nodes. The selected nodes are placed in the backbone set and deleted from the neighbor list. The DDC procedure is then performed to determine whether two nodes have a redundancy relationship. At this moment, the nodes too close to the backbone node are deleted from the neighbor list. The selecting process is repeated until the neighbor list is empty and neighbor nodes are either chosen to the backbone set or deleted due to the redundancy.

Subsequently, final result of the backbone set is then broadcast to the neighbors.

All 1-hop neighbors receive the message, and check whether they are in the backbone set. If a node finds itself in the backbone set, then it knows that it has been chosen as a backbone node, and changes its state to backbone and starts to relay passing packets.

Simultaneously, the selected backbone nodes continue with the selecting procedure to extend the backbone as backbone seed performs described above. Conversely, if a node cannot find its ID in the backbone set, then it knows that it has not been chosen to be a backbone node. Such situation happens due to the node’s priority is not high enough, or the node itself is too close to other backbone nodes. Noticeably, regular operations of redundant nodes such as sensing and processing data can be switched on.

However, their radio can be turn off to save the energy consumption. It is always helpful to lower the interference with proper number of nodes relaying packets.

Usually a node waits for a random time period before forwarding the packet to the next hop. Too many nodes relaying packets increase the possibility of two nodes waiting for the same time slot, thus causing the data collision.

Redundant nodes must be deleted. Haitao Liu and Rajiv Gupta in [6] determine whether nodes are too close to each other by checking whether the proportion of common neighbors exceeds a threshold. However, this method is not satisfactory.

Decisions must be made based on the network condition. SmartBone adopts a

procedure called Dynamic Density Cutback (DDC). The rules are tightened for dense topologies, meaning that more nodes are deleted (i.e., more nodes are considered too close). On the contrary, the rules are loosen for sparse topologies, meaning that fewer nodes are deleted for being too close to each other, in order to maintain an acceptable network performance even under poor network conditions such as a sparse topology.

Therefore, multiple levels of threshold called CUT_TH are set, and are utilized in DDC to determine how many nodes are deleted. A CUT_TH value of n means if the number of different neighbors of two nodes is less than or equal to n, then they are too close. CUT_TH can determine the acceptable level of closeness. For instance, consider two nodes, named node-k and node-m, and k is a backbone node. The goal is to determine whether m is too close to k. If CUT_TH is set to 0, which means if all neighbors of m are subset of neighbors of k (i.e. the number of different neighbors = 0), then m and k are said to be too close, and m is therefore deleted. Otherwise, m and k are not too close, and m may be chosen as the coordinator or deleted by other coordinators later. If CUT_TH is set to 2, then if m’s neighbors include more than two nodes that are not among the neighbors of node k, then m and k are not too close and hence m is chosen as the backbone node; otherwise, m and k are too close and m is deleted.

Although a sensor network is deployed with an even distribution fashion, network density still could be different from one local area to another due to the different geographic areas and different ways of node deployment. Therefore, we further define a local node density. Node degree is used as the indicator of local node density. Therefore, local node density can be easily obtained from collected neighbor information. The levels of CUT_TH values are determined according to granularity of local node density. For example, n levels indicate n−1 local node density boundaries and n different CUT_TH values. A larger n implies that a more detailed local node density granularity can be distinguished. In practical, we have demonstrated that choosing three levels works best, so our simulation used three different local node density intervals corresponding to different CUT_TH.

A practical example is given to explain how DDC works. If network designers deploy sensor networks with higher average network density (e.g. the average network density = 20). Three levels were applied, and the density boundaries of these three levels can be set as 15 and 25 respectively, as shown in Table II(a). CUT_CH1 was therefore applied to the nodes with local node density less than 15; CUT_CH2 was applied to the nodes with local node density between 15 and 25, and CUT_CH3 was applied to the nodes with local node density more than 25. Table II shows the

CUT_TH and local node density boundary used for different average network density during simulation. Each node maintains table 2 and operates DDC accordingly.

Table II. CUT_TH and boundary of local node density used during simulation Local Node Density < 15 15 ~ 25 > 25

CUT_TH 0 5 10

(a) Average network density = 20

Local Node Density < 8 8 ~ 25 > 25

CUT_TH 0 4 8

(b) Average network density = 15

Local Node Density < 10 10 ~ 25 > 25

CUT_TH 3 5 8

(c) Average network density = 10

Local Node Density < 5 5 ~ 25 > 25

CUT_TH 3 8 8

(d) Average network density = 8

(a)

(b)

(c)

(d)

Fig. 2. Example of SmartBone construction

A simple example is given below to illustrate the operation of SmartBone. The backbone seeds in the network topology include the sensor gateways and the critical nodes selected via FlowBP. Figure 2(a) shows the initial topology state. SmartBone would then perform the FlowBP procedure, which finds the critical nodes from the entire topology. Critical nodes are fragile components of the network structure, so must be selected as backbone nodes. Figure 2(b) shows that node-d and node-e are critical nodes. The DFS_PRED of node-e is less than the threshold, so node-e and its correspondent, node-d, are chosen as critical nodes. The coordinators (including the critical nodes just selected) continue with backbone selecting procedure, and the neighbors of the coordinators are considered as potential candidates for the new coordinators. As shown in Fig. 2(b), node-a, node-b and node-c are on the edge of the network topology, and do not help extend the backbone. Therefore, SmartBone algorithm would not choose them as coordinators. In Fig. 2(c), assume the priorities of node-g and node-i are higher than those of other neighbors of the coordinator, so they are chosen as backbone nodes. The DDC procedure is then performed. Node-f and node-h are removed from the DDC procedure because they are too close to the selected nodes, node-g and node-i. The selection procedure is continued with node-g choosing node-j until the algorithm is completed. Figure 2(d) displays the final result.