In this section, we present detail operation method of the proposed two-way collaborative neighbor discovery algorithm, COND, for DSNs. Each COND node tries to explore maximum number of neighboring nodes in different sectors. A COND node stays in each of its sectors for a particular time duration and performs direct and indirect neighbor discovery processes using polling mechanism. Unlike [11, 13, 30], we allow COND nodes to dynamically vary the time duration operating in a sector based on percentage of its neighbors already discovered. Furthermore, unlike in our previous work [14], we allow COND nodes to explicitly track the neighbors discovered indirectly and take actions differently, facilitating to increase the neighbor discovery performance. In summary, the COND mechanism is condensed into the following three steps:
-
Initialization of neighbor discovery with appropriate value of a delay tuning parameter (\(\mathcal {K}\))
-
Discovery of neighbor nodes in different sectors using contention-based polling mechanism
-
Maintaining and updating the neighbor tables of COND nodes in collaborative fashion
What follows next, we present the detail operations of the COND steps.
Initialization
Each node in the network first calculates the approximate number of neighbors around them after the deployment of the nodes in the network. The expected number of neighbors of each node can be calculated as
$$ E_{n} = \rho \times \pi \times r^{2}, $$
(2)
where r is the communication radius of a sensor node and ρ is the node deployment density. Then, the expected number of neighbors in a particular sector \(m \in \mathcal {M}\) of a node is given by
$$ \mathcal{N}_{e}^{m} = \frac{E_{n}}{|\mathcal{M}|}. $$
(3)
Initially, each sensor node \(s \in \mathcal {S}\) starts to explore neighbors in all of its sectors \(m \in \mathcal {M}\) by switching its direction clockwise after a certain interval of T seconds. T is the time interval for staying in a particular sector of each node. As we are assuming that each node switches its sector one by one for neighbor discovery, it is necessary to stay in a particular sector for a certain period so that two nodes can steer their antennas to each other in that period. Hence, T depends on the number of sectors of a node and the delay incurred for switching a direction, and it is determined as follows:
$$ T = T_{\text{switch}} \times (|\mathcal{M}|-1) \times \mathcal{K}, $$
(4)
where T
switch is the switching delay and \(\mathcal {M}\) is the set of sectors. Furthermore, when a good number of nodes are discovered in a particular sector of a node, it must stay less period of time over there so as to reduce the discovery overhead. On the other hand, when a node has discovered very less number of neighbors in a sector, it must stay longer period in that particular sector in order to reduce the discovery latency. Thus, for determining the value of time period T, we introduce a delay tuning parameter \(\mathcal {K}\) that is updated after each iteration depending on the number of discovered neighbor nodes in a particular sector as follows:
$$ \mathcal{K} = \delta_{m} \times \mathcal{K}, $$
(5)
where the value of δ
m
is chosen in such a way that the discovery latency in each sector \(m \in \mathcal {M}\) is minimized. If a node discovers most of its neighbors in a given sector \(m \in \mathcal {M}\), then it is wise for the node to stay for less period of time there and vice-versa; otherwise, discovery overhead will unnecessarily be increased. Thus, the value of δ
m
helps us to dynamically control the staying period of a sensor node in a certain sector \(m \in \mathcal {M}\) for neighbor discovery. Let \(N^{m}_{d}\) represents the percentage of nodes that are already discovered in sector \(m \in \mathcal {M}\), then the value of δ
m
is determined as follows:
$$ \delta_{m} = \left\{ \begin{array}{ll} 2.0, & N_{d}^{m} \le 30\%, \\ 1.5, & N_{d}^{m} \le 50\%, \\ 1.0, & N_{d}^{m} \le 80\%, \\ 0.5, & N_{d}^{m} > 80\%. \end{array} \right. $$
(6)
Note that the numerical values in Eq. (6) are not strict choices; rather, the values are depicted through numerous simulation experiments for a given network environment (stated in Section 6), and they are tunable by the network administrator. In the case the number of already discovered nodes in a certain sector crosses the expected number of neighbors, the node may stop staying in that sector. Hence, it may happen that a node misses a good number of neighbors to discover if the calculation of expected number of neighbors is incorrect (due to distortions in deployment). Therefore, we allow a COND node to continue the discovery process until it fails repeatedly (say, up to two iterations) to find a new neighbor in a particular sector.
Contention-based polling mechanism
The COND nodes contend among them to poll their neighbors in different sectors so as to discover those. The frame structure followed by the polling mechanism contains ‘H’ (Hello) and ‘L’ (Listen) slots, as shown in Fig. 2
a. In H slots, a node broadcasts HELLO messages in random time slots with persistent probability P
t
. In the remaining slots, the node listens to the medium for any HELLO message from the neighboring nodes.
Each slot is further divided into several mini sub-slots, as shown in Fig. 2
a. If a node decides to transmit a HELLO message in a slot, it does so in the first mini-slot and listens to the channel for any REPLY message(s) from its neighboring node(s). The HELLO message contains the node’s ID, (x,y) coordinate, sector number, and neighbor table, i.e., \(\Gamma _{H} = \{ID,\ \text {coord}(x,y),\ m,\ \mathcal {T}\}\). On reception of HELLO message, the surrounding nodes update their neighbor tables and relay back their information in a randomly chosen mini-slot. Thus, the nodes develop their neighbor tables for each sector with so far discovered nodes. The structure of the neighbor table is represented by the tuple, \(<ID, \text {coord}(x,y), m, \mathcal {F}>\), where the fourth field is a flag that contains 1 if the designated neighbor is discovered through direct exchange of messages and 0 if it is discovered indirectly. The details of direct and indirect discovery processes are discussed in the following section.
Collaborative discovery of neighbor nodes
The key challenge in reducing neighbor discovery latency in DSNs is the synchronization of HELLO-REPLY transmissions among the nodes in a neighborhood. Therefore, in addition to discover neighbors through direct exchange of messages, we allow COND nodes to share their neighbor tables with each other and to update their tables collaboratively so as to further decrease the discovery latency. Thus, some neighbor nodes are discovered indirectly (via other nodes).
Direct discovery
When two nodes are beamformed to each other and successfully exchange HELLO and REPLY messages, they can directly discover each other. After the HELLO-REPLY handshaking, two nodes update their neighbor tables accordingly. Thus, it is highly dependent on the synchronization of corresponding sectors of two neighbors. In Fig. 2
b, when the node a discovers a neighbor node b through direct handshaking, the flag entry for b in a’s neighbor table is set to 1. Unlike existing works in the literature that depend only on direct discovery, we allow indirect discovery of neighbor nodes through collaboration among them.
Indirect discovery
In omnidirectional communication, only direct discovery is sufficient for neighbor discovery. For directional nodes, it is the most important that two nodes are beamforming their antennas to each other; otherwise, the handshaking between the nodes would never occur. So, it may happen that when a node is broadcasting HELLO message in a particular sector, some of the neighbor nodes cannot receive the message because of the deafness problem [9]. Hence, the strict requirement of directional synchronization among nodes upsurges the discovery latency among the sensor nodes.
Consider a scenario in Fig. 2
b, where pairs a and b and a and c have already discovered themselves in the present or previous time frame, but node b has not yet been discovered by c or vice-versa, as their antenna directions did not match during the direct neighbor discovery process. In order to ease the problem and to accelerate the discovery process, we allow COND nodes to share their neighbor tables with already discovered nodes. That is, node a shares its table with b and c so that they can discover each other as a neighbor of the respective sectors by checking their coordinates. We term this update of neighbor table as indirect discovery, and the flag entry for such discovered node is set to 0.
The proposed collaborative neighbor discovery (COND) mechanism has been summarized in Algorithm 1. Initially, the neighbor table of each node remains empty. After getting a HELLO/REPLY message from any neighbor, a node updates its own table (lines 6–23). The node that receives a HELLO message checks its neighbor table to find whether the node is discovered earlier or not. If there exists a record, the node checks the flag value and if the value is 1, it does not give any REPLY message to that node assuming that it has exchanged messages in the earlier slots with that node; otherwise, it updates the information in the neighbor table and sends a REPLY message in a random sub-slot to the direction of the sender node (lines 15–22). If the sender node receives a REPLY message (without any collision) from any neighbor, it adds the node in the neighbor table (lines 8–12). In this way, two nodes discover each other using two-way handshaking. In the case, a node cannot discover any new node in a certain sector in consecutive two iterations, we stop COND process in that sector (lines 25–27).
The time complexity of Algorithm 1 for one iteration is quite straightforward to follow. The lines 1–31, enclosed in a loop, iterate \(|\mathcal {M}|\) times having a complexity of \(\mathcal {O}(|\mathcal {M}|)\) in the worst case. Again, the statements 4–23 iterate |T| times in a nested loop. The rest of the statements have constant unit time complexities. Therefore, the overall time complexity of the proposed COND algorithm is \(\mathcal {O}(|\mathcal {M}| \times |T|)\).