Cluster-Based Communication protocol and architecture for a wastewater purification system intended for irrigation

The remote location of agricultural fields leads to the difficulty of deploying Precision Agriculture (PA) systems as there is no Internet access in those areas. Therefore, the use of long-range wireless technologies such as LoRa can provide connectivity to rural areas and allow monitoring PA systems remotely. In this paper, a heterogeneous architecture and protocol that allows communication with both WiFi and LoRa, including multiple hops in LoRa are presented. The design is based on a tree topology comprised of electronic devices deployed on different areas of interest for PA systems such as the canals of irrigation water, the fields, and the urban areas that generate wastewater. A set of practical tests with different configurations have been performed to determine the correct operation of the proposed protocol. The results show that the consumed bandwidth for both 433 MHz and 868 MHz frequency bands remained within the limits for the most restrictive LoRa configurations. Therefore, different deployment needs can be addressed with the implementation of this proposal. Furthermore, the use of packet transmission delays of 500 ms at the CH node results in high successful packet delivery rates.


I. INTRODUCTION
Precision agriculture (PA) systems aid in reducing water consumption and improving the quality and quantity of the production. Most fields are located in rural areas with no Internet access resulting in difficulties in deploying PA solutions. Ad-hoc networks allow forwarding the information to a sink node by transmitting the data from one node to another. However, deploying numerous sensing nodes is expensive and may not serve the needs of the farmer. The use of drones to gather the data from sensors deployed on the fields can be another solution for these remote fields [1]. However, this solution only allows to access the data at the time the drone flies over the field. Another option is to use robots that move through the fields to collect the data from the sensor nodes [2]. However, with the use of vehicles as gateways, the PA solutions cannot perform any actions in real-time or quasi-real-time. Therefore, there is the need to provide connection to remote areas in order to deploy PA systems with all their functionalities.
Long-rage technologies such as LoRa allows providing connectivity to remote areas. The Things Network was able to perform a LoRaWAN transmission that reached 766 km utilizing a transmission power of 25mW in two occasions [3]. Although the maximum theoretical distance would not exceed 6 km for the configurations required to achieve higher data rates in the 868 MHz frequency band [4]. Furthermore, the LoRaWAN protocol only considers a star topology, which presents a limit to the distance between node and gateway. Therefore, it may be necessary to add more hops to the LoRa network. In this regard, studies on multi-hop and mesh LoRa networks and protocols have been performed by some researchers [5]. The scenario of LoRa nodes for a water quality monitoring system intended for irrigation, including an architecture with several hops, has been studied in previous works [6]. Where clusters of nodes are deployed on the water canals to monitor the state of the water and avoid false positives and false negatives by comparing the data of all the nodes in the cluster. However, there can be a scalability problem due to possible collisions among the messages forwarded by each node in a shared coverage area. As it may be necessary to deploy several sensors on the fields, combining LoRa with a smaller range wireless technology may be a good solution.
There is a variety of low-range and medium-range wireless technologies such as WiFi, ZigBee, or Bluetooth Low Energy (BLE). WiFi is the most accessible technology due to the wide variety of devices and prices which makes it a good option for affordable solutions. Furthermore, its extensive documentation allows farmers and nontechnicians to easily operate the devices. Wi-Fi has been thoroughly studied for agricultural applications considering different types of vegetation and different positions of emitter and receiver and, it is the most utilized wireless technology in PA IoT systems [4]. ZigBee would also be a good solution but its usage in PA is yet to grow. Nodes such as the Heltec LoRa WiFi v2 [7] allow the utilization of both wireless technologies at the same time at an affordable price. The use of nodes with transceivers of multiple technologies allows to provide more functionalities to the system and to address the peculiarities of each scenario.
In this paper, a new communication protocol and architecture for PA systems located in remote areas is presented. This protocol has low overhead and is encapsulated over UDP and LoRa. The architecture contemplates WiFi clusters that obtain the data from the fields and the water channels and transmits it over a multihop LoRa wireless network to the gateway by utilizing a WiFi-LoRa bridge. The alerts caused by water salinity, water pollution, malfunctioning elements of the nodes, low battery or down nodes are contemplated. Real tests on different locations have been executed to determine the performance of the protocol and determine the maximum distance that can be reached with the proposed architecture.
The rest of the paper is organized as follows. Section II discusses the related work. The description of our proposal is depicted in Section III. The results are presented in Section IV. Section V compares the proposed system with other previous published works. Finally, the conclusion and future work is presented in Section VI.

