Map coverage of LoRaWAN signal’s employing GPS from mobile devices

. Forests are remote areas with uneven terrain, so it is costly to map the range of signals that enable the implementation of systems based on wireless and long-distance communication. Even so, the interest in Internet of Things (IoT) functionalities for forest monitoring systems has increasingly attracted the attention of several researchers. This work demonstrates the development of a platform that uses the GPS technology of mobile devices to map the signals of a LoRaWAN Gateway. Therefore, the proposed system is based on concatenating two messages to optimize the LoRaWAN transmission using the Global Position System (GPS) data from a mobile device. With the proposed approach, it is possible to guarantee the data transmission when ﬁnding the ideal places to ﬁx nodes regarding the coverage of LoRaWAN because the Gateway bandwidth will not be fulﬁlled. The tests indicate that diﬀerent changes in the relief and large bodies drastically aﬀect the signal provided by the Gateway. This work demonstrates that mapping the Gateway’s signal is essential to attach modules in the forest, agriculture zones, or even smart cities.


Introduction
Protecting forests is an emerging issue worldwide, given the enormous importance of these ecosystems to the planet. The possibilities and challenges in developing a robust surveillance system are several. Portugal has the highest incidence of wildfires in the Mediterranean region [1]. Recent studies point out that, in the case of forest fires in Portugal, plans for macro-scale actions are already more than consolidated. These plans demonstrate that it is possible to mitigate fire damage considerably. However, according to [2], there is a perspective that only these macro plans are still insufficient to solve this problem. Therefore, there is a need for a thorough study of innovative technologies with the potential to intensify fire fighting or even create new plans on a micro-scale. In this sense, the new features inserted in Forest 4.0 can digitize regions to help combat teams in decision-making.
The project Forest Alert Monitoring System (SAFe) comes with the proposal to develop innovative technologies to allow efficient forest monitoring based on Internet of Things (IoT) technologies. For any IoT application, the study of device position and data transmission is essential to guarantee system efficiency [3][4][5][6]. Forests are generally remote, abandoned/unmanaged areas, hard to protect due to their characteristic of large dimensions, irregular lands, trees, animals, and other obstacles that can interfere the signal quality and, consequently, compromise the integrity and transfer of crucial information that guarantee the correct functioning of the system.
As the forest is remote areas with irregular lands, it becomes even more challenging to map the range of signals that implement systems based on wireless and long-distance communication. However, the interest in IoT functionalities for forest monitoring systems has increased the attention of several researchers. Motivated by the popularization of technologies such as LoRaWan and Global Positioning System (GPS), many researchers are concentrating on overcoming the difficulty in providing signal and communication guarantees between IoT devices. The use of Long Range Communication (LoRa) and GPS can be seen in [7], in which a forest monitoring system through flame sensors modules is presented. The system can predict and detect forest fire through a sensor (Flame Sensor Module YL-38) and send an alert message to the fire authorities. In this case, the Global System for Mobile (GSM) technology is used to give an alert signal through a cell phone, and the integration between the LoRa transmitter and the GPS systems allows the recognition of the fire location precisely. Another proposal of the LoRa module with GPS integration to forest fire monitoring system is shown in [8]. The system uses LoRa with a GPS hat module integrated into Raspberry Pi 3 to transmit and receive data using radio frequency communication. A set of flame sensor modules is used to detect fire, and through the system integration (sensor, LoRA, and GPS), it is possible to know the fire location, taking the coordinates data from the GPS.
Developing a platform that uses GPS technology from mobile devices to map the signals of a LoRaWAN Gateway can optimize the mapping. In this sense, the platform would use the mobile internet network (3G, 4G, or 5G) to inform the values of the coordinates (latitude and longitude). This process would prevent data from being transmitted via LoRaWAN, as they are data with many decimal places (e.g., 41.796289, −6.767479). Therefore, to not waste LoRaWAN transmission during mapping, the proposed system is based on the concatenation of two messages: a message from a mobile device's GPS and another from a device with communication-based on LoRaWAN. The proposed approach is expected to guarantee data transmission by finding the ideal locations to fix the nodes concerning LoRaWAN coverage. At the same time, it is keeping the Gateway bandwidth not fully occupied.
The rest of the paper is organized as follows. After the introduction, section 2 presents the related work. In section 3, the system architecture is addressed, and the focus of this paper is highlighted. Section 4 presents the mapping used to identify the LoRaWAN coverage area, and section 5 stresses the results of the proposed application. Section 6 concludes the paper and points to future work.

