GEOSPATIAL SENSOR WEB ADAPTOR FOR INTEGRATING DIVERSE INTERNET OF THINGS PROTOCOLS WITHIN SMART CITY

: In recent years, the multi-scale comprehensive perception is central to smart city development. We propose an "adaptor" for geospatial sensor web as an integrated sensory system that can integrate access to geodetic equipment based on the Internet of Things technology with multiple platforms and protocols. At the same time, the acquisition, fusion, and processing of sensory resources can perform. The geospatial adaptor can access and process sensors of different IoT protocols to different conditions simultaneously. Grace to this geospatial adaptor, a considerable number of the sensor based on IoT in the community, can achieve distributed access, ensuring the better robustness of the geospatial sensor web. This paper describes the system architecture of the geospatial sensor web adapter. Furthermore, from the perspective of protocol access, it introduces the access capabilities of geospatial sensor web adapter to the standard IoT interface protocols. By comparing the geospatial sensor web adapter with traditional observation methods by experiments and acquisition of test data. The results show that the geospatial sensor web adapter can achieve powerful access capabilities and network stability, and it is a better solution for heterogeneous sensing platform access in smart cities.


INTRODUCTION
How today's humidity? Is the water in our community polluted? How the air quality community today? Should we need to water our land now? These problems may not get a real-time response in the past. Today, thanks to the smart city, which seems to be a breeze. As a terminal user, he only cares about results, and the source of the data is inseparable from the perception service system in the smart city. In other words, city perception service systems are essential. It bases on the rapid development of the earth observation technology, sensors technology, and the Internet of Things (IoT) technology (M. Wollschlaeger, 2017). These two core technologies support the development and application of smart cities. The core product brought by earth perception technology is the geospatial sensor network named Geospatial Sensor Web (GSW) (Chen et al., 2012).
In the history of the geological observations, there are three stages here. Firstly, which is dominated by manual observations; In the second stage about 2000, which is dominated by computerized observations; Nowadays, the observations based on sensor networks. Figure 1 shows the Geoscience Research Model Development (Zhang et al., 2018): However, with the iterative update of sensor technology and the Internet of Things technology, the earth observation system is gradually developing from the Internet to the Internet of Things. Multi-scale comprehensive sensing of smart cities is a new application of geospatial sensor networks under the Internet of Things framework.
When we deploy the sensors to observe the earth, at present, the architecture always in "Point to point." It means a considerable number of sensors collect the data and upload the data to a server directly and immediately. The server receives the data from sensors named "Sensor Observation Service" Corresponding to SOS, there are Sensor Alerting Service (SAS) and Sensor Planning Service (SPS). These servers communicate directly with the data source (sensor). The advantage of this method is simply to access the sensors. It can realize the observation and planning of the sensors with software (Chen et al., 2014).
Nevertheless, in a smart city, even in a community, a significant amount of heterogeneous sensors will be deployed. If we still adopt the legacy, it will inevitably lead to an increase in the amount of data and requests on the server, and the server of sensors is instability. Alternatively, the perception data transmits to the server, which is also limited by the quality of the Internet connection. Therefore, the severe problem is that the server will be down frequently. Meanwhile, the platform with various protocols, with the city perception service as an example thereof, divided from the wireless communication protocols, including ZigBee, LoRA (Semtech Corporation, 2015), Bluetooth, RFID, and NB-IoT; Divided from the data communication protocol, including ModBUS, ProfiBUS, 1-Wire, RTP/RTCP. From the division of application platforms also includes Mavlink, an opensource drone. It can see that the method "Point to Point" will no longer be supported for accessing such a tremendous perception service in a zone. Therefore, an integrated access method and software and hardware system must propose. Otherwise, due to the heterogeneity of IoT sensing devices and communication protocols, the information will be isolated, and there will be a massive delay in information fusion, which will restrict the comprehensive perception and integration of smart cities. It is also one of the severe problems of intelligent decisions.
In the construction of smart city sensing systems, usually, we use the sensors supplied by many different manufacturers. Each manufacturer may choose different wireless communication protocols and data transmission protocols, so it is necessary to use a large number of Remote Terminal Units (RTU) from various manufacturers for sensor access. There are several problems, the first problem. It is a repeated acquisition of data. Even for sensor kits produced by different manufacturers, there will be repeated measurements of specific environmental parameters. Therefore, a large amount of data not necessary will be generated, which will increase the resource consumption of acquisition and storage. Secondly, different sensor manufacturers bring a large number of RTU modules. They will upload data to the SOS server through the Wide Area Network (WAN). Therefore, it is obliged to enable a large number of ports for receiving data, which will cause network instability. The third problem is that different sensor manufacturers use different data protocols and encoding methods. The SOS. server needs to analyze the data uploaded by each RTU according to different protocols used by different manufacturers (See Figure 2, the Sensor Web Access in the past).