II. RELATED WORK
In this section, we present previous works on protocols designed to be applied on WSN that are employed on agricultural monitoring systems or to reduce of the consumed energy for their functioning.
Large-scale wireless networks benefit from technologies such as LoRa for long-distance communication. However, when distances larger than 2 km are necessary, there are new solutions not contemplated in the LoRaWAN protocol such as ad-hoc or mesh topologies. Therefore, new protocols have been designed to provide ad-hoc and mesh functionalities. Heon Huh et al. presented in [8] a modification of the LoRa protocol for mesh networks. Furthermore, the proposed protocol utilizes time-division multiple-access to avoid collisions and the mesh network is limited to three hops. The protocol was tested on a fire pipe freeze monitoring system, a smart street light system, and a toxic gas monitoring system with successful results. Daniel Lundell et al. proposed in [9] a routing protocol intended for LoRa mesh networks. The protocol was developed using the tunneling principle, where the packet is forwarded if the node does not have Internet connection. Tests were performed utilizing Pycom LoPy 1.0 microcontrollers. The results showed the feasibility of the proposed protocol. A multi-hop LoRa network protocol based on concurrent transmission was designed by Chun-Hao Liao et al. [10]. In order to avoid collisions, the authors utilized random timing offsets. The results of the proof-ofconcept experiments showed an approximated 100% of packet delivery rate for topologies with both high and low density. Furthermore, the frequency-domain energy spreading effect led to a high possibility of packet collision survival including scenarios with small power offset.
The introduction of ad-hoc and mesh functionalities can be applied to many scenarios. Petr Gotthard et al. [11] utilized a supervised LoRa mesh network that utilized RSSI to determine the location of cars in a car park. The network was comprised of 1000 low-cost tags that reported the RSSI to the central server. Furthermore, the authors proposed a slot allocation scheme to avoid collisions. The results showed an error of 8 meters in car location and a lifetime of 5 years. In [12], Andrea Abrardo et al. presented a multi-hop LoRa network for underground medieval aqueduct monitoring in order to minimize the energy dissipation. This environment required data monitoring every one hour or less transmission , low power consumption, and coverage of several kilometers. Tests were performed utilizing Arduino nodes and Libelium LoRa modules. The results showed a reduction of 50% in power dissipation obtained from optimizing the wake-up time. Huang-Chen Lee et al. designed in [13] a LoRa mesh network to provide LoRa coverage to the campus area. Tests were performed utilizing Semtech SX1278 modules. The results showed packet delivery ratios of 58.7% for the star topology and 88.49% for the proposed mesh topology with three hops. Parg Kulkarni et al. performed in [14] several experiments of LoRa networks in a campus environment. The tests evaluated different configurations of coding rates, bandwidth, spreading factor to determine the transmission performance and link quality. The results showed smaller transmission times with high modulation coding schemes (MCS) and higher transmission times with the lower MCS settings. Lower MCS creates more collisions as well. Therefore, the authors conclude that higher MCS settings should be utilized when possible. Lastly, Silvano Bertoldo et al. [15] presented a propagation study for LoRa ad-hoc networks in urban environments. Tests were performed utilizing the Adafruit Feather 32u4 LoRa board with point-to-point and star topologies. For the point-to-point topology, packet losses remained below 4%. However, for the star topology, the packet losses ranged from 6% to 36%, with an average of 17%.
However, networks with high number of LoRa nodes transmitting on the same channel at the same time are susceptible to collisions. In order to solve this problem, Philip Branch et al. [16] proposed a broadcast scheduling scheme for LoRa relay networks. The proposal is intended for activities such as mine, tunnel, or pipe monitoring. It considers transmission delays to determine when to transmit the message. Successful tests were performed using Arduino boards and, Dragino and Modtronix LoRa shields, reaching distances of one kilometer per hop. Thiemo Voigt et al. performed in [17] a study on the interferences caused between LoRa networks. The authors consider the use of multiple base stations and directional antennae. Simulations with the LoRaSim simulator were performed to test both solutions. The results showed that although both proposals improve the performance of the scenarios with interferences, the best performance was obtained with multiple base stations.
Finally, these types of networks often face energy constrictions. Therefore, several solutions have been considered to optimize the energy consumed by the LoRa adhoc network. In [18], Derek Heeger et al. analyze adaptive data rate (ADR) techniques for ad-hoc LoRa networks with energy constrictions. ADR was extended with the use of frequency shift keying (FSK) and they propose a process for error recovery. Simulations were performed with the incremental search algorithm, the binary search algorithm, and a greedy search that utilized SNR and RSSI. The results showed that the greedy search algorithm was the best solution although it presents implementation challenges. The binary search was good for a high data rate, but it had difficulties with high Spreading Factor (SF) settings. Lastly, the incremental search performed better than the binary search with high settings but not for FSK configurations. George Klimiashvili et al. [19] analyzed the energy consumption and delay of LoRa and WiFi Ad Hoc networks with the NS3 simulator.In this paper, authors present a mathematical model for the delay and energy consumption. The results showed that LoRa presented higher delay due to the low throughput and the duty cycle. Furthermore, WiFi presented less energy consumption than LoRa for distances below 300 meters when they are covered in one hop. On the other hand, LoRa presented higher efficiency for large distances.
In this paper, a cluster-based multi-hop communication protocol for precision agriculture systems is presented.
Our work presents a new cluster-based algorithm and communication protocol for the detection and purification of waters that other authors have not previously defined. As opposed to other solutions, our work allows connectivity with two wireless technologies and implements multiple LoRa hops to reach longer distances.

III. SYSTEM DESCRIPTION
In this section, we are going to describe the architecture, the communication protocol, and the data analysis algorithm for a wastewater purification system intended for irrigation.

