Adaptive nodes algorithm to solve the orphan nodes problem in a ZigBee Tree WSN

We have developed an algorithm based on hybrid nodes composed of an XBee S2C module configured in API mode with escape and connected to a microcontroller ATMEGA 328P to solve the orphan node problem of a ZigBee tree topology. The sensor nodes have both features End Device and Router that may alternate depending on the situation, and the node can adapt itself to keep the network integrality as much as possible. On the other hand, the coordinator node comprises an XBee S2C module and the embedded system Raspberry Pi 3, which hosts the algorithm and is set up as an access point, a database server, and a web server. Using the proposed algorithm, we were able to recover up to 42.8% of the network coverage, but it comes with an energy cost due to the switch from End Device to Router. Additionally, a mobile application integrated with notification service and Google Maps was developed to monitor every node’s behavior in the Wireless Sensor Network.


INTRODUCTION
Wireless Sensor Networks (WSN) typically consists of sensor nodes deployed in some area to achieve certain goals. Each node is equipped with a transceiver for communicating with neighboring nodes and a microcontroller for storing and processing data [1].
A common protocol in WSN is ZigBee, which supports three types of nodes, ZigBee Coordinator (ZC), ZigBee Router (ZR), and ZigBee End Device (ZED). The ZC is the central node responsible for establishing and managing the network and other functions such as security and general operation. The ZR has all the functionalities of the ZigBee protocol. It can join the network for sending, receiving, and routing information to the coordinator node. ZED has the same functions as the routers but has no routing feature; it is mainly responsible for uploading data collection to the coordinator node with lower energy consumption than a router.
ZigBee networks can be constructed into pair topology, star topology, and mesh topology to give the network its structure, as shown in Figure 1. The three network structures could be combined into the cluster tree topology to expand the network's coverage scope [2].
WSNs have been utilized over the years around the world for data collection in several fields. In China, Jiang et al. [3] used the ZigBee technology for a smart home system with an Android app to control and monitor real-timely household devices and the house's environment. In Turkey, Kabalci & Kabalci [4] worked on a metering and monitoring system for solar string inverters using ZigBee technology to transmit the measured current, voltage, and power to a host PC. In Taiwan, Chou et al. [5] implemented a WSN with biosensors, XBee modules, Arduino Mega, and a computer to monitor Glucose and Lactate using LabVIEW software. In Pakistan, Ali et al. [6] designed a WSN monitoring platform for the oil and gas pipeline using a custom sensor board named SimpliMote and a graphical user interface that can run on a Windows or Linux platform. In general, there are many applications where the WSNs can be used, and therefore, there is a necessity to develop new techniques to improve their efficiency and robustness.
To optimize this type of networks' behavior and efficiency, some algorithms and strategies have been proposed in the literature. For instance, in [3], the authors used a Genetic Algorithm-Particle Swarm Optimization Algorithm (GA-PSOA) to enhance the network's routing for searching for the optimal route with fast speed improving the response rate and energy consumption of the nodes. In [6], a network algorithm has been proposed for a Linear WSN (LWSN) that finds the neighbor nodes and relies on RSSI (Received Signal Strength Indicator) measurements to map each node looking for the best RSSI along with the hop count to reach a gateway node. Also, if there is some network failure, a message is broadcasted, and it will start the networking process to repair the LWSN. In [7], to improve the system lifetime in a network, the authors developed a protocol architecture named Low-Energy Adaptive Clustering Hierarchy (LEACH) for avoiding "hot spots" in the network using the randomized rotation of the cluster head positions taking into account the energy level of the node; in this way, the node with higher energy has a higher probability of becoming a cluster head. By using LEACH, the energy in the network will be balanced, and its lifetime will increase. Other frameworks have been applied to the LEACH protocol to improve its functionality, such as the Virtual Field Force framework (LEACH-VF) to maximize the coverage of the network [8]; the K-LEACH-VF protocol to improve the energy balance of the network [9]; and, the LEACH-SP protocol to improve the covered area and the network lifetime [10]. Furthermore, in [11], an adaptive routing optimization technique is proposed to update the ZigBee hierarchical structure in real-time to route the information through the optimal path for energybalancing. To reduce the congestion in a WSN based on ZigBee technology, Ullah & Youn [12] proposed a routing algorithm called Statistical Multipath Queue-wise Preemption. The purpose of the algorithm is to avoid the overload of some nodes and prioritize the packets based on their type by scheduling statistically multiple paths to improve the network's performance.
In all these cases, there are chances of some faults to occur. The faults may occur due to compromised sensor nodes, exhausted batteries, or harsh environments [13]. When a failure occurs, the network will have holes, and its overall integrity might be compromised. If the failure of a ZR produces a hole in the network as depicted in Figure 2, then the children nodes of that ZR would lose communication becoming orphan nodes. If there are no paths to transmit information, then the proposed routing algorithms mentioned before might not repair the network, and the coverage of the network will decrease. Some solutions have been proposed by managing addresses in the network and modifying the connection of joining nodes and their potential parents [14,15,16,17] to solve the orphan nodes problem; also, in [18], Yang, Xu & Qiu proposed an algorithm to transform ZED into ZR by pressing a button. We present a solution based on hybrid nodes in this work, where the sensor nodes have both features, ZED and ZR. With this approach, if some fault occurs, the nodes are capable of switching from a ZED to a ZR and vice versa automatically. Moreover, with this algorithm, we can detect possible failures in the network and generate an alert notification as soon as possible using an Android mobile application, which was also designed to monitor the WSN.

