SWAP: Smart WAter Protocol for the irrigation of urban gardens in Smart Cities

The implementation of Smart City projects has experimented a surge in the recent years with examples such as Smart Santander or Barcelona Smart City. Among the different domains that comprise the Smart City, water management has a great importance, more so in areas with water scarcity. Furthermore, water from different sources such as treated sewage water or collected rainwater can be utilized to address water needs where the use of potable water is not necessary. Therefore, the implementation of smart systems for the irrigation of urban gardens and other urban vegetated areas are of great importance to manage both water needs and the available resources. In this paper, a communication protocol for smart irrigation systems designed within the context of the Smart City is presented. The protocol enables the communication among devices with both LoRa and WiFi wireless technologies. Tests were performed with low-cost devices on an urban area. The results demonstrate the good performance of the proposal, obtaining the minimum packet loss by adding a 500 ms delay at the CH node when transmitting messages from WiFi to LoRa and vice versa.


I. INTRODUCTION
The evolution of cities to introduce Smart City solutions to monitor and automate different aspects such as traffic, energy consumption, urban gardens or sewage system has increased in recent years. The domains of the Smart City can be divided into five categories being eco-smart cities, traffic control, schooling, e-health, and e-energy [1]. However, there may be other type of classifications. Water management has also been the object of study regarding Smart Cities with concepts such as water-sensitive urban design or using smart meters to monitor non-revenue water [2]. Smart water solutions can be utilized for decentralized water management to reduce energy consumption compared to centralized systems. Furthermore, the use of water management within Smart City policies can also be utilized to provide cooling options in heatwave conditions as it has been studied for the case of Australia [3]. By using the water collected by rainwater tanks, storm water, and recycled sewage wastewater, a reduction of 1ºC -2ºC of the air temperatures can be obtained through the irrigation of urban green-space habitats. Water management in Smart Cities can also be applied to urban agriculture [4]. These smart practices are based on the use of electronic devices and equipment that allow the automation of certain tasks. This includes water sprayers or light controllers. The potentialities of these types of systems are their portability, small size, and low labor requirements. On the other hand, the challenges are related to its difficulty for large-scale crops.
Several projects of smart cities have implemented smart solutions for the different domains. Norway has deployed Smart City solutions such as the ECO-city project in the city of Trondheim in 2005, which is focused on energy consumption [2]. Furthermore, a decentralized smart water treatment was performed in the neighborhood of Klosterenga, Oslo, and other water management solutions were deployed on Bergen. Spain has also performed Smart City initiatives such as Smart Santander, Barcelona Smart City and Guadalajara Smart City [1]. Smart Santander is comprised of devices such as sensors, actuators, RFID tags and cameras, counting more than 10000 devices. This project considers the irrigation of parks and gardens, traffic monitoring, participatory sensing, augmented reality, parking systems and environmental mobile monitoring.
Barcelona includes a smart lighting system, smart water management, smart mobility and WiFi access points for the citizens. The data is open access and is published through a mobile app. Lastly, Guadalajara Smart City includes the SOU (Sistema Operativo Urbano), which is a data center that collects and analyzes the data from the devices, and services for public spaces. Moreover, the European Union has presented the CERP-IoT initiative to reach a common vision of IoT which includes several Smart City projects.
The city environment provides access to the existing infrastructure so that the devices can be connected to the power grid and the ISP (Internet Service Provider). However, deploying cabled communications for all devices is costly and difficult to implement. Thus, many smart solutions utilize wireless communications. The selection of the best wireless technology should be performed according to the application and the available resources [5]. The distance, traffic type and the energy consumption should be considered to select among the varied options available. This way, Bluetooth can be used for short range communication, WiFi is a good option for medium range communications with high traffic demands and it is accessible for the majority of the public, and LoRa can be employed for long distance communications as it would be required for large parks such as Central Park in New York City. As Smart Cities include different functionalities, the utilization of more than one type of wireless technology should be considered.
Smart Cities are comprised of different types of devices that communicate with each other to perform different activities. These devices conform an architecture that in its generic form may be divided into four layers, as proposed by Camilo A. Medina [1]. These layers are the sensing layer, the communication layer, the data layer, and the application layer. In order to enable the communication among the devices, a protocol is required. However, it is difficult to find a solution suitable for networks comprised of devices that use different communication technologies such as WiFi and LoRa. In this paper, the SWAP (Smart WAter Protocol) protocol is presented. It enables interoperability between LoRa and WiFi devices. Furthermore, the messages are designed for the specificities of smart irrigation systems for urban gardens in Smart Cities. Lastly, the protocol was developed and tested with low-cost devices to determine its performance.
The rest of the paper is organized as follows. Section 2 presents the related work. The methodology, including the description of the architecture and the protocol, is presented in Section 3. The results are depicted in Section 4. Lastly, Section 5 presents the conclusion and future work.