A. ARCHITECTURE
In this subsection, we detail the proposed architecture for our wastewater purification system for irrigation purposes.
The disposition of the area and the distribution of each type of zone we have identified are presented in Figure a. As shown, we identify several urban areas, a canal area, and fields. These areas communicate using wireless technologies. The wastewater disposed of by the population inhabiting the urban areas is transported to a purification station before being released to the irrigation canals. However, the quality of the resulting water may not be optimal and non-treated waters and different contaminants may worsen the quality of the water before reaching its destined field. Thus, an in-situ water purification system is needed to ensure the quality and the healthiness of the production. Urban Area 0 has an Ethernet/Fast-Ethernet connection to the data center. We have chosen cabled communication because the performance of the data transmission is better, and the urbanized area allows easy access of the infrastructure of the service provider. The Canal area designates the zones where the irrigation canals are located. Auxiliary canals connecting to the principal one have been designed in a comb-shaped structure to perform the biosorption process. Then, the decontaminated water would be released again to the main canal in order to use it for irrigation. Lastly, at the Field area, soil and meteorological parameters are monitored to determine the necessary amount of irrigation. The detailed view of the Canal area is provided in our previous work [6]. This is the area where the different types of nodes will be deployed. Three models of sensor nodes can be identified. Sensor nodes are comprised of a microcontroller and the different sensors that allow quantifying the pollution in the water. Actuator nodes are comprised of a microcontroller and the necessary actuators to open and close the gates to return the water to the main canal. The Cluster head is the node that receives the information from the rest of nodes and forwards it to the gateway situated in Urban area 0.
The auxiliary canals that contain the biosorption materials are deployed in a comb-shape. As it can be seen in Figure 4, all the auxiliary canals have the same structure and they are connected to each other to allow the water flow through the biosorption process several times if necessary. In order to determine if the water from the canal needs to be processed in the biosorption canals, the sensor nodes check the its pollution at the entrance of the canal. When contaminants are detected, the gates are opened to let the water flow into the biosorption canals. Once inside the biosorption canals, the water is treated to remove the contaminants. At the end of the auxiliary canal, another set of sensor nodes are placed to monitor the water in order to decide if the water can be returned to the main canal or if it needs to go through the biosorption process again. The actuator nodes are connected to the lock-gates that allow regulating the passage of the water flow.
The Field area is depicted in Fig. 2. The fields are divided into sectors and each sector has a deployment of a soil sensing cluster comprised of two Soil Sensing Nodes and a soil Sensing Cluster Head that aggregates the data from the soul sensing nodes and transmits them to the Aggregator node. The moisture sensors of the Soil Sensing Nodes and the Soil Sensing Cluster Head are deployed at different depths to determine if the water has reached the needed depth or if there is water stress. The Soil Sensing Cluster Head is placed at the same spot as the dripper with its sensors located on the vertical of the dripper [21]. The Soil Sensing Nodes are located at the mid-point between drippers, which is at a distance of 45 cm from the dripper. All the Soil Sensing Nodes forward the data to the Aggregator node. This node aggregates the data from all the sectors to forward it to the gateway in the Urban Area. Lastly, the actuator node controls the opening of the gates and the water flow.
The network topology is presented in Fig. 3. The nearrange communication is performed using WiFi and the longrange communication is performed utilizing LoRa. Due to the low amount of data that need to be transmitted, the nodes adjust the WiFi connection to 2 Mbps to reach higher distances and increase the robustness. On the other hand, the AP is set to 54 Mbps as it needs to manage the messages from different nodes at different distances allowing the dynaminc adjustemet. The communication between the data center and the gateway is performed using a wired connection. As it can be seen, the system presents a star topology. This is due to the need of implementing a low-cost system where the number of nodes that can be employed is limited. In a star-topology of LoRa Nodes, there can be collisions and thus, losses due to all the nodes transmitting in the same channel. As the system does not require to send data in real-time, there is no need of modification in the LoRa medium access control protocol. Furthermore, as a LoRa node can send the data to the data center through multiple gateways, more gateways would be installed if necessary.  The system is comprised of the following elements: • Water Monitoring Node: This node is comprised of an embedded board, an SD card module with an SD card for data storage, a turbidity sensor, a salinity sensor, an oil sensor, a battery, a WiFi interface and a solar panel for energy harvesting. This node communicates with the Water Monitoring CH using WiFi. • Water Monitoring CH: This node has the same elements as the Water Monitoring Node. However, this node has more capacity for data storage and processing as it receives the data from the Water Monitoring Node.Moreover, it has a LoRa interface. It communicates with both the Water Monitoring Node, with WiFi, and the Aggregator Node of the Canal Area, with LoRa.
• Soil Sensing Node: This node is comprised of an embedded board, a soil humidity sensor, a soil temperature sensor, an SD module, an SD card, a WiFi interface and a solar panel. This node monitoring the state of the soil and forwards the data to calculate the water requirements of the trees. This node communicates with the Soil Sensing CH using WiFi. • Soil Sensing CH: This node has the same elements as the Soil Sensing Node with more storage and processing capacity as it processes the data from the Soil Sensing Nodes and a LoRa interface. It communicates with the Soil Sensing Nodes through WiFi and the Meteorology Monitoring Aggregator Node through LoRa. • Aggregator Node: The Aggregator Node is a LoRa node with high processing capabilities and data storage resources to manage and aggregate the data received from all the sensors. It also has an energy-harvesting module to ensure it has enough energy to operate. • Meteorology Monitoring Aggregator Node: This node adds functionalities to the Aggregator Node described before. It has an air temperature and humidity sensor, a light sensor, a rain sensor, and a wind sensor to provide the Data Center with the necessary data to calculate the water requirements of the fields. It communicates with the CH Nodes, the Actuator Nodes, and the Gateway using LoRa. • Gateway: It is a commercial LoRa gateway connected to the internet through an Ethernet connection. • Data Center: The Data Center can be either a cloud service of a service provider or a private server that performs storage and data analysis to determine the water requirements of the fields. The results of the data analysis are then forwarded to the deployed nodes and the users.
Moreover, we also add two types of users in our network, in order to show who should be advised: • Farmer User: This user is the owner or the manager of the fields. Thus, the Farmer User needs to know the problems of the nodes on the field area to replace them when necessary. Furthermore, the Farmer User needs to know the water requirements of the fields as well.
• Hydrographic Confederation User: This user is the owner or the manager of the canals. They are responsible for replacing the broken nodes in the canal area and they can only access the information of the quality of the water and the state of the actuators of the canal area.
Using a LoRa node to relay data in a LoRa network has been studied in works such as [8,13]. Adapting the LoRa SF and BW settings according to the data that needs to be transmitted can be done. The protocol Stack of the system is presented in Fig. 4. The Cluster Head is the node that acts as a bridge between the elements of the network that utilize WiFi and the elements that use LoRa. Regarding the LoRa network, LoRaTM defines the Physical Layer. Our proposed Heterogeneous Communication Protocol (HCP) is part of the Application Layer. Regarding the WiFi network, HCP is encapsulated in UDP.