Figure 2. Sensor Web Access in the past
To solve this problem, we proposed a middleware named "GSW Adaptor". It is a comprehensive, integrated system and based on the SWE international standard system. It dynamically integrates a large number of heterogeneous sensors in smart cities and provides edge computing capabilities. Generally speaking, it locates between the sensors (edge devices) and the server. This adapter can be compatible with seven types of platforms (the ground-aware networks, drones, RFID micro-networks, monitoring equipment, uncrewed mapping vehicles.) and ten protocols (based on user needs, compatible with and currently connected to the Internet of Things) ZigBee. LoRA, RFID, Bluetooth, NB-IoT, Wi-Fi, ModBUS). It realizes the problem of access to different protocols and avoids excessive dispersion of the acquisition devices. In addition to sensing devices connected to different IoT protocols, it can conduct preliminary analysis and processing of the collected data and upload them to the server through the OGC interface specification, thereby reducing the number of data packets sent to the server and ensures the stability of the network system. In the case of server network interruption, the adapter can ensure that data continues to be uploaded generally without being interrupted.
With this research and innovation, we have improved the existing "Point to Point" geospatial sensing resource acquisition and transmission mode and introduced a "GSW Adaptor" integrated system to access heterogeneous sensors with various protocols. Thus, the data can be collected, processed at the "GSW Adaptor", and uploaded to the server uniformly. It dramatically improves the access ability and data processing ability of heterogeneous sensing resources.

The GSW Adaptor
The "GSW Adaptor" is an integrated hardware and software system. It is based on the Open Geospatial Consortium (OGC) Sensor Web Enablement (SWE) standard and follows its specifications and protocols. Compared to the observation mode like "Point to Point," the GSW Adaptor can achieve simultaneous access to seven different types of observation platforms such as the in-Situ sensors web, open-source drone with Mavlink protocol, Surveying and mapping robots, micro-network observation with RFID, the surveillance cameras.
Actually, it is designed to support more than ten protocols of IoT Sensors at the same time, including ZigBee (IEEE 802.15.4, 2006), LoRA, Bluetooth / Bluetooth -Low Energy (IEEE 802.15), RFID (Radio Frequency Identification) and NB-IoT (Narrow Band -IoT). The above-described protocols are the radio transmission protocol for connecting the sensor nodes to the GSW Adaptor. Grace to Wi-Fi and cellular network connection, such as 4G and 5G, they can help the GSW Adaptor establish the network connection between the GSW Adaptor and the server. In the GSW Adaptor, the data communication protocols, for example, ModBUS, ProfiBUS, 1-Wire, RTP/RTSP/RTCP, and Mavlink, can be parsed in the GSW Adaptor. Thus, with data receiving modules and computers that integrated into the GSW Adaptor, it can receive data observation from sensors and analyze the data in the GSW Adaptor synchronously. The processed data pack is encapsulated by the GSW Adaptor, via Wide Area Network, the data pack will upload to the database in Sensor Observation Server (SOS). All process will follow the specification by OGC.
From the architecture diagram (Table 1 and Figure 3), there are six modules in the hardware part. Furthermore, uploading the data to Sensor Observation Server (SOS), it is also possible to control and plan the sensors, just like a Sensors Planning Server (SPS). The third module is a data warehouse. It supports up to 8 hard disks, which is sufficient to store a large amount of structured and unstructured data locally. Currently, a hard drive with 3TB storage space installs in the system. The fourth part is the central core of the GSW Adaptor, which is a transceiver that integrates five radio protocols, which is a base station to ZigBee, LoRA, Bluetooth, and RFID. The data received by these five protocols passes through their Remote Terminal Unit (RTU), which is transmitted to the computer via Ethernet to complete the data acquisition process. To ensure the continuity and stability of data acquisition, the power of the RTU provides by a lithium battery module. Due to the technical characteristics of NB-IoT, it is a communication protocol similar to a cellular data network. In the GSW Adaptor, we develop a device similar to a "soft gateway" through Raspberry Pi 4B + (an edge computing device), to complete the receiving and forwarding of the data of the sensors with NB-IoT. The fifth module, it can help that GSW Adaptor communicates with the server. It includes two ways of network connection, Local Network Connection, and Mobile cellular data network connection. When the local network connection is regular, Wi-Fi or wired local area network (LAN) is preferred. If the local system is interrupted, the mobile cellular data network to maintain effective communication with the server. The last part is the display and dashboard. With a 13.3-inch touch screen, users can operate access management of sensory resources, system diagnosis, system maintenance, and present the results. A panel is the module of dot-matrix LCDs; it shows the status of system operation only.