II. RELATED WORK
With the introduction of the concept of Smart City and the growing interests in deploying this type of smart systems, the development of solutions that cater to the need of irrigating vegetated areas within urban environments as part of the functionalities of Smart Cities has been increasing. Amit Kumer Podder et al presented in [6] a smart IoT system for urban agriculture that considers temperature, humidity, and soil moisture. The controller incorporated an ESP8266 chip, and the utilized sensors were the DHT 11 for temperature and humidity and a soil moisture sensor comprised of two probes. A relay module and a water pump were included as well. Tests were done to determine the error percentage with results below 1.5% for temperature, and below 3% for humidity and soil moisture. Hamza Benyezza et al. presented in [7] an irrigation strategy based on zones and implemented through IoT. The focus of this strategy is the reduction of water usage and the optimization of plant growth. The sensors deployed on the green house monitor different parameters of the environment such as soil humidity and temperature, and fuzzy logic is applied to obtain the best decision. The results show a reduction in water and energy consumption. A smart design for the irrigation of urban trees in the context of smart cities was provided by Henner Gimpel et al. [8]. The prototypes were deployed in Frankfurt, Germany, including 18 sensors that monitor soil moisture, temperature, and water potential for the evaluation of 8 trees. Furthermore, the sensors gather data at different depths. The authors estimate a reduction in 1 million liters for the total of 5000 young trees of Frankfurt. José Marín et al. presented in [9] a system for urban lawn monitoring. It is comprised of an Arduino board with a camera mounted on a drone. The drone flies over the grass to obtain pictures that are analyzed utilizing a rule-based algorithm that indicates the quality of the grass in terms of coverage. The tests were performed with 12 pictures, showing a 100% accuracy. Furthermore, tests were performed to determine the suitability of monitoring grass fields with drones. The results show that drones should be used for fields larger than 1000 m2. An IoT module for resource and energy saving in smart cities was developed in [10] by Vijender Kumar Solanki et al. The module is comprised of an Arduino board, sensors such as water level indicators and soil moisture detectors, and other components such as relays. These modules are deployed on different appliances such as garden sprinklers or garden lamps, among other devices, to reduce the energy consumption. Luis Cano et al. proposed in [11] a smart irrigation system for city parks. The system considers, temperature, humidity, land area, and the weather forecast. Humidity and temperature maps of the parks are generated, and the data is analyzed with a fuzzy inference system (FIS) to obtain the irrigation needs of the parks. The application of this proposal is expected to generate significant savings. Lastly, André Glória et al. presented in [12] a smart water management system that collects data in real time and obtains the irrigation requirements of the garden. The nodes communicate utilizing the MQTT protocol. The results showed a reduction of 34% of water usage if data from humidity, temperature and soil moisture is obtained. In the case of only providing temperature data, a reduction in water usage of 26% can be obtained. On the other hand, it is also important to consider the network required to deploy smart irrigation systems in Smart Cities and the security requirements specific of this type of systems. Lorena Parra et al. proposed in [13] a network topology formation algorithm for Wireless Sensor Networks in smart gardens. The algorithm considers the resources and capabilities of the devices, generates piconets and communicates them establishing slave-slave bridges. The simulation experiments were performed considering varied scenarios. The provided results include the formation time for the different scenarios and the created links. An edge computing framework for smart cities to reduce the latency that may be introduced in scenarios where cloud computing is utilized was designed by SK Algamir Hossain et al. in [14]. The information gathered about the environment was utilized to generate a situation that is later analyzed. A prototype implementation was developed utilizing Laravel Framework 5.6 and DK version 8. Existing databases were utilized to perform the tests of the prototype. The results showed that the latency was reduced, and the proposed framework provided situational awareness. Finally, Seyyed Keyvan Mousavi et al. presented in [15] a hybrid cryptographic algorithm to provide integrity and confidentiality to smart irrigation systems. The algorithm is based on Rivest cipher (RC4), the Secure Hash Algorithm (SHA-256), and the Elliptic-Curve Cryptography (ECC). This way, the ECC algorithm encrypts the RC4 key. After that, the result is transformed to SHA-256. The results showed that the proposal is secure to Man -in-the-middle (MiM) attacks, provides robust confidentiality, and it has better performance than other existing proposals. This paper expands on the communications between the different elements that comprise a smart irrigation system for a Smart City and presents a heterogeneous communication protocol to connect devices that utilize different wireless technologies.