Nodes architecture and setup
Sensor nodes (ZED and ZR) are composed of an XBee S2C module configured in API mode with escape and connected to a microcontroller ATMEGA 328P which performs the changes in the node configuration according to the proposed algorithm and takes measurements from environmental sensors. Five environmental variables were considered (temperature, humidity, soil moisture, UV light, and visible light intensity) in the crop, and the data are wirelessly transmitted using ZigBee technology. The Li-Po battery provides electric energy to the nodes to guarantee an autonomy of at least 14 days (actual energy consumption varies according to sleep time mode and operating conditions). The microcontroller processes the sensors' data and transmits the information of the variables to the Coordinator through the XBee module using the ZigBee protocol. Figure 3a shows the Sensor nodes, and 3b shows one of the nodes placed on the cocoa crop tree. To switch between ZED and ZR, we used the AT command SM (Sleep Mode), where "1" is to set the node as ZED and "0" as ZR; depending on this parameter, the microcontroller executes a specific code.
Having said that, the timeout must be set up to an appropriate value; if it is shorter than the sleep time, the end device will be disassociated from the network before it wakes up; but, if it is too long and the end device needs to change parent, it will not be able to do it, because the child table will not change on time. To set up this time, we established the parameters SP (Sleep Periods) and SN (Sleep Number of Cycles) to 0 x 68 (104) and 0 x 28 (40), respectively. By replacing these values into equation 1, the timeout is set to 124.8 seconds. The sampling rate is 12 seconds; thus, the ZED is going to be in the child table at least for 10 cycles before it is disassociated, and it has to scan the network again, looking for a new parent.
To test the proposed algorithm, we used the ZigBee tree topology (see Figure 4), which has more coverage and can be expanded to a bigger network. The WSN has been deployed on a cocoa plantation. It is an NLOS (No Line of Sight) scenario, and to properly operate, the maximum distance between nodes is 40 m.