B. PROTOCOL DESCRIPTION
In this subsection, we present the protocol designed and developed for the proper running of the system. The message format is described in Fig. 5. The first field of the Header is the NODE_ID field. It is one byte long and it has the specific ID of each node. This field is set to 0 when the node has not yet been registered in the network or when the sender is the Data Center. It is followed by the NODE_TYPE field which is 4 bits long. Table I depicts the different node types and the value at the NODE_TYPE field. The MESSAGE_TYPE field is 3 bits long and determines the type of message the nodes or the Data Center is sending (see Table II). The next field is the Priority Field. The messages with priority have this flag set as 1. All messages have the priority flag activated except the DATA message. The DATA message does not have priority unless the access to the data has been requested by the user. The next field is the Payload which has the information that is forwarded in the message. Not all messages have a payload.

Yes
A scheme of the phases of the protocol is presented in Fig.  6. When the system is deployed, the first process performed by the protocol is the Activation Phase to connect all the devices. Then, the Verification Phase is performed to ensure all devices work properly. Then, the User Registration Phase is performed to add all the Users to the system. The Data Acquisition Phase, the Data Transmission Phase, the Action Phase, and the Alert Phase can happen at the same time between the different elements of the architecture. Lastly, the Verification Phase is performed periodically to assess the state of the devices. Hereunder, an in-depth description of each of the phases is provided.

1.
Activation phase: In this phase, the nodes detect their neighbors and establish the connection with the other nodes. The initial set-up of all the variables necessary for the correct working of the system is established as well.
All the nodes have a static address assigned by the network designer. The nodes establish the connection with one another according to the specifications of the WiFi/LoRa technology. Once the topology has been established, the nodes send a REGISTER message to obtain the Node ID from the Data Center. The register process begins with the Gateway, followed by the Aggregator Node, then the CH, and, lastly, the Sensing Nodes. As it can be seen in Fig. 7, the NODE_ID is set to 0. The NODE_TYPE is part of the initial configuration of the node. Therefore, depending on the type of the node, the NODE_TYPE field in the REGISTER message will have a different value. The MESSAGE_TYPE is the REGISTER message, and the P flag is set to 1. Lastly, in order to know which of the nodes has forwarded the message, the payload of the REGISTER message will be a Byte with a random number. The answer from the Data Center will substitute the random Byte with the Node ID assigned to the node. An example of the REGISTER message for a Water Monitoring Node is provided in Fig. 8.

2.
Verification phase: The nodes verify that all the sensors, the solar panel, the radio, and the communication are working correctly. If any of the elements of the system has a problem, a MALFUNCTION message is generated.
Once the nodes receive the NODE_ID, they begin the verification process to check if all the sensors and elements that comprise the node are working properly. If there is not any problem, no messages are sent. However, if there is a problem with any of the elements of the node, a MALFUNCTION notification will be sent to the Data Center (see Fig. 9). The Verification phase is performed periodically to assess the performance of the system as it is exposed to the elements, animals, and machinery of the workers of the farm.
The payload of the MALFUNCTION message is different according to the Node Type. It consists of a set of flags that indicate which sensor is malfunctioning (see Table III). The Actuator Nodes only have two flags while the Soil Sensing Node and CH, and the Meteorology Monitoring Aggregator Node have 5 flags. When one of the sensors is not working correctly, the MALFUNCTION message is forwarded with the flag of the broken sensor set to 1. The sensors that are working properly have their flags set to 0.

User registration phase:
The user is registered at the Cloud platform to access the sensors data and to indicate any changes in the initial variables. If any new information is provided by the user, the data is forwarded to the nodes that need that information.
In this phase, the user is registered in the system. There are different types of users with different privileges. Table IV presents the types of users and the nodes they have access to. As it can be seen, the Farmer user has access to the nodes deployed in their farm whereas the Hydrographic Confederation User has access to the nodes deployed on the water canals. The message exchange between the User and the Data Center is presented in Fig. 10. As it can be seen, the employed message is the REGISTER message. In the case of the user, The NODE_TYPE field has the values of the User Type. The NODE_ID and Payload fields are used in the same way as the nodes on the Activation phase.