III. METHODOLOGY
In this section the architecture of the proposed system for irrigation in Smart Cities, the proposed protocol and the states of the nodes are presented.

A. ARCHITECTURE
In this subsection, we propose an architecture for a smart city irrigation system intended for urban gardens.
The need for water resources optimization has been addressed by many smart irrigation systems intended for agriculture. However, there are not as many proposals focused on urban gardens and the deployment of smart devices for irrigation within the context of a smart city. Firstly, it is important to notice some relevant differences between the environment of an agricultural field and the environment of an urban garden.
Firstly, the most evident difference is the deployed infrastructure that provides access to energy and the Internet. While agricultural fields are located in remote areas often with no access to the electric grid nor to any devices with internet access, smart cities have many options available to provide smart devices with energy and to enable the communication among these devices.
Secondly, the crops in agricultural fields need to meet the standards for human consumption or the specific requirements of their industry, thus, these plants often require more care. On the other hand, the trees, plants, and the grass of urban gardens are usually more robust and could be irrigated with other sources of water such as filtered wastewater as the standards for these types of plants are not as strict as those for agriculture.
Lastly, it is important to consider possible interferences when deploying devices with wireless communications. Smart irrigation systems in agricultural fields will often be the only network deployed in the area. However, depending on the location, amplitude, and the surrounding area of the urban gardens, other networks from businesses, and other smart city functionalities may interfere with the frequencies selected for data transmission in the smart city irrigation management system.
Considering all these aspects, the architecture in Fig. 1 is presented. The Soil Monitoring Nodes are comprised of an embedded system and sensors for temperature, humidity, and pH monitoring. These nodes transmit the gathered data through WiFi to the Cluster Head as this wireless technology as a transmission range that allows distances up to 100 meters approximately. The cluster head is able to transmit with both WiFi and LoRa. LoRa is employed to forward the data to the devices located at distances further than 100 meters. This node receives the data form the soil monitoring sensors and sends it to the Environment monitoring Aggregator node. These nodes include air temperature, air humidity, luminosity, and precipitation sensors to determine the environmental conditions of the garden. This is important due to the differences that can be found at the streets with buildings, vehicles and the asphalt, and the parks with green areas that may be cooler and more humid. After that, the data is forwarded to the Gateway. Different LoRa gateways may receive the data depending on the location of the aggregator node and the gateway. Finally, the data is transmitted through Ethernet to the Data Center where it is stored and analyzed.