Embedded system and data base
The collected information of all the sensor nodes is stored in a database hosted on the Raspberry Pi 3 (RPi3) embedded system, responsible for receiving the information from the sensor network using an XBee module connected through a serial port. The RPi3 and the XBee module work together as the network Coordinator node and use the Zigbee protocol to receive the information.
The Raspberry Pi 3 model B has an interpreter for Python programming language. An algorithm in Python for processing and storing the data originating from the XBee modules was developed; the database where the data is stored requires the Structured Query Language, which is interpreted and organized by MySQL database manager. We developed a service to allow queries through Web ports using PHP language; this service allowed us to make GET queries to the database and allowed the responses to be interpreted and schematized. For that, relational tables are implemented in an Apache and MySQL server to structure the information, thus avoiding data redundancy and containing the main information about the nodes, as shown in Table 1.
The RPi3 was configured as an access point using its integrated module 802.11 n, a DHCP server, and user validation. In this way, the embedded system establishes its Wi-Fi network so that the mobile application can connect to it.

Behavior of the nodes
The consumed current was measured using an oscilloscope connected to a 1 Ω resistance in series with the node to analyze the network sensor nodes' behavior.
The sampling rate for ZED is 10 seconds. A functional ZED associated with the network behaves as shown in Figure 5, where the average awake time is 440.94 ms, and the mean current is 10.88 mA. On the other hand, a ZED disassociated to the network behaves as shown in Figure 6, and the mean current is 21.88 mA. In contrast to ZED, ZR does not operate in sleep mode because a ZR must listen to its connected nodes all the time. Therefore, a ZR node consumes 40 mA on average, regardless if it is connected to the network or not, as shown in Figure 7.

PROPOSED ALGORITHM
The main purpose of the algorithm is to keep the integrality of the original network topology based on the status a node might have. Such statuses are enumerated according to the situation that occurs. We have established the following cases.
(0) Not functional. It occurs when a node has lost communication with the network, and there are no near end devices with a status different from 0. (1) Functional. When a node is working with its original settings. (2) Possible Fail. It occurs when a node has lost communication with the network, and there is at least one near-end device with a "Functional" status (1). (3) Trying to restore. It occurs when the node is with a status of "Possible Fail" (2), and there is at least one near node whose status is "ZED turned into ZR" (4). (4) ZED turned into ZR. When an original ZED is turned into ZR to re-associate a near ZED with no communication.  (5) ZR turned into ZED. When an original ZR is turned into ZED because it has no children.
As for energy consumption, considering the analysis made in the previous section, a ZR consumes 40 mA in every status, a ZED consumes 10.88 mA if the status is either 1 or 5, otherwise, it consumes 21.88 mA.
Depending on the problem in the network, there are different strategies to deal with it. We classified these problems as four main cases, and then, we analyzed the coverage and the energy consumption of each node based on the experimental data described in the previous sections.

Case I. ZR loses communication with the WSN. Restoration of ZED
In Figure 8, if N2 loses communication, then N4 and N5 will lose their parent, and the network would have lost three nodes. However, with the proposed algorithm, the network will attempt to recover the lost nodes as follows (see the stages in Figure 8). 1) The network is working with all of its nodes. 2) N2 loses communication, so N2, N4, and N5 change their status to 2; after that, the embedded system selects the closest node to the coordinator with no communication, in this case, N2. The algorithm then looks for ZEDs close to that node with status different to 0 and different to its original children nodes in case of being a ZR; if there are no close end devices, then the node changes its status to 0 as occurred with N2 in Figure 8. After that, if the node cannot be restored, then the algorithm tries to restore the next closest one. 3) There are no functional end devices close to N4 but, N5, whose status is 2, could rejoin the network. N6 is a functional ZED close to N5 so, it is turned into a ZR and tries to become the parent  of N5 to restore it to the network. 4) The just recovered N5 turns into a ZR and tries to restore N4 to the network. Table 2 shows the parameters per node in every stage; in the end, the network consumes more current than the original topology, but after the fault in N2, it is working with two more nodes. Thereby, the WSN will work with five nodes instead of three, restoring 33.33% of its integrity.