4.
Data acquisition phase: The nodes of the cluster gather the data from the sensors. The sensing nodes send the data to the Cluster Head for its latter transmission to the data center. The system enters this phase more regularly than the Data transmission phase. Depending on the activities performed by the node, it can vary from minutes to hours.
According to the NODE_TYPE, the payload of the DATA message is different. The bits required for each of the parameters are the minimum size necessary according to the resolution required for the calculations. This way, the size of the message is reduced as much as possible while ensuring the desired functioning of the system. The P flag of this DATA message is set to 0. The message exchange for this phase is presented in Fig. 11. No ACKs are forwarded to reduce energy consumption. Instead, The CH has a Reception Timeout to assess if the messages from the Monitoring Nodes have been received within the expected time. This is a parameter that is configured at the establishment of the network. When the Reception Timeout is reached, a DATA message is forwarded to the Monitoring Node with a Payload of 1 bit set to 1 (see Fig. 12).

5.
Data transmission phase: The nodes start gathering the data from the sensors. This data is stored in an SD card. Then, all the local analysis is performed, and the data is transmitted to the specified node. For the Cluster Heads, the data from the sensor nodes are aggregated and forwarded to the gateway. If any alerts arise during this phase, then an alert notification is forwarded. There are different types of alerts. This phase is entered when a notification occurs and once a day to forward the data stored in the SD card.
Unless it is a message with priority, the information is forwarded to the Data Center once a day. The message exchange for the Data Transmission phase is shown in Fig.  13.

6.
Action phase: Once the data reaches the data center, it is stored and processed using AI based on a dataset of preestablished values of correct performance. With the correct performance in mind, decisions are taken throughout the performance time. When actions are required, the specific action is forwarded to the actuator nodes.
The message ACTION is forwarded from the Data Center to the Actuator Node (see Fig. 14). The payload of the ACTION message is the new values of the Actuator Node, such as opening or closing the gate. The Actuator Nodes of the Canal Area are LoRa Class B nodes so they can receive an ACTION message when necessary, with a latency below 30 seconds, which is an acceptable latency for our system. The Actuator Nodes of the Field area are LoRa Class A nodes. As the calculations for the amount of water needed for irrigation are performed for the next day, the Actuator Node will forward an empty DATA message so it can receive any queued ACTION messages from the Data Center. The Aggregator Node will discard the empty DATA message and forward the ACTION message.

7.
Alert phase: When the Data Center receives an Alert message, the system processes the notification and determines the action that has to be taken to solve the problem. Depending on the type of the alert, different type of action has to be taken by the element of the network that has reported the alert. The alert messages have priority over the rest of the messages. Therefore, if an alert is received, the node will send the alert before sending other information. There are different types of alert messages according to the detected problem.
a. Pollution detected: When the water is contaminated, an alert message is forwarded to the Data Center and to the Hydrographic Confederation User. The data center will take the necessary action and forward it to the corresponding actuators. This alert generates a response from the Data Center as described in the Action phase.
When pollution is detected in the water, a POLLUTION message is forwarded to the Data Center (see Fig. 15). The payload of this message is the measured pollution levels. The Data Center uses this information to determine the required action. Furthermore, the priority messages need to be acknowledged to ensure that the message has been received. The acknowledgment is done by forwarding a message with the same header as the POLLUTION message and the payload set to 0.
b. High salinity levels detected: When high salinity is detected, a SALINITY message is sent to the Data Center (see Fig. 15). The payload of this message is the salinity levels detected by the node that sends the alert. The message is acknowledged by a message with the same header and the payload set to 0. Then, a decision is taken to modify the amount of irrigation water so the salinity levels of the soil, resulting from the irrigation, are reduced in comparison to those that would result when taking no action. This alert generates a response from the Data Center as described in the Action phase.

c.
Cluster Head node is not operative: When the Cluster Head Node is detected to be down, the system generates an IS_DOWN message to notify the user (see Fig.  16). The message is acknowledged with an IS_DOWN message with the payload set to 0. The sensing nodes that send their data to the Cluster Head will store the information on their SD card until the CH node is replaced.
This message is forwarded from the Aggregator Node to the Data Center when the Aggregator nodes detect that no messages are received from the CH Node. Therefore, the NODE_ID of the message is the ID of the Aggregator Node and the payload of the message is the NODE_ID of the CH Node.
d. Sensing node is not operative: The CH node sends an IS_DOWN message to notify the user and continues with its operation (see Fig. 16). The payload of the IS_DOWN message is the NODE_ID of the Sensing Node. For the acknowledgment of the message, the payload of the message is 0. If decisions need to be taken, the CH will only consider the operative nodes.

e.
Actuator node is down: The gateway sends an IS_DOWN message to the Data Center and to the Actuator Node of the next canal to operate as indicated by the sensing nodes of the previous canal (see Fig. 17). The payload of the IS_DOWN message is the NODE_ID of the broken Actuator Node. For the IS_DOWN acknowledgment, the payload of the message is 0. In case of malfunctioning, the water will always go through the biosorption process to ensure water quality.