Related Work
The performance of any IoT-based system is intrinsically related to positioning issues. Since these systems depend on remote connection, it is essential to guarantee signal transmission and reception quality. Besides, in some IoT applications, such as forest monitoring systems, it is crucial to know the real device's position since this location will guide the fire-fighting actions. GPS has been widely used in IoT applications, however, the GPS technology is relatively expensive and has high power consumption, becoming unappropriated for long-range and lowpower IoT devices [9]. Communication technology that has increased more and more popularity in the IoT domain, especially for long distances communication, is the Low Power Wide Area Network (LPWAN), with a particular highlight on LoRa technology, which is a physical layer that enables the long-range communication link [10] with low power consumption [11]. The LoRaWan uses the LoRa spectrum modulation method in a communication protocol and system architecture for the network designed to support a large part of the billions of devices associated with the IoT [10].
Signal modulation in the LoRa architecture is carried out using the Chirp Spread Spectrum and is broadcast in unlicensed Industrial, Scientific, and Medical (ISM) frequency bands, which can minimize the cost of its use [12]. This frequency range is available according to the place of use, and in Europe, the frequency range available is between 863 MHz to 870 MHz [13]. In addition to the restrictions made, the frequency to be used is still necessary to obey a set of constraints like the transmission power +14 dBm, Duty-cycle < 1% and a Bandwidth of 125 kHz [14,15]. Another parameter that directly affects this modulation's distance and transmission quality is the relationship between the bit rate and the chip rate, and the Spreading Factor (SF). The SF can assume values from 7 to 12, and the higher the assumed value, the more the Signal-to-Noise Ratio (SNR), also increasing the sensitivity and the range of the packet, however, it also increases the transmission airtime [16].
Considering these restrictions in the article [17], the authors propose a new approach based on cloud-centric systems for automatically creating coverage maps in complex scenarios. To elaborate on this system, the authors use Laird's Sentrius RG186 gateway. The Microchip RN2483 is connected to a notebook to provide the GPS coordinates since the microchip does not have this capability as an end device. The used configurations were divided into three topics, better transmission confidence, wider range both with an SF of 12, and faster data rate with an SF of 7. The presented results in this paper solidify the need to carry out network mapping, demonstrating that the area coverage can be very uneven, with multiple barriers between end nodes and gateways hindering successful communications.
As the forest usually is large and remote, the LPWAN is the optimum solution for IoT device development. Although there are other LPWAN technologies such as SigFox, LTE, Random Phase Multiple Access (RPMA) and 5G that can be used in remote areas. The low-cost LoRa nodes and gateways led to the increment of its attraction, mainly in the area with difficult access. Additionally, compared to SigFox, the closest technology, LoRa can reach a higher Data Transfer Rate [11]. Once the LoRa signal can cover a wide area, it is essential to analyze the quality of the signal power available in the sender device's position and the receiver's position. The Received Signal Strength Indication (RSSI) receives signal power in milliwatts and is measured in dBm. This value can be used to measure how well a receiver can "hear" a signal from a sender [18]. Another critical parameter to be measured is the SNR, which describes the relationship between the received power signal and the noise floor power level [19].