Multiple Protocols Access
In the previous chapter, we have introduced the problems of access Point to Point in the past. So, we need to provide a multiprotocol access method in our GSW Adaptor. Through integrated and embedded development, we integrate the RTU devices and radio transceivers of sensors of multiple wireless communication protocols in a module. And the NB-IoT sensors based on the operator network are accessed through the Raspberry Pi so that the entire GSW Adaptor can access heterogeneous sensing resources in the area.
Grace to the GSW Adaptor, not only can it connect with standard wireless communication protocols such as ZigBee, LoRA, RFID, Bluetooth, it is also compatible with the data transmission protocols such as ModBUS, ProfiBUS, RTP / RSTP / RTCP commonly. At the same time, it receives the request from the server (such as the sensor planning from the SPS. server), the acquired data provide to the SOS server, and the alert information is provided directly to the SAS server. (See Figure 4: Sensor Web with the GSW Adaptor). At this time, users can choose Wi-Fi, wired network, or wireless broadband to implement data transmission to the server.

Edge processing
Based on the integration of multiple wireless communication protocols and data transmission protocols, this GSW Adaptor can enable the sensors that are connected (Sensors Enablement), by configuring the edge computing equipment, the sensors are no longer just physical conversion elements (from Analog signal to Digital signal ), and they can process the signals and measurements. The signals and measurements are collected, processed, judged, and transmitted according to an individual strategy while achieving the required standards and meet the interchangeability of sensors in the GSW Adaptor. The edge computing equipment miniaturized; they can hide in the GSW Adaptor or not being aware of them. Importantly, low power consumption is incredible.
At present, in the process of development, our team has successfully realized the precise analysis and acquisition of water quality under Arduino (An open-source electronic prototype platform) using sensors fusion. We use a conductivity sensor to collect the conductivity of the water sample, a temperature sensor to measure the temperature of the sample, and implement calibration, measurement, and error correction through sensors fusion. Finally, a programmed Arduino can do calculations to get accurate water conductivity and make a judgment. The evaluation results present on a dot matrix LCD (the water quality is good, kind, medium, or bad). By installing a Bluetooth transceiver under Arduino, the enabled sensor can communicate with the acquisition module named Raspberry Pi (A commonly used edge computing device that looks like a credit card-sized microcomputer). We process the results from enabled sensors in parallel in the Raspberry Pi to achieve encapsulation of data processing has reached a predetermined standard, and it can realize the interchangeability of sensor data in the GSW Adaptor. (Mitsugu Terada et al., 2009).

Provide OGC standard-compliant interface
This system still bases on the OGC standards, and its core is still the framework of SWE (Sensor Web Enablement). It provides three information models: Sensor Modelling Language, Observation and Measurement coding (O&M), and Event description language, and four services specifications for Observation, Access, Planning, and Alerting of heterogeneous sensors (Chen et al., 2014;Peng and Zhang, 2004). Sensor Observation Service (SOS) refer to sensor systems, observations, and processing; Sensor Access refers to obtaining real-time and time-series observations using standard coding; Sensor Planning Service (SPS) refers to planning sensors to facilitate observations of interest; Sensor Alerting Service (SAS) refers to subscription and publishing information.