f.
Aggregator node is down: When the Aggregator Node is down, the Gateway will generate an IS_DOWN message and it will send it to the Data Center, which will send the IS_DOWN message to the Farmer User to repair or replace it (see Fig. 18). The message is acknowledged by an IS_DOWN message with a payload of 0. Then, Cluster Head nodes will store the data until the Aggregator node is active again. As the CH nodes cannot receive any decision from the data center, the nodes will decide if the water needs to go through the biosorption process locally. On the field area, the last irrigation schedule provided by the data center is maintained.
g. The gateway node is down: When the Gateway Node is down, the clusters and the Aggregator Node will perform fog computing and make independent decisions VOLUME XX, 2017 9 based on the information gathered up to the gateway being down (see Fig. 18). When the Gateway is operative, the stored data is forwarded, and the decision process is again performed by the data center. If there is more than one gateway, the Aggregator Nodes and the Actuator Nodes will forward the data to the available Gateway. When the Data Center detects that the Gateway Node is down and sends an IS_DOWN notification to the User with the ID of the Gateway for the Farmer User to repair or replace it. h. Node with low battery: If the energy harvesting system of the node is malfunctioning and the node detects low battery or the battery is malfunctioning and it is not charging, a LOW_BATTERY notification is forwarded to the Data Center, which conveys the notification to the user (see Fig. 19). If there is enough energy available, the node will forward all the stored data. The node will continue functioning until the battery expires. The node of the layer above will store the data of the node with a low battery until it is down. This problem may be caused by weather conditions damaging the node, or elements blocking the solar panel, such as soil or leaves.
Unlike the IS_DOWN message, the LOW_BATTERY message is forwarded by the node with the problem and thus, the payload of this message is set to 1 as the NODE_ID in this message is that of the node with a low battery. Furthermore, the message is acknowledged with the same message and the payload set to 0. However, if bad weather conditions were detected by the Meteorology Node and the LOW_BATTERY message is received, the message forwarded to the Farmer User by the Data Center will indicate this aspect in its payload.
i. Malfunction detected: If the node detects a malfunction in one of its elements, a MALFUNCTION message is forwarded to the Data Center as specified in the Verification phase (see Fig. 19). A message with the same header and the payload set to 0 is forwarded as an acknowledgment.

j.
Data Center down: This is not a habitual problem as data centers have backup systems. However, if the data center is not a hired service from a service provider and it is a server created by the Farmer User, it is possible that it does not have a backup and the data center could be susceptible to blackouts, failures of the equipment, and accidents such as fires. In case this problem arises, the User application will notify the Farmer User that the Data Center cannot be accessed. Furthermore, The Aggregator Node will perform fog computing and make independent decisions based on the information gathered up to the Data Center being down. This way, the system can operate independently until the Data Center is running again. k. Farmer User or Hydrographic Confederation User not available: If the Farmer User or the Hydrographic Confederation User is not available, the system will function in an autonomous manner. The notifications intended for the User will be queued at the Data Center until the User is active again.

IV. RESULTS
This section presents the performance results of the protocol from the real tests.

A. TESTBED DESCRIPTION
The tests have been performed in a real environment. Two types of nodes were utilized. The Wemos Mini D1 [20] and the Heltec LoRa WiFi 32 v2 [7] (see Fig. 24). The Wemos Mini D1 is an embedded system with 1 analog input, 11 digital input/output pins, and 4MB of flash memory. This node includes the ESP 8266 chip and has Wi-Fi connectivity. The Heltec nodes have both LoRa and Wi-Fi connectivity through the ESP32 microprocessor and a SX1276/SX1278 LoRa chip. Furthermore, it is comprised of an OLED (Organic Light-Emitting Diode) display, 18 ADC (Analogto-Digital Converter) input ports, and 2 DAC (Digital-to-Analog Converter) output ports, with 3 UART, 22 GPIO (General-Purpose Input/Output), 6 GPI, 2 I2C (Inter-Integrated Circuit), 2 SPI (Serial Peripheral Interface), and 2 I2S (Inter-Integrated Circuit Sound). Heltec devices are available for both the 433 MHz and the 868 MHz bands. Therefore, the tests were performed for both 433 MHz and 868 MHz for the LoRa nodes with the antenna shown in Figure 20. Furthermore, a preliminary test was performed to test the coverage of the utilized LoRa nodes with the antennas provided by the vendor. The topology utilized for the tests (see Fig. 21) corresponds to one of the branches of the topology proposed in Fig. 3. Several libraries were created using the C++ programming language in order to implement the protocol on the aforementioned nodes. Each node type has its own library that specifies implements the state of the nodes introduced previously. The environment where the tests were performed is shown in Fig. 22. For the normal performance of the system, the time between messages would be high, however, in order to test the performance in a worst-case scenario, the number of forwarded messages was incremented. Both WiFi sensing nodes forward the data message each minute. Then the WiFi 1 node sends the LOW_BATTERY message at minute 7 and the IS_DOWN message at minute 9, and the WiFi 2 node sends the LOW_BATTERY message at minute 6 and the IS_DOWN message at minute 8. The total time for each test was 10 minutes. The REGISTER messages are forwarded at the beginning when the nodes are connected. Lastly, the alarms are generated according to the data. The payload of the data messages was generated in a random manner within the range of each parameter with the addition of a range extension of values that would not be possible for the parameter in order to trigger an alert. Therefore, the forwarded alerts are more numerous than those of normal performance. For the case of LoRaWAN, there is a 1% policy to avoid collisions. With the proposed protocol, this policy is not considered.