System Architecture
The map coverage of the LoRaWAN signal is of great importance for systems that require a guarantee that they will be receiving the data at the LoRa gateways, thus being of greater or lesser importance according to which system will be applied. One of the LoRa network problems is to provide coverage in certain areas, as previously mentioned, in addition to the fact that there is no tool to map the network coverage points. This section will deal with which system this work aims to use and its respective architecture for tracking the LoRa signals.

SAFe
The SAFe project intends to integrate some tools that can work collaboratively and form the architecture of the system, illustrated in Fig. 1. The region that SAFe project intends to monitor is represented by A ○. A set of wireless sensor modules, represented by B ○ will be allocated on strategy points to collect data. The Gateway is represented by C ○, with an internet connection represented by D ○. The Gateway will receive the data from each sensor module by radio frequency communication, and then forward the data through a 4G/LTE link (or by Ethernet where available) represented by E ○ to a server represented by F ○. The received data by the server will be processed on the control center G ○, that computes the data and sends alerts for hazardous situations or forest fire ignitions to the surveillance agent in the region. The received data will also be stored and processed by artificial intelligence procedures to correlate data from sensor modules with external data represented by H ○; such as satellite image, local scale real-time fire hazard indexes, availability fuel content and weather data.
In general, the system proposed by SAFe can be divided into 4 main elements: I -the monitoring region, which involves the study of regions with a potential risk of forest fires, II -the set of sensor modules, where the sensor technical specification is considered and also the sensor positioning, III -the communication system in which the technologies that make it possible to receive and send data are defined, and finally the element IV -the control center, where the data are stored, processed and the decision are taken. Due to the complexity in the description and development of each one of these elements, this work will focus only on the study of the communication system, expressly, the study of the signal range provided by the Gateway. For this, it is necessary to map the region where the sensors may be installed, ensuring data transmission.

Overview LoRa Tracker
The LoRa mapping system presented here results from a combination of several free software programs, resulting in a graphical presentation of the coverage relative to a given LoRaWAN Gateway. The entire system was implemented using the programming tool Node-RED. It was necessary to import the location data and the data from the test module. Since this is a mapping system and considering that the test module is not equipped with GPS, it is necessary to use a mobile device equipped with these functions allied to the LoRa module.
Therefore, localization software must be used to obtain the locations with a specific time interval, thus enabling the configuration simultaneously with the data from the module.
For this purpose, the OwnTracks application was used; this is a free and open-source application that allows the location of mobile devices, ensuring various options for the time interval between locations. Once the exact location is obtained, it is also necessary to ensure the transmission of the module data to be able to interconnect the data and perform reliable coverage. In this way, The Things Network (TTN) application is used; this global community aims to build an open-source and decentralized LoRaWAN network. The following Fig.  2 shows the system's operation. As it can be seen, there are two sources of data import, the OwnTracks software for importing the location data and the TTN platform that guarantees data acquisition regarding the modules. Implementing the OwnTracks software in the system depends on the Message Queuing Telemetry Transport (MQTT) protocol, which will send the data from the software to the Node-RED program using mobile internet. The data obtained through the TTN platform will be further divided, taking into account its signal strength and its SNR, resulting in different colors depending on the power and the associated SNR.
The system is configured to allow multiple measurements on different hours or days, saving all data individually, thus allowing the user to choose whether to access the database in its entirety or only on a particular day. Next, the system's operation will be presented in more detail, from data acquisition to the map presented to the user.