Experiment Design
We chose Baoxie Street, Jiangxia District, Wuhan City in China for relevant experiments and feasibility verification of the GSW Adaptor. Baoxie Street located in the east of Wuhan, Longitude 114°31'E, Latitude 30°28'N. It is defined as a new area of the city. There are plenty of green spaces, natural and artificial woods, and various types of soil and water resources. There are also communities, factories, and R & D centers of enterprises. It is typical of future cities. Figure 5 is a satellite image of the experimental area: In this experimental area, we have deployed some sensors that require solar energy and batteries to provide energy, and the installation locations are relatively scattered. To reduce the cost, share a power supply and network equipment, all of the sensors will be gathered at the same observation point and connected by cables. The disadvantage of this architecture is that we cannot arrange the appropriate type and number of sensors according to the actual situation. Virtually, at present, the technology of GPRS is almost eliminated. The sensor web under the architecture of the network is impossible to adapt to smart cities. Figure 6 is an example of this architecture of sensors. At present, we deploy a large number of sensors that work in low-power with the IoT protocols. We only need to consider the practical needs, such as the issue of temporal resolution, spatial resolution, and the data size of a single sampling. When deploying sensors, they will connect with the mode "Plug & Play" via the GSW Adaptor used in the community.
For example, residents who live in communities; real-time meteorological information is necessary for them. Thus, we only need to deploy wind speed, wind direction, rainfall, air temperature, humidity, and air quality sensors. In the zone of factories and enterprises, the air quality sensors and water quality sensors will deploy densely because the factories may have environmental pollution emissions. In the afforested areas, the sensors, such as soil temperature, humidity, and pH, should be installed. In addition to the above-mentioned in-Situ sensors, we have also deployed surveillance cameras equipped with gimbals and aerial drones in emergency cases.

Implementation of the system
Appearance: The architecture of the GSW Adaptor has introduced in Chapter 2.1. All the hardware of this device integrates into a box, and its appearance is similar to the industrial computer, likes Figure 7. The GSW Adaptor equipped with the x64 computer, radio transceivers, (embedded matrix antenna or external antennas is an option), and the modules of the microcontroller. The front panel equipped with switches, dashboards (dot matrix LCD), and status indicators in real-time. The upper panel installed with a high-resolution touch screen. The back panel has various connection ports for connecting external devices. Figure 7. Appearance of GSW Adaptor 3.2.1 Hardware: Briefly speaking, an x64-based PC and a hard disk array for data storage inside the GSW adaptor. The PC and the hard disk array are the core of the GSW adaptor. Permanently, the GSW adaptor also embeds wireless transceivers and matrix antennas for sensors via ZigBee, LoRA, RFID, and Bluetooth protocols, and the user can use external antennas according to the actual situation. These modules ensure that the adapter is compatible with multiple wireless communication protocols. Data messages received are processed by the programmed microcontrollers such as STM32 and A.V.R. Thus, they realize the acquisition control, protocol parsing, and data analysis of sensors data and their functions are equivalent to DAq (data acquisition) in the sensors' measurement chain. In the GSW adaptor, data exchange through a 5-port 10 Gigabit network card and a soft route (Routing Software) built in the P.C. The data will be transmitted to the GSW adaptor's computer through TCP / IP protocol. For the NB-IoT sensors under the wide-area network (WAN), we embed a Raspberry Pi in the GSW adaptor, which is a microcomputer that uses as edge computing. Raspberry Pi uses for data acquisition control, analysis, and processing of the sensors with NB-IoT protocol. Raspberry Pi will also use as the transceiver of the sensors' access via NB-IoT protocol. All radio transceivers and Raspberry Pi should be controlled by physical switches in the front panel or P.C. software of the GSW adaptor to control the access of sensors.

Software:
The software used for this GSW adaptor prototype includes the following three core modules. The first module is a soft gateway, which is used to access and aggregate the data transmitted by each platform and protocol to the GSW adaptor and can upload data and information to the server (SOS, SAS). It can also receive sensor planning information from the server (SPS). This module follows the OGC. international standard interface (Refer to Chapter 2.4). The second module is the data analysis and database. It analyzes data according to data transmission protocols (such as RTP, Mavlink, ModBUS.). This module will establish a database and save the data in local storage. The third module is the interaction between software and hardware. It is a visual program that can use for In-Situ sensor access control, sensor planning, and wireless access control, system diagnostic tools.