B. TEST RESULTS
In this subsection, the test results of the proposed protocol are presented.

1) CONSUMED BANDWIDTH
For LoRa networks, the consumed bandwidth is an important metric as the maximum data rate can be very limited depending on the LoRa settings. The data rate for the most restrictive settings for the 433 MHz and the 868 MHz frequency bands is 250 bps [22]. Therefore, maintaining lower data rates facilitates the selection of a great variety of configurations. The tests for both frequency bands were performed with variations in the packet forwarding delay of the CH node so as to reduce de number of lost packets due to collisions.
The results for the tests performed for the 433 MHz frequency with a packet delay of 0ms at the CH node are presented in Fig. 23. As it can be seen, for the two nodes that only transmit in LoRa (see Fig. 23 a and b), the maximum data rate remains below 250 bps considering that the tested scenario has more packet transmissions than that of the normal performance of the system. For the LoRa 1 node, the maximum data rate was 112 bps and the average data rate for the duration of the test was 1.68 bps. For the LoRa 2 node, the maximum data rate was 160 bps and the average data rate in the 10 minutes of the test was 2.63 bps. The rest of the nodes transmit using WiFi and LoRa for the CH node and only WiFi for the monitoring nodes. Therefore, the overhead of utilizing WiFi and UDP leads to an increased data rate compared to that of the LoRa nodes. The CH node reaches a peak of 760 bps when both WiFi and LoRa packets are received within the same second (see Fig. 23 c) and an average of 13.69 bps for the duration of the test. Lastly, for the WiFi nodes, both of them reached a maximum data rate of 256 bps (see Fig. 23 d and e) with an average of 2.49 bps and 1.25 bps respectively for the tested time. The total consumed bandwidth is presented in Fig. 23 f. The peak in bandwidth consumption reaches 760 bps corresponding to the CH node and the average data rate for the duration of the test was 21.64 bps.  MHz frequency band and a packet forwarding delay of 250 ms for the CH node. For the LoRa 1 node, as it can be seen in Fig. 24 a, the maximum data rate is 112 bps, and the average value for the duration of the test is 2.21 bps. For the LoRa 2 nodes, the maximum data rate reaches 216 bps and the average reaches 3.61 bps (see Fig. 24 b). The maximum data rate for the CH node is 808 bps and the average value is 15.47 bps (see Fig. 24 c). For both of the WiFi nodes, the maximum data rate was 256 bps with an average of 2.08 bps in both cases (see Fig. 24 d and e). For the total consumed bandwidth in the network (see Fig. 24 f), the maximum data rate was 1056 bps, and the average value was 25.89 bps. The consumed bandwidth from the tests performed in the 433 MHz frequency band and a packet delay of 500 ms at the CH node is presented in Fig. 25. As seen in Fig. 25 a, the maximum data rate for the LoRa 1 node is 160 bps. The resulting average data rate is 2.24 bps. In Fig. 25 b, it can be seen that the maximum data rate for the LoRa 2 node is 304 bps. It is higher than the value of 250 bps for the most restrictive LoRa settings regarding the data rate. However, the data rate obtained at the test does not surpass the data rate for the second most restrictive LoRa settings. The maximum data rate for the CH node is 824 bps with an average of 15.17 bps (see Fig. 25 c). In Fig. 25 d and e, it can be seen that the maximum data rate is 256 bps with an average for the duration of the test of 3.32 bps and 1.25 bps respectively. Regarding the total consumed bandwidth in the network, the peak data rate was 984 bps with an average of 25.62 bps (see Fig. 25 Fig. 26 a shows the results for the LoRa 1 node where the peak data rate is 112 bps and the average data rate for the duration of the test is 2.1 bps. The results for the LoRa 2 node, as shown in Fig. 26 b, indicate that the maximum data rate is 208 bps and an average data rate of 3.21 bps. For the CH node, the maximum data rate is 608 bps and the average for the 10 minutes of the test is 14.68 bps (see Fig. 26 c). For the WiFi nodes, the maximum data rate is 256 bps, and the average data rate is 3.32 bps and 1.25 bps respectively (see Fig. 26 d and e). Lastly, Fig. 26 f presents the results of the total network where the peak data rate is 872 bps with an average of 23.63 bps. The results of the test performed utilizing the 868 MHz frequency band and with 250 ms of packet delay at the CH node are presented in Figure 27. As it can be seen in Fig. 27 a for the LoRa 1 node, the maximum data rate is 160 bps and the average data rate for the duration of the test is 2.05 bps. The maximum data rate for the LoRa 2 node is 256 bps and the average data rate is 3.56 bps (see Fig. 27 b). For the CH node, as seen in Fig. 27 c), the maximum data rate is 808 bps and the average data rate for the duration of the test is 15.05 bps. For the WiFi nodes, the maximum data rate is 256 bps, and the average data rate is 3.73 bps and 1.25 bps corresponding to the WiFi 1 and the WiFi 2 nodes (see Fig.  27 d and e). For the complete network, the peak data rate value was 872 bps with an average data rate of 25.57 bps (see Fig. 27  The results for the tests performed with the 868 LoRa nodes and a 500 ms packet delay at the CH node are presented in Fig. 28. As it can be seen in Fig. 28 a, for the LoRa 1 node, the maximum data rate is 160 bps and the average data rate for the duration of the test is 2.24 bps. For the LoRa 2 node, as seen in Fig. 28 b, the maximum data rate is 256 bps, and the average data rate is 3.57 bps. For the CH node, as shown in Fig. 28 c, the maximum data rate is 760 bps, and the average data rate is 13.77 bps. For the WiFi nodes, the maximum data rate is 256 bps, and the average data rate is 3.32 bps for the WiFi 1 node and 1.25 bps for the WiFi 2 nodes (see Fig. 28 d and e). Lastly, for the complete network, the peak data rate is 968 bps, and the average data rate is 24.16 bps (see Fig. 28 f). The data rate values for all the tests remain very similar. Thus, it can be concluded that the proposed system is viable and adequate for heterogeneous networks intended for water quality and field monitoring in order to automate and improve irrigation. However, it is necessary to determine the packet loss that can occur due to the characteristics of LoRa.

2) PACKET LOSS
The utilization of LoRa can lead to packet loss due to the collisions that occur when two or more packets are forwarded at the same time. The successful packet delivery rate of each test has been determined. The results are shown in Fig. 29. As it can be seen, the high delivery rates were obtained for all tests, but the additions of delays help in improving the number of successful packet deliveries. For a delay of 0 ms, 91.26% of the packets were successful for the 433 MHz frequency band and a 94.02% successful packet delivery rate was obtained for the 868 MHz frequency band. For a packet delay at the CH node of 250 ms, the successful delivery rate was 93.33% and 98.43% for the 433 MHz and 868 MHz respectively. Lastly, for a delay of 500 ms, the successful packet delivery rate for the 433 MHz was 98.46% and for the 868 MHz frequency band the obtained result was 98.37%. As it can be seen, for the 868 MHz frequency band the delay of 250 ms allowed reaching a high delivery rate but for the 433 MHz frequency band a delay of 500 ms was necessary.
VOLUME XX, 2017 9 FIGURE 29. Successful delivery rate of the performed tests.