Mapping
The literature demonstrates several types of tracking signals' transmission based on LoRaWAN technology, and most studies point to the use of a GPS shield inserted into nodes that perform the communication. Thus, this GPS shield will send the coordinates together with the LoRaWAN signal; that is, when there is some data transmission, the module sends the GPS location incorporated into the payload. When performing this tracking process, the user will consume a large amount of LoRaWAN's duty cycle (an example of fair use policy can be seen in [20]). After all, one of the variables that influence the accuracy of this tracking is the number of bytes used by the decimal places of coordinates. In other words, the user consumes a significant amount of bytes to transmit the floating points of the GPS location. This excessive consumption of the duty cycle leads to a high transmission interval during the tracking process (amount of sampling of transmitted signals); consequently, the identification of the transmission point can be affected. For example, if a device is installed on a truck with a 3-minute transmission interval, it may be that the truck is too fast to track at some points. In this case, by optimizing the sending of the location to increase the amount of sampling, the truck does not need to reduce its speed.
Considering the problem of excessive consumption of bytes when employing a GPS shield to perform the tracking of LoRaWAN signals, an alternative was sought to monitor the gateways transmission used in the SAFe project [3][4][5][6]. Therefore, the work's purpose is to use two devices to create the signal map coverage. Thus, one device is in charge of transmitting the data via LoRaWAN, and another device is responsible for informing the GPS coordinate using MQTT. In this sense, the flowchart shown in Fig. 3 summarizes the union of the data from these two devices. This process occurs in the system's first part, identified as Data Acquisition and Storage. On the other hand, the second part is named Monitoring and Updating of Data; in this step, the data stored in the previous process is read and published in a dashboard. The first device is namely the node that transmits data via LoRaWAN; for this approach, a node adapted from [4,5] was used. As it is only necessary to obtain the LoRaWAN transmission at a certain point, this node has been adapted to send only the battery levels. Thus, during the creation of the map coverage, the proposed approach consumes 2 bytes of payload transmission. The second device, responsible for sending the GPS location is a Galaxy Tab A7 tablet model SM − T 505 from the manufacturer Samsung. It was chosen for bearing: Android operating system (compatible system to install OwnTracks) and having access to the internet via WiFi and 4G LTE (these networks can be used to receive GPS locations through MQTT). Note that any other device could replace the second device with internet access and support for the OwnTracks application.
As previously mentioned, the system is developed to work on the Node-RED platform. In this platform, to generate the map coverage, all data (GPS location and LoRaWANs' transmission) are acquired, stored with the support of InfluxDB, and viewed through the Node-RED dashboard. Therefore, all data concerning location, module data, and the conjunction of these two are saved in different databases. The Monitoring and Updating Data is done using a world map implemented in Node-RED, the plugin Worldmap, where all the acquired data is placed, resulting in a map that combines not only the validated data according to signal strength and SNR but also the GPS data where there is no coverage. This way, it will be possible to elaborate a more specific coverage map facilitating the implementation of any system that uses LoRaWAN transmission. Fig. 3  ○: a function is dedicated that guarantees the correct acquisition of the payload for a given Gateway (named by TTN as gtw id). In other words, verify if the transmission was performed by the Gateway in focus, then the data will be saved in the LoRa database created in InfluxDB. These data are Airtime, Channel, Frequency, Gateway Altitude, Gateway Latitude, Gateway Longitude, Payload, RSSI and SNR.
-Wait LoRa Signal and Join the Payloads 5 ○: Buffer the last message provided by the tablet's GPS until a TTN message appears. Then, these two messages are grouped and checked if the values are different from null.
-Gateway coverage 6 ○: saves the final message in the Tracker database created in InfluxDB and executes the information available to the Worldmap dashboard.
After the acquisition of all data and its storage, it is always necessary to maintain the coverage map updated. For this purpose, the second part Monitoring and Updating of Data is dedicated (Fig. 3): The code implemented in Node-RED to perform all the steps detailed above can be seen in Fig. 4.

Results
As mentioned before, a module based on SAFe project [5,4] was used with some adaptations and a tablet Tab A7 Galaxy model SM-T505. In this sense, it is possible to validate whether the platform developed in this work can perform the coverage map of the LoRaWAN network of the SAFe project. With these two devices, it is expected that the LoRaWAN network coverage mapping is identified through the adapted module's communication and the sending of messages of the Tablet's GPS location. These two devices should always be as close as possible to each other so that the mapping has better accuracy when both send the information.
The mapping will be focused on analyzing the quality of the LoRaWAN signal provided by the Gateway RAK 7249 installed on the roof of the Escola Superior de Tecnologia e Gestão de Bragança (ESTiG) -Polytechnic Institute of Bragança (IPB). Therefore, only the data obtained by this one will be accounted for in generating the map, ignoring others in the area. This Gateway contains the default settings for 16 channels; that is, the two concentrators are enabled and configured to operate between 863 MHz to 870 MHz. As previously mentioned, the node used in this test is only configured to send the battery level information. This configuration was chosen only to optimize the sending of messages during the test; in other words, not to occupy the Gateway's duty cycle too much and increase the sending time interval. Therefore, the time interval for this node is 30 seconds. On the other hand, the tablet has the OwnTracks settings recommended by default, except for the location sending interval. This interval is set to send the current coordinates every 100 meters or every 30 seconds. Before starting the test, it was verified that all databases were empty, as shown in Fig. 5. Then, a button to refresh the map by request is created, and a possibility to set an automatic time to update the map. The first test was carried out around the Gateway RAK 7249, which implies the two devices were carried by a person walking approximately 500 meters away from the Gateway. Fig. 6 demonstrates the result obtained in this LoRaWAN signal coverage map, where it is possible to see the person's trail represented with a human symbol. A blue line was designed according to the signal strength when there was a simultaneous combination between the two communication signals (GPS location and LoRaWAN signal). The blue coloration was established according to Table 1, where nine levels of sizes and blue colors range from −85 dB to −125 dB (RSSI). These values are obtained through LoRaWAN communication, as the TTN service informs communication quality data and the message payload. Each blue line is created with a Euclidean equation from the position of the Gateway to the two devices, and the pixel size gives its thickness in the Worldmap. Another test was performed to determine the coverage of the LoRaWAN signal, named the second test. Fig. 7 demonstrates the LoRaWAN signal coverage map in this test far away, almost 2000 meters from Gateway, where it is possible to notice that some points of the trail did not have LoRaWAN coverage (the regions where there is no blue line with the human symbol). The third test was dedicated to the outskirts areas of the city to identify how the signal coverage behaves in regions with less construction density. The furthest point of the track was approximately 2200 meters in a straight line with the Gateway. It is possible to notice through Fig. 8 that there are more blue lines than in the previous test. The last test was conducted in rural areas close to the city center, so a car was used to perform the trail. The furthest point registered was approximately 11000 meters in a straight line from the Gateway. As Fig. 9 shows, there was good quality communication compared with the previous measurements. In this case, the terrain relief contributed to the transmission between the module and the Gateway since the area is 1320 meters altitude (from the sea).
After completing all tests, it is clear that some regions in the city center of Bragança have low or even no connectivity with the Gateway (as shown in Fig. 7). On the other hand, other peripheral regions to the city center have good coverage (Fig. 8). According to the manufacturer, factors such as the ground relief, the density of buildings and trees, and even the positioning of the Gateway can influence the signal quality. Therefore, three zones were chosen around the city of Bragança to test the developed platform with the static LoRaWAN Gateway (any positioning of the Gateway was modified to improve the transmission signal during the tests). This choice was based on this work's main objective: to develop the map coverage platform without excessively consuming the bandwidth of the LoRaWAN Gateway.

Conclusions and Future Work
IoT applications are increasing daily, but one of the most critical requirements is communication, sometimes remote and wireless transmission. This paper presented a GPS-based system to map the coverage of the LoRaWAN signal. In fact, it combines the localization information with the LoRa signal strength allowing to identify the lack of signal zones. It is a tool mainly developed to plan the installation of fire detection modules developed in the SAFe project. Although, the proposed approach can be used in different areas, such as agriculture and animal tracking, among others. Results are beneficial in a real experiment validation since the modules' installation coordinates can be automatically affected, and to optimize managing the fire detection areas. Future work direction can be pointed out using this developed tool to optimize the Gateway positioning in other projects depending on the terrain and environment characteristics.