Multi-protocol access capability
Before the experiment, we tried to calculate the ideal communication distance of ZigBee and LoRA protocols according to the selected radio transceiver chips and antennas. The model of ZigBee transceiver chip, we decided ZM5168P2, which uses an antenna with a transmission signal (Tx) strength of + 20dBm and a reception (Rx) strength of -100dBm. According to relevant Chinese laws, 2405MHz was selected as the communication frequency for ZigBee. For the LoRA protocol, we chose the LoRa-02 chip from Vendor is named A.I.-Thinker, we use 433.92MHz as communication frequency, which uses an antenna with a transmission (Tx) signal strength of + 10dBm and a reception (Rx) strength of -105dBm. The calculation method of wireless communication distance when free space propagation is given here: The so-called free space propagation refers to the radio wave propagation when the antenna surrounds by an infinite vacuum, which is an ideal propagation condition. When a radio wave travels in free space, its energy is neither absorbed by the obstacle nor reflected or scattered. The communication distance is related to transmit power, receiving sensitivity, and operating frequency.
The calculation method of the ideal communication distance is as follows: [ ] = 32.44 + 20 lg( ) + 20lg ( ) where [ ] = the transmission loss, the unit is dB. = communication distance, the unit is Km. = communication frequency, the unit is MHz loss [Lfs] will increase by 6dB. Thus, in our experimental area, the sufficient communication distance of ZigBee may only be 620m, and the adequate transmission distance of LoRA is only 1900m.
For Bluetooth 4.0, it well knows that 10m is its optimal transmission distance. Because NB-IoT is dependent on the operator's network, the communication distance is infinite (in the area covered by the operator's network). Thus, we will not make estimates in this article.
We placed the prototype of the GSW adaptor indoors in the experimental area of Baoxie, and set antennas external. The GSW adaptor to WAN. Based on estimates and theoretical knowledge, the available communication range of ZigBee, LoRA, and Bluetooth and NB-IoT sensors was determined. The sensor of the Bluetooth Low Energy (BLE) protocol can be connected to the atmospheric environment sensor with a high sampling rate. The sensor can simultaneously acquire a large number of parameters, such as wind speed, wind direction, and air quality. The device placed close to the GSW adaptor, and the sufficient communication distance is 20m. In the experiment, there are two groups of sensors using the ZigBee protocol, which used to measure air quality, rainfall, air temperature, and humidity. There are real-time requirements and large data message capacity. It is valid under the condition of ensuring lossless data transmission, and the communication distance is 250m. Soil temperature and humidity sensor, soil pH sensor, and air dust sensor using LoRA protocol, sufficient communication distance is about 750m. At the same time, according to the necessity of scientific research projects, 30 sets of NB-IoT soil temperature and humidity sensors were deployed and connected. This communication technology depends on the operator's base station, and they can reach an unlimited communication range. They are possible to acquire the soils to cover nearby forest areas.
We tested radio access capabilities and the transmission distance of the communication. We verified data reception and data analysis on GSW Adaptor. Either in-situ sensor observations ModBUS / 1-Wire protocol transmission, or to a wide area network NB-IoT data transmission can be effectively received. The following Figure 8 is an example of the monitoring data of one soil moisture sensor.

CONCLUSION
We propose hardware named GSW Adaptor in Sensor Network Enablement (SWE), which based on the OGC international standard. It is a middleware between the data acquisition sensors (equivalent to the client) and the server. It has successfully solved the problem of unified access, real-time data acquisition, and processing in multiple sensing platforms via IoT interface protocols through the establishment of architecture like Edge -Middleware -Server. By solving this problem, we have broken through many technical difficulties. For example, we realize that heterogeneous sensors via IoT interface protocols are possible to plug into observation network fleetly, seamlessly and intelligently in a complex network environment. Then, we try to achieve real-time access, observation, edge processing for the heterogeneous sensors. At the same time, the data is encapsulated according to the OGC standard, forwarded the data to the server. The GSW adaptor can realize adaptive, bilateral control, network supported, software and hardware integration, and standardized shared observation. Its advantage lies in its powerful access capability and network stability. At least, we perform experiments on the prototype of the GSW adaptor about various access and performance. The results show that the GSW adaptor is a better solution for heterogeneous sensing platform access in smart cities.