V. System Characteristics comparison
This section compares our proposal with published proposals on irrigation systems. Table V shows that our proposal is more complete and has better characteristics than existing irrigation systems. On one hand, some proposals combine different wireless technologies. The work in [24] allows the use of different technologies but the transceiver for wireless communication needs to be changed according to the desired technology. The work in [23] includes RFID and QR for the identification of the irrigation facilities but it needs the user to walk or drive at a close distance to access the information. The use of GSM for long-range communications in [27] allowed forwarding SMS to the users. Our proposal includes technologies for medium-range and long-range communication with the incorporation of multiple LoRa hops for coverages of several kilometers. Furthermore, our proposed protocol is able to operate with WiFi and LoRa to allow the communication between the different nodes of the network.
Regarding the consideration of the irrigation canals, two other proposals deployed sensing devices in this type of area. However, they did not include water quality monitoring.
The proposal in [24] included some type of electrical error recovery that was not specified in detail. However, our proposal incorporates fault tolerance and recovery considering all the possible forms of malfunction that can affect the system.
Warning alarms are present in proposals [25,27]. These alarms are focused on the monitored parameters. However, our proposal also incorporates notifications for different malfunctions in the system and the electronic devices. This way, the user is notify of the need of component replacements or reparations.
Regarding scalability, proposal [27] considered the deployment of a high number of sensing devices. However, the data is collected from the nodes through the use of drones. Therefore, the system in proposal [27] is as scalable as the capacity of the available drones to cover all the static nodes within their maximum flight time.
Lastly, regarding the monitored paramteres, our proposal includes the highest number of monitored parameters from varied aspects such as water qualiy, state of the soil and weather conditions. Other proposals focus on on or two of these aspects. The system presented in [24] also included multiple parameters but water quality was not considered. Therefore, our system is able to include multiple functionalities and improve on the existing solutions for each specific functionality.

VI. CONCLUSION
Systems for precision agriculture are frequently deployed in remote areas with limited or no access to internet infrastructures. In this paper, an architecture for water quality monitoring for an irrigation PA system and has been presented. Three areas have been considered being the canals for irrigation water, the fields, and the urban areas. The data is forwarded utilizing both WiFi and LoRa wireless technologies, where the CH node is the WiFi/LoRa bridge that allows the connection between the WiFi and the LoRa nodes. Furthermore, a tree topology for LoRa with multiple hops has been introduced. This allows reaching further distances and reducing the amount of data and the number of messages forwarded from one node to the following node. Moreover, a heterogeneous communication protocol for a precision agriculture system was presented. The protocol designed to enable communication between devices that employ WiFi and LoRa communication technologies has low overhead with a header of only 2 Bytes. Tests have been performed in a real environment with WiFi and LoRa nodes to determine the performance of the proposed protocol. The consumed bandwidth for both 433 MHz and 868 MHz frequency bands remained within the limits for the most restrictive LoRa configurations. Therefore, the proposed protocol can be implemented considering all the deployment needs. Furthermore, high successful packet delivery rates were obtained utilizing packet transmission delays of 500 ms at the CH node.
We plan in our future work to add more types of technologies, such as ZigBee or BLE, to the system in order to provide new functionalities. As a result, the proposed communication protocol should be extended to support these newly added technologies. Moreover, by introducing a tree topology for a LoRa network, multiple LoRa devices need to communicate. Creating a routing protocol for multi-layer LoRa networks would allow providing more scalability to our proposal.