Case II. ZED turned into ZR with no children nodes
In step 3, if for some reason N5 does not connect to N6 as shown in step 2.1 in Figure 9, then: 2.2) N6, whose status is 4, will be turned back into ZED and change its status to 1 because it has no children nodes. Also, N5 will be considered as a not functional node and change its status to 0. 2.3) Thus, there are no end devices close to N4, so it will also be considered as a not functional node.   As shown in Table 3, if the algorithm fails in restoring a node, the current is going to rise unnecessarily. This can be seen in stage 2.1, where the current rises from 145.52 mA to 174.64 mA because of the amount of ZRs in the network; thus, the algorithm keeps the original configuration of the nodes consuming once again 145.52 mA as in stage 2.3.

Case III. ZR restores communication with the WSN
Taking step 4 as the starting point, the algorithm will work as follows: 5) N2 restores communication with the coordinator. 6) The original children nodes of N2 (N4 and N5) with status 5 will turn back into end devices. So, N4 loses communication with N5 and looks for a new parent, becoming N2's child again. 7) The current parent of any original child node of N2 turns into ZR again if it is not the parent of another node and its status is 5. So, N6 turns into ZED, and N2 becomes the parent of N5 again. Hence, the network will re-establish its original configuration, as depicted in Figure 10.
In step 5 the network is completely functional, but it is composed of four ZRs and two ZEDs consuming  Table 4; in contrast, in step 7 the network is composed of two ZRs and four ZEDs, reducing the consumption to 123.52 mA because the adaptive algorithm tries to keep the original topology as much as possible.

Case IV. ZR loses communication with the WSN. With restoration of ZR
If the network is larger, as shown in Figure 11, then the algorithm works in the same way. For instance, in this case, the WSN will behave as follows: 8) The network is working normally with all of its nodes. 9) N2 loses communication with the network, and therefore, its whole branch loses communication too. Thus, the network loses N2, N4, N5, N8, N9, N12, and N13, whose statuses change to 2. Thereby, the WSN is working only at 50% capacity.
10) The algorithm selects the closest node to the coordinator, being N2 in this case, and search for near ZEDs different to its original children with status different to 0. Again, as in step 2 shown in Figure 8, N2 has no near functional ZEDs; so, the algorithm looks for the next closest nodes, N4 has no near functional ZEDs either, but N5 does have Figure 10. Case III.

MOBILE APPLICATION
The mobile application was developed in Android Operative System following the proposed Android developer's community methodology. Using async tasks the mobile device can connect to the RPi's Wi-Fi Network. When the status of each node changes, a notification is sent to a mobile application. Furthermore, every node's status is shown to the user on a list (Figure 12), allowing the network behavior monitoring. If the mobile application is connected to the Wi-Fi network of the RPi, then the information about the nodes is updated in the smartphone (Figure 12.a). Otherwise, the stored data in the app is shown to the user (Figure 12.b).
Each node location is shown in the app using the Google Maps API and considering the latitude and longitude values stored in the database. The final user interface for geographic location is shown in Figure 13.

CONCLUSIONS
By exploiting the ZigBee protocol's functionalities, we obtained versatile nodes that may switch their role depending on the situation and can adapt to keep its integrality as much as possible. In this way, we were able to recover up to 42.8% of the network coverage. As an improvement to other works reported in the literature, the proposed algorithm offers an automated solution that helps mitigate the problem of the orphan nodes by maintaining the network's integrity and coverage as much as possible using the available nodes.
The proposed algorithm presented in this work may be useful in future studies to optimize the integrity and coverage of a WSN, but it comes with an energy cost. As shown in section III, to recover a node, a ZED needs to switch to a ZR and become a parent, increasing the current consumption, in this case, from 10.88 mA to 40 mA. Although the energy consumption varies depending on the devices used, the environment, and the sampling rate, it is still the same principle. The algorithm works based on the location and minimum distance for communication between nodes.   The mobile application allows the researchers and users to monitor the network behavior and take action in case of a failure. Also, a notification service in the app is necessary to timely alert the users about the change of status on each node.