B. PROTOCOL DESCRIPTION
In this section, the message format and the message exchange of the protocol is presented.
The proposed protocol SWAP enables the communication between the devices of the irrigation management system for smart cities. This protocol functions over LoRa and over UDP for the WiFi elements of the network. The message format of the protocol is presented in Fig. 2. The header is comprised of four fields. The NODE_ID field is one byte long and it is a random number assigned to the device. Each device has its own ID number that is not shared with any other device. The next field is the NODE_TYPE. It is a code assigned for each type of node. Therefore, nodes of the same type will have the same number on this field. The MESSAGE field indicates the type of message that is being forwarded. Lastly, the PRIORITY field is the last field in the header. It is one bit long and indicates if the message is considered as a priority. The header is followed by the payload, which is comprised of the data gathered by each of the sensors in a node.
The different node types include the Data center, the gateway, the aggregator, the CH, the soil monitoring nodes and the Users, as it can be seen in Table 1. On the other hand, Table 2 shows the message types, which are are the REGISTER message, the DATA message, the ACTION message, the ERROR message, the DOWN message and the BATTERY message.
The message Exchange of the protocol is presented in Figure 3. Firstly, all the nodes are registered in the Data Center. In order to do so, the nodes send a message of the REGISTER type starting from the closest to the Data center up to the furthest ones. The Data Center responds with a REGISTER message including in the payload the ID assigned to that node. After that, the nodes begin obtaining data from the sensors and sending it to the data center. If the Data Center detects that a packet is lost, it can send a data petition utilizing the same DATA message. The DATA message is not acknowledged. When the Data Center decides for the actuators to perform any action, it sends an ACTION message indicating in the payload the new state of the node. This message is acknowledged to let the Data Center know that the action has been performed. The devices may detect some errors from their own elements. If any errors are detected, the node sends the ERROR message to the Data Center indicating the motive of the error in the payload. This message is acknowledged as well. The nodes may also detect failed connections to other nodes. In that case, a DOWN message is forwarded indicating the ID of the node with the failed connection. The Data Center then acknowledges the message. If no acknowledgement was received, the message would be forwarded as well. Lastly, if one of the electronic devices detect low remaining energy, it forwards a BATTERY message to the Data Center to let it know that it requires a battery replacement. This message is acknowledged as well.

C. STATES OF THE NODES
In this subsection, the states of the nodes are presented. Depending on the different nodes and their specific functionalities, each of the nodes go through a different set of states: -Register state: When the node is in the first state, a REGISTER message is forwarded to the data center to receive their Node ID.
-Verification state: This state is reached after the register state. The correct operation of the node, its elements and the communications are verified. In case of the detection of an error, a report is forwarded with an ERROR message to the Data Center. If the node is working correctly, no messages are forwarded. The state can be reached again by request of the users.
-Acquisition state: The data is obtained from the sensors and forwarded to the next node in the architecture.
-Data state: A DATA message is forwarded to the Data Center with the available information.
-Alert state: This state is reached when an error or an alert of the types DOWN or BATTERY are detected.
-Action state: This state is reached when an ACTION message is received. The four states of the Gateway are presented in Fig. 4: The states of the actuator are presented in Fig. 5. The states of the monitoring nodes are presented in Fig. 6. The states of the CH nodes and the Aggregator nodes are presented in Fig. 7.

IV. RESULTS
In this section, the results of the performed tests are presented.
The tests were performed in a vegetated area close to edifications as it is shown in Fig. 8. The gateway was placed at the top of a building, and the rest of the devices where at street level. All the tests were performed with a total of five devices. One Gateway, one Aggregator, one cluster head, and two soil monitoring nodes. The Wemos Mini D1 devices were utilized for the soil monitoring nodes. They include the ESP8266 WiFi chip and incorporates and antenna. For the rest of the nodes, the Heltec LoRa WiFi 32 v2 was utilized. It allows transmitting with both WiFi and LoRa. For the experiments, the two soil monitoring nodes send messages to the CH each minute. The CH then sends the data to the Aggregator, and lastly, the aggregator sends the data to the gateway. The duration of the experiment was 10 minutes. Furthermore, the tests were performed for both 433 MHz and 868 MHz frequency bands, and the delay at the CH node was variated from 0 ms to 500 ms to avoid collisions between LoRa packets.

