Integration of Agricultural Wireless Sensor Networks to Web-of-Things Through an Edge-Computing-Enriched WSNs/WoT Gateway

To connect agricultural wireless sensor networks (WSNs) to web services and applications, the agricultural WSNs/WoT gateway is empowered with local data management and network maintenance functions for downstream WSNs in addition to traditional upstream data collection. This work demonstrates a low-cost, highly scalable, rapidly deployable web of things (WoT) gateway with edge computing capabilities. First, an agricultural WSNs/WoT topology is architected, connecting a ZigBee WSNs to the Web for remote monitoring the local environmental and agronomical information, and simultaneously for managing the solar-powered WSNs for a prolonged lifespan according to the instant data scrawled from the cloud. Second, a WSNs/WoT gateway is designed with the hardware platform Raspberry Pi 3, which serves multiple needs for bidirectional information exchange and local WSNs management. Finally, experimentation demonstrates the proposed hardware platform and architecture can perform edge computing, and efficiently realize the up and down transmission and distribution of data stream.


INTRodUCTIoN
Recent advances in sensors, actuators and wireless radio frequency (RF) technologies and their convergence with the Internet offer vast opportunities for the development and application of WSNs for agriculture (Pierce & Elliott, 2008). conventional agricultural WSNs merely collect local environmental or agronomical information and send them to the remote terminal, while contemporary smarter applications support web-based, bi-directional services with highly dynamic content and real-time data (Piromalis &

ARCHITECTURE oF THE AGRICULTURAL WoT
The rapid development of embedded technology, sensor network technology, and RFID technology has provided support for the interconnection among objects. A wide variety of smart things, complex transformations between different network protocols and application exclusivity have led to the complexity of inheritance among the WoT. Therefore, the Web of Things technology that combines Web technology and WoT technology has emerged (Gubbi et al., 2013;Khan et al., 2012). WoT integrates smart things, such as RFID tag objects, sensor nodes, etc., using web technologies to provide an open platform for the WoT. WoT application development can simplify the application integration of intelligent objects by making full use of mature Web development tools, programming languages and methods, and also can realize the fusion between the physical space of intelligent objects and the virtual space of web applications (Ferdoush & Li, 2014).
Most WoT applications are still closed-loop applications, and resource information lack sharing between applications, which is not conducive to promoting application innovation. WoT technology virtualizes objects into Web resources, providing the foundation for interoperability between objects, which enables interaction and collaboration among objects. WoT technology is open and flexible. This paper proposes and implements a WoT framework, which uses the web technology gateway and WoT service platform to open sensor capabilities to the application layer. The Classical architecture of WSNs/WoT is shown in Figure 1. The architecture mainly includes four parts. data-sending tasks for long-term operation. The web-API use the API interface service provided by Ali cloud. This paper focuses on the design of the gateway.

Functionalities of a WSNs/WoT Gateway
As WoT designers push intelligence to the edge of the WoT, the WSNs/WoT gateway must serve multiple needs, such as protocol conversion and data transmission between multiple sensing networks and basic networks. In addition, the gateway also needs to have a device management function. The gateway supports WSNs communication interface and supports TCP/IP, WiFi, 3G/4G, GPRS communication interfaces and other protocol interfaces. Therefore, the WoT gateway features the following functionalities: 1. Extensive access capabilities: There are many transmission protocols currently used for shortrange communications, each of which has its targeted application and lacks compatibility and uniform standards. Data access capability for heterogeneous networks is one of the gateway's essential functions. 2. Protocol conversion: The WoT gateway solves the communication problem between WSNs and the traditional Internet. Therefore, a unified information model for information exchange needs to be established to realize the conversion of communication protocols. This function standardizes the construction of agricultural WoT applications and achieves the goal of efficient application integration and data sharing. 3. Data Interoperability: Interoperation refers to the process of interactive operation of data and information sharing between two systems (Calvo et al., 2016). The interoperability between information systems is the basic requirement for system integration. 4. Management functions: The amount of heterogeneous data received by the gateway need to be properly managed. Simultaneously, it receives not only the node data of the sensor network, including the node's identification, parameters, status and other information, but also the control commands issued by the remote monitoring terminal. Therefore, the gateway needs to identify, classify, and process all kinds of data to achieve unified management (Al-Fuqaha et al., 2015). 5. Edge computation: Each WSNs/WoT gateway is designed to manage a local area WSNs.
The sensory data from WSNs are stored in a light-weighted database and optimally selected for transmission. Meanwhile, an energy-aware task scheduling algorithm parses the Web-API package for solar radiation forecasting data to hibernate or invoke the WSNs node in real-time according to the node energy status and its energy-harvest prediction. Both of these strategies alleviate the server and WSNs computational workload in an edge computing manner.
The heterogeneity of application scenarios and applications brings lots of challenges to the abovementioned gateway design. It is critical to design and implements efficient algorithms and hardware platform for customizing the WSNs/WoT gateway. Here an open-source hardware platform Raspberry Pi 3 is adopted as a future-ready and easily customizable edge computing device that can be expanded and configured to match and scale to every requirement in a gateway context. The Raspberry Pi Card computer was originally designed for student computer programming education. Considering its powerful scalability and excellent performance, Raspberry Pi has become an important part of education, research and amateur network physical systems. It is based on the LINUX operating system and supports C, java, python and other languages. It provides Ethernet, USB, and HDMI interfaces, featuring processing, networking, and video decoding capabilities (Molano et al., 2015;Upton & Halfacree, 2014). It also exposes its General-Purpose Input-Output pins (GPIO), making it a simple matter to connect peripherals. Because the Raspberry Pi does not have a memory chip, all data, including the operating system, needs to be saved on a micro-SD card. Such a resilient hardware architecture can help create the secure, scalable and robust infrastructure needed to facilitate WSNs/WoT convergence, reduce risks and maximize overall working time. Samourkasidis A et al proved that Raspberry Pi can be used as a small, lowcost data repository that provides persistent data storage and data sharing services (Samourkasidis & Athanasiadis, 2017). Due to the simple and easy-to-use, low-cost features of the Raspberry Pi platform, it has swept the world in just a few years. The application of the Raspberry Pi in a variety of situations has gone far beyond its educational significance. These papers (Jain et al., 2014;Leccese et al., 2014;Noriega-Linares & Ruiz, 2016;Rudin et al., 2016;Segura-Garcia et al., 2015) apply the Raspberry Pi to experimental research, smart city, home automation, intelligent medical and other fields. In these papers (Flores et al., 2016;Kamath et al., 2019;Moshayedi et al., 2019;T. & I., 2020;Z. et al., 2020), Raspberry Pi is used in agricultural WoT systems. The authors can conclude from these works that the Raspberry Pi is powerful and cost-effective, and it is feasible to build a gateway platform for the Web of things. In this paper, the authors designed and implemented a lightweight, low-cost gateway system using a Raspberry Pi as a hardware-centric platform. It provides WIFI/ZIGBEE-based WSNs interfaces, data interoperability, data storage, and data sharing services.

Hardware
The WoT gateway uses the Raspberry Pi as the center to establish a gateway hardware platform, which the authors denote as a "network repeater". On one aspect, the network repeater, which can be connected to the Internet in various modes such as Ethernet, WiFi, or GPRS, is used as the gateway main hardware to implement wide access to communication protocols. The remote server can open ports to receive data. On the other aspect, the network repeater is connected to the embedded sensor network coordinator, which implements USB to TTL serial communication through the PL2303. The coordinator then performs parameter configuration and topology management on the sensor network. The function module is shown in Figure 4(a), and Figure 4(b) shows the photograph of the gateway. To better illustrate the functionality of the gateway, the authors match the functionality implemented by the gateway with the general overview functionality in Section 3.1, as shown in the following table 1.
The proposed sensor network coordinator selected C8051F340 as the master chip. The C8051F34x devices are fully integrated mixed-signal system-on-chip (Microcontroller Units) MCUs. It is fully compatible with the standard 8051 core, and instruction execution speed is greatly improved (Jassas et al., 2015). The coordinator includes four parts, the ZigBee module, the WiFi module, the voltage conversion module, and the serial communication module. The ZigBee module selects the DRF1605H module. This module can realize the conversion between ZigBee and serial port communication. The The sensor node also includes a ZigBee module, a WiFi module, a voltage conversion module, and a serial communication module, and the design implementation is also the same as the coordinator. The difference is that, in order to achieve solar power and energy-aware, the solar node voltage regulator module, relay module and battery energy measurement module are added to the sensor node. In addition, each sensor node carries a 3000mah lithium battery for powering and storing solar energy. The solar power supply voltage regulator module is used to connect to solar panels with unstable input voltage. The relay module controls the sleep and working state switching of the node. When the relay is turned on, the sensor and the wireless transmission module are energized. Otherwise, the power is turned off. The battery energy measurement module calculates the remaining battery power.

Software development
The functionalities of the WoT gateway are as follows. (1) To aggregate the data from the agricultural sensor network and realize it by using the Zigbee coordinator as the data receiver. (2) To perform data management such as data storage and energy efficiency scheduling in an edge computing method.
(3) To keep the real-time communication of WSNs/Web and maintain the stability of WSNs. The WoT gateway prototype software function module is shown in Figure 5.
In this system, each node has the function of data acquisition and independent routing. The data's format is shown in Table 2. The sensor network coordinator receives data from the WSNs. It identifies the data source address ID after judging whether the data's format is correct, and assigns a network repeater recognized address ID to the data again. The collated data is sent to the Raspberry Pi through the serial port. A timer is started in the program to eliminate the error redundancy periodically generated when receiving data errors. When the data is wrong, the receptive fields and send fields are cleared. Similarly, the data that the coordinator accepts from the network repeater is still processed, then address reassigned, and finally sent to WSNs.
The network repeater communicates with the serial port of the WSNs Coordinator prototype through the USB interface, and uses the Python language to write an application programming interface (API) based on the USB interface to realize the transmission of sensor data. First, accept data from the coordinator and parses the node data, such as the node ID, environment data, and battery voltage. And then, sqlite3, a lightweight integrated database module in python, creates data Table 1

Function Description
Extensive access capabilities For the WSNs side, the gateway provides Zigbee and wifi communication methods. For the web side, it provides three communication methods: Ethernet, WIFI, and GPRS.
Protocol conversion For different protocols, there are corresponding interfaces in the gateway, and then the data is parsed and converted.

Data Interoperability
The authors can query the real-time and historical data of WSNs in the cloud server, and WSNs can also receive web scheduling commands.

Management functions
The gateway can implement various functions such as data storage and forwarding, WSNs address allocation and network topology, and energy scheduling calculation.

Edge computation
The authors combined WEB-resource information and local data to design energy-aware scheduling. This work is done in the repeater instead of in the cloud server.
tables for normalized storage, and meanwhile, Wxpython, an image user interface module of python, realizes real-time display of node data on the network repeater. second, the program sends TCP/IP client connection requests to the cloud-server and export the data to the server from sqlite3 database. In the Energy-Aware Scheduling task, the network repeater inputs battery voltage data into the battery model to obtain the remaining battery power. At the same time, it will obtain weather data through the weather API and enter it into the Energy-Aware Scheduling Algorithm(EASA) along with the battery model output data. Finally, the scheduling scheme is obtained and a control command is issued. The communication flow and data flow are shown in Figure 6. And the pseudo-code of EASA is shown in Algorithm 1.

EXPERIMENTATIoN ANd RESULTS
The key components of the perceived node's energy consumption are data acquisition, wireless transmission, and the basic energy consumption of nodes to maintain operation. It is important to formulate the operation strategy of the node device according to the intensity of the sunlight and the remaining power of the battery in the energy-aware scheduling algorithm. The given design is to adjust the frequency of data acquisition and transmission, as described in the energy-aware scheduling algorithm. The authors measured the power consumption of the node in the high-power state, low power state, idle state, and sleep state, and the result is shown in table 3. More specifically, the high power, low power and idle states respectively indicate three different data acquisition and transmission frequencies for the node device. The Sleep state means that the node does not perform  active transmission activities, and only maintains a surviving state, ensuring that it can be woken up when the power reserve is sufficient. The data shows that the power consumption of the node in the low power state is 31.11% lower than that in the high-power state. The overall energy consumption of a node is calculated indirectly from changes in battery capacity. The node device uses two parallel 4.2V lithium polymer batteries, which are mainstream in the market. Accurate battery capacity measurements are more complicated. The authors use the classic empirical model shown in Figure 7 to estimate the percentage of battery capacity remaining. The relationship between the voltage and the remaining capacity of a standard 4.2V lithium-ion battery can be represented by the curve in the empirical model. Therefore, the authors only need to measure the voltage of the battery to estimate the remaining capacity of the battery.
The authors measured and recorded the voltage value of the battery. The sampling period is 5 minutes. Here the authors extract the node battery voltage data collected from October 18 to October 23. Set the accumulated hours, which the start time is 0:00 on October 18, 2017, as the X-axis, and the battery voltage as Y-axis to establish a line graph shown in Figure 8(a). The vertical dotted line indicates 0 o'clock of the day. It can be seen that the battery voltage drops steadily from around 6 p.m. to 6 a.m. There is no light at this time, so the solar panel cannot generate energy and the battery is in a pure consumption state. The battery voltage rose in varying degrees between 6 a.m. and 6 p.m. This is because solar panels have different charging powers under different weather conditions. The weather conditions are shown in Table 4. The overcast, cloudy and light rain are all meteorological representations in the weather forecast. Overcast in meteorology refers to more than 90% covered by clouds. Cloudy refers to the cloud coverage of the sky is 30% ~90%. It can be seen that when the weather is light rain or overcast, the battery voltage is in a relatively low state. However, it can still be charged during noontime. In stable cloudy weather, the battery voltage changes in a certain periodicity. This means that even in cloudy weather, the node can maintain sufficient power. So, if there is less cloud, the battery can get more power. In energy-aware scheduling. The authors set the node to run at low power operation when the is lower than 60% and the light is insufficient. The