A. 433 MHZ FREQUENCY BAND WITH DELAY OF 0 MS
In this subsection, the results for the case of transmitting with the 433 MHz frequency band and a delay of 0 ms are presented. Fig. 9 shows the results of the throughput for each of the nodes. Fig. 9 a) and b) show the results for the soil sensing nodes. As it can be seen, the maximum throughput peaks are 512 bps for and 760 bps, with an average of 5.64 bps and 6.46 bps. Fig. 9 c) shows the throughput and loss packets of the CH node. The maximum throughput peak is 256 bps, and the average is 3.17 bps. A total of 7 packets were lost in this test. The results of the Aggregator node are presented in Fig. 9 d) with a peak of 160 bps and an average of 2.62 bps. Lastly, the results for the gateway are presented in Fig. 9 e) with a peak of 56 bps and an average of 0.77 bps.  Fig. 10 presents the results for the case of the 433 MHz frequency band with a 250 ms delay. Regarding the soil monitoring nodes (See Fig. 10 a) and b), the peaks in the throughput reached 760 bps and 512 bps. The average values were 7.70 bps and 6.88 bps. Fig. 10 c) presents the throughput of the CH node and the lost packets. The maximum peak is 368 bps, and the average value is 5.06 bps. Furthermore, 10 packets were lost. The results for the Aggregator node are presented in Fig. 10 d) with a peak of 216 bps and an average of 3.50 bps. Lastly, the maximum throughput for the gateway is 152 bps and the average is 1.24 bps (See Fig. 10 e). Fig. 11 presents the results for the case of the 433 MHz frequency band and a delay of 500 ms. The results for the soil sensing nodes show peaks of 512 bps and 760 bps with averages of 6.05 bps and 7.70 bps (See Fig. 11 a) and b). The CH node has a maximum throughput of 456 bps and an average of 4.56 bps (See Fig. 11 c). The number of lost packets in this test were 2. For the Aggregator node, the maximum throughput was 144 bps, and the average was 1.33 bps (See Fig. 11 d). Lastly, the gateway presented a throughput maximum peak of 304 bps and an average of 3.94 bps (See Fig. 11 e).

D. 868 MHZ FREQUENCY BAND WITH DELAY OF 0 MS
The results for the case of 868 MHx and 0 ms of delay are presented in Fig. 12. The soil sensing nodes have peak throughputs of 512 bps and 760 bps and averages of 5.64 bps and 7.70 bps (See Fig. 12 a) and b). For the CH node, the maximum peak is 456 bps and an average of 4.66 bps (See Fig. 12 c). The number of lost packets for this case was 7 packets. The aggregator node had a throughput peak of 208 bps and an average of 3.21 bps (See Fig. 12 d). For the gateway, the peak was 56 bps, and the average was 1.02 bps (See Fig. 12 e).

E. 868 MHZ FREQUENCY BAND WITH DELAY OF 250 MS
The results for the case of 868 MHz and a delay of 250 ms are presented in Fig. 13. The maximum throughput for the soil sensing nodes was 512 bps and 760 bps, and the average was 5.64 bps and 7.68 bps (See Fig. 13 a) and b). The maximum throughput for the CH node was 456 bps and the average was 5.16 bps (See Fig. 13 c). The number of lost packets is 2. For the Aggregator node, the peak throughput is 256 bps, and the average throughput is 4.09 bps (See Fig. 13  d). For the gateway, the peak was 144 bps, and the average was 1.50 bps (See Fig. 13 e).

F. 868 MHZ FREQUENCY BAND WITH DELAY OF 500 MS
The results for the case of the 868 MHz frequency band and a delay of 500 ms are presented in Fig. 14. The maximum throughput for the soil sensing nodes are 512 bps and 760 bps, and the average throughput is 5.61 bps and 7.70 bps (See Fig. 14 a) and b). The CH node has a maximum throughput of 408 bps and an average of 4.56 bps (See Fig.  14 c). The total of lost packets was 2 packets. The Aggregator node had a maximum throughput peak of 256 bps and an average throughput of 3.57 bps (See Fig. 14 d). Lastly, the gateway presented a maximum peak of 144 bps and an average throughput of 1.33 bps (See Fig. 14 e).  Bandwidth consumption for a) WiFi 1 node, b) WiFi 2 node, c) CH node, d) Aggregator node, e) Gateway node transmitting in the 868 MHz frequency band with delay of 500 ms.

V. CONCLUSION
Smart Cities have seen a rapid growth in the recent years with projects focused on traffic management, energy management, or water management, among other functionalities. Smart water management solutions can be focused on the reduction of water consumption but also on the treatment of wastewater and the reuse of this treated water or the water collected from infrastructures such as rainwater tanks. In this paper, we have presented a communication protocol intended for smart irrigation systems as part of a Smart City solution. The protocol considers the characteristics of these systems with specific messages for different actions and alerts. Furthermore, this protocol operates with a network comprised of both WiFi and LoRa devices. Tests were performed in an urban environment utilizing low-cost deices. The results showed the good performance of the proposal with minimum packet loss utilizing the configuration that includes a delay of 500 ms in the CH node.
As future work, we will include more types of wireless technologies to the protocol so as to provide more interoperability and to widen the possibility of the addition of new